"Firewall termination defense" testing - firewallleaktester.com

New test board from firewallleaktester.com

The announcement:

http://www.firewallleaktester.com/news.htm#62

The explanation & the test result page:

http://www.firewallleaktester.com/termination_overview.php

 

I personally think there should also of been tests made for "termination of a program protected by":- and tested programs such as PG / SSM etc, to see how well they stand up to termination, and how well they protect other programs. (just a thought)

 

I think this is a good idea.

The first three firewalls did well in the "termination defense" tests , I am impressed.

 

Wasn't SKPF supposed to be better at preventing something like this now after getting help from that Matousec fellow?

 

why no tiny firewall?

 

Looks like Comodo has done rather well. But I guess we should stear clear of it because Comodo must be up to no good, eh

How about that "bullet proof" Look 'n Stop? Yeeikes!

 

bad results for LnS

i've tested look'n'stop with PG installed
all option enabled

APT

KILL3: Failed (Secure Message Handling ENABLED)

SPT -- spt1/7 + e- -f parameters

TEST7: Failed

PROCX
All PASSED

SDT
PASSED

not to bad..

 

Well, I just went over there with my below guns, and passed all but one. I was really surprised how many Prevx1 caught and jailed very quickly.

 

I notice that Stem closed the other thread about the leaktests in favor of this present one, therefore I assume it's okay to pursue herein the topic of that other thread -- namely, the leaktest results themselves, instead of ONLY the termination tests.

Am I missing something? It seems to me that Comodo did rather poorly on the leaktests, scoring only 35.2%, whereas Look 'n Stop scored 74%, more than twice as good as Comodo! Why isolate only the termination scores?

I realize that a terminated firewall isn't much use, no matter how strong it is. But isn't it equally a fact that a weak firewall that resists termination is still a weak firewall? I ask these questions from the standpoint that there are apps that will securely protect a process from termination (SSM, for instance).

Ergo, it seems to me that a strong firewall that is termination-protected by SSM or PG, is intrinsically a better security set-up than would be the case with a weak firewall standing on its own. Or am I missing something here?

 

As far as i know a older version of comodo (1.1) was tested. The most recent version (2.3) blocks most of the leaktests.

 

On the leaktest it is a rather old version of Comodo tested (V1.1.05)

 

Both this thread, and the one I closed refer to, and link to "Firewall termination defense" testing

 

@Stem- I only included my comment so as not to be considered off-thread. I apologize for not reading carefully enough.

@Martijn2 & Clweb- All the firewalls were tested as of the same point-in-time and the versions tested were current as of that moment. I'm sure that most of the firewalls have had improvements subsequent to the test. Therefore, isn't it appropriate to discuss ALL the tested firewalls on that same level playing field? Otherwise I suppose we might end up ignoring the whole test because some of the tested firewalls have since been updated.

The point of my previous post was NEITHER to disparage any firewall, NOR to promote any firewall. Actually, the FW I use & love is so old it wasn't even included in those tests. (sob)

Instead, the point of my previous post herein is that the FW termination results should be viewed in context with the leaktest performance results, and not in isolation. More to the point, which I wonder is the better choice...

+Running a strong firewall & protecting it from termination?
OR
+Running a weak firewall that needs no such protection?

I choose the former. Your mileage may differ.

 

This was mentioned under "4. Understanding the results :" in the link: http://www.firewallleaktester.com/termination_overview.php.

I think the above is a fair statement - "Firewall termination defense" tests alone cannot determine whether a firewall is good or bad.

 

Perhaps you would better call these facts to the attention of the writers who have incorrectly used test results in order to disparage Look N Stop in this thread.

I was quite aware of the test report's caveats, but it seemed to me that some of the others in this thread were not, so I sought to clarify.

 

There is nothing much I can do if they misunderstand or intentionly abuse the test results.

 

And differ it does, because I would prefer, if it’s possible, running a strong firewall with strong built-in termination protection. I believe this is better than a firewall that requires a “crutch” to be fully reliable. Having said this, I do like the idea of running a HIPS to bolster system security.

.

I am aware of them too. If my dig at Look ‘n Stop is to be misinterpreted as wholesale criticism of the product, then that is beyond my control. The comment was based on the black and white results of the tests. Look ‘n Stop failed miserably in the termination tests. That is all.

 

Nicely put.

 

I may be "old school" in my approach, but a firewalls primary and most important task is controlling internet traffic, both inbound and outbound. Without control over internet traffic, any other security application has to fight an uphill, if not an entirely hopeless battle. While it's desirable for a firewall to have built in termination resistance, it shouldn't be at the expense of the ability to control traffic. Given a choice, I'll always choose the firewall with the stronger traffic control ability, primarily because defense of the firewall process itself can be turned over to a separate application designed for such purposes, like HIPS for example.
I prefer to use separate applications for application control and traffic control for several reasons. Without getting into the "which performs their tasks better, single purpose apps or security suites?" type of discussion, my primary reason for using separate applications for each is to allow them to stand independently and defend each other. HIPS software like SSM can defend the firewall process quite well, allowing the firewall to focus on its primary task, traffic control. It also separates the targets. When they're conbined into one package, an attacker could potentially take out both should a vulnerability be found in either component. When separated, direct attacks on the firewall are difficult because it's process is defended. An app like SSM can both defend the firewall from termination and restart it should an attacker manage to terminate it, using the "keep process in memory" option. If your HIPS can do both, use both methods. If someone finds another way to terminate a process that your HIPS doesn't prevent, have it restart the firewall. At most, your firewall goes down for a few seconds instead of being taken down completely. By the same token, a good firewall blocks external attacks on the HIPS software, making it difficult to attack. Unless the attacker finds a way to bypass the firewall completely without killing the process, an attacker would almost be forced to attack both simultaneously, a much more difficult task than attacking one security program.
The leaktests and termination tests both need to be viewed in their proper perspective, starting with the fact that they are tests, which the user both willingly put on their systems, and if the tests are to be realistic, allowed to perform their functions. The user needs to start with this and how it compares to a real life scenario. While having a firewall that can resist all the process termination methods is good, the user needs to ask how such a command would be executed against their system in a real attack. Can such a termination command be sent into your system from the net? If it can, then your firewall is failing in its primary purpose, traffic control, and the user either needs to examine their ruleset for weak rules or replace the firewall. Another example would be the PCAudit firewall test. Any decent HIPS, whether it's part of a firewall suite or separate like SSM or PG, should detect the process and the hook it creates and defeat it. That's not a test of the firewall itself or the firewall ruleset. Let the test run and see if your firewall and its ruleset are set up as they should be. This test can be defeated with firewall rules alone, at least Kerio 2.1.5 can, with no help from the HIPS software. By watching both the firewall status screen and any alerts your firewall gives you, the test itself can teach you how such exploits work, and better enable you to learn to defeat at attack of this nature. Regarding why you'd want to be able to defeat such a test with firewall rules when HIPS beats it so easily, ask yourself one question. If your HIPS fails for whatever reason, or if someone finds a way to use or "hook" another application in a manner your HIPS software doesn't detect, are you still protected? Don't rely on just one layer of defense when you have several available to you. If you start with the assumption that a malicious application that functions like PCAudit is slipped into your system with a command to start, (most likely accomplished by tricking a user) how many layers will it have to penetrate outwards to do its job? At least 3:
1, starting the process itself undetected.
2, hooking another application undetected.
3, penetrating the firewall.
That doesn't include the layers it had to get past to get into your system to begin with and whatever defenses you have protecting the registry or other autostart locations it would need to launch it.
One other point needs to be made here. While there's definite value in testing individual security apps, how well your security package protects you is what really matters. Whether your firewall defends itself from termination or is defended by a separate HIPS, what matters is that it is defended. If your firewall doesn't defend itself, test whether your separate HIPS is truly defending it, but bear in mind that the test is artificial. You allowed the process termination app to run. You allowed/sent the termination command. You need to examine how this could be done in a real attack. Can it be done from outside, from the net? How would the command bypass your firewall? If it were to be done from inside your PC, how would the malicious app get there? How would it be launched? Unless the user was tricked into downloading the malware or it was on a CD or something similar, it came thru your firewall, either the command or the file itself. It still comes back to how well your firewall controls traffic. If it doesn't do this well, it doesn't matter what else it does. It's not performing its primary task. No matter what you use or how many security apps you run, as far as security-ware is concerned, it all starts at the firewall and how well it does its primary job.
Rick