Jump to content

Strange Google DNS queries


Recommended Posts

I have two workstations protected by EIS, one with W7 and the other with W10, in the last month I've noticed strange DNS queries in the network logs, here an example:

      <COLUMN NAME="Time">04/09/2019 11:55:10</COLUMN>
      <COLUMN NAME="Event">Communication denied by rule</COLUMN>
      <COLUMN NAME="Action">Blocked</COLUMN>
      <COLUMN NAME="Source">192.168.1.193:57600</COLUMN>
      <COLUMN NAME="Target">8.8.8.8:53</COLUMN>
      <COLUMN NAME="Protocol">UDP</COLUMN>
      <COLUMN NAME="Rule/worm name">Google dns</COLUMN>
      <COLUMN NAME="Application">C:\Program Files\ESET\ESET Security\ekrn.exe</COLUMN>
      <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN>
    </RECORD>
    <RECORD>
      <COLUMN NAME="Time">04/09/2019 11:55:16</COLUMN>
      <COLUMN NAME="Event">Communication denied by rule</COLUMN>
      <COLUMN NAME="Action">Blocked</COLUMN>
      <COLUMN NAME="Source">192.168.1.193:57601</COLUMN>
      <COLUMN NAME="Target">4.4.8.8:53</COLUMN>
      <COLUMN NAME="Protocol">UDP</COLUMN>
      <COLUMN NAME="Rule/worm name">Google dns</COLUMN>
      <COLUMN NAME="Application">C:\Program Files\ESET\ESET Security\ekrn.exe</COLUMN>
      <COLUMN NAME="User">NT AUTHORITY\SYSTEM</COLUMN>

These queries are not made by the OS services (SSL/TLS filtered), if you look at time of detection in DNS log they aren't present:

eset-google2.thumb.png.45fc6c3274a55771f408c7c474e5ef0a.png

I'm not using Google DNS, nor DoH in FIrefox, TCPv4 is set to use Quad9.

This happens every time pc's are in sleep mode, could it be some kind of undetected/unquarantined infection, like Nymaim? https://www.welivesecurity.com/2013/10/23/nymaim-browsing-for-trouble/

 

Best regards.

 

Edited by Enrico
Link to comment
Share on other sites

  • Administrators

Ekrn uses system DNS servers for DNS lookup. Did you create the blocking rule for ekrn to block updates, LiveGrid, antispam and other functionalities of ESET?

Link to comment
Share on other sites

Appears you got "creative" in regards to Eset's default firewall DNS rule as I did some time back and decided to create your "more secure" DNS rule only allowing DNS outbound traffic to Google DNS servers? As @Marcos stated, ekrn.exe performs DNS proxy activities.

Link to comment
Share on other sites

@Marcos: I've created allow rules for all documented Eset (proprietary + MS Azure) IP ranges and block rules for all Google IP ranges and websites, ekrn.exe is only monitored (log-information).

If ekrn is performing dns poisoning detection or other things, why it's not using the OS DNS settings? (Cloud9 or OpenDNS)

Link to comment
Share on other sites

4 hours ago, Enrico said:

This happens every time pc's are in sleep mode,

The question is why there is any DNS activity is occurring in sleep mode. Your device is powered down in that state; including the network adapter. Check the times associated with the Win DNS Client-events log and see if those sync with times that the PC is powered up from the sleep state.

I checked the same log on my device. It has zero entries. The only time that log will contain entries is when the Win firewall is the primary firewall and its inbound/outbound rule processing is in effect. That processing is disabled when Eset is installed. Once Eset is installed Eset "manages" the Win firewall and only by default, uses select existing inbound rules. If you examine the existing Win firewall rules, there is no inbound rule for DNS; only an outbound rule. And again, Eset does not use existing Win firewall outbound rules period.

Check your existing Windows firewall section using Win Control Panel and ensure its states it is being managed by Eset Internet Security.

Link to comment
Share on other sites

I can confirm that Windows security is managed by ESET (all green). The "DNS client events - Operational" windows log need to be enabled in order to register DNS queries and responses. I forgot to specify that on my pc's only the monitor is put into sleep mode, all the other devices must remain active because of my professional CAD-CAM sw needs (HASP).

The lookup of "4.4.8.8" points to nothing, if it's not hard coded in the OS or in EIS, what else could be?

The other sw running from startup is nvcontainer (quadro -nvtelemetry), Logitech GS, 3DConnexion broker, MSI Afterburner.

Edited by Enrico
Link to comment
Share on other sites

Here it comes, it's a new pc so not all firewall rules are optimized. (previous admin user became corrupted because of the latest W10 bug)

The queries are made every 60 minutes even when the pc is in use.

eis_logs.zip

Link to comment
Share on other sites

Update: in web access protection I've found a blocked address *.trafficmanager.net, which include " edfpcs.trafficmanager.net", was this rule that caused the dns queries?

Link to comment
Share on other sites

I've removed trafficmanager.net from blacklist and still have 4.4.8.8 - 8.8.8.8 connection attempts.

Now I'm logging only blocked programs (freeware tools with automated connections) and untrusted IP ranges, so ESET components should not appear in the list.

Link to comment
Share on other sites

  • Administrators

We do not fallback to Google's DNS servers. Please try configuring the DNS servers to obtain address automatically instead of using Quad9 DNS servers 9.9.9.9 and 149.112.112.112.

Link to comment
Share on other sites

I can't because I need static IP's for LAN shares and with Win it's impossibe to obtain DNS server address automatically when a static IP is used. (fyi modem default DNS are 151.99.125.1 and 151.99.0.100)

Link to comment
Share on other sites

4 hours ago, Enrico said:

I can't because I need static IP's for LAN shares and with Win it's impossibe to obtain DNS server address automatically when a static IP is used. (fyi modem default DNS are 151.99.125.1 and 151.99.0.100)

Assumed is those are your ISP DNS servers.

Note that Win network adapter IPv4 DNS settings will override whatever is shown on the router. What is shown on your devices for DNS settings?

Eset_IPv4.thumb.png.2ea02234f22756fc98aac2b9b6f763b7.png

Also if you set up your static network connections using a guide such as this: https://pureinfotech.com/set-static-ip-address-windows-10/ , note that the alternate DNS server connection is for Google DNS server.

 

Edited by itman
Link to comment
Share on other sites

As you can see it's all configured and working.

dns.png.7ff7224483c6aa4ec4cb4a62372dabce.png

What I meant is that auto DNS is greyed out with static IP.

By the way: until now the Google DNS queries has quit in both W10 and W7, in the logs of W7 I see that ekrn is quering the configured DNS.

Link to comment
Share on other sites

I enabled DNS logging, and see zip Google DNS entries. In Win 10, opened both IE11 and FireFox which is configured to use DoH - Cloudflare DNS servers.

Eset performs network port traffic examination using a hidden local proxy server. One of those ports is port 53. In other words, any port 53 traffic examination by ekrn.exe would be internal only. If ekrn.exe is indeed initiating stand-alone DNS queries, it most likely is for rDNS validation purposes or possibly, telemetry activities as this article explains: https://www.leadfeeder.com/blog/what-is-reverse-dns-and-why-you-should-care/

Edited by itman
Link to comment
Share on other sites

I also enabled ekrn.exe logging. During the time it was active, I saw less than a handful of DNS requests and they were to the DNS server on my router per my current Win DNS server configuration.

Also as far as the Win DNS-client event log entries, all I observed was normal DNS resolution via DNS cache entries or specifically from my respective IPv4 and IPv6 DNS servers. There was no way to determine what the source process was. As such, there is no way to prove any originated from ekrn.exe.

This gets us to the blocked entries shown in your Eset Network Connections event log screen shot for ekrn.exe. The only way that would happen is if you disabled Eset's existing default DNS firewall rule and created your own rule restricting outbound DNS traffic to your specified DNS servers and a block rule for any other DNS traffic. The problem is ekrn.exe performs internal proxy activities using select ports; one of them being port 53. I really suspect this is the cause of these weird ekrn.exe connections to 8.8.8.8 and 4.4.8.8. You in essence borked Eset's internal proxy processing and Eset went into some type of "spastic" mode.

If this "wierdness" returns, create a duplicate of the existing default ekrn.exe rule and place it prior to your custom DNS rule. Then disable the existing ekrn.exe. This will ensure ekrn.exe DNS proxy activities are not blocked.

Edited by itman
Link to comment
Share on other sites

This is what I've did:

1: Created an "allow" "all" rules for ekrn and egui with the only purpose of log network traffic and override another rule that was blocking Azure cdn traffic.

2° Created an "ask" rule for svchost

svchost_ask.png.b8dc8a71244f330351b1eba612f3b695.png

3° Everytime ESET detect a new svchost\DNS connection I add the IP to the custom "allow" rule, but only if remote/local are trusted destinations.

dns_rules.thumb.png.7813b436088ff74fa353cd5c1ef00345.png

 

As you can see custom rules have higher priority than predefined "allow" rules, this way ESET can use all whitelisted IP's when needed and ask for other DNS connections when they're not present in the "allow" custom rule, except for the ones made to Google servers which are always blocked (I don't trust that corp. and won't use their sw).

I had to do that way because of data gathering code (GA) hidden here and there in some common freeware applications, drivers and purchased sw.

Probably ESET was only detecting attempts made by other sw, but better if I review/reorder all my custom settings.

Best regards.

 

Edited by Enrico
Link to comment
Share on other sites

7 hours ago, Enrico said:

As you can see custom rules have higher priority than predefined "allow" rules, this way ESET can use all whitelisted IP's when needed and ask for other DNS connections when they're not present in the "allow" custom rule, except for the ones made to Google servers which are always blocked (I don't trust that corp. and won't use their sw).

Hum ........... Things are a bit worse than I imagined.

You have "granulated" the Eset firewall rules to the point you're monitoring individual svchost.exe service network traffic. Here's the issue. It have serious doubts that such rules work property.

An Eset past ver. created its like default rules as such in regards to svchost.exe service network traffic. This was abandoned in later ver. releases. This would be indicative to me that the firewall rules were not functioning properly as intended.

Link to comment
Share on other sites

That rules were set with the only purpose of identify the "offender", they were not present before finding "4.4.8.8" in tcplogview, now I'm back to the previous configuration "block untrusted IP ranges"->"ESET default rules"->"custom rules".
Anyway, custom rules with the wrong priority still were uncapable of explaining the presence of 8.8.8.8 and 4.4.8.8 in the logs.
In the last 24 hours the logs had no presence of strange DNS queries, so probably I will never be able to identify what happened last month... (yesterday)
...Until this morning! I left the pc unattended for some time, Interactive firewall was asking what to do with some windows processes, meanwhile Google DNS queries has been logged. My suspect is that when the endpoint could not be reached in the expected ammount of time then win services override user dns settings.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...