Discussion in 'other firewalls' started by gkweb, Feb 16, 2006.
kareldjag suggests BitGuard. I second that but if I remember, GK did look it over some time ago and decided it was more a sand box rather then a firewall.
You would have to do a search here for BitGuard.
Supposedly, Kaspersky ISS 6.0 has a vastly improved firewall. I think including it in the testing (if possible) would be beneficial to Kaspersky users.....
I'd be interested in Prisma firewall.Seams pretty good.
Bitguard is no more available for buying/downloading (see their website).
Tests are mostly done, I will not add more firewalls for the moment.
I'm sorry in advance for not including every firewall people asked, I have tested more than finally included, mostly were simply packet filters only, and do not check for application activity.
The update will come in March.
Thanks you very much for your feedback
Website finally updated :
thanx for taking time and doing teh tests. jetico did very well maybe ill try it when the next version comes out. as with the last test both outpost and looknstop did very well, however now theyre tied. lastly i find it weird how the two mcafee firewalls performed so differently.
Thank you gkweb for putting in your time and effort into this new test
Im using Jetico right now and from these tests I am happy that is the top rated firewall out of those other 14
Im dissapointed in Sunbelt Kerio thought is would do much better, but o well
Interesting... thanks for the testing gkweb...
Thanks for taking the time to test these products.
I'd like to see you test some of the HIPS programs such as Prevx1, Cyberhawk, Anti-hook. I've personally downloaded and tried to run all of the leaktests on a system with only Prevx1 Pro active. Only one program was able to launch without getting blocked (Firehole).
Thanks for theses tests, gkweb .
But I think the new testing criteria are penalizing a lot Kerio, compared to others. With this methodology, several leaktests, although passed with flying colours by Kerio, give it only 1/2 point each (it seems the same goes for PrivateFirewall, but I didn't test this one ever, because I got BSOD on BSOD as soon as it was installed on my computer).
I understand the reason of this new criteria, you prefer to see a connection attempt blocked than a code injection detected; but as you say on your Leaktest scoreboard explanation, it can be seen as a more safe blocking method, since it does block the "threat" more soon during execution.
And the fact that this method can require more knowledge can be discussed too, I think : Between a firewall that does alert about DLL injection, and another clearly alerting about a "blocked code injection", I'm not sure the first one is easier to interpret .
Furthermore, the same could be stated about connection attempts vs code injection : I've never got any false positive by Kerio's HIPS
Between asking the user about a global low level mouse hook, and asking about a network access, I think it's clear that the later is easier.
Moreover, using such features (API hooking) will ask the user about application having no network code at all, and which consequently will not access the network.
That is the difference between the block (generic hook), and the pass (network access warning)
But don't get me wrong, I am not against HIPS, I advise them. This is just that in the context of a leaktest (being a concept), to claim "passing" the network test, by "cutting" an unrelated network API, is the same as claiming to secure a computer by cutting the wire
It works, but it's not the spirit of the test.
Finally, people have of course the right to have their own opinion and point of view, and that's why the leaktests are available for download, for you can check your setup, based on your personal criteria.
And thanks you to the people for their support, these tests ask a lot of time, and requires some hours and coffee (don't ask me my coffee bill )
I will try to update the results more often.
Sorry I don,t find McAfee firewall in results. Is the name different.
gkweb included both the consumer (personal firewall plus) and corporate (desktop firewall) mcafee firewalls.
Thank you for doing the tests gkweb, hopefully you'll do them again next year!
Yes, as others have said....thanks as well for conducting these tests as well, gkweb. Your hard word, time and effort to provide these results are very much appreciated.
Just one question regarding the outcome and results: Did you properly configure and/or tweak each and every firewall to the manufacturer's "suggested" settings or tightest level of security? Or did you perform them on the individual firewalls primarily as they are presented to the customer "out of the box"?
IMHO you have an obsolete conception.
I don't know what could make you think this. We can easily lead this to a specific choice: trust or not trust an application.
Of course, but that's not the point.
If we want to be precise, a firewall should open/close ports for incoming/outgoing tcp/udp(/igmp) traffic from/to another host. That's all. Only this.
If you admit "application firewalling" capabilities then you cannot separate them from "proactive actions" capabilities: if something injects something into another process, we are already at a network-unrelated level. We are at "system-level", so an "application firewalling" application should also work at "system-level".
The fact is that most (not all) of these leaktests work at "system-level". They don't access the network: they "injects something" making *other applications* to access the network. So they are not "network API" tests because they work at another level so, as I've aleady said, an "application firewalling" application should also work at another level.
Just my 2 cents (and excuse me for my bad English )
Very good test, appreciate the hard work you have put into this. I found this to be very informative. Thanks.
Just check out the results for Jetico firewall, or best, try it yourself.
Disable completly it's "process attack table", so it won't warn you about any injection/DLL whatsoever, but still warns you about the network access.
As you can see, this "obsolete" point of view seems rather effective
Of course you need to check at system level what is happening to link the activities to the network activity.
But at the end, as I often say it, you can disagree and test yourself your setup the way you want, what matters is that you are secured.
This is not the point.
The point is that you are confusing "firewalls" and "application firewalls" (look at this other reply: https://www.wilderssecurity.com/showpost.php?p=703549&postcount=67 ).
I am for sure not confusing both, may be I am not clear instead.
But make yourself your own opinion
So you should not make differences between things detected by "proactive modules" and "not proactive" modules That "0.5 points instead of 1.0" is not very logical... but this is only my opinion
Separate names with a comma.