Jump to content

itman

Most Valued Members
  • Posts

    12,231
  • Joined

  • Last visited

  • Days Won

    322

Posts posted by itman

  1. Use the uBlock Origin add-on in Firefox and almost all ads and other undesirable stuff will be silently blocked. Hence, a drastic reduction in Eset alerts about the same in FireFox. Also if Eset alerts keep appearing when using uBlock Origin, it would be a strong indication that Firefox is compromised in some way.

  2. 1 hour ago, peteyt said:

    Off topic slightly what is the best and easiest way to prevent windows telemetry and do you think this should be something security programs should try to prevent/block or is it beyond what they should do? 

    Win 10 is the main OS that introduced OS telemetry on a level previously unheard of. As far as Win telemetry goes, some of the concerns are  well founded whereas others boarder on paranoia.

    Microsoft designed Win 10 to "be chatty" that is, to provide constant feedback to its monitoring servers. "It's the nature of the animal" so to speak and nothing is going to change that abet direct government intervention against Microsoft. As far as security software getting involved with this, it is frankly out of the scope of what they were designed for. The assumption here is whatever Microsoft is doing telemetry wise is per se legit activity. At least whatever they are doing isn't malicious in intent.

    Whereas it is possible to "harness" Win 10 telemetry manually, the easiest and safest was to do so is by using third party software designed for this purpose. I use O&O Shutup10: https://www.oo-software.com/en/shutup10 and run it using the default recommended settings. These will block most of the objectionable telemetry activities and leave it place the telemetry activities Win 10 needs to function properly. Assumed is some of these allowed telemetry activities do have purposes other than just legit system activities. Remember that Microsoft provided the Home version for free. In the real world, there is no such thing as a "free lunch."

  3. Some further info on Telnet. Port 23 is not the only port used. Port 107 is used by Remote Telnet.

    Also there is a way to shut down all Telnet activity using the Eset firewall. You would have to create a firewall rule to block all inbound and outbound activity specifying the protocol as "Custom" and the protocol number as 240 - 255. In other words, 15 firewall rules would be needed since the Eset firewall only also one protocol number to be specified per firewall rule.

    Ref.: http://www.networksorcery.com/enp/protocol/telnet.htm

  4. The Win Server versions vulnerable to this are noted below. The question is how many Eset installations have applied it? And it is a Remote Desktop Services vulnerability:

    Quote

    Microsoft has released patches for Windows 7 and Windows Server 2008, along with Windows XP and Windows Server 2003, which are no longer supported. Windows 8 and Windows 10 are not affected. Users of Windows 7 and Server 2008 can block unauthenticated attackers from exploiting the flaw by enabling Network Level Authentication (NLA). The threat can also be mitigated by blocking TCP port 3389 at the perimeter firewall.

    https://www.securityweek.com/wormable-windows-rds-vulnerability-poses-serious-risk-ics

  5. To be 100% accurate in regards to telnet is the following. The telnet client is not installed on Win 10 by default: https://www.rootusers.com/how-to-enable-the-telnet-client-in-windows-10/ . As noted in the article if the telnet client is installed, any port can be used by it; not just port 23.

    When router's reference telnet, they are just referring to its default use of port 23. Disabling the telnet option on the router is just blocking all inbound/outbound WAN side port 23 TCP/UDP traffic to/from the router.

    When the router is set to bridge mode, you are  instructing the router to pass all inbound and outbound traffic through the WAN side of the router. All firewall, IDS, and protocol filtering methods on the router are disabled. Additionally, both NAT and stateful transmission detection are also disabled on the router. As such, you are now relying 100% on Eset's firewall for port 23 protection. Whereas Eset's firewall will block an unsolicited inbound port 23 traffic by default, such is not the case for any outbound port 23 traffic. By default, Eset allows all outbound traffic.

  6. On ‎5‎/‎18‎/‎2019 at 6:16 AM, PERRYGOGAS said:

    I found it with WiperSoft.

    As far as this software goes, it's a PUA:

    Quote

    What is WiperSoft?

    The Malwarebytes research team has determined that WiperSoft is a "system optimizer". These so-called "system optimizers" use intentional false positives to convince users that their systems have problems. Then they try to sell you their software, claiming it will remove these problems. More information can be found on our Malwarebytes Labs blog.

    https://forums.malwarebytes.com/topic/240472-removal-instructions-for-wipersoft/

  7. 12 hours ago, TomFace said:

    What I'll probably do is update my log maintenance so as to not have so many logs just sitting there.

    Don't believe it's due to log entry volume, but you can look at your existing Eset scheduled log maintenance task and verifying that it is running probably. My best guess is the log file got corrupted somehow. Chalk it up to one of those "s*!t happens" Windows happenings.

  8. Referring to the first two postings in this thread, browser ad and JavaScript blocking extensions and the like would not have prevented this activity.

    It appears something was installed manually. It could have be standalone software. If it was then the following were applicable:

    1. The software was installed prior to Eset being installed.

    2. Eset's PUA protection was/is not enabled.

    3. Eset's PUA detection was ignored and the poster allowed the software installation.

    Another possibility is the poster either explicitly or inadvertently installed a browser extension that contains the javacript code being detected.

  9. Microsoft extended support for XP embedded versions just ended on 4/9/2019.  I assume that was one factor.

    Also "in a blast from the past" when MS introduced Win 7, they offered a downgrade option from devices with Win 7 installed to XP for a limited time. This in effect extended XP support on those devices to the end-of-life date for Win 7; i.e. Jan., 2020. The requirement for this was:

    Quote

    The downgrade rights are available only from OEM copies of Windows 7, those that are pre-installed by computer

    https://www.computerworld.com/article/2519032/microsoft-extends-windows-xp-downgrade-rights-until-2020.html

    So technically speaking, Win XP is still support abet in a limited scope.

  10. 7 hours ago, kamiran.asia said:

    These 2 servers are working about 1 Year and ESET were working probably , This Problem accrued suddenly.

    So we think they could not use sysprep recently.

    It is very possible that a recent Win Server OS update is causing this issue. This seems reasonable to me since as you stated, the problem manifested recently and is affecting multiple servers.

    You really need to contact Microsoft about the IMAGE_STATE _UNDEPLOYABLE issue.

  11. 32 minutes ago, Rami said:

    It blocked the install because CCleaner installer was doing some 'suspicious' activity to the Registry

    It probably detected this:

    Quote

    Considering that CCleaner is configured to run as a startup application by default, this means CCleaner could be communicating with CCleaner servers without you even realizing it.

    https://helpdeskgeek.com/free-tools-review/why-you-shouldnt-download-ccleaner-for-windows-anymore/

    As this article and others like it state, you shouldn't be using it in the first place.

  12.  Here's a Sophos posting where the OP was having SSL protocol scanning issues in an AD environment: https://community.sophos.com/products/unified-threat-management/f/web-protection-web-filtering-application-visibility-control/47035/certificate-warning-with-https-set-to-url-filtering-only#pi2353=1 . Since I am not knowledgeable when it comes to AD usage, what I gleaned from the postings was the issue had something to do with option to use AD certificates versus client certs. on Internet traffic.

    What is needed here is someone using EES in an AD environment to "chime in" here.

  13. Refer to Eset's default firewall rules. 

    Assuming you have made no modifications to those by changing default services settings, Eset's firewall doesn't monitor multicast DNS UDP traffic at all. That is; protocol is UDP, port is 5353, and IP address is 224.0.0.251. What it does monitor is local-link multicast UDP traffic; i.e. IP address 224.0.0.252.

    Additionally, Eset's Web Filtering protection only monitors port 80/443 traffic as far as I am aware of.

    Therefore as I see it, Eset cannot be the cause of any external network slowdown activity that's routing its traffic via multicast DNS connection.

    -EDIT- Another "tibit" in regards to mDNS UDP port 5353 traffic is that its used as a backup DNS mechanism if Windows has difficulties connecting using normal port 53 UDP DNS. Of course this implies that Microsoft can use it for its nefarious telemetry activities in Win 10. Again, the hourly activity element is a dead giveaway of Win 10 telemetry activities. I observed it also until I started using O&O Shutup 10 to block most of Win 10 telemetry.

  14. 1 hour ago, Potattoo said:

    Oh thanks a lot!But some of them has  question marks on it?

    Refer to this article for further information: https://support.eset.com/kb6268/ .

    I use a Public profile and hence, this Eset feature is not applicable. As such, I can't help you with any questions in regards to it.

    Also this feature is for scanning one's router connections. If you don't use a router, this feature is non-applicable.

  15. Also as I again understand it on Win 10, an app with an expired cert. will be flagged by UAC:

    Quote

    On the other hand you might find yourself in a perfectly valid situation where you’ve downloaded the drivers for a file directly from the manufacturer website and they simply won’t run properly on Windows 10 because of technical (but not malicious) problems like an expired or improperly applied certificate

    https://www.howtogeek.com/230063/how-to-circumvent-this-app-has-been-blocked-for-your-protection-to-install-apps-in-windows-10/

  16. 2 minutes ago, Marcos said:

    as long as there is a timestamp (countersignature), the digital signature remains valid if the certificates used to sign the file already expired.

    If its not countersigned, the cert. will show as expired as is my understanding.

  17. I didn't realize the OP was referring to the cert. for the Eset Installer download.

    I don't have a downloaded copy of the current installer, but will show a screen shot of the Eset cert. use to sign ekrn.exe. As @Marcos posted, as long as the it shows that the cert. is valid on the download .exe, there is nothing to be concerned about:

    ekrn_cert.thumb.png.1887de496b018728c071b1b76ac04d2e.png

     

×
×
  • Create New...