I must admit, I think CFP's inbound protection is not that good...

Hi, everybody.
Since I've been, using various firewalls, I decided to try out CFP 3.0.
However, I must admit that I'm not completely sure if they care about CFP 3.0's inbound protection that much.

Although, both Egemen and Melih said that they need practical proof that CFP's inbound protection is not that good, I still doubt about inbound protection.

The main reason is that it seems to me that there was too small number of intruders blocked, while ZA blocked about 100 of them in one hour, CFP blocked them only 36!?

So, I need a favor:
Can anyone please test ZA Pro at Sunday evening/night from 5pm to 10 pm, and can someone else test CFP 3.0 also from 5pm to 10 pm at Sunday evening/night, please?

The reason why I'm asking this is because my computer is on re-installation process, and I need someone who can test these firewalls how many intrusions CFP 3.0 blocked and How many ZA Pro blocked in these 5 hours straight?

The reason why I'm asking this is because I tested several times ZA Pro in 3 hours period with ARP protection nabled, unchecked "Allow VPN protocols" icon, no sharing with other computers which means both firewalls are set too High level, enable Block Internet Servers, Block trusted servers, Filter IP traffic over 1394, check Lock hosts file.
In 3 hours ZA Pro 7.0.462 blocked over 4000 intrusions from 6pm to 9pm at Sunday evening.
I'm wondering how much will CFP 3.0 block them?
Just to make an comparison, please.

Thank you for your time and patience


Also, this is a copy what Egemen wrote about Stateful Packet Inspection and Deep Packet Inspection:

It would be too naive to claim that having a network based packet inspection can prevent malware from being downloaded and run.

Network Intrusion Detection and Prevention is conceptually similar to anti virus scanning such that packets are scanned for known signatures or patterns. It adds an additional layer of security but is far from being able to stop most of the known threats, never mind the unknown ones.

Malware can be trasmitted over an encrypted traffic, e.g., SSL, VPN or SSL based Jabber(IM) protocols. And even over the unencrypted traffic, detecting malware detection is not 100% guaranteed. When you compress some files and transfer it, are those packet inpections going to build the whole archieve, decompress it, and then scan? So they are svery limited and cant be assumed as the main line of defense.

SPI, Deep packet inspection or intrusion detection are just another additional security layer which can not be considered the main line of defense. For server protection, it can help to protect against hackers, and automated tools. Noone considers, even for the server computers, this, as the main line of defense.

you have 100% clean PC:

1 - Lets assume you have an AV software. If AV signatures did not detect a threat, after some signature updates, you will be able to detect the virus later, possibly after all the harm done. None the less, lets assume this is acceptable. This would be generally be the only way you would be infected.

2 - Lets assume you dont have an AV but an intrusion detection system which scans network packets against some signatures:

Lets assume a known malware is going to be transfered:

- If the malware is tranfered over an encrypted channel, you are vulnerable
- If the malware is transfered over an unencrypted channel, but with an uncommon protocol that your IDS does not know, you are vulnerable
- If the malware transfered, over an unencrypted channel, but with an infected setup file, you are vulnerable, especially if the file is large.
- If the malware comes from another source than network, you are vulnerable

At the network layer, you are quite limited in terms of detection capabilities(you have a couple of packets and that all). Consider AV programs having everything(emulation, unpacking, heuristics etc) failing to detect malware. Never mind a fragment of malware inside a packet.

If your IDS does not know the malware, it can not detect it and even after the signature updates. Unlike an AV, it can do nothing after signature updates.

So an N-IDS, is a nice, additional layer of security. But it is not comparable to an H-IPS and can not be trusted as the main line of the defense. Would you trust a firewall only as your main line of defense?

Cheers.

 

Incoming intrusions like worm scans, messenger spam, file sharing
searches, etc., are all aimed at IP addresses. What two different
systems randomly are probed with, at the same time on the same day,
are generally unrelated.

 

You do have the option to protect ARP in Comodo Firewall 3 under Attack Detection Settings.

There are a number of other options on there such as protocol analysis etc but most of these tend to slow down your internet connection etc...

I find Comodo's inbound protection varied. ZA Pro and CPF work differently. CPF certainly beats ZA Pro with regards to system protection with it's Defense+ enabled especially when it comes to Leak Protection.

ZA Pro uses a lot more system resources but I suppose it's really a matter of preference.

Which do you like best? I know what I've gone with.

Eric

 

I don't belive that the number of so called "intrusions" in CPF is in any way relevant for the quality of inbound protection. The number is there just to make the user feel he is secure, and it has no practical value. A better test for inbound protection would be something like ShieldsUp from GRC.com, or even to scan yourself with a tool like nmap, from another computer.

 

The main problem with Comodo are inexperienced users allowing system and svchost.exe to receive inbound connections from the other side of the world, as "Alert to incoming connections" is the default mode and they read "safe" in the alert windows. But is not Comodo's fault that users don't know how to use and configure a firewall.

 

Hi CoolWebSearch,

You would really need to set up and check correctly before making such a statement.

Simply going from logs could only show one firewall logs more than another.

 

You need to run the stealth port wizard in Comodo and select the option to "block all incoming connections". First delete all your global rules. You will see your intrusions pick up. Set system and svchost to outgoing only.

 

Hi, Stem.
I'm not so sure.
Please, check this thread, it seems to me that CFP 3.0 couldn't protect against UDP flood!?
http://forums.comodo.com/leak_testi..._research/ddos_attack_udp_flood-t20441.0.html

 

I'm not so sure, if ZA Pro is weaker than CFP 3.0.
It seems to me that ZA Pro does indeed pass all known leak-tests. The 4 tests that Matousec refers where ZA Pro supposedly failed is because in these 4 tests ZA Pro used user-mode hooks not kernel-mode hooks.
Can anybody test PC Flank leak-test, OSFwbypass leaktest, and CPILSuite leaktest against ZA Pro?
Because supposedly ZA Pro fails PC Flank leak-test, OSFwbypass leaktest and also fails 2 tests of CPILSuite!?

 

I don't follow your logic. According to that thread, Comodo defended
against the attack, which is why it was logged. That's what a
firewall is supposed to do.

I can't speak for Comodo 3.0, I only ran it for a day. But I
ran Comodo 2.4 for several weeks on one machine, and constantly got
the "UDP flood" alert when just surfing. I kept switching back and forth
with CHX3, which showed no such thing. Looking at the information
provided in the Comodo logs, the "UDP flood" was coming from
my DNS server. IMO, just a bug in Comodo. (I figured out a way to
stop it, too!)

 

So, you were protected from UDP attacks?

 

Yes. The firewall automatically switched into "Emergency Mode,", and
blocked the packets and the attacker according to the parameters set
under "Advanced Attack Detection and Prevention."

The problem was, the "attacker" was a false alarm. Increasing the
Traffic Rate packets per second from the default figure to a higher
number, ended the false alarms. The UDP SPI in CHX3 recognized the
traffic as legitimate, but Comodo saw it as an attack because of the
rate (only my guess).

 

Ok, than I misunderstood it, because on Comodo's forums someone said that you should block all ICMP types in the general rule section. Because of that I thought that CFP 3.0 failed to block UDP attack.