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

Discussion in 'other firewalls' started by CoolWebSearch, Mar 12, 2008.

Thread Status:
Not open for further replies.
  1. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,216
    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.
     
  2. FadeAway

    FadeAway Registered Member

    Joined:
    Apr 6, 2007
    Posts:
    270
    Location:
    USA
    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.
     
  3. EricEgan

    EricEgan Registered Member

    Joined:
    May 3, 2007
    Posts:
    22
    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
     
  4. Nebulus

    Nebulus Registered Member

    Joined:
    Jan 20, 2007
    Posts:
    1,582
    Location:
    European Union
    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.
     
  5. ggf31416

    ggf31416 Registered Member

    Joined:
    Aug 20, 2006
    Posts:
    314
    Location:
    Uruguay
    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.
     
  6. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    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.
     
  7. Dieselman

    Dieselman Registered Member

    Joined:
    Jan 6, 2008
    Posts:
    795
    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.
     
  8. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,216
  9. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,216
    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!?
     
  10. FadeAway

    FadeAway Registered Member

    Joined:
    Apr 6, 2007
    Posts:
    270
    Location:
    USA
    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!)
     
  11. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,216
    So, you were protected from UDP attacks?
     
  12. FadeAway

    FadeAway Registered Member

    Joined:
    Apr 6, 2007
    Posts:
    270
    Location:
    USA
    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).
     
    Last edited: Mar 14, 2008
  13. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,216
    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.
     
Thread Status:
Not open for further replies.