ESS is connected to an unknown server

[cobolp 0]

Today, through the firewall logs I saw that the ESS is connected to an unknown server that is not used by your company.

 

 

104.81.60.80

 

What is the ip address and why it is connected to the ekrn.exe?

[Marcos 5,070]

That's an Akamai server's IP address. ESET does not use any servers hosted at Akamai. Couldn't it be that you are using Windows XP? In such case, ekrn would be used as a local proxy for http traffic so any http communication would appear to be initiated by ekrn.

[cobolp 0]

No. I m use Windows 10.

[itman 1,659]

Are you using any other software that uses a proxy server such as AdGuard for example?

Edited June 25, 2016 by itman

[cobolp 0]

Are you using any other software that uses a proxy server such as AdGuard for example?

No.

[itman 1,659]

My first question is why are you seeing that connection in the Eset firewall log? Are you logging all firewall activity? The only thing that should be in the log are  blocked connections.

 

Best you post a copy of this log entry. If you mouse right click on the entry, you can copy it to the clipboard. Then paste same in your forum reply.

[cobolp 0]

Firewall has blocked outgoing call ekrn.exe to the Akamai server. Logs are cleaned every 24 hours. So give them I can not. You do not have enough of my words? I have blocked already all connections for ekrn.exe except updates and activation.

 

PS: In the two weeks that I have been using the new firewall I'm just horrified scale leak of information from the computer. The term "personal computer" is not applicable to computers with Windows 10. I will soon migrate to GNU\Linux. There are more serious about privacy.

[Marcos 5,070]

Firewall has blocked outgoing call ekrn.exe to the Akamai server. Logs are cleaned every 24 hours. So give them I can not. You do not have enough of my words? I have blocked already all connections for ekrn.exe except updates and activation.

 

PS: In the two weeks that I have been using the new firewall I'm just horrified scale leak of information from the computer. The term "personal computer" is not applicable to computers with Windows 10. I will soon migrate to GNU\Linux. There are more serious about privacy.

 

Don't forget to permit communication with LiveGrid servers, otherwise you won't be protected to the maximum possible extent against new borne threats. For a list of servers that ESET products communicate with, see hxxp://support.eset.com/kb332/.

[itman 1,659]

For what it is worth, I have noticed similar activity from ekrn.exe as shown in the below TCPView screenshot. This connection manifests itself when a new HTTPS web page connection is made. Ekrn.exe dials out to Eset servers to perform SSL certificate pinning validation since I have SSL protocol scanning enabled. A short time thereafter, the Eset connections go into a wait state since they are no longer needed. It is a this point the connection to my ISP provider web page servers appear for the same previous Eset connections. I don't believe any physical connection actually exists at this point.  

 

Edited June 27, 2016 by itman

[ken1943 22]

Akamai is a well known company for hosting software updates and various other stuff. It is also a "man in the middle" for many

companies with no bad intentions.

 

Could be some software is using them for updates and to pass information to that company.

Edited June 27, 2016 by ken1943

[MMx 28]

There are two reasons ekrn.exe might make connections to servers that are not operated by ESET if you have TLS filtering enabled. First when a browser tries to establish a TLS connection, ESET Security needs to decide if it will filter, block or leave the connection untouched. This decision is in part based on the certificate the server would present if the connection was to proceed, which is not available yet. To solve this problem, ekrn.exe opens a separate connection and requests the certificate, which allows it to make the right decision in the main connection. This certificate is then cached so that the extra connection is not needed later which minimizes performance impact. Doing this is necessary to implement certificate exclusions (e.g. F5 -> Web and email -> SSL/TLS -> Exclude communication with trusted domains, or storing a certificate with Access set to Allow or Block).

 

Second reason is related to the fact that ESET Security needs to verify the validity of the certificate presented by the server. Online communication is a regular part of such verification (see https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol). Doing this is necessary to make sure that no attacker hijacked the connection in transit since your browser won't see the original certificate.

 

Please note that in both cases ekrn.exe sends only what a browser would send if ESET Security was not installed. In a way ekrn.exe acts on behalf of the browser. You can verify this by capturing the communication using wireshark and analyzing it (the initial part of TLS connection that ekrn.exe does in case 1 is not encrypted, and OCSP is not encrypted at all since it relies on digital signatures).

[itman 1,659]

This certificate is then cached so that the extra connection is not needed later which minimizes performance impact.

MMx - thanks for the detailed explanation which verifies what I have observed using Smart Security w/SSL protocol scanning enabled. 

 

However I have not observed what I highlighted above using ver. 8. Each time I connect to a HTTPS web site even if it was one I had previously accessed in a browser session, Eset will make a connection to one of its web servers. So the question is where the cached certificate chain info stored? I have the IE11 advanced option of "do not store encrypted files to disk" enabled. Could this be preventing the storing of the certificate chain data?

Edited June 28, 2016 by itman

[MMx 28]

itman: That shouldn't be happening regardless of version. Can you try if you can replicate it using an utility that accesses only a single page (e.g. wget or curl) and make sure you connect to the same IP each time? It is possible that each time you reload a page a new server is connected due to load balancing.

[itman 1,659]

itman: That shouldn't be happening regardless of version. Can you try if you can replicate it using an utility that accesses only a single page (e.g. wget or curl) and make sure you connect to the same IP each time? It is possible that each time you reload a page a new server is connected due to load balancing.

OK - after a bit of effort I finally got wget to connect to a site. As you can see from the below screen shots, I made two connections to the web site and TCPView recorded two dial-out connections from ekrn.exe. Hope this is what you requested.

 

 

 

 

 

Edited July 1, 2016 by itman

[itman 1,659]

Also will add that this morning shortly after initial boot for the day, I observed ekrn.exe dialing out to IP address 198.41.214.185. It was an IP address connection and not by URL. No browser connection was established.

 

The IP address noted is associated with Cloudflare and according to this assessment of it by VirusTotal: https://www.virustotal.com/en/ip-address/198.41.214.185/information/ not the safest place due to the number of malware files associated with it.

 

I see no reason why ekrn.exe should be connecting to this IP address and have blocked the connection.

Edited July 2, 2016 by itman

[itman 1,659]

They say "a picture is worth a thousand words." Below is a screen shot of ekrn.exe connecting to Akamai servers. 

 

The sequence of events are:

 

1. Connect to Akamai server on port 80. No inbound or outbound network activity. 

2. Connect to Eset servers.

 

I use VeriSign as my DNS provider. So it is safe to say that Verisign did the routing of the ekrn.exe cert. validation lookup through Akamai backbone servers. Most likely the same applies to my previous my posting about use of Cloudflare servers. The same scenario could also apply to direct use of your ISP DNS servers. I also believe this type of connection routing occurs since I live in the U.S. and Eset servers are in Slovakia which would dictate more intermediary transaction routing methods. So in my case, my gripe about use of Cloudfare servers needs to be directed to VeriSign, my DNS provider.

 

 

 

[cobolp 0]

137.135.12.16 IP address does not even belong to you. But the ESS is connected to it many times a day and almost always after power the computer. Without it is impossible even activate your product ESS. Very strange and suspicious that the update download from the Slovakia servers, and this server is located in the USA.


I am more and more inclined to think that your company is involved in a leak of personal information of users from their computers.

[Peter Randziak 1,130]

Hello,

 

to see details about the IP addresses used by ESET and corresponding services please see this KB article hxxp://support.eset.com/kb332/?viewlocale=en_USthe mentioned one is listed there as well.

We have servers located in various hosting locations and we use cloud to host some of the services we provide.

 

Regards, P.R.