I noticed a possible flaw in the way the rules are handled in comodo firewall (64-bit Windows 7). This bug is in the way the firewall evaluates application rules and global rules.
Basically the following configuration was used:
Blacklist IP 192.168.1.1 (Deny all from any host to this 192.168.1.1 for any protocol)
Application app1 is allowed all TCP outbound to ANY HOST
Application app1 can still connect to 192.168.1.1 despite the global rule blacklist this IP.
I would think the global rule black listing the IP would override the application rule.
Please Post a screen shot of the global rule
We would very much appreciate it if you would edit your first post to create an issue report in line with the bug forum guidelines and format here. You can copy and paste the format from this topic.
To understand the reasons why we ask you to follow these guidelines please see below.
WHY WE ASK YOU TO FOLLOW THESE GUIDELINES
Bugs/issues can be impossible or very time consuming to fix if developers don’t have enough information to reproduce them. Since CIS is free, development time is limited. So if you want your issue fixed, please use the format below to describe it.
To avoid clutter, issues not described in the format below your post will not be moved to the ‘moderator verified’ issues topic. This means that the developers may not look at it.
Best wishes and many thanks in anticipation
Please see the following screenshots of the application /global rules configuration:
This is the wireshark data capture. I’m not a networking expert (Part of why I am even looking at this is I am doing malware analysis, so I’m more on the app side). It appears no data is actually transferred to the blacklisted IP, but there appears to still be a partial TCP handshake.
When configuring windows firewall similarly, there is no such packet capture, so I figured Comodo would act the same.
*Also, I believe when I also blocked incoming connections from the black listed IP, the issue was resolved. I don’t understand how their could be any incoming packets from the blacklisted IP though if none were able to be sent out.
Things work different with CIS.
The easiest way of blocking an IP address completely is to add it to Blocked Zones.
Look at the image in Global Rules section of the online manual. Incoming traffic first sees Global Rules and then Application Rules. Outgoing traffic first sees Application Rules and then Global Rules.
If you want to block all traffic to and from one IP address by making rules in Global Rules then you make one rule for the incoming traffic and one rule for the outgoing traffic.
As a rule of thumb you typically use Global Rules to allow for incoming traffic as the default is block and use Application Rules to control outgoing traffic.
Even though the connection is being blocked, the behaviour is a little odd.
I reproduced the scenario and looking at the wireshark capture, we see the DNS query and response, followed by a RESET/ACK response form the destination. There is no outbound request, other than the DNS. However, if we allow the connection, unsurprisingly, we see the whole transaction.
Another interesting aspect of this is the CIS firewall log entry for the blocked connection, which is actually presented by WOS and not by the application that made the initial request. even though I would have expected the application to be listening.
Need to think about this…