Comodo is working or not?

Hi aigle,

I do not know why you would want to place such a rule, as it would be easier to just place a block all inbound TCP rule. If the rule is fired/logged, the port info will be within the log.

I have just installed Comodo and put together a quick ruleset that I would use for Browser/mail. This is a restrictive ruleset at network level. If I was to continue to use Comodo, I would place the IP`s of my DNS/Mail servers within the rules.

Quick example:- I have split the rules for logging (although it would be better if a rule could be named)

 

Thanks Stem. I will change it. As I said, I use only default rules by Comodo. My only concern was that Comodo does not show any high risk inbound blocked/ logged. I was wondering what about those pop ups I used to get from Kaspersky antihacker and ZAP in the past. May be that were just bells n whistles and Comodo is doing same but just a bit silently.

 

Nice post from you Stem. Adds some more restrictions that are not in the default 5 rules for the outgoing connections. Especially that comment for DNS to ISP servers only.
Not sure if your rule number 2 should be moved down after those allowed ones? I would move all 3 of them down there as a habit of first allow rules and then blocking and that default install final block all incoming rule should take care of them already?
So as told to KDNeese, again, what is the need for these block rules? Except below answered to have a different block rule ID in the log. As poor as the log is now, I really see no much use to all your 3 first rules. IF you have that final block rule in place of course that you don't have now. Maybe i made it to log, but i think it was set to log already.

I understand your reasoning too KDNeese, separating the various blockings with a rule. Too bad as Stem told, no rule description is logged. Or possibility to tick those network rules on/off. So it is totally quite redundant to make those rules in my opinion. I stand corrected if i am wrong, but Comodo as a default install blocks all incoming, except them few pings.

Comodo needs some polishing to do for a really nice firewall, the interface, I don't mean any shiny looks they are ok, but basic functionality and of course that log view sucks big time.
I am not happy with that block all rule at the bottom, but since network and application filtering are separate and application filtering as told is not trusted as much, what other solution is there to be made?

I think as now Comodo is a quite good firewall. I am just more a kerio 2.1.5 guy. I don't like betas and I don't call comodo as it is a beta, but any new firewall, with any new release is of course always a little bit beta. Needs time to test and all that. And firewalls, as packet filtering, with no extras, they are working. Comodo is a bit more than packet filter, but this thread I think takes back some considerations how well it matches in that. Basic filtering and logging that are what most constitute a firewall.
No mention that I lost some of my computer OLE things while playing with latest Comodo release and after reboot, some of them are just not working anymore. I blame my ailing hardware as much as Comodo. But Comodo was a hazard risk to run on my system.

 

Hi aigle

I did perform scanning (to check logging), most, but not all TCP/UDP scans where logged, but none as "High" Dropped inbound connection/UDP to closed ports are not a major concern (there are a lot). I do think the logging could be better.
I cannot understand some missed logging from my scans!

 

thanks for that testing. I have heard some people over here complaining about its logging as well.

 

KDNeese,

I don't have that set up in the network rules, but I do have my browsers limited in the application rules. One option in Comodo is you can set the option as "block all except," then just allow ports 80 & 443 as the exceptions. I do allow outbound local ports 1031-4999 for my browsers.

I have other rules which I didn't include in my posts, as I only wanted to provide some basic ones. Some of my other rules block outbound connections for certain ports (all protocols), with port 23 being one of them.

Good idea. I do have it set up that way in my application rules, but for whatever reason didn't think to do that in my generic network rules. I'm so used to Kerio 2.1.5 it's taken a little getting used to having two sets of rules to deal with. Personally, I will be glad when Sourceforge gets their Kerio clone up and running, as I'm dying to try that.

 

When I first tried Comodo, I did use the rules to block "not (all except)", and then place the remote ports as you mentioned, but later builds changed, and there where popups to allow these remote ports (even with those rules in place) so I found little point in using them.

It would be better, if posting rules, to post all relavent rules, not just part off. As you would of seen, other members have been trying these rules, and as I mentioned, the rules posted are insufficient for your statement of what they could accomplish, and would leave a member thinking they where protected when not,
Example

would give the impression that simply blocking the inbound to this port(as posted in your rules) would stop "Phoning home" from this port when it would not.

 

Stem, I still don't understand how your network rules work?
I am currently running kerio 2.1.5 and so cannot test your rule ID 2 (the 3rd rule), but it is too high up in those rules in my opinion and as far as I understand it is blocking everything incoming? So the first 2 rules are not even needed.

Remember that the default rules taken as a screencapture from program's pdf-manual are:

 

As mentioned, I split the rules for logging purpose, (so rule event 0,1,2 etc could be found in logging). Comodo has TCP SPI (and pseudo UDP SPI). The inbound blocking rules only block unsolicited inbound, not returned packets.
The rules I posted work within Comodo. The rules may not work in Kerio 2.1.5, but they where not created for that firewall.

Yes, far too open for my liking.

 

This has nothing to do with kerio 2.1.5 as you well do know.

I thought that rule with id 2, could block also incoming ICMP's?

Another point from my Comodo experience was keeping various rules for insolicited incoming rules below the final block rule when the apps like torrents were not running. Your solution needs to put them on top. Fine, but not so convenient.

To me those default 'network' rules were quite ok, since one should be able to restrict 'application' rules to certain ports, like browsers to TCP 80, 443. At least with high alert level settings. I did get prompted for the unknown outgoing app connections if they were not covered by already existing ports/protocols in appp rules. I agree with you that one could restrict outgoing network rules to those local/remote ports you put there. Especially when allowing all in application rules as that that "low level of alert" settings does.

And incoming with default rules Comodo blocks all unsolicited as you said, so I see no point in putting those 3 block rules there on top. I finish now, we obviously think different. I did study Comodo quite thorough, but must have missed something.