Ver. 9 Firewall Issue

[itman 1,659]

Win 10 Build

 

I am posting a screen shot of a persistent intermittent connections to ports on my router. Ekrn.exe is allowing this connection, so I am assume that it is Eset dialing out every 15 minutes or so for rep file updates? The problem is those connections are for my Chomecast and Amazon Firestick dongles that are attached to my TVs. This might also explain the large number of firewall blocked unstateful inbound connections from Eset U.S. servers i.e. 38.90.229.xxx I am receiving.  

 

I am running Eset using the Public profile and as such none of my wireless network connections are trusted. So the question is how to get Eset not to use my wireless LAN ports for its connections?

 

Edited August 14, 2016 by itman

[itman 1,659]

Appears this is perhaps Win 10 telemetry baloney at work? It tries to find any unused open port on the LAN side of the router to phone home to MS? Darn right scary and insecure in my opinion.

 

There is also the question of these unstatefull blocked inbound TCP connections for ekrn.exe from Eset U.S. servers i.e. 38.90.226.xxx posting I never received a response to . Should a firewall rule be created to allow these? What I thing is happening is these are Rep file updates and as such those are not being updated properly. 

 

The one I am getting hammered with is 38.90.226.28 which is:

 

SSL Certificate check

 

proxy-detection.eset.com 38.90.226.28, 91.228.166.91, 91.228.167.91

 

Ref.: hxxp://support.eset.com/kb332/?viewlocale=en_US

 

So I will allow it since it appears all my SSL cert. checks are being borked

 

Time Eset took a look at their ver. 9 default firewall rules -or- fix the firewall. Also this might explain all those failed audit messages in the event log?

Edited August 15, 2016 by itman

[itman 1,659]

Below is a screen shot for Eset proxy server connections to 38.90.226.28. Both inbound and outbound connections exist. I suspect that one of the LAN IP addresses in the screen shot I previously posted is being used for the outbound connection. Appears Eset never set up the local proxy server correctly? Those connections need to be going to/from a 127.0.0.x address not a LAN port. 

 

-EDIT- Eset is also screwing up my LAN traffic since its directing this traffic to ports being used by other wireless devices. So SSL scanning is being disabled for Internet apps until this mess is straightened out.

 

Edited August 15, 2016 by itman

[Guest]

i think im not the only one who dont know what your problem really is

 

so please tell us first whats your configuration?

you are using both wireless and a lan cable on your desktop pc? and you want that the connection of you lan is in an higher priority than your wireless adapter?

 

go to network settings in the old system settings window (sry im a german user and dont know the exact word)

adapter settings and press alt

advanced or extended

advanced settings

 

there you can select the priority of your lan configuration

 

2. do you connect to this wireless lan you dont want that this should be used for anything? if so why do you connect?

 

3. if not please write down your problem in an form we can understand what is going on

[itman 1,659]

i think im not the only one who dont know what your problem really is

 

so please tell us first whats your configuration?

you are using both wireless and a lan cable on your desktop pc? and you want that the connection of you lan is in an higher priority than your wireless adapter?

 

go to network settings in the old system settings window (sry im a german user and dont know the exact word)

adapter settings and press alt

advanced or extended

advanced settings

 

there you can select the priority of your lan configuration

 

2. do you connect to this wireless lan you dont want that this should be used for anything? if so why do you connect?

 

3. if not please write down your problem in an form we can understand what is going on

 

First, I thought I was very specific with the issue.

 

I connect using a wireless D-Link USB adapter to a WAP that is connected to my AT&T Uverse provided Pace gateway router. This is done due to the distance from where my PC is located from the router.

 

I don't trust any of the multitude of wireless devices other people in my household use and don't want them accessing my PC.

 

The issue again is it appears the Eset firewall is using a hidden proxy server to connect to its servers to perform SSL certificate verification. As I posted in the log screen shot, the connections to that hidden proxy server are not working. Hence, the Eset IPS blocking activity due to  "TCP packet does not belong to any open connection."

 

If Eset needs to use my existing non-PC allocated LAN ports to do such proxy activity, it is not the proper way to do so. The proper way to do so is to use a localhost proxy server i.e. 127.0.0.1/255. The bottom line is however is on Win 10,  Eset's proxy is not working correctly. If it was, there wouldn't be all the IPS block activity occurring,

Edited August 15, 2016 by itman

[itman 1,659]

Most important to note on this issue is the following extract from Eset's own documentation pertaining to IPS protection:

 

Check TCP connection status – Checks to see if all TCP packets belong to an existing connection. If a packet does not exist in a connection, it will be dropped

 

This means that all the incoming SSL certification validation data from Eset servers is being dropped. As such, it is fair to conclude that the SSL certificate validation is not being properly performed. Also, other Eset incoming traffic success is also suspect that is using any type of LAN proxy connection - see the below screen shot.

 

This is not exclusively a ver. 9 network problem. The same behavior was observed when using ver. 8 on Win 10. Win 10 altered the way LAN connections are being done it appears.

 

Finally, the Eset proxy activity is being performed via some type of hidden process. When I created a rule for ekrn.exe to monitor this activity, it had no effect. For obvious security reasons, you do not want to create a firewall rule to allow anything to connect in or out absolutely to an external server IP address.

 

Also this problem occurs for a home group profile since I experimented with that. 

 

Edited August 16, 2016 by itman

[ken1943 22]

If you keep looking under rocks, eventually you will find something you don't like/understand.

[itman 1,659]

I found the problem and it is serious so do hope Eset fixes this pronto.

 

There is a bug in IPS as it applies to Win 10. The "Check TCP connection status" protection for Packet Inspection is not detecting proxy connections properly or what I believe should be done, ignoring them.  In Win 10, proxy connections are auto configured by default which might be the issue. What Eset's IPS is doing is blocking any inbound/outbound proxy connection as unstateful.

 

Not only is this problem borking connections to Eset proxy servers, it is also blocking Win 10 OS proxy connections.

 

I have disabled "Check TCP connection status" in IPS since I have a router that does stateful packet inspection. However if one does not have such a router, then this type of IPS protection is a necessity.

Edited August 16, 2016 by itman