How To - Understanding & Creating Network Control Rules properly

[Guest]

[panic]

How would  Comodo handle this rule, which would seem to be logically, and functionally impossible; considering the current meaning of "source ip" and "destination ip".

example Network Control Rule:

Action = Allow
Protocol = TCP/UDP
Direction = In/Out
Source IP = 5.5.5.5             -this is my ip
Destination IP = 7.7.7.7      -this is site X's ip   
Source port = Any
Destination port = Any

Scenario:

When my packet goes out the rule matches ok, but when 7.7.7.7 sends a packet back to me the rule goes FALSE since 7.7.7.7 is now the source. (According to current definition)

The same situation exists with one host being an IP or IP range when the other host is Any IP.

The only time an "In/Out" rule seems logically possible is when both the destination IP and source IP ranges are set to "Any". IF Source IP was "Local Machine/Host" and Destination IP was "Remote Machine/Host" then the logic would work just fine and a single rule to cover In/Out would match the rule statement.

Therefore, is it logically or functionally possible to write a single rule to allow "In/Out" communication between MY ip range (or single address) and any other host?


I can see why the earlier definition of "Remote" was changed to "Destination", but swapping which computer "source" and "destination" refers to, based on packet direction, makes the "In/Out" logic simply impossible.....(unless the ip numbers switch computers too, at the same time)

edit 2006.09.21 0850hrs
If a list or set of ip's were possible, the logic could be satisfied by using:
Source IP = 5.5.5.5,7.7.7.7
Destination IP = 5.5.5.5,7.7.7.7

How would Comodo parse and implement the example Network Control Rule? Since sets or lists of IP's are not currently possible, would 2 rules need to be written to achieve the desired result?

edit
After giving this some additional thought, and considering the latest definition of "Source IP" and "Destination IP", and those limitations, the solutions i see are:

1. Whenever "In/Out" is selected for a rule: source ip AND destination ip must default to "Any". If u want an In AND Out rule for a specific addy or range then u will need to make 2 rules. The underlying firewall code and interface will need to be changed to "grey out" any choice except
"Any" when an "In/Out" rule is selected.

2. Change "Source IP" to mean (and display) "Local Host/Machine". This will always be YOUR IP. Change "Destination IP" to mean (and display) "Remote Host/Machine. This will always be the remote host(s) IP specification. The underlying firewall code and interface will need to be changed.
______
Sticky

Hey sticky,

Please bear in mind that teh following is just my opinion. I simply don't use In/Out rules at all. I create separate In rules and separate Out rules. In the scenario you've outlined, this would necessitate four rules - in and out for each IP. I prefer this method as I can more readily monitor traffic in and out. Logs are easier to follow and diagnose, in the event of a stuffup, as well.

Hope this helps,
Ewen :-)

[Rotty]

So if an In/Out rule is fired you can't tell whether it was going in or out?

cheers, rotty

[Little Mac]

mOngOd -

TNX for the great explanation of NCR!  I got a lot out of it.  Good mental exercise; stretches my li'l brain.   

[Sticky]

Hey sticky,

Please bear in mind that teh following is just my opinion. I simply don't use In/Out rules at all. I create separate In rules and separate Out rules. In the scenario you've outlined, this would necessitate four rules - in and out for each IP. I prefer this method as I can more readily monitor traffic in and out. Logs are easier to follow and diagnose, in the event of a stuffup, as well.

Hope this helps,
Ewen :-)

I certainly agree about not using the "In/Out" rule in part. I wont use (or make) an ""In/Out" rule UNLESS "Source IP" and "Destination IP" both equal "Any". Mainly because the logic is impossible if an IP range or address is used in either field. (add "Source Port" and "Destination Port" to our equation... (my head hurts, anybody got an aspirin? ))

My only real point is that I wanted everyone to be aware of the impossible logic that currently exists when trying to make such a rule under the current definitions of "Source IP" and "Destination IP".

I might make an "In/Out" rule with a specified IP if anyone knows how the rule would be parsed by the firewall...
I could fire up something like Ethereal and get a friend online to test what the firewall will do, but at this stage of the firewall's development this is a job for the developers... (even if i reported the results, this is a problem that will need the developers' attention anyway. I believe that if they haven't done this yet, they certainly will...  )

It really does need to be fixed one way or another...

I have only been using Comodo firewall for several days now, and except for this one irritating issue, like many others I think that  . With just a bit more tuning it might go into history with the likes of Kerio 2.1.5....  High praise indeed.

[m0ng0d]

mOngOd -

TNX for the great explanation of NCR!  I got a lot out of it.  Good mental exercise; stretches my li'l brain.   

Thanks for the feedback, I do appreciate it.

[yomahtoot]

Hi all. I just installed comodo with its default settings which are said to be robust. But I look at my network control rules and see this:

ID    Permission       Protocol         Source     Destination    Criteria
0      Allow            TCP/UDP Out       Any            Any           
1      Allow                 ICMP In          Any            Any          Where icmp message is echo request
2      Allow                 ICMP In          Any            Any      Where icmp message is fragmentation needed
3      Allow                 ICMP In          Any            Any           Where icmp message is time exceeded
4     Allow                   IP Out           Any            Any           Where IPPROTO is GRE
5     Allow (+log)       IP In/Out        Any           Any             Where IPPROTO is any


Surely the "allow" rules for IDs 1,2 and 3 for allowing incoming echo requests are not a good thing? I've always been told that allowing ping requests to your computer is a security risk. These are the default settings. Should I change them to "block". Also what is IPPROTO GRE?

Thanks.

[Little Mac]

Hi all. I just installed comodo with its default settings which are said to be robust. But I look at my network control rules and see this:

ID    Permission       Protocol         Source     Destination    Criteria
0      Allow            TCP/UDP Out       Any            Any           
1      Allow                 ICMP In          Any            Any          Where icmp message is echo request
2      Allow                 ICMP In          Any            Any      Where icmp message is fragmentation needed
3      Allow                 ICMP In          Any            Any           Where icmp message is time exceeded
4     Allow                   IP Out           Any            Any           Where IPPROTO is GRE
5     Allow (+log)       IP In/Out        Any           Any             Where IPPROTO is any


Surely the "allow" rules for IDs 1,2 and 3 for allowing incoming echo requests are not a good thing? I've always been told that allowing ping requests to your computer is a security risk. These are the default settings. Should I change them to "block". Also what is IPPROTO GRE?

Thanks.

I saw (and thought) the same thing when I saw those rules propagated on CPF when I installed it a few weeks ago.  I worked my way through m0ng0d's Network Rules post and redid it in accordance with that.  I didn't think all the "In" was very good, and a lot of the other stuff just didn't make sense to my non-computer-genius brain.     I had to take some ibuprofen.   

[NewUser]

I believe the default for rule ID 1 is actually "ICMP Out", not "ICMP In".  This should allow you to be the "ping-er" but not the "ping-ee".

Rule IDs 2 and 3 seem to have something to do with determining the appropriate packet size to transmit over a connection, and letting your system know when it needs to re-send data that was lost in transit.

[m0ng0d]

I believe I read that those ICMP lines are needed to resolve some "issues" that people were having seeing some content on certain web-sites.

Please understand that my guide here was written based on an older version of CPF where there were only 3 default rules.  My goal was to help people understand how they worked and why they were added as defaults; then I threw my 4th rule in for good measure.

The default rules have evolved over time and are still an excellent starting point.  The largest thing that should "separate" users is whether or not they are part of a LAN... because if you're not on a LAN, the ZONE can be easily replaced by your IP in the rules (for example).

Regarding the In/Out "combo" rules... They are invalid for the most part.  There are some valid examples of rules using it, but I always prefer using separate rules; keeps things straight in my mind... and I like being able to set a rule to Log if i want to watch the traffic or troubleshoot.  If the rule contains specific traffic, then my log will be small and easy to sort through to find what I am looking for.

[Michele]

Monogod,
   What are the current (Nov. 17, 06) default rules?

[m0ng0d]

As of the official build 2.3.6.81...

The default rules are:

ID    Permission     Protocol       Source   Destination    Criteria
0      Allow          TCP/UDP Out     Any          Any           
1      Allow             ICMP Out        Any         Any          Where icmp message is echo request
2      Allow             ICMP In          Any          Any    Where icmp message is fragmentation needed
3      Allow             ICMP In          Any          Any          Where icmp message is time exceeded
4     Allow               IP Out           Any          Any          Where IPPROTO is GRE
5     Block (+log)   IP In/Out          Any          Any           Where IPPROTO is ANY


If you run the Add Trusted Network Zone wizard (if you share a LAN with other PC's), you will also get: (which I promote to be the new ID 0 & 1 rules)

ID    Permission       Protocol         Source     Destination    Criteria
0      Allow                IP Out             Any            ZONE         
1      Allow                IP In              ZONE            Any         

[Michele]

Monogod,

   Thank you very much for taking time to respond. I began a thread: Desktop Security Products/Comodo Firewall/Help/Basic Setup Novice Questions (Nov 14, 06). Several of my initial questions remain unanswered. If you have the time I'd love your input. I need someone technically savvy enough to compare/contrast the automatic configuration with Stem's setup. I can tell you fit the bill. 
   
    Also in re to a fix for Avast issue--if there isn't one coming could you please let me know. I understand not all Avast/Comodo users are experiencing difficulties. We were told to upgrade to version 2.4 on the Avast forum, however, I see a Chinese version has been released. I can appreciate the challenge of producing multilingual versions. If this is Comodo's focus for the time being, it's understandable & I can make decisions accordingly.

   Perhaps I should have PM'd you. It's not my intent to double post.

Michele

[AOwL]

There is an English version too, not just Chinese,

[Michele]

AOwL,
   You must be referring to the beta release with multiple known issues. Is it buffer overflow that causes the 2.3.6 conflicts with Avast? The logic in beta use as a means of "issue-free" resolution escapes me.
   

[Eric Cryptid]

Just a quick question. I have these rules set as the above default with the trusted network included. How come I mainly see Outgoing Blocked items (re Rule 7) yet very very few incoming blocked items? Is it just a case that I'm going to relatively safe sites? just asking...

[Tags:]