Serious Issue w/Eset Firewall on Win 10

[itman 1,659]

For reference, refer to this posting: https://forum.eset.com/topic/9237-ver-9-firewall-issue/ . This issue applies to both ver. 8 and 9.

 

The issue manifests itself under the following conditions:

 

1. You are using a WI-FI connection in Win 10.

2. You have a home router that controls other devices.

3. You are using the Eset firewall Public profile.

4. You have configured your IPv4 and/or IPv6 Win 10 adapter settings to use a third party DNS provider.

 

As I noted in the above posted link, I have been plagued with strange hidden proxy activity from Eset since the day I installed Win 10. It existed in ver. 8 and persisted when I upgraded/installed ver.9. It is a given that Eset uses a hidden proxy. However, this activity should not be noticeable to the user. Nor should your event log be full of blocked firewall entries from this activity. Additionally, you should not see hundreds of entries originating from your router connected non-PC devices listed in Eset's network trouble shooting wizard as blocked activity. I was 10 mins. away from permanently uninstalling Eset and never ever again using the product or recommending it when I discovered what the problem was.

 

I had to disable Eset's default "ekrn verification" rule to determine the problem. When Eset uses the Public profile, it basically sets up the firewall for your PC alone. In other words, it does not see your home router connection. The problem is that Eset's hidden proxy server needs another device to set up in to perform the proxy activity. In my case, Eset's firewall was sending outbound requests to ports 53, 137, 1900, and 3702 and the following up with an outbound multicast request to IP address 239.255.255.250. The problem is that those discovery requests were being directed to my third party DNS IPv4 IP address! Appears Eset's firewall will not allow any local proxy outbound routing to devices that haven't been explicitly defined to it. Once the port 137, 1900, 3702 requests weren't responded to by the third part DNS providers, Eset's firewall went bonkers and did eventually find my router and then assumed it was some type of actual external device that it could start doing its proxy baloney on.

 

I was able to resolve this Eset garbage activity by removing my third party DNS server references. Eset's Public profile immediately found my router's IP address and set that up as an IPv4 address based DNS server. Eset's firewall thereafter properly set up its hidden proxy on the router and all Eset internal router based blocked connections disappeared.

 

I would very much like to be able to use third party DNS providers with the Eset firewall in Win 10 using a Public profile on a Wi-Fi connection.

 

-EDIT- I will also add that the above configuration worked w/o issue in Win 7. The difference was that Eset's firewall did recognize the existence of a LAN when using  the Public profile and recorded same in the network zones settings.

Edited September 15, 2016 by itman

[itman 1,659]

I finally got this resolved. Before I get into the solution, I also want to note that the Eset firewall has initialization issues. The situation is most pronounced upon resume from standby mode. For example, the default "allow all connections within the computer rule" will allow outbound DNS connections to addresses not within your subnet i.e. third party DNS servers. This is a vulnerability in my book.

As far as the solution to the original issue, I added my router's IP address as a trusted address to the Wi-Fi Public profile that Eset created. Eset's firewall however should have enough "smarts" to know that the Wi-Fi connection is originating from same. I guess the software's title of "Smart Security" is an oxymoron?

[Marcos 5,074]

You are talking about a hidden proxy but there's nothing like that in ESS. In the other topic you mentioned proxy-detection.eset.com which is probably what you mean. To clarify that, there's no proxy functionality at that address; it exists just for the purpose of determining and remembering proxy settings by making an http request to it which could be done to an arbitrary existing domain.

[itman 1,659]

Marcos, please refer to the screen shot in the original posting: https://forum.eset.com/topic/9237-ver-9-firewall-issue/ . It is clearly shown that ekrn.exe is routing traffic through two of my existing LAN connections; 192.168.1.76 and 192.168.1.88. As previously explained, those connections are for Chromecast and Amazon Firewire dongles attached to my TVs. That is hidden proxy activity. Additionally, Eset has no business using connections on my router that are dedicated for other purposes. Additionally, the traffic is being finally routed to 185.67.201.35 which is www.amtso.org .

 

I saw the same like activity occur last night after I had done some malware tests. My conclusion is that when Eset detects malware activity, it will use the proxy to start uploading and downloading files for further analysis. It does so regardless of the user's specified LiveGrid settings. I have both options for file/data uploading disabled.

 

-EDIT- Just realized that the screen shot I originally posted doesn't show ekrn.exe as the source of the proxy activity. Below is a screen shot I took a while back while diagnosing the issue with using third party DNS providers. Additionally, ekrn.exe was performing both inbound UDP and outbound TCP activity on 192.168.1.94. This connection is the gateway my router uses to connect to my AT&T Uverse wireless TV desktop boxes.  

 

Edited September 17, 2016 by itman

[itman 1,659]

As luck would have it, I just had an "incident" and can describe in detail Eset's proxy activity.

1. Eset's firewall detects an IDS intrusion from a smartphone on my LAN. It blocks, notes it, and immediately ekrn.exe sends outbound UDP 16 packets containing 2K+ of data. I assume it used my 192.168.1.94 router connection.

2. Shortly thereafter, Eset's firewall detects another IDS intrusion from a second smartphone on the LAN.

3. A period of time elaspes and ekrn.exe does outbound TCP connections to both 192.168.1.76 and 192.168.1.88 as noted in the below screen shot:

4. Another period of time elaspes and ekrn.exe does again outbound TCP connections to both 192.168.1.76 and 192.168.1.88. This occurs at least one more time.

From the above, it is obvious some type of cloud scanning is being performed on files from my PC. I have no issue with the scanning other than such activity is not publically disclosed by Eset and is in direct contradiction to LiveGrid data uploading preferences. But I do take exception on using existing dedicated LAN connections in a hidden manner to do so. Additionally, the 192.168.1.76 and 192.168.1.88 connections are established and stay in a wait state for at least one minute before data transfer occurs. If Eset wants to do such proxy activity, it should create its own proxy server to do so using a dedicated port.

Edited September 17, 2016 by itman

[itman 1,659]

I have pretty much identified what is causing all the above posted activity.

All I have to do is access the Network troubleshooting screen in ver. 9 Network Connections. It immediately triggers all the above described LAN connections. Since you have stated Marcos that this activity should not be occurring, I am creating a firewall rule for ekrn.exe to block access to all my LAN connections other than to my PC and router's IP addresses.

My theory is Eset is not "smart" enough to recognize a local LAN using the Public profile and decides to use those LAN ports for its cloud scanning activities.

 

-EDIT- Actually it makes no difference whether the Public or Private profile is selected. The same behavior occurs with both profiles.

Edited September 18, 2016 by itman

[Marcos 5,074]

Please enable diagnostic logging under Tools -> Log files - Minimum logging verbosity as well as advanced personal firewall logging under Tools -> Diagnostics. Then clear your firewall log, restart the computer and try to reproduce the problem. When done, disable diagnostic logging as well as advanced firewall logging. Then collect logs using ESET Log Collector (hxxp://support.eset.com/kb3466/), upload the output archive to a safe location and pm me the download link.

[itman 1,659]

Please enable diagnostic logging under Tools -> Log files - Minimum logging verbosity as well as advanced personal firewall logging under Tools -> Diagnostics. Then clear your firewall log, restart the computer and try to reproduce the problem. When done, disable diagnostic logging as well as advanced firewall logging. Then collect logs using ESET Log Collector (hxxp://support.eset.com/kb3466/), upload the output archive to a safe location and pm me the download link.

Sent you a PM containing the event logs.

[itman 1,659]

I am attaching a screen shot of Eset's firewall log showing the events log upon access to Networking Connections troubleshooting wizard. Obviously Eset went bonkers as evidenced by the unknown access to ports 1900 and 3700.

 

One event however which by the way was the initial one is missing from Eset's firewall log. The event was an outbound access by ekrn.exe to port 137 on my PC! Note that I have NetBIOS disabled on my Wi-Fi adapter IPv4 connection. So, I am wondering if Eset actually uses NetBIOS for something? It shouldn't be doing so if that is indeed the case.

 

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          9/19/2016 6:59:35 PM
Event ID:      5157
Task Category: Filtering Platform Connection
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      XXX-PC

Description:   The Windows Filtering Platform has blocked a connection.

Application Information:   Process ID:  1168

Application Name: \device\harddiskvolume3\program files\eset\eset smart security\ekrn.exe

 

Network Information:
 Direction:  Outbound
 Source Address:  192.168.1.73
 Source Port:  56249
 Destination Address: 192.168.1.73
 Destination Port:  137
 Protocol:  17

 

Filter Information:
 Filter Run-Time ID: 91543
 Layer Name:  Connect
 Layer Run-Time ID: 48

 

Edited September 20, 2016 by itman

[itman 1,659]

Time to "cut to the chase" on this issue. Below is a Process Monitor log extract screen shot showing all network activity performed by the Network Troubleshooting wizard.

Ekrn.exe performs the following activities:

1. Sets up a DNS connection.

2. Performs a series of router probing activities via broadcasting to determine what current connections exist that it can send/receive UDP and TCP traffic. On my PC, it finds an open port on the WAN side of the router for which it can receive UDP traffic and direct to my PC.

3. Upload and downloads data from my PC using TCP to allocated router connections on the LAN side. It uses always port 8008 plus other random port numbers.

All the above activity is something I would expect to find when malware or spyware is present.

 

 

 

[itman 1,659]

Yesterday was a productive day on this issue for a change. Pretty sure I have Identified the bug with Eset.

 

Appears Eset's firewall for some time has been using a long ago deprecated Windows feature to resolve 6to4 RD6 tunneled IPv6 addresses. ISP's uses this facility to deliver IPv6 addresses to IPv4 routers that they have hacked the existing router's firmware to allow for such activity. The Windows deprecated feature Eset is using is site local scope IPv6 DNS resolution via use of fec0::/10 addressing. This feature allows for IPv6 address resolution locally when an IPv6 DNS server does not exist. The fec0::/10 addresses exist in the DNS Servers section of Firewall Zones section. The same addresses do not exist in the ipconfig /all display for my wireless connection or any other connection for that matter. Hence my assumption that Eset added these addresses to the DNS Servers section.

 

A bit of technical comment:

 

This is the only use case that you might have an issue because if you are using any IPv6 and publishing an IPv6 DNS name resolver then you will prefer that IPv6 DNS name resolver right away. So the only use case where you might potentially use site local is if you actually assign a host an site local address. It makes no sense to do that at all but that is the one case where you might have a problem. So, the simple conclusion is...

 

Don't use site local, which is obvious, since it was deprecated way back in 2004. i.e. RFC 3879

 

Ref: hxxp://www.howfunky.com/2015/10/ipv6-site-local-addresses-why-are-those.html

 

I assume Eset is attempting to assign URL's to these RD6 delivered IPv6 IP addresses for validation purposes.

 

I have been monitoring DNS traffic for sometime. One firewall alert I have been receiving for some time is from ekrn.exe inbound from port 53 from svchost.exe. OK, nothing wrong with that since I have previously posted details that ekrn.exe does do outbound port 53 activity in support of the above site local DNS resolution. But .......... here's the problem Eset. The inbound port 53 traffic for ekrn.exe is not for the DNSCache service but for the DHCP service. What the ....! It is at this pint when Eset goes bonkers with the internal proxy activity running amuck in my PC. 

 

I have coded/modified firewall rules to shut the site local scope IPv6 DNS resolution thereby eliminating the borked Eset internal proxy activity. It appears also that Win 10 internally has either shutdown or modified the use of site local scope IPv6 DNS resolution use. Additionally, Eset needs to do DNS resolution using the correct service.  Most importantly, Eset needs to stop using vulnerable deprecated Windows facilities.

[itman 1,659]

One last comment and I am done with this thread.

 

Eset is also using your LAN ports for SSL certificate validation if you have SSL protocol scanning enabled. You can verify this by creating a firewall rule prior to the existing default ekrn verification rule. The new rule detail is application - ekrn.exe -, outbound traffic, protocol -TCP/UDP-, with local connection IP addresses being your LAN IP addresses excluding your existing PC IPv4 address.

 

This explains the ekrn.exe UDP connection which appears TCPView that shows inbound and outbound internet traffic w/o any connection IP address.

 

Again if Eset wants to do local host based proxying, it should so like other security vendors do and use 127.0.0.0/8 addressing.

[itman 1,659]

I got off on a tangent about Eset's proxying methods and forgot to mention what needs to be fixed in Smart Security 9.

 

For starters, the Troubleshooting Wizard needs to incorporate some "smarts" into its processing. If a user who has a LAN setup selects the Public profile, he is doing so to expressly to have the firewall block all his LAN connections to his PC. If he wanted to have those LAN connections accessible, he would have chosen the Home/Workgroup profile. Therefore any firewall based blocked LAN connections should not be recorded into the Network Wizard blocked connections. Furthermore, Eset's firewall should be dropping the blocked LAN activity and not forwarding same to the Windows firewall filtering platform resulting in hundreds of Windows event log entries being generated. The Eset firewall already has a mechanism to easily include a LAN connection if so desired; just add the IP address to the Trusted Connections area. 

 

I realize the intent of adding the Network Wizard to version 9 was to simplify the process of creating a firewall rule for a blocked connection. However, I question the wisdom of such an approach. The average non-technical user does not have the knowledge to first, properly interpret, and second, to respond appropriately to the information currently displayed by the Wizard. Eset should instead concentrate its efforts on improving the firewall's event recording capability. For example when running in Interactive mode, all user blocked firewall alerts should be logged in the Eset firewall log. 

 

Eset should change the Network Wizard to only capture and record IDS based blocked activity. This would greatly decrease the activity captured and thereby minimize proxy activity currently done to show such information in the Wizard. 

 

-EDIT- Also add to the Network Wizard an option to ignore existing user block rules. I assume Eset can differentiate between the default and user created rules?

 

Again pertaining to firewall activity, the Network Wizard should only storing blocked firewall activity generated when the firewall is set to Policy mode. Personally if the firewall by default just logged all blocked activity, more information would be provided on the event than that currently given by the Network Wizard.

Edited September 28, 2016 by itman