itman

Not on my like ver. build. This is why I reported the status initially. Ref.: https://forum.eset.com/topic/20040-ssltls-scanning-port-assignments/

I would say presently this is the best approach till Eset definitely resolves why this port range specification was added. And again, I informed about this previously and it appears no action was taken at that time. Note that Windows internally sends encrypted data various ways other than by port 443 and it is likely that communication may silently being blocked. One possibility is that the 0-65535 port range was added for non-HTTPS scanning use and Eset internally is erroneously using it instead for also HTTPS scanning.

@Marcos refer to this bleepingcomputer.com where Kaspersky users are having the same issue: https://www.bleepingcomputer.com/news/security/kaspersky-av-having-certificate-conflicts-with-google-chromecast/ . Appears Chromecast is using a self-signed cert., select IP addresses, and most importantly port 8009. I believe this might be related to my prior post where I noted that SSL/TLS protocol scanning was defaulting to scanning all ports. Folks, as a test make sure Eset SSL/TLS protocol scanning only specifies port 443 for the HTTPS setting and see if the problem goes away. -EDIT- If you get an Eset "internal error" message when attempting to save your settings after the change to port 443 exclusively, ignore it. Eset will still perform the change. But, also verify later that only port 443 is shown.

Looks like Eset has changed the alert format across the board; most likely for display consistency purposes. When a threat is detected, a popup will also briefly appear. In this case showing the threat was removed by Web Access protection

Below is a screenshot of what I get on attempted access to that web site. Note that this is a blacklist detection. Also this alert type does appear to be new and does give the user the option to ignore it. I believe the desktop popup alert you are referring to is when a web site is hosting known malicious content. In this instance, the connection would be unconditionally blocked. So the answer to your question is no, there is nothing wrong with your Eset settings.

i went through Google's Chromecast support web site documentation and noticed this: https://support.google.com/chromecast/answer/3249268?hl=en Try temporarily disabling Eset's SSL/TLS protocol scanning and see if that resolves the connection issue.

Also: https://social.technet.microsoft.com/Forums/Lync/en-US/fd85f2da-2701-434e-8777-56e33f855840/desktop-icons-missing-in-windows-server-2008-r2?forum=winservergen

Hum ..... Why did I anticipate you were going to state this? Most brute-force RDP attacks are against the network server. In other words, they have guessed the network admins password and are now in the "Holy of Holies " to do whatever they want. This would include the ability to log into an endpoint Eset GUI even if was password protected. Even better, just disable all Eset GUI password protection on all endpoints at once, run the ransomware, and then re-enable password protection on all endpoints. Actually, the damage an attacker can do when he has gained access to an admin server is limitless.

Unfortunately, most here can't read Chinese; if that is the language displayed. Therefore we have no clue what IE11 is displaying when a connection can not be made.

This type of behavior is typical of screen lockers but in this case whatever it is trying to display appears to be malfunctioning. I have been hit by at least two that Eset didn't detect but only when I had a browser session open.

OK. I now see what you are referring to when you enter a query into the search window. Yeah, I noticed this a while back. BTW - the Eset forum web site also uses Google Analytics if you weren't aware of that. So I guess being redirected to Google search is no big deal in the scheme of things.

No problem here when I clicked on the shown link using FF 68:

If you are referring to FireFox "private mode," B&PP will open it in that mode. However and by design, and extensions and add-ons are disabled. I assume the same holds true for Chrome. However for IE11, it opens in B&PP in normal mode. However, you can switch to private mode in B&PP w/o issue. Remember that you should not be using B&PP for normal browsing sessions but only for connection to your financial or other sites that require locked down browser protection.

I would say this is a no-no. NOD32 doesn't contain the firewall. Since the export file is .xml and parameters within are positional, suspect an import into ISS would mess up things quite a bit.

Might be the Eset stand-alone uninstaller no longer checks for old Smart Security install residual entries. Believe that is a reasonable assumption since it hasn't existed since ver. 10.

It's OK on my EIS 12.2.23 build. Click on the gear symbol and verify that "Disable notifications" is not enabled. You can also click on "Reset" option while there. This should cause data to be populated from this point on.

Actually, Eset Smart Security components are installed in Internet Security version but are not activated. I actually have a Smart Security license but opted instead to install Internet Security since I have no need for the encryption of password manager features of Smart Security. So if anyone should be seeing the abnormal updating activity you posted, it should be me. Such is not the case. I agree that it appears your current Internet Security installation is probably borked and an uninstall/reinstall should fix it. You could also try a repair install first and see if that resolves the updating issue.

This sounds like an Eset firewall issue to me. Open the Eset GUI. Select Network Protection. Click on the Troubleshooting Wizard and see if the Chomecast dongle connection is shown as blocked. If so, click on the Allow tab and Eset will auto create firewall rules to allow the connection thereafter.

My own opinion is that upgrades from a prior xx version can be problematic. Upgrades within a xx version are OK. As a rule, you should always do a fresh install of the current Eset version when a full new release is issued; e.g. to ver. 12 when ver. 11.xx.xx is installed.

Next time I will be more specific in my replies to you. What I inferred was "Sophos has a simple mitigation recommendation." It appears you obviously have no Microsoft training in how to properly secure a business computer network. As such, it would be prudent to reflect a bit on your comments prior to posting them. It is not Eset's or any other AV vendor's software responsibility to ensure that a business network is properly secured against not only external unauthorized access/breaches but also internal like activities. It is however the organization's IT/security administrator responsibility to ensure that Microsoft's "best practices" to do so are implemented and enforced.

There's a simply way to verify what directory epfwlwf.sys is loading from. Refer to the above registry screen shot. Find the entry for epfwlwf. Refer to the "ImagePath" entry. If it shows C:\Program Files\ESET\Eset Security\Drivers, then that is where the driver will be loaded from. Note that driver loading and use of it are two different things. I examined the Start Type setting value for my network adapter and it's "3', i.e. Load on Demand or manual. Obviously the network adapter has to be initialized prior to the assignment of Eset's NDIS mini-port filter to it. This is where ekrn.exe use might come into play. So it might be that there is a bug/issue here where possibly some residual registry entry or the like that ekrn.exe refers to, and it is set to C:\Program Files\ESET\ESET Smart Security\Drivers versus C:\Program Files\ESET\ESET Security\Drivers?

The option has nothing to do with either. Both gpedit.msc or secpol.msc are Windows policy/security utilities only available on the Pro+ versions.

I will also add that Sophos has a simple mitigation recommendation that will eliminate most RDP brute force password guessing attacks while at the same time not permanently locking out a user's workstation: https://nakedsecurity.sophos.com/2017/11/15/ransomware-spreading-hackers-sneak-in-through-rdp/

Here's how we can verify that EpfwLWF.sys is properly loaded. Had to "comb the deep recesses of my brain" for Win 7 memories which I rather not remember.😅 Refer to the below screen shot in regards to your network adapter. Under the "This connection uses the following items" should be something titled "NDIS Eset Mini-port Filter" or some wording similar to that. If it exists, assume the driver has been loaded and is functioning properly and just ignore the Event Log entry. Additionally if the driver wasn't properly loaded, Eset's SSL/TLS protocol filtering processing wouldn't be functional.

There's also possibly another dimension to this problem. @Marcos is not EpfwLWF.sys, Eset's network adapter mini-port filter driver that Eset stopped using releases ago in favor of Windows Filtering Platform use? In other words, the question is if this driver should be installed in the first place?