ekrn connects to 8.8.8.8:53

[Daidai 3]

Could someone please tell me why does ekrn connects to 8.8.8.8:53 ?

Nothing else, just ekrn connects to 8.8.8.8:53

I don't use google dns service nor I use DNS over Https.

I found a similar thread, but that didn't provide a solution.

https://forum.eset.com/topic/20732-strange-google-dns-queries/

I have even set a block rule at the top of firewall table to block 8.8.8.8, but situation remains.

Please help.

 

[Marcos 5,070]

If you are sure that resolution by your DNS server works alright, I'd recommend opening a support ticket for further troubleshooting and analyzing diagnostic logs.

[itman 1,659]

Open a command prompt window. Enter:

ipconfig /all

In the displayed output, refer to the "DNS Servers" section. Do you see IP address 8.8.8.8 listed there?

Edited June 27, 2022 by itman

[Daidai 3]

15 hours ago, itman said:

Open a command prompt window. Enter:

ipconfig /all

In the displayed output, refer to the "DNS Servers" section. Do you see IP address 8.8.8.8 listed there?

No, just 192.168.1.1

The 8.8.8.8 ekrn connection does not always happen.

[itman 1,659]

7 hours ago, Daidai said:

The 8.8.8.8 ekrn connection does not always happen.

I assume you are using Chrome as your browser.

Refer to the following linked article:

Quote

Here’s the crux of the problem: If Google Chrome can’t find the IP address for the domain name the user is requesting using the system-specified DNS servers, then it will attempt to connect to the Google DNS servers (like the 8.8.8.8 address shown below)

https://medium.com/cloud-security/google-chrome-dns-security-bypass-9a1e10e02114

[Daidai 3]

The 8.8.8.8 ekrn connection even happens before I start anything. (I open ESET GUI right after Windows desktop appears)

Could someone tell me why can't I reveive response from ESET support? Not even the notification email.

[Marcos 5,070]

Probably there was a problem with resolution using your DNS server, hence the fallback to Google DNS.

If you have opened a support ticket and didn't get a confirmation email with an ID in a timely response. check your spam / junk folder. It unlikely that the email would not have been sent out. You can reach out to support via alternate means, e.g. by chat or phone, whatever your local ESET distrubutor supports.

[itman 1,659]

9 hours ago, Daidai said:

The 8.8.8.8 ekrn connection even happens before I start anything. (I open ESET GUI right after Windows desktop appears)

Check your router and verify that ISP DNS's server primary IP address shown there has not been changed to 8.8.8.8. This assumes you are using an ISP provided router/gateway. The ISP would have hard coded their external IPv4 DNS address on the router via factory firmware initialization. Or,  possibly later, changed the DNS server address via firmware update.

It is also possible this is malware related. An example is given below referencing the Hafnium exploit:

Quote

Windows Firewall - Here I blocked powershell inbound and outbound traffic. This is a pretty heavy-handed and potentially impactful option but as an immediate stop-gap to prevent remote powershell from executing in to or out from the infected machine, it works. This is what stopped DNS from flipping from our internal DNS to 8.8.8.8 and 9.9.9.9 and generally upset the virus execution.

https://community.spiceworks.com/topic/2312153-compromised-by-hafnium-cleaned-using-established-tools-still-see-ps-events

You can do the same using the Eset GUI to add firewall rules as follows:

1. In the Firewall rules window, click Add.

2. In the Name field, type Deny network connections for powershell.exe (native)

    Use the following configuration for the rule:

        From the Direction drop-down menu, select Both.
        From the Action drop-down menu, select Deny.
        From the Protocol drop-down menu, select Any.
        From the Profile drop-down menu, select Any profile.

Click the Local tab, and in the Application field, type: C:\Windows\System32\WindowsPowerShell \v1.0\powershell.exe.\v1.0\powershell.exe.

Repeat the above to create another rule for;

Name: Deny network connections for powershell.exe (SysWOW64)
Application: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

3. In the Firewall rules window, click OK after adding all rules. 

Edited June 29, 2022 by itman

[Enrico 3]

Connections to Google DNS were also made by the antispam module, try disabling it. (email client protection-antispam protection)

Edited June 30, 2022 by Enrico

[Daidai 3]

@Macros

I checked the spam/junk folder, nothing was sent in.

@itman

I have added the two rules you mentioned, the same.

@Enrico

I will try that and keep an eye on ekrn.

 

By the way, I have changed the router, so it is unlikely this is caused by  the old router.

Edited June 30, 2022 by Daidai

[Marcos 5,070]

As I wrote, probably it takes some time until resolution through your DNS server starts working when the OS starts so ekrn tries to use Google DNS as that time.

[itman 1,659]

2 hours ago, Marcos said:

As I wrote, probably it takes some time until resolution through your DNS server starts working when the OS starts so ekrn tries to use Google DNS as that time.

As far as I am aware of, anything related to Google including Google DNS is blocked by "The great Chinese firewall": https://en.greatfire.org/blog/2012/nov/googlecom-blocked-china . I assume this also now applies to Hong Kong.

If Eset internally is using Google DNS servers for anything which I was not aware of, it should not be doing so for Chinese installations.

[Daidai 3]

@Enrico

I have tried disableing the spam filter, sorry to say it remains the same.

@Marcos

The 8.8.8.8:53 connection at ekrn happens occasionally and randomly, it can appears at startup, after browsing the Internet, or when I am doing nothing.

@itman

I am sure to tell you this is not related to the Great Firewall. Under the 'One country two systems' policy, Hong Kong can use Google DNS servers.

 

I am starting to think is it possible that it is because I have disabled some default firewall rules? But I have leaved the "outbound DNS request" enabled.

[itman 1,659]

2 hours ago, Daidai said:

I am starting to think is it possible that it is because I have disabled some default firewall rules? But I have leaved the "outbound DNS request" enabled.

Ensure that you have not disabled the default firewall rule that allows all inbound/outbound network traffic for ekrn.exe. Ditto for the default firewall rule for equi.exe.

[itman 1,659]

BTW -here's @ericothread on observed Eset ekrn.exe recording of Google DNS server 8.8.8.8 use: https://forum.eset.com/topic/20732-strange-google-dns-queries/ . The thread ends with this comment:

Quote

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.

@Marcos confirmed in the thread Eset doesn't use Google DNS servers for any network communication. I concur with this statement. Ekrn.exe does monitor whatever DNS server IP address is being connected to. That is the extent of Eset's activity in regards to DNS network processing. Since 8.8.8.8 is a valid Google IPv4 DNS server address, Eset won't find any issues with this activity.

I also advise you review this article: https://4sysops.com/archives/secure-dns-requests-over-https-doh-in-windows-1011/ in regards to if you inadvertently enabled DoH at the operating system level in Win 10/11.

Edited June 30, 2022 by itman

[Enrico 3]

(In Win10 and Linux I've set DNSWatch servers, the router uses the provider DNS servers, DoH is forced disabled with GP's)
I did some more testing and I can confirm that Eset antispam module is using google DNS servers for resolve *.e5.sk , it bypasses the custom firewall rule to block connections to 8.0.0.0/9 and no log entry is created.


This is why I've disabled the antispam module long time ago, but at least with the older EIS/ESS versions the firewall rule was respected (connection blocked + entries in the log).
I've disabled unused ESS features, so I can't check if Eset engine uses google DNS servers for other modules.

[Daidai 3]

I have set a rule to block any traffic going to/from 8.8.8.8 at the top of ESET firewall table, so it is unlikely my machine is infected.

According to eveyone in this thread, I can only assume ekrn is using 8.8.8.8 sometimes.

 

[itman 1,659]

6 hours ago, Enrico said:

I did some more testing and I can confirm that Eset antispam module is using google DNS servers for resolve *.e5.sk , it bypasses the custom firewall rule to block connections to 8.0.0.0/9 and no log entry is created.

I am still not convinced Eset in itself is the source of redirection to Google DNS server use. Refer to the below screen shot:

The use of Google DNS servers starts immediately after outlook.exe e-mail download starts. Granted as your screen shots show, the connection activity is to Eset servers. However, internally outlook.exe could be forcing use of Google DNS servers for any outbound network originating from it. Note that Eset interface to outlook.exe is via .dll plug-in but the outbound network traffic is still originating from outlook.exe.

[Enrico 3]

That screenshot was took after enabling antispam and doing a send/recive, whitout antispam no queries to google were made.

Look at this:

I was in pause and left the workstation unattended (antispam disabled), at 13:34:22 there was a google DNS query for setting.e5.sk, at 14:can't:remember Eset used my DSN when searching for updates...

So ESET have google DNS hard coded and it's used for some purpose.

From my point of view, this is a severe security/privacy issue. If a backup DNS is needed fore some reason, than the user should be able to choose wich one.

[itman 1,659]

As far as the OP's concern over Google DNS server use, ask your ISP if there are situations where they will internally route port 53 DNS traffic to Google DNS servers.

I will also note that all port 53 DNS traffic is routed to the ISP's DNS servers. This holds true when a third party DNS provider has been configured on the local device. In this instance, the ISP just routes the DNS network traffic to the third party DNS provider versus processing it using its own DNS servers. The only exception to the aforementioned is when a VPN is used.

Additionally, not all ISP's allow for use of third party DNS providers. Mine does not. So if Eset was indeed trying to route somehow port 53 DNS traffic to Google DNS servers, that traffic would fail on my device.

[itman 1,659]

11 minutes ago, Enrico said:

I was in pause and left the workstation unattended (antispam disabled), at 13:34:22 there was a google DNS query for setting.e5.sk, at 14:can't:remember Eset used my DSN when searching for updates...

Is that DNS traffic using port 53?

[itman 1,659]

Now there is this possibility in regards to Eset port 53 DNS network activity. It is in effect performing a DNS man-in-the-middle attack. It is intercepting the resolved incoming DNS port 53 traffic from the ISP and then re-routing that traffic to Google DNS servers.

I also believe this might be occurring in its Network inspection processing via localhost proxy interception. I do know that if the Network Wizard feature is disabled, this proxy is no longer present.

Of note here is if you disable Eset's firewall default rule for DNS and add a new rule only allowing remote connection to your assigned DNS server IP addresses, you will see blocked ekrn.exe connections "up the wazoo."

Edited July 1, 2022 by itman

[itman 1,659]

"Taking the bull by the horns" to get to the bottom of this, I did some further testing:

1. I disabled Eset firewall default DNS rule.

2. I created a replacement DNS rule specifying svchost.exe and dnscache service with only remote IP addresses for my router DHCP IPv4 and Ipv6 DNS server addresses. This is the strictest DNS firewall that can be created.

3. I set ekrn.exe default firewall rule logging level to Warning so that all network activity from it is logged.

4. I finally crated a new firewall rule to block all outbound UDP traffic to remote port 53. I also set its logging level to Warning.

Absolutely no DNS issues in testing with the above configuration. There was no blocked DNS traffic. There also were no Network event log entries created for ekrn.exe.

Below is a screen shot using Eset Network monitor tool after an Eset signature update:

The connection outlined in black is the DNS port 53 connection to my local subnet assigned IPv6 DNS server address.

The connection outlined in red is the connection to Eset update server. Note that connection is via UDP and the port is 53535. Refer to Eset KB article on IP addresses and ports used by Eset and you will note repeated references to the statement the above UDP protocol use to port 53535 must not be blocked.

Next is most are now familiar with DNS over HTTPS since its now being phased in as the de factor standard for encrypted DNS communication. However, there previously exists another method for encrypted DNS communication called DNS over TLS: https://developers.google.com/speed/public-dns/docs/dns-over-tls . The point to "glean" from the Google article is the normal port used for DoT communication is 853. However, if there is an issue with the DoT handshake processing, DoT will fall back to using unencrypted DNS via port 53.

It appears Eset ekrn.exe is not using DoT for communication to its servers via Google DNS server resolution. This process should work seamlessly and be transparent to the user. If one observes ekrn.exe DNS connections to its servers using UDP port 53 versus 853, it means that secure encrypted communication to Eset servers can not be established and insecure unencrypted DNS is being used to connect to Eset servers.

-EDIT-

Below is code on how to set up a DNS-relay. This is what Eset sets up for its internal use. If you delve into the sync.io article, it is noted that the relay must be set up to use either DoH or UDP for DNS resolution. It's unclear what UDP usage is about other than port 53 is being used. As such, I assume DoT is not being deployed.

Quote

DNS Relay

DNS relay for UDP and DoH requests

Node usage

In code

// ESM
import { UDP, DoH } from 'dns-relay';
// CommonJS
const { UDP, DoH } = require('dns-relay');

// Instant start
UDP(53535, 'cloudflare');
DoH(80, '127.0.0.1', 'google');

// Class usage
const udp = new UDP(53535, 'cloudflare');
udp.start();

const doh = new DoH(53535, 'cloudflare');
doh.start();

// Object params
UDP({ port: 53535, host: '127.0.0.1', provider: 'cloudflare'});
const doh = new DoH({ port: 53535, host: '127.0.0.1', provider: 'cloudflare'});

 

https://snyk.io/advisor/npm-package/dns-relay?utm_medium=referral&utm_source=skypack&utm_campaign=snyk-widget

Edited July 2, 2022 by itman

[Daidai 3]

Thank you everyone.

I have a new question, any reply is welcome.