ESS has their built in firewall. EAV is designed as a stand alone AV, and should work with any third party firewall such as CPF.
Marcos seems to think if we want to use NOD32.v3.0 we should find a firewall that can communicate with their AVs proxy. Not sure which software firewalls he means? Lookn`Stop perhaps can do this?
Outpost (plus many others I suspect) and obviously Comodo v3 currently cannot.
I did revert to NOD32 v2.7 with CPF v3. and I am happy with this combination until either Eset stop supporting NOD32 v2.7 or Comodo come to the rescue and find a way to deal with proxy using AV`s
Yes, I noticed Marcos’ post at Wilders. Since NOD32 is not planning to change its approach and reportedly firewalls can be developed in a manner to correct the situation, I want to hear if Comodo is taking the same approach as NOD32 (meaning - if one wants to have outbound control then pick a different AV…). I will then have to decide what apps to use and what apps to ditch.
So that’s the problem, leak test are going through erkn.exe and not CFP?
I have read the forums at wilders but none give details, as yours does not, on the specifics of the issue. Is there really a “tunnel” to the internet through ekrn.exe totally by passing CFP, or is it that there are people just “thinking” that there is this tunnel?
I am very concerned that I may be exposing my data to a danger that I am at a complete loss as to how to test for or otherwise insure that this is not happening.
I would love to have someone with technical knowledge about this issue come forward with information as to just what the problem is.
I’ve found the information I needed after careful reading of the long post over in Eset forums, it requires a self filtering of a few rants to get to the real issue, but it’s in there.
Not sure if that’s the correct way to refer a post in another forum but a search on Eset forums for: Nod32 v3: Software firewall made useless b/c all connections are running through v3?
Will lead you to it.
In particular post #11 by Marcos which pretty much sums it up along with post #98 by mickhardy
Hey all, if you search the Comodo forums via the little gray search box at the top (i know, it’s easy to miss) and just type in ekrn.exe you’ll see a slew of posts here regarding that same issue. I just tried it and I did. Sorry I can’t dig more but its late here and there’s work in the morning. I personally use Nod32 2.7 and I refuse to upgrade to v 3. anything. My plans are to use CAVS V. 3 when it comes out once my nod subscription runs out.
Comodo is unable to recognise the originating source because of ekrn as everything goes through ekrn.
Marcos said there were firewalls that could deal with this but declined to name any. He also said this is not a ‘flaw’ or ‘bug’ but a purposfull design in NOD which is why I’m sticking to V2.7 in the meantime.
You offer a setting without saying (proof) that it actually solves the ekrn proxy problem, or how it solves the problem.
So. A couple of questions on this if I may:
Has this been tested with NOD32 v3 using leaktests?
How does this setting enable CPF to see through the ekrn.exe proxy?
There are a great many NOD32 users concerned about this issue and an effective (proven) solution would be most welcome to both NOD32 users and indeed Eset staff, who seem unable to offer a solution.
If you mean limit to specified IP addresses with the NOD32 proxy running the only ways are:
limit the access for the application acting as a proxy. That is going to affect all other applications using that proxy and the same port. For e-mail traffic that shouldn’t be a problem but for HTTP traffic is not very practical.
configure NOD32 to don’t scan HTTP traffic for that application. You are still protected by the other AV modules (e.g. AMON) . If your program only need to access a few IPs then you realy don’t need HTTP scanning for that program.
I don’t have NOD32 so I cannot test it. If you are using NOD32 v3 you can test by yourself.
If nod32 is using a localhost proxy (that’s what I can read in the Wilders thread) like many other programs then ekrn.exe listens on some port for conections from 127.0.0.1 and the applications using that proxy (e.g. Web Browsers) create an outgoing connection to 127.0.0.1 and the port used by ekrn.exe
This is what I have as settings for Nod32 v3 to solve that proxy problem:
In advanced settings, uncheck all browser and email clients (web browsers under HTTP and email clients under POP3). Then disable POP3, HTTP and Web access protection.
With this settings, all my connections connecting as normal not thru ekrn(proxy).
I tested this by loading an anti-virus test program from a site and nod32 stopped it.
www.eicar.org/download/ is the site where the anti-virus test program is located.
With my set-up nod32 did not even allow loading it. Then I disabled Nod32 and downloaded the file to my computer. Then enabled Nod32 and run the virus program and Nod32 straight away quarantined the file. But when I disable nod32 and run the virus program, Comodo’s defend + did not give me any alerts!!!
I also tried GRC leaktest and PCFlank tests with no problems.