Does ekrn.exe open only the ports set by Internet Explorer firewall rules?

[loverboy]

The question is in the title "Does ekrn.exe open only the ports set by Internet Explorer firewall rules?"
Both Outbound and Inbound

Is there any way that I can check it?

I have COMODO Firewall (5.0) and EAV 4.2.67.10

[loverboy]

Come on guys.
It is a simple question.

Is it possible that no one in ESET can give a simple answer?

How does the "ekrn.exe proxy" act?

[Marcos]

Sorry that I cannot respond, it's not clear to me what you mean.

[loverboy]

I mean this (= simple question):

1. I have Internet Explorer 8 on a Windows XP Home SP3 PC

2. I have a Firewall (COMODO 5)

3. I have set some firewall rules (for Internet Explorer 8 ), see picture below, referred to HTTP requests on ports 80, 443, 8080 , to FTP request, DNS requests etc etc etc

4. I had NOD32 2.7, but since I installed 4.2.67.10 when I look at the traffic on my COMODO I see that ekrn. exe (and not IE8 ) is accessing the Web. That is because (I know) I have HTTP protocol filtering activated in EAV4 and I like it very much.

5. So my question is: Do all the rules that I set for IE8 in my Firewall still exist even if the web access is made by ekrn.exe?

If, say, I decided to allow IE8 "HTTP outgoing requests" only to ports 80, 443, 8080, is it still so?
Does ekrn.exe simply analyze the protocol of what is transmitted using IE8 "in and out" my PC, opening towards the web (and coming from the web) only the IE8 ports that I decided in my firewall rules (both outgoing and ingoing) or does ekrn.exe communicate "in and out" with Internet Explorer 8 only through one channel [that I see is 127.0.0.1 port 30606 (loopback zone)] and opens towards the web its own ports and not those decided for the program (IE8 in this case, but also others) whose HTTP protocol it is filtering?

Sorry for the messy explanation, but I am not an expert

[Marcos]

I assume that the "Web browser" rule group is binded on the signature of browser executables (a db of MD5 would be harder to keep current) so ekrn would not be identified as a browser and thus these rules would not apply for communication routed via ekrn. This is just my speculation which should be confirmed or denied by the vendor of the Comodo firewall.

[vtol]

Originally Posted by loverboy

Does ekrn.exe simply analyze the protocol of what is transmitted using IE8 "in and out" my PC, opening towards the web (and coming from the web) only the IE8 ports that I decided in my firewall rules (both outgoing and ingoing) or does ekrn.exe communicate "in and out" with Internet Explorer 8 only through one channel [that I see is 127.0.0.1 port 30606 (loopback zone)] and opens towards the web its own ports and not those decided for the program (IE8 in this case, but also others) whose HTTP protocol it is filtering?

Sorry for the messy explanation, but I am not an expert

ekrn.exe may be the scanner component but it does not communicate via the browser. the NOD communication filtering is achieved through a driver, sort of a proxy - which also renders encrypted ssl traffic transparent for the sake of making the data stream accessible to the scanner - that if SSL protocol filtering is enabled.

as pointed out by Marcos the interpretation of the NOD communication filtering is up to the firewall vendor

[loverboy]

So all this long thread
http://www.wilderssecurity.com/showt...do#post1151116
was based on a wrong starting assumption?

Thanks anyway for your (=both of you) replies

[vtol]

Originally Posted by loverboy

So all this long thread
http://www.wilderssecurity.com/showt...do#post1151116
was based on a wrong starting assumption

looks outdated, discussing v3 back in 2007/08, maybe things been different then with NOD

[act8192]

It works exactly like described in the link posted above - post 197.
NOD goes out via TCP to localhost, post 30606. Browsers listed in NOD don't make a direct connection. NOD does.
Important thing is to allow ekrn.exe to localhost:30606.
But also important is to restrict EVERY application in the firewall from using that port. So rules which allow loopback for other applications needs to use at least two ranges in a way that excludes 30606 (1-30605, 30607-65535). To prevent tunneling behind your back.

For Avast it's 12080, Avira's is 44080. Same story.

[vtol]

that seems to be correct when running on XP, it does not apply to Vista/W7 though. me apologizes

[pegr]

Originally Posted by loverboy

Does ekrn.exe open only the ports set by Internet Explorer firewall rules?

My understanding is that ekrn.exe doesn't open ports at all. What it does, as described by others in this thread, is to filter web and/or email traffic via a proxy for the sole purpose of checking it for malware, not to function as an outbound firewall. What gets filtered and what doesn't depends on how application filtering in the Protocol filtering section in NOD32 advanced settings is configured.

When an application tries to make an Internet connection, Comodo firewall will see the attempt, and will alert for any application that is not on the safe list (assuming the firewall is in Safe Mode) and for which a rule is not already defined. This does not mean that Comodo has been bypassed, as it is still Comodo that initially determines whether or not to allow the connection. You can check this by disabling or deleting the firewall rule(s) for the browser, switching to Paranoid Mode, then launching the browser to make an Internet connection. Comodo should immediately detect and alert you to the attempt. This will prove that the firewall is not being bypassed.

It does affect the way Internet traffic is reported within Comodo though once the connection has been allowed. If the connection is one that NOD32 has been configured to filter via its proxy, then Comodo will show the network connection as having come from the NOD32 proxy, and not the application. This is in a sense correct as it is the proxy that has made the Internet connection, not the application directly. Although unsatisfactory from a reporting point of view, it doesn't represent a loss of control. The problem is that Comodo can't see inside the NOD32 proxy to report the application that requested the connection. This is not specific to Comodo; it is true of all third-party firewalls and there is no solution.

You basically have three choices: (1) Live with the situation as it is; (2) Disable web filtering for applications that you want to see correctly reported by Comodo firewall (not recommended); (3) Upgrade to ESET Smart Security which includes a firewall that works with the proxy to report traffic correctly.

The other alternative would be to upgrade the operating system. I assume that you're on Windows XP as I believe that NOD32 filtering is only done via a proxy on XP. On Vista and Windows 7, it is my understanding that filtering is done via WFP (not supported by Microsoft on XP).

EDITED: A minor point of clarification added.

[loverboy]

Originally Posted by pegr

My understanding is that ekrn.exe doesn't open ports at all. What it does, as described by others in this thread, is to filter web and/or email traffic via a proxy for the sole purpose of checking it for malware, not to function as an outbound firewall. What gets filtered and what doesn't depends on how application filtering in the Protocol filtering section in NOD32 advanced settings is configured.

When an application tries to make an Internet connection, Comodo firewall will see the attempt, and will alert for any application that is not on the safe list (assuming the firewall is in Safe Mode) and for which a rule is not already defined. This does not mean that Comodo has been bypassed, as it is still Comodo that initially determines whether or not to allow the connection.

<SNIP>

It does affect the way Internet traffic is reported within Comodo though once the connection has been allowed. If the connection is one that NOD32 has been configured to filter via its proxy, then Comodo will show the network connection as having come from the NOD32 proxy, and not the application. This is in a sense correct as it is the proxy that has made the Internet connection, not the application directly. Although unsatisfactory from a reporting point of view, it doesn't represent a loss of control. The problem is that Comodo can't see inside the NOD32 proxy to report the application that requested the connection. This is not specific to Comodo; it is true of all third-party firewalls and there is no solution.

You basically have three choices: (1) Live with the situation as it is;

<SNIP>

Thanks
This is the explanation I was looking for

[pegr]

You're welcome.

Regards