itman

No. I believe HTTP/2 has worked with Eset in these two browsers for some time. Note: the web site must also support HTTP/2; a number still do not.

HTTP/2 and Eset work fine together in IE11 or Edge.

In the forum Search window click on the magnifier glass symbol. Under Date Created section, select "Custom." Enter a "From" and "To" date for the search. I suspect by default, the search option only goes back a year since that is the earliest specific date option offered.

I will get an audible on Eset firewall, HIPS, etc.. alerts. But never as I recollect on scan completions. My best guess is the Windows sound event Eset is using for scan completions is not "*" which is indeed assigned a default audible; i.e. Windows.Background.wav.

Idle-state scan option. My assumption is this is basically a Smart scan that runs every day when the system is in an idle state. I assume If not in an idle state, the scan is paused and resumes scanning upon return to idle state.

Internet Security ver. 12.0.27 This behavior has been going on for a while. For example, I ran a scan on 11/15/2018 and it scanned 241,797 files in 2:09 mins.. I ran a scan a hour ago and it scanned 332,423 files and took 18:09 mins. In other words, the most recent scan included approx. 1/3 more files but took 9 times longer to complete. One possible explanation is I have the continuous scanning option enabled. As noted above, the most recent scan occurring in the morning about a hour after boot time. The faster scans were run in the mid-afternoon when the PC was running for 6 hours or so after boot time. So is the explanation for this variance in number of files scanned and time related to the continuous scan element? It seems logical to me to assume so since continuous scanning would have already scanned a large number of files prior to manually initiated scan.

I also don't get any audio sound notification when a scan completes on IS 12.0.27. Can't recollect if I did on prior Eset versions or not. This feature has never been a big deal for me since the Eset desktop toolbar icon shows graphically that a scan is underway. When that stops, I know the scan completed.

Based on this: https://www.eset.com/int/about/contact/ , Russia is supported from the Eset home office in Slovakia. I would just call the phone number given on the web site and ask your purchase question there.

I suspect what the OP has installed is just a cable modem. Example here: https://www.hitron-americas.com/wp-content/uploads/2016/09/CDA3-35-datasheet1.pdf . In this setup, all devices must be connected via co-axial cable to the modem. Most cable modems do not have advanced security features routers provide such as a SPI firewall, NAT, etc..

Another observation on this issue. Appears my above posting is not 100% correct. What I noticed today is that the Eset GUI home page showed last update 12 hours. If I closed the Eset GUI and immediately reopened it, it showed the correct last update time. So the issue is only on the initial startup of the Eset GUI. Thereafter, all is correct. -EDIT- I just noticed that upon opening the Eset GUI home page sometime after the initial system boot, the last update time is not correct. Again, reopening the GUI displays the correct last update time.

It appears his Hitron router isn't supported: https://openwrt.org/toh/start

This thread pertains to a specialized and not the normal user run environment. The Eset firewall protection wise is more than adequate for the vast major of PC users including corp. endpoint users.

As an example of WAN security settings for the above Netgear referenced cable router, all the "disable" options shown in the below screen shot would not be selected. Appears all those options are enabled by default:

If your ISP provided your router, you can contact their tech support for assistance. Also if your ISP is a cable provider, they might have only installed a cable modem. Modems have none of the security features a router provides such as a stateful firewall, NAT, etc.. My best guess based on what you posted would be the firewall, if provided ,would be in the DOCSIS WAN section. Again if you don't know what you are doing, strongly recommend you contact your ISP provider for assistance. Here's an example of a cable modem/router combo whose security protection specifically notes it has a SPI firewall w/NAT and denial of service protection: https://www.netgear.com/home/products/networking/cable-modems-routers/C7000.aspx#tabs-Security

ICMP ping flood attacks are one type of denial of service attacks. The best way to prevent them is by configuring your router's firewall not to respond to ping requests from the Internet. Ref.: http://www.tomsguide.com/answers/id-3643545/stop-icmp-flood-attacks.html Also it is imperative that all external router ports, i.e. WAN side of the router, are shown in "stealth" mode. This is means that the ports are basically invisible to anyone trying to access the router from the external internet. If the attacker can't "see" the ports on the router, he can't launch a ICMP ping attack against one. This is really the only effect method to defeat these types of attacks.

Strange. Same version I am using but on a desktop. Well, not exactly since I am using the home version. Since you are using the Pro version, have you configured any SRP's or other Windows security mechanisms; e.g. ASR rules, to block cmd.exe execution? Or, are you using third party security software like NVT's OSArmor?

Posting OS ver. used really is necessary to properly diagnosis this. On Win 10 Home x(64), I never have had an issue with it opening the Win 10 system win update check screen. My main complaint about the feature is it appears to be triggered by the Win 10 system update checking and is not sophisticated enough, or is not programmed, to wait to see if the update was actually done automatically. In other words, the Eset notification should only appear if the Win update was not installed.

Mystery solved as far as I am concerned. Also my previously posted suspicions were confirmed. Today at first cold boot, I purposely waited approximately 30 secs. to logon to Win 10. When the desktop initialized, the Eset GUI icon was present on the lower toolbar and Eset had completed its update at logon task. I then opened the Eset GUI, the home page did indeed show last update was 12 hours ago. I then within the GUI went to the Eset logs section and opened the Event log. It indeed showed Eset was updated a minute ago. I then returned to the Eset GUI home page and it now showed the time of last update was a minute ago. Appears the Eset home page last update time for some reason is dependent upon internal GUI access for updating at system startup time. Why, I really don't know. One possibility is the Eset update successful popup screen triggers an update to the last update time on home page. I really believe this is such a minor issue most will never notice it.

What I am wondering is this is tied to how fast the Eset update is performed at boot time. For example when I boot, the Eset update always completes after the desktop is fully initialized and the last update time is correct on the Eset GUI home page. However lets say you boot and then "dilly dally" at the Win logon screen for a while. You then eventually sign on. By that time, the Eset sig. update has been completed. When one then displays the Eset GUI home page is the last update time correct?

Well one issue with the Comodo firewall is it certainly isn't to specific in its source application identification. For me, Windows Operating System means possible two things. It's either what is referred to as "System;" i.e. ntoskrnl.exe or svchost.exe. Why you would be receiving that volume of blocked inbound connections from System is a mystery unless its NetBIOS related although the destination ports don't indicate that. If you're satisfied with Comodo, by all means stay with it.

Ecmds.exe among other things is used to start the Eset GUI process. If that is not started or functioning properly, well a lot of things in Eset could be borked. Another thing I strongly advise is you go to this web site: https://www.amtso.org/feature-settings-check-for-desktop-solutions/ and ensure Eset detects all the tests given there; especially the non-archive ones.

One more thing to check. Eset's firewall uses the Window Filtering Platform. Regardless of if the Network option to also use Windows firewall rules is enabled, elements of the Win Firewall are used. In your Win Event log, check the Audit Failure log section for blocked network connections. My experience has been that anything blocked by the Eset firewall also shows in this log. Although I have also seen Win firewall blocks not related to Eset firewall blocks show there; especially at boot time. However, I also have the Eset option to use inbound Win firewall rules enabled.

One last thing to check. See if Eset Troubleshooting wizard shows a non-zero count per the below screen shot:

Eset's event logging has a few "quirks." Without getting into that, do this as a test. For one of your block rules that you feel you should be seeing Network log entries for, set the logging severity to "Warning." If you now start seeing Network log entries for that rule, set the logging severity likewise for your remaining block rules and your problem is solved.

My best guess at this point is there is a bug in NOD32. This behavior does not manifest on Internet Security. What we need is other NOD32 users to confirm it is happening to them. I suspect most users don't pay any attention to the update time displayed on the Eset GUI home screen. I didn't until you brought up the issue.