itman

Hum ........... Eset looks like we have a problem; at least in ver. 8. I have SSL 3.0 disabled in IE 11. Yet, I can connected to this Bank of India web site that only supports SSL 3.0 as shown below with Eset SSL protocol scanning enabled. I also tried excluding this web site from SSL protocol scanning and could also connect to the site w/o issue. I also checked the registry key associated with this i.e. "SSL3Fallback" and it is properly set. Appears SSL protocol scanning is interfering with the browser's protocol fallback capability.

I assume the version of IE you are using is IE 11? Effective April, 2016, MS updated IE 11 to no longer support the SSL 3.0 protocol: https://blogs.microsoft.com/firehose/2015/04/15/april-update-for-internet-explorer-11-disables-ssl-3-0/ The web site in question uses the SSL 3.0 protocol which is an insecure method for doing encrypted communication. So you are going to have issues connecting to any site using SSL 3.0 protocol with IE 11. I assume you have manually reset IE 11 to allow communication with the SSL 3.0 protocol? Please note that Eset nor any other security solution's banking protection will protect from threats that can exploit use of insecure protocols. Additionally, it is not uncommon for web site servers to downgrade to a lower SSL/TLS protocol when connection issues arise. By allowing the browser to use the SSL protocol, it is possible your connection could be downgraded to SSL 2.0 protocol. If that occurs, Eset will block the connection. By default, Eset does not allow SSL 2.0 connections.

I just ran a QUALS test on this web site. There are major security issues with it. This might explain why Eset's secure browser is having an issue with the web site. Personally, I would not do any online banking at that web site.

It's a denial of service attack as noted here: https://security.radware.com/ddos-knowledge-center/ddospedia/tcp-flood/ Question is why was that smartphone connecting through your network? Letting the phone connect through your router is a no-no.

Probably the worst new feature added to ver. 9 is the Network Troubleshooting Wizard; namely the logging of blocked connection activity. I know the intent of the feature was well intentioned. However based on the number of postings in the Forum on normal and benign blocked activity, appears Eset has created a reporting mechanism totally unsuited for the average non-technical user.

I has blocked the ESET Service two times in 5 days now. I guess I should have originally stated that occasional blocked activity is normal and nothing to worry about. Again, this is usually caused by network initialization issues that often occur at boot time or when resuming from sleep/standby mode,

I would listen to Marcos and ignore what is posted Trouble Shooting Wizard unless you have having Internet connection issues with one or more applications. For example, IP address 91.228.166.16 is associated with Eset. The blocked activity noted probably occurred because of a network "glich" during Eset update processing. Things like this happen on occasion and is perfectly normal. Now if there are persistent and repeated failed Eset update issues, then the problem needs to be investigated.

I would say you don't have a problem since it only occurred once. This type of block activity most likely occurred because your PC connection to the Netgear router wasn't fully initialized when Eset tried to connect to the Internet for updates and the like.

https://www.selabs.uk/download/consumers/january-march-2016-consumer.pdf

I downloaded the Bluecoat cert. per MS blog instructions and manually revoked it so I am good to go on this issue.

As far as a behavior blocker, Eset uses a HIPS. You cannot have both a behavior blocker and a HIPS employed is a single security solution since they will conflict with each other. As far as suspicious packed file protection goes, it depends on the degree of packing employed. "Loosely" packed files can be detected by Eset's DNA sigantures and possibly blacklist of the hash. For densely backed and obfuscated files, Eset's advanced memory scanner will be employed once the file has been uncloaked in memory which by definition is post-execution detection. The only real way of knowing if the process was malicious pre-execution would be to run it in a full sandbox application.

Check to see if "gammer mode" is enabled in Eset SS. If not, enable it and see if that resolves your game playing issues.

Excluding your trusted subnet, DNS traffic is always received via port 53. How did you determine that this traffic was DNS based and originated from your ISP? Please copy the related blocked entry from Eset's personal firewall log and post same. Or post a screen shot of the alert you are receiving.

The real-time scanner does limited virtualization as I understand it. I too would like to see a permanent sandbox added and all Internet facing and e-mail client apps added to it by default. When the app shuts down, all non-user saved downloads e.g. browser temp files, etc. are auto deleted. This is the safest and easiest way to prevent malware; especially the every increasing packed and obfuscated type let alone the ransomware scourge.

More and more malware these days is being downloaded packed and obfuscated. This type of malware is designed to only unpacked and un-obfuscate after it has been loaded into memory i.e. started execution. Since the malware is packed on download, conventional signature based methods cannot detect it in that state. What Eset's AMS does is detect the unpacking activity and then scans the malware in memory using its DNA signatures. As is explained in Eset's write up on AMS, it is post-execution detection. As such, there is a chance that partial infection has occurred. HMP-A is first and foremost anti-exploit software that over time has expanded its scope to include other protections such as for ransomware and the like. Exploits attack allocated process memory by heapspraying and the like. They also attack kennel table areas and the like. Note that malware packing is not an exploit technique. Exploits need a vulnerability.

I would try the following: 1. Disable Eset's advanced memory scanning. Try to open Chrome. 2. Disable Eset's exploit blocker. Try to open Chrome. If Chrome runs successfully with either of the above disabled, we have identified the source of problem. Next, as an interim solution disable Chrome's sandbox feature. Important: make sure to re-enable Eset's advanced memory scanning and exploit protection. Finally, start Chrome with the sandbox disabled and see if runs OK with Eset's AMS and exploit protection enable.

A far as context menu scanning goes, make sure the its setting is enabled as shown in the below screen shot. Note: screen shown is for ver. 8. You need to use like setting in ver. 9.

I would love to see a "Win Update" mode added to the HIPS. Would temporarily disable all user rules for 15 mins or so until updates could install without alerts.

When dealing with "iffy" .exe downloads such as video ones, scan the file at VirusTotal: https://www.virustotal.com/ . This will give you 60+ "opinions" on if the file is malicious.

Might be an issue with SSL protocol scanning as noted in this article: hxxp://support.eset.com/kb3487/ . Note article is for ver. 8 so you will have to find like settings in ver. 9 if your using that ver.. Scroll down to section II in the article and follow the steps given there.

How about adding the ability to perform SSL certificate pinning validation without enabling SSL protocol scanning? Believe this would be easy to do by using the existing excluded SSL certificate processing. Allow the feature to be enabled when SSL protocol scanning feature is disabled. Users would manually select SSL certificates as done presently using the "excluded/pinned certificate" option. Eset would add an option for certificate pinning checking only. This option could only be enabled if SSL protocol scanning was disabled. When Eset detects the certificate pinning option enabled, it would know to perform the web site to root CA certificate thumbprint validation check only. This would enable Eset to provide EMET like certificate pinning protection w/o having SSL protocol scanned. That way users could still be protected against man-in-the-middle and phishing attacks on HTTPS web sites. Also this option should be added to ver. 8 and above.

Have you checked to see if Eset's icon is not located in the "hidden icons" area? Click on the "up" arrow symbol located on the bottom toolbar toward the right edge of the desktop. If its there, just drag it to the lower right toolbar area.

I haven't tried ver. 10 yet. However, wouldn't just switching to Public Network setting at work solve your problems?

Yes, that is normal Win OS behavior. Explorer.exe is a shell that runs at startup which controls applications that interact with the desktop. Equi.exe does so by use of a toolbar icon and communication to the desktop using alert pop-up windows.

Glad you showed the registry transversal. People have to be careful to code "*.*" and not just "*" if they want the rule to apply to all subordinate primary registry keys. Another thing I found out through testing is the HIPS "start new application" option is pretty comprehensive. It will detect any PE regards of what suffice might be employed e.g. .txt, .tmp, .scr, etc.. However, I don't believe it detects scripts e.g. .ps1, .js, .vbs, etc..