Changed LiveGrid Behavior Under Ver. 11.1.42

[itman 1,659]

@Marcos, I found what the problem was.

If you do the following from admin command prompt window:

netstat -anob

It will force a connection attempt to LiveGrid. It appears LiveGrid, as I suspected, is dependent upon one the Incoming RPC Communication Over SMB Services show in the below screen shot. I suspect it is the Service Control Manager service. I need you to get back with me on which services need to be enabled for LiveGrid to function properly. I try to disable as many of these services as possible since they are all remote attack surfaces:

[itman 1,659]

@Marcos, I finally got LiveGrid straightened out by performing a Win 10's "hard" network connection reset. This is the one where Win 10 will after a period of time shutdown the PC after it has totally rebuilt the TCP/IP stack and associated protocols.

The result of this reset is:

1. Eset network connection DNS server now is reset to my router's DNS server/cache IP address.
2. Actual DNS servers used are my ISP ones.
3. Win 10 NetBIOS settings are now at default meaning NetBIOS is enabled and active on the network connection.

What is now observed in TCPView is two persistent ekrn.exe connections; one with a local IP address of 127.0.0.1 which never shows any activity and one with an IP address of 0.0.0.0 which does show activity. Assumed 0.0.0.0 is Eset's proxy server which is now set to use NetBIOS. Through this connection is observed periodic LiveGrid connection verification activity; 1 packet of approx.. 127 bytes being sent and received. When an actual LiveGrid transmission occurs, the data is filtered through the NetBIOS-ns connection i.e. port 137.

The primary question now to be responded to by Eset is if NetBIOS active status is required for LiveGrid to function properly? As I stated in a prior reply to this thread, I have as a rule always disabled NetBIOS on the network adapter setting since it is not need for Windows Homegroup to function properly, I don't have a home network setup, and NetBIOS has long been considered a security vulnerability.

As best as I can determine LiveGrid functioned properly using the localhost connection i.e. 127.0.0.1 until the recent install of ver. 11.1.42  over 11.0.159 horribly screwed up my network connection in regards to localhost thereby rendering LIveGrid non-functional. Far worse as noted previously, there was no indication by Eset Internet Security that LiveGrid was non-functional. I assume this was so since Eset had previously changed LiveGrid alert status frequency to placate user complaints about always be alerted about it. This issue needs immediate attention by Eset.

[itman 1,659]

Another point of discussion is how Eset performs its connection to the LiveGrid DNS server/s. What I knew previously but did not directly comment upon is how Eset does this connection.

Rather that performing a standard DNS request using Windows dnscache service, ekrn.exe does an outbound connection port 53 request to my router's DNS server as shown by the below Eset firewall log entries. As such, it bypasses any of the local DNS cache entries stored as a result of previous Windows dnscache service resolution. I strongly suspect that LiveGrid DNS server connections might now be working since my routers DNS server cache holds duplicate domain name to IP address resolutions of those stored in Windows dnscache service resolution storage. However when a third party DNS provider is used, LiveGrid's DNS request would show a target IP address of the providers server; previously this was 1.1.1.1 for Cloudflare DNS servers. This would result in the domain resolution being performed by my ISP provider servers prior to routing the request to Cloudfare. It appears something was getting "hosed" in this routing process. 

BTW - LiveGrid DNS servers are polled ever 5 mins. as shown in the log entries in ver. 11.0.159. 

Time;Event;Source;Target;Protocol;Rule/worm name;Application;User
4/9/2018 4:16:30 PM;Communication allowed by rule;192.168.1.XX:49318;192.168.1.254:53;UDP;Allow verification for ekrn;C:\Program Files\ESET\ESET Security\ekrn.exe;NT AUTHORITY\SYSTEM

Time;Event;Source;Target;Protocol;Rule/worm name;Application;User
4/9/2018 4:21:30 PM;Communication allowed by rule;192.168.1.XX:49318;192.168.1.254:53;UDP;Allow verification for ekrn;C:\Program Files\ESET\ESET Security\ekrn.exe;NT AUTHORITY\SYSTEM

Time;Event;Source;Target;Protocol;Rule/worm name;Application;User
4/9/2018 4:26:30 PM;Communication allowed by rule;192.168.1.XX:49318;192.168.1.254:53;UDP;Allow verification for ekrn;C:\Program Files\ESET\ESET Security\ekrn.exe;NT AUTHORITY\SYSTEM

[itman 1,659]

Pondering upon what I have posted to date in this thread about LiveGrid processing behavior, I believe I have now narrowed down what the primary issue is.

In regards to the prior posted LiveGrid outbound port 53 communication every 5 mins., this is LiveGrid's connectivity test. It is in essence sending a "ping" or like facsimile command to LiveGrid's DNS servers. As long as a reply is received from the server, LiveGrid assumes no problem with connectivity to its DNS servers.

Previously this appeared to work when I had specified a third party DNS server IP address for my network connection. However when the system went into standby mode and then returned to normal power mode, LiveGrid's connectivity test to its DNS server failed. Also from this point on, any further actual LiveGrid attempted DNS server requests failed. Of note is this behavior does not exhibit itself when the system DNS server is locally based i.e. located on your router.

I can only speculate as to why the LiveGrid connectivity test fails upon resume from standby mode when a third party DNS provider is specified:

1. My ISP provider who forwards these DNS requests to the third party DNS provider now views these "ping" requests as not validity sourced and drops them at that point.

2. Or, the same result occurs when the request arrives at the third party DNS server provider; the request is viewed as not validly sourced and dropped.

I believe no. 2 is what is occurring since "ping" requests routed via router's DNS server to my ISP for DNS resolution work w/o issue upon resume from standby mode.

Why this is occurring I have no idea but speculate it has something to do with the connectivity command LiveGrid is using. Or more likely, DNS name resolution for the Eset domain used for the connectivity test exists in the router's DNS server cache allowing the request to be directly forwarded to LiveGrid's DNS server/s w/o any DNS name resolution occurring by my ISP DNS servers.  That is upon resume from standby mode, no DNS domain name resolution is required.  

Edited April 12, 2018 by itman

[itman 1,659]

One other possibility I forgot to mention.

When a third party DNS provider is deployed, Windows uses its own DNS cache for address resolution. It may be that Win 10 1709 now flushes that cache upon resume from standby for security reasons. This results in whatever LiveGrid connectivity DNS server method being deployed to fail thereafter. If true, this would mean if a DNS cache flush was done manually via the ipconfig command, the same result would occur.