Jump to content

itman

Most Valued Members
  • Posts

    12,102
  • Joined

  • Last visited

  • Days Won

    319

Everything posted by itman

  1. Since you already did a Win 10 reset install and the issue still persists, do the following. At least, this will stop the Eset alerts for the time being and allow for hopefully, identifying which process is performing this activity. 1. Go to your Eset Filtered Web Sites log and search for all long entries related to amanda.run netc. Make a note of all IP addresses associated with the log entries. Hopefully, they are all the same IP Address or only a few. 2. Create an Eset firewall rule to block; i.e. "Deny", "TCP and UDP protocol", and Direction set to "Out." Name your rule something meaningful. Set Logging Severity to "Warning." Do not checkmark the Notify user option, since this will keep giving you alerts. Click on the Remote tab. Navigate to the window labeled IP. Enter each previously noted IP address. If entering multiple IP addresses, enter a comma after the end of the address, a space, and then the next IP address. Do not enter a comma after the last IP address entered. Click on the "OK" tab and every "OK" tab thereafter to save you newly created firewall rule. Once a few Eset Network log entries have been created from this firewall, copy those entries and post them into your next forum reply. Hopefully, this will point us to what process is performing this activity.
  2. You will have to wait till @Marcos or someone else from Eset comments on this.
  3. I also suspect your issue has something to do with the domain controller environment. What it could be I have no clue since I am not familiar with Eset's File Server or ERA; don't know what you use.
  4. Yes. Or, the result shows "OK." Anything highlighted in red Is a failure.
  5. Now I know what is going on with the https://badssl.com/dashboard/ test. I disabled Eset's SSl/TLS protocol scanning and passed all the tests using IE11; including the SHA-1 test I failed when SSl/TLS protocol was enabled. So Eset has a problem there. Bottom line - the only alerts you should receive from this test are Eset alerts. This test was set up primarily to test that AV's that perform SSL/TLS protocol scanning, do it correctly.
  6. Browser alerts when the baddssl.com test was running. You already stated you didn't receive any eset alerts.
  7. That is very strange indeed. Especially since Eset's root CA certificate is installed in Chrome's corresponding root CA store. Obviously, something blocked the connections since you passed all the tests; i.e. "cannot connect." Did you get any other alerts from the browser's themselves about an untrusted certificate when the test was running?
  8. Passed all the tests except for SHA-1 Intermediate of which IE11 shows a few including Microsoft's. What about a Comodo code signing cert? Should I get rid of that one?
  9. Some more info on FireFox send: https://blog.malwarebytes.com/cybercrime/privacy/2019/03/mozilla-launches-firefox-send-for-private-file-sharing/ In other words, this is the same as sending/receiving encrypted e-mail via e-mail client. Eset SSL/TLS protocol scanning can't scan the encrypted FireFox send files because it has no access to the public key used to unencrypt the files.
  10. FireFox Send is new. My take on it is, it's basically an encrypted cloud file sharing service. Conceptually similar to how client e-mail file transfer works. It may very well be that Eset SSL/TLS protocol scanning doesn't work with FireFox Send downloads from Chrome; I assume that was the browser you were using. Personally, I wish Eset kept the network adapter mini-port filter driver approach for SSL/TLS scanning which would ensure everything downloaded is scanned. Ref.: https://blog.mozilla.org/blog/2019/03/12/introducing-firefox-send-providing-free-file-transfers-while-keeping-your-personal-information-private/
  11. Thinking a bit more about this if packed, encrypted, or obfuscated malware exists in an archive, Eset or any other AV scanner is not going to be able to detect it until the archive is extracted. And if its a script, not until it is executed via AMSI examination. Which brings up the issue of those nasty bundled Python engine and script .exe's.
  12. Doublechecked startup and module update scan parameters. They only scan select files and areas. Looks like I have to ponder this disk archive scanning after file creation a bit.
  13. If I recollect, the Endpoint line has a minimum seat licensing requirement; 5 licenses is the minimum I believe? I asked about the possibility of a single Endpoint license some time ago, and never received a response to the question.
  14. True. But being the default scan profile, it would be deployed in Eset's startup and module update event scans. The question is if the User Download directory is scanned by those?
  15. I assume this is because SmartScan default Is not set to scan archives? Setting SmartScan to do so I assume would then scan all archive types?
  16. Yes, it indeed does. You can use this web site to verify Eset's downloaded archive scanning: https://www.amtso.org/feature-settings-check-download-of-compressed-malware/ . It will/should detect every download prior to hitting your disk. However, the AMTSO archived payload is the EICAR file. FortiGuard likewise has a similar test here: http://metal.fortiguard.com/ . Eset scores 17/18 on this test only failing the password protected archive test. Again and unfortunately, the test payload is EICAR. By any chance are the malware files in the archive packed, compressed, or obfuscated? Eset's web scanner might not be able to detect those until they fully "decloak" which might only occur after disk file creation and extraction from same.
  17. It has already been shown that the other poster with this issue had traces of Comodo installed. You have already posted you are "always testing new browsers." Even if uninstalled, it is possible Eset is detecting their traces. Ditto for multiple versions of FireFox installed and then subsequently uninstalled. Finally, I would not install any browser other than IE11, Edge(official release), Chrome, or Firefox when using Eset.
  18. This is just a replacement for using your existing ISP DNS servers. More public DNS servers are given in this article: https://www.lifewire.com/free-and-public-dns-servers-2626062 . Eset's default firewall DNS rules will connect with whatever public DNS servers you specify for your existing Windows network adapter connection. As such, nothing additional needs to be added to existing Eset software.
  19. The problem with Eset as I see it, is it is a "bit too accommodating" in regards to attempting to add its root CA certificate in browsers when there is an existing configuration issue in regards to a particular browser. It should have issued an "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO xxxxxxxxx BROWSER FAILED" alert, logged the same, and thereafter stopped trying to perform this activity. Eset should also create a knowledge base article in regards to the above alert stating that there is a configuration issue with the browser preventing Eset from installing its root CA certificate. Eset might also want to consider developing a "clean" utility for both Firefox and Chrome that would uninstall all traces of both. The knowledge base article would then instruct the user to download and reinstall the latest version of FireFox or Chrome. My understanding is Mozilla will be soon implementing a change to Firefox that will start using the Windows root CA store either in place of or as supplementary certificate retrieval to its own root CA certificate store. In regards to the later approach, it has existed as an option since FF49 version for Enterprise environments. However, it required reconfiguration of Firefox settings that are beyond the scope of the average PC user.
  20. BTW - which Eset Event Log was full of these entries; no one ever mentioned that? Also a posting of the actual event log entries would have been helpful.
  21. Both IE11 and Edge use the Windows root CA certificate. I have no idea what this new Edge Chromium based browser uses, but expect the same for that. If you're referring to FireFox nightly as the current ver. downloaded from the Mozilla web site, that is the version to install. You would first have to remove all traces of existing FireFox versions installed prior to this. No need to uninstall Eset; at least at this point. As far as full SSL/TLS scanning support for browsers other than IE11, Edge, Chrome, and Firefox, I am unsure. I would think it would at most mirror the scanning currently performed for non-browser processes. For example, I would imagine that Eset would not be able to inject its root CA certificate into those browsers associated root CA certificate store if so deployed. If one was using the Pale Moon browser for example and it did not use the Windows root CA certificate store, I assume Eset would ignore it as far as trying to create its own root CA certificate in Pale Moon. However, having a like non-supported Eset browser installed might be one reason for Eset's "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO ALL KNOWN BROWSERS FAILED" alert/log entry.
  22. Be careful of OSArmor. Its kernel mode driver has had past issues with Eset; namely the HIPS but new protentional conflicts could be with AMS and the new deep behavioral inspection protection. Also, OSArmor doesn't always uninstall cleanly and completely. This plus the fact the software is developed and maintained by a small developer has lead me to the believe it is not needed with Eset. I do use some its "living of the land" protections in equivalent Eset user HIPS rules.
  23. Have no idea since I haven't used MBAM for years. Like any realtime scanner, it shouldn't be installed as such on any PC using PCMatic, Eset. or any other realtime AV solution.
  24. To begin with, I have never had FireFox installed on any Win 10 build on my PC. It currently has x(64) 1809 installed. As such, I have no old and possibly borked Firefox files and registry entries from prior versions of it, etc.. To get to the bottom of this current FireFox baloney in regards to EIS 12.1.34, I went to the Firefox web site and downloaded and installed it. I believe the current ver. is 66. I then opened FireFox and checked what certificates were stored in its Authorities certificate store. Eset's root CA certificate was not there as expected. I then rebooted the PC to try to simulate the behavior posted in this thread; namely if "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO ALL KNOWN BROWSERS FAILED" alert/log entry would manifest. It did not. I then again checked what certificates were stored in its Authorities certificate store. Eset's root CA certificate was there as expected: Finally, I rebooted again to see if I could see if Eset would created the "AN ATTEMPT TO ADD THE ROOT CERTIFICATE TO ALL KNOWN BROWSERS FAILED" alert/log entry. It did not. All this leads me to believe that whatever is causing this behavior on user's PC's has nothing directly to do with the Eset installation but rather, some misconfiguration issued with their current Firefox installation. I would advise uninstalling Firefox, clearing out all past remnants of it on your OS installation, and rebooting. Then install the current version of Firefox from the Mozilla web site and repeating the installation steps I posted above. As far as running development or beta versions of Firefox concurrently with Eset, you do so at your own peril; just like if you were running a pre-release ver. of Win 10.
×
×
  • Create New...