I’ve just started to test Comodo Firewall, and while my first impression of it is rather positive, I am a bit concerned by what I read on matousec.com about their in-depth test of Comodo Firewall version 2.3.6.81. Quote:
The implementation of the security design is very superficial. Today's malware creators would not have problems to bypass the protection of Comodo. [b]The development of this firewall probably missed independent betatesting of its security features because the number and the nature of bugs we have found in it is alarming. This is why we can not recommend Comodo Personal Firewall as a personal firewall solution to anyone who requires real protection against today's malware.[/b] You can see public information about bugs we found in Comodo Personal Firewall in the following sections below.
My question: Have these bugs all been fixed in the current release of Comodo Firewall?
There’s one thing I’m uncertain of: if CFP doesn’t pass those 2, how come Matousec’s leak tests results doesn’t show it failing any of them or why weren’t those included as part of his leak testing with the other firewalls?
I don´t think the Matousec moustec ran those specific tests in their tests, they do not classify them a leak tests they call them “testing programs”. These are listed as vlnerabilites below. And I ran them with 2.4.18.184 and they failed. It also seems I remember reading in the comodo forums that these were not being passed by CPF 2.4.18.184. The good news is they seem to passing now (CFPA 3.0.2.5)in my tests
Matousec Advisory 2007-03-01.01
Comodo Bypassing settings protection using magic pipe Vulnerability
Vulnerable software: Comodo Firewall Pro 2.4.18.184
Matousec Advisory 2007-02-15.01
Comodo DLL injection via weak hash function exploitation Vulnerability
Vulnerable software: Comodo Firewall Pro 2.4.17.183 (2-4-18.184 was released on February 16,2007)
OD
PS
Edit:Note on methodology: I read on the Matousec site that in the methodology used for one of the above mentioned tests was to always click “Allow” whenever given the option to "Allow " or “Deny”. In my methodolgy I click “Allow” only to start the program with a parent of Command. (if run from the Command Prompt) or Explorer.exe if the program is launched from the Windows GUI. Also if the program is supposed to display a screenshot in paint or another graphics program I will “Allow” acces to this program at the end of the test to see itf the screen shot is displayed. at all other prompts I click Deny as if I don´t what the program is that is asking for access. This is my normal procedure if something fails to function properly I will save what is need and reboot if that is what is required.
And it looks like they’re very definitively not limiting themselves to firewalls any longer… they’ve tested SSM & DSA, neither of which is in any way a firewall. Odd that Matousec doesn’t seem to specify the difference. These “firewalls” do nothing to filter traffic or have any bearing on connectivity; more like an IDS than a FW.
It also appears to me that they’re gearing up for full HIPS testing, rather than Firewall w/HIPS testing. I note that ZA Free scored much lower than it did before, as did several others that used to be fairly well ranked. They even appear to have revamped one of their tests just to make sure that a particular firewall no longer passed it.
It’s still nice to see CFP 2.4 at the top of the heap, but concerning that they seem to be changing their approach in such a manner.
LM, DSA does work as a stateful firewall (no control over the rules, only outbound application control). It shares some of Private Firewall’s code.
SSM also has outbound app control, but not a real firewall. Regarding SSM, if you place a packet filter with it, you’re done.
I did some more looking, and find that DSA alerts the user to In/Out traffic that is application-specific; sounds more like an ABA sort of thing than an Application Monitor. No network control over traffic in general.
SSM 2.2 on allows the user basic control over application connectivity. Still no traffic control in general.
I guess, based on other current dedicated firewalls that only offer application control, this would put them on the list. But this still wouldn’t offer any sort of inbound protection, wouldn’t do what a firewall should from that standpoint (denial of service, port scanning, etc). While either would no doubt be good in conjunction with a firewall, as part of layered security, I still think it’s a bit of a stretch for Matousec to test them as a “firewalls” along with the others that really are firewalls.
Since it’s about leak tests, HIPS should be able to block them. I understand your opinion though.
A minor correction: DSA can be used as a firewall, you just have no control over the network rules, only per process, and those are limited enough too. If you disable Windows firewall, and install DSA only, the security center will identify DSA as a firewall. That’s because it is one, a stateful one. Would i use it alone? NO, i can’t see the rules ;D
But if DSA has no network/traffic control, how can it possibly be a Stateful (Stateful Packet Inspection) firewall? By definition this would mean that it inspects each packet for authenticity (short definition, of course…). If it’s only controlling applicational access, where’s the SPI come into play?
I did not see anything in their information that suggested DSA has any control over the transmission of information (packets, etc); only over whether a specific application is allowed to make or accept a given connection attempt.
However, I take it that you’ve used DSA; having done so, you may be in a better position to comment on what it does/how it works than they are (real-world stuff, rather than computer lab)…
My fault. what i mean by control is user’s control over the rules. There’s no NetMon like in Comodo, and i don’t remember well, but it was almost ‘svchost, deny or allow?’ , yes or no, not what ports, ips etc.
Read from here: Dynamic Security Agent (DSA) to replace firewall??
My name is Chris Iannicello, Product Manager for Dynamic Security Agent. I wanted comment that DSA does also provide protection for TCP, UDP, ICMP and and UDP Protocols, just like our personal firewall, Privatefirewall. We do have some copy on our website that mentions only TCP, but the other are protected as well.
However, you are correct in that DSA does not provide any functionality to set specific rules per application like Privatefirewall.
DSA does make ports invisible to port scans and does protect unauthorized entry the same as a dedicated firewall. When referring to 'Application Security', that is only one module within DSA.
Basically, DSA is the same as Privatefirewall and provides a comparable amount of protection except you cannot create custom rules for Applications, have no access to a firewall log, and does not display port tracking details (which ports are being used by your system at that moment, etc.). With DSA, you can control which applications access the Internet, but cannot specify ports or specific TCP or UDP rules per application like you can in Privatefirewall.
If you install DSA and then run a port scan (www.grc.com), etc., all the ports should be ‘stealth’, unless you have an app like Skype that keep certain ports open etc.)
While DSA has 4 visible modules in its interface (System Anomaly, Email Anomaly, Process Detection, and Application Security), it also contains Privatefirewall’s proprietary layer-3 firewall using stateful packet inspection technology running in the background.
Well, he’s pretty specific about that, but their website does not support his statements in the least (which he even acknowledges). Kind of odd. Of course, I’m sure they want the $$ generated by FW sales, so they don’t want folks thinking they can have the same thing for free with DSA, LOL.
LM
PS: Amen to that! ;D For that matter, there’s no paid version that tops it either, according to Matousec…
I think the thinking behind testing these producs was that they are testing leak tsts which is primarily out bound testing but I think they should be more specific in their product notation