itman

Bunch of HTML5 tests here: https://html5sec.org/#html5 . Many would not run in IE11. I did get a SmartScreen alert from the evil.com test. Nothing from Eset but don't know if that means anything since the test shows HTML5 code used by malware w/o any actual malicious code employed.

Through prior testing and network connection behavior observation using a network connection monitor such as TCPView, normal ekrn.exe behavior is to maintain two persistent internal UDP network connections. One which shows as a 0.0.0.0 connection is used for polling LiveGrid servers for connectivity status. The other is a localhost connection to 127.0.0.1. The inconsistency I am observing is for the localhost connection. Normal ekrn.exe behavior is to establish the localhost connection at boot time and the LiveGrid connection shortly thereafter. However, this is not always the case on my Eset installation. For example, today upon first cold boot, the localhost connection was never established. Upon a later system restart, it was. However for the prior two days at least, the localhost connection was established at cold boot time. Such is inconsistent ekrn.exe UDP connection behavior observed. As best as I can determine, this inconsistent behavior doesn't appear to affect base Eset proxy activities such as SSL protocol filtering. Not so sure as to LiveGrid download activities since from prior observation, ekrn.exe UDP proxying is used for DNS connectivity purposes. This inconsistent behavior appears to be more pronounced since upgrading to ver. 11.1.54 although I believe it did occasionally occur in prior Eset versions. Once possible source of conflict could be Win 10's IP Helper service which also establishes connectivity on 127.0.0.1 for UDP. The service is set to Automatic by default. Will experiment with setting the service to Manual to see if that helps. Wonder if Eset starting using a different UDP localhost address such as 127.0.0.2 as a possible mitigation?

I will state this about this Eset IP address connection. For anyone using a router with a stateful firewall, this inbound traffic would have been automatically blocked by the router. Possibly why I have never seen it. If this inbound traffic bothers you, just create an Eset firewall rule to block any inbound TCP traffic with a remote IP address of 91.228.166.47. Move the rule to the top of the existing rule set and your issue is resolved.

OK. I misunderstood what your concern was. The network alert you are receiving is one that is associated with an unstateful network connection; i.e. inbound connection associated with no preceding outbound connection. Verify that that the default Eset firewall for ekrn.exe is enabled and has not been modified; it should allow all inbound and outbound communication for ekrn.exe. This same issue has occurred previously: https://forum.eset.com/topic/7831-ess-log-shows-27-inbound-tcp-packet-blocks-from-ip-belonging-to-eset/so refer to this:

Here's what Robtex says about the IP address: Based on this, I would say the server IP address acts as a Eset network "router" to direct the connection to its desired Eset destination. -EDIT- For example when I enter skh1-webredir01-v.eset.com in my browser, I am redirected to this Eset U.S. where I reside based web site: https://www.eset.com/us/get-protected/?adobe_mc_ref

Same here. On my device the problems were most pronounced after a Win 10 cumulative update. It appears that it internally messes up Win power settings. In one instance I was ready to start tearing down the PC for repair. The device would not power up regardless of what I tried. Never had anything likewise happen in all my PC days. Unplugging the power cord from the power supply and plugging it back in final did the trick.

My best guess is its associated with LiveGrid. Eset published list of LiveGrid IP addresses include 91.228.166.45 and 91.228.166.46. Possible uses for 91.228.166.47 would be as a backup server for LiveGrid traffic when its main servers are off-line or having communication problems. Hence, the "webredir" as part of the domain name.

Another thing that should be checked with people having this problem is via Windows device manager, verify that Eset's keyboard driver is properly installed:

You could try to use the "File" option to add the certificate to the List of know certificates as shown by the below screen shot. First of course your would have to export the cert. using certmgr.msc option. I have never used this option. "My gut" tells me you will end up with an entry identical to the existing one. That is Name and Issuer will be set to "Localhost." So what you have presently might be your best option. Also Eset doesn't explain what "Localhost" means in this context. It might just mean ignore scanning any HTTPS communication that uses this certificate which I believe is what you want.

I can't because I am not having the problem you described.

If this certificate is related to a specific internal IP address as you posted, you can try to exclude SSL protocol scanning for that IP address as shown by the below screen shot. Add the IP address to the Excluded IP addresses section. Before doing this, you will have to first delete the existing List of known certificates entry. Then test to see if this solves you problem. -EDIT- Note this disables all of Eset's web filtering protection for this IP address.

It might also be helpful if people start posting the type of keyboard they are using: 1. Manufacturer 2. Type of connection; PS/2 or USB 3. Type of driver being used. Windows default keyboard driver or manufacturer provided driver. -EDIT- 4. Are you using any other security software that has anti-keylogger capability, e.g. Trusteer Rapport, or keystroke scambling capability, e.g. KeyScrambler? This might help Eset narrow down the source of the problem. I suspect this problem might be related to a specific subset of keyboard devices.

Appears your solution here didn't work out? https://www.tenforums.com/software-apps/112217-devicecensus-exe.html I use O&O ShutUp10 to manage by Win 10 privacy settings. Run it with default recommended settings. I have the same system configuration as yours running Eset IS 11.1.54. Also applied the last Tues. Win Updates. Checked by Event log entries and Windows Control Panel Reliability Monitor and see no entries related to Devicecensus.exe.

Just that you're aware of this, any localhost HTTPS connection; i.e. 127.0.0.0 - 127.255.255.255, using this certificate will not be scanned for malware via Eset's SSL protocol scanning feature.

Post a screen shot of what is currently shown in "List of know certificates."