Some general feedback v2.4.18.184

I’ve been doing some testing of PortsLock 2.0 with CFP 2.4.18.184, and have some notes on some things that came up regarding Comodo Firewall:

First up, defining an ICMP rule. There doesn’t seem to be a way to specify “all subcodes” for any given ICMP type. The case in point is ICMP type 3 “destination unreachable”. The subcodes tell the reason why. A few of the subcodes are selectable on the pull-down menu. Note that subcode 0 is a specific reason (net unreachable, and is not an “any” placeholder). My reference materials list 14 existing RFC subcodes for ICMP type 3. The prospect of entering 14 rules is not really very appealing. I want to specify a rule to accept any ICMP type 3 packet.

An aside, the FreeBSD box that is the packet filter router for the LAN subnet can define any subcode it wants for an ICMP type 3. For example, this ipfw rule

ipfw add unreach 250 all from any to any

defines ICMP type 3, subcode 250, if that particular packet filter rule gets hit. While not an everyday occurance, such things have been done around here.

Second up, other than taking a screen shot, is there some way to print the rules for review off-line? CFP logs tell the rule number that was in effect at the time that log entry was made, which is not necessarily the same rule today. This is for both Network Monitor rules, and for Application rules.

Third is a curiosity question, and not a need (at least, not yet). Does CFP have a cmdlet interface to Windows Powershell (aka Monad)?

Fourth, in doing testing of PortsLock, the Comodo Firewall facility to watch connections proved to be tremendously useful. If you don’t have Sysinternals.com TCPView installed, the connections monitor will do the job equally as well. However, since connections come and go, sometimes literally in the blink of an eye, would it be possible to log the connections to a file? This could help a lot in getting network rules set up properly, if you happen to blink at the wrong time or don’t write fast enough or have a video camera sitting over your shoulder. I use Microsoft’s Network Monitor for things like this, but then I’m way way down there in the protocol bits. MS NetMon, and tcpdump-like things, are not for the typical Windows user. But a connection list such as shows on CFP can be extremely useful, and educational. If there was a way of printing it, or viewing it in Notepad, or something.

Fifth, is something that kind of annoyed me with PortsLock, and is something CFP does also: having a netmask in the form of 255.255.255.255. That’s a lot of typing, and so opens an opportunity for errors. With CIDR addressing these days, there are only 32 valid bit patterns. I mean, when was the last time you saw a legit 255.255.255.249? If asking for a mask, can it be done as a pulldown menu, or use the /nn notation (with 0<=nn<=32 for IPv4)?

Sixth and final, something PortsLock did that was useful, was use 0.0.0.0 as “me” for a source address in its rules. PortsLock, working on per-user rules, didn’t seem to care what the specific subnet IP address was for the laptop I was testing. The rule was in effect “allow me to any outbound”. Fairly compact, and a quick notation. The potential problem is that the laptop in question could have 6 different “me” addresses, and they don’t always mix (wired, wireless, 56k modem, VPN node, Firewire-Ethernet, and USB-Ethernet. CFP rules for the VPN node don’t allow it to talk to anything outside the VPN.)

Similarly, noting the fifth point above, the netmask is defined by the network interface. In this instance, the wired LAN address was 192.168.2.19/24. A different DHCP connection could give 192.168.7.2/29. Defining a “me/myNet@eth0” could be the only address needed by the rules, and the value of “me” and “myNet” change only according to what eth0 is plugged in to. CFP rules wouldn’t need to change (or at least, not much, maybe).

And my general comment, is that I’m extremely pleased with Comodo Firewall. When there is a need for a Windows firewall to be installed, Comodo Firewall is the choice. Good job, folks!

and CFP 2.4 is just a small piece of the upcoming CFP 3.0 (B).can’t wait for the final version

I know what you mean. There’s a support ticket that I’ve filed about this, so hopefullly the devs will implement the ability to specify other ICMP type 3 codes in v3.

Out of curiosity, I checked the “stone tablet archive” at iana.org for ICMP definitions. (http://www.iana.org/assignments/icmp-parameters). Turns out that my dead-tree reference material is out of date. There are in fact 16 subcodes for ICMP type 3, as of RFC1812. And a mere 41 ICMP types. That was a surprise, as I had thought there were only 18. I really ought to keep up with my reading…

Hi, I don’t know about all of the other stuff but, your question about logging the connections that were listed in the firewall… I think that if you enable “log” in the network monitor by setting the Permission to “Allow and Log” it will log all connections made while CF Pro is running. I think that the rule that needs to be set to apply to all connections would be listed as CF Pro’s Default Rule 0 (TCP/UDP Out, Any Source IP, Any Destination IP, Where Source Port is ANY and Destination Port is ANY). This should log all connections made while CF Pro is running. And if you would like to save the log in the form of a file for looking at later you can “right click” in the log listing and select to “Export HTML…”. Hope that helps.

P.S. I realized that this is an old thread but, I thought I had the answer to help so decided to post. Sorry if that irritated anyone.

It’s not that old a thread. Not yet at least…

You’re on to something here. Although CFP rules, when read from the top down, stop processing at the first match (so an any-any rule isn’t the way to do it), changing all rules to be allow&log or deny&log would have the effect of logging everything.

But that points out an obvious change request: a no-op rule, so you can no-op&log and do the same thing. Since it wouldn’t do a match comparison, it wouldn’t have any effect on the way CFP processes things. If rule 0 was a no-op&log, you’ve turned packet trace on, and if you turn rule 0 into just a no-op, it doesn’t do anything.

I like that thought. Thank you!