If you're like me, your experience with software firewalls has primarily been
an application is trying to receive/send some form of communication... do you wish to allow it?... we say
yes/
no, choose whether it should remember our answer, and life continues until the next prompt.
Not that there is anything wrong with that experience, that was the norm for our beloved firewalls of old... until one day we realize that the product(s) we've stuck with (or flipped between) hasn't been updated for months/years, or is a resource hog, etc... and found ourselves searching for, finding, and installing
Comodo Personal Firewall (CPF).
We open up CPF for the first time, see an
Application Monitor, and get all excited like we found our
comfort zone once again. And for the most part, we are right, but here is where our education begins, as
Application Control Rules don't operate alone... they require
Network Control Rules (within the Network Monitor) to set the stage for all communication flow. (I think I have read this referred to as
Traffic Shaping.)
Now we can bring a quick end to our education by using the
Add a trusted zone Wizard (within Tasks) which will help create some core rules to let some basic communication flow in/out of our PC... but where is the fun in that? And what would we have learned?
(if you are interested in the learning curve I went through, check out http://forums.comodo.com/index.php/topic,1102.0.html)So let's start the education!Now before we jump into
Network Control Rule creation, let's get the Rules Terminology straight.
Network Control Rule's TerminologyRule ID - sets the order Rules are applied. A communication attempt starts at the top of the
Network Control Rules (
ID 0), and works it's way down through the Rules (unless stopped/blocked) until it finds a Rule that allows the comminication (unless blocked before it hits that Rule).
Action/Permission - when a communication attempt occurs, do we want to
Allow or
Block it?
Protocol - "A convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints." Or more simply put, the type of communication (i.e. IP, TCP, UDP, etc...)
http://en.wikipedia.org/wiki/Protocol_%28computing%29Port -
TCP and UDP protocols typically use ports to map data to a particular process running on a computer. As an example, a server used for sending and receiving email may provide both an SMTP and a POP3 service; these will be handled by different server processes, and the port number will be used to determine which data is associated with which process.
http://en.wikipedia.org/wiki/TCP_and_UDP_portDirection: Communication requests can hit our PC whether we've asked for it or not
- Inbound Rule - defines unrequested inbound communication (for the selected Protocol)... like hackers probing our ports, or a friend on our LAN trying to join the FPS/RTS game we are hosting.
- Outbound Rule - defines requested inbound communication (for the selected Protocol)... like opening IE, "requesting" google to load, and receiving the inbound homepage
Source IP - who
made the request for communication (IP address or Range/Zone)
Remote IP - who is
responding to a request for communication, or is the
expected responder (IP address or Range/Zone)
*** For more verbose terminology definitions for these and other things, please refer to Ewen's Internet and Networking Terminology for Beginners ***One of the most important observations on the definitions above (other than the heirarchy of the Rules set by the Rule ID) is that both InBound Rules and OutBound Rules both control information comming into our PC. InBound Rules deal with incoming information/communication we didn't ask to happen (but may want to happen), while OutBound Rules deal with incoming information/communication we asked to happen.Ok, assuming that my definitions are well in hand, let's start putting some of them together; specifically showing how
Source and Remote relate to
Inbound Rules and OutBound Rules.
Source- InBound Rules use Source to define who is trying to send our PC information. Like another PC on our LAN, or a hacker sitting in his/her mom's basement on some other continent.

- OutBound Rules will always have a Source of our PC (whether we specifically set its IP address, its subnet / Zone, or use Any)... when we launch IE to browse Google, it is us on our PC making the request to open the webpage.
Remote- InBound Rules will always have a Remote of our PC (whether we specifically set its IP address, its subnet / Zone, or use Any)... whether its another PC on our LAN looking for Shares/Printers or to join a game hosted on our PC, or the hacker in his/her mom's basement, ourt PC is the expected responder.
- OutBound Rules use Remote to define who is the expected responder to our request for communication/information... the rule needs to know we are expecting google to respond to our request to load the google homepage.
On with some Rules!Alright, I think we have enough to try creating our first
Network Control Rules. So let's think about what we want, then try using the
building blocks of the Rules (our terminology definitions) we've looked at to create a rule for it.
Rule AWhere should we start? How about keeping that hacker, probing for ports, off our PC? Good plan! I like how you think.
I want to... Block attempts by an hacker (outside my network/PC) from reaching my PC, regardless of what protocol they try use.Using the Rule building blocks: (after selecting to Add a new Rule)
Action: Block (we want to make a rule to
stop the hacker)
(I also suggest checking the "create an alert if this rule is fired" option so that attempts [good or bad] blocked by this rule are logged)Protocol/Direction: IP In (The hackers
communication attempt will be one we didn't request to occur)
Source IP: Any (I know what your thinking... we said we wanted to
stop communication from outside our network, and
Any would also mean the
LAN!!
Good observation. We'll need another rule to fix that by allowing the LAN communication before it hits this
Block All catch rule... so let's make that rule next [
Rule B])
Remote IP: Any (remember, InBound Rules will always have a Remote of our PC [whether we specifically set its IP address, its subnet / Zone, or use Any])
IP Protocol: Any (
regardless of what protocol they try and use. Did you notice when you selected
Any from the dropdown list here all the protocol types
Any covers?)
And there is our
First Network Control Rule!
Rule BSo we discovered that
Rule A was pretty agressive and even
Blocked our LAN. But remember what we learned about
Rule ID's and the order Rules are applied? If we put a new Rule (
Rule B) before
Rule A that Allows other PC's on our LAN to send communication requests, we should be Ok, right? Right.
And what if you aren't on a LAN? Then this rule means nothing to you.Note: Now before we get started on this Rule, I want to mention something useful that we'll want to make sure we have set. I don't know about you, but I don't want to have to type the IP addresses (or ranges) for the PC's on my netweork when I'm defining Rules, so unless you have a [LAN] or [Home Network] Zone defined, please do that now by switching to the Tasks tab, and pressing the Add a New Zone button... give it a name and a start/end range. Good!I want to... Allow all requests for communication from other PC's on my LAN to my PCUsing the Rule building blocks: (now we could select to
Add a new Rule and move it above
Rule A, or you could
right-click Rule A...
Add Rule...
Add Before [either way works])
Action: Allow (we want to make a rule to
let the other LAN PC's make requests to us)
Protocol/Direction: IP In (The LAN communication attempt will be one we
didn't request to occur, but
we expect that)
Source IP: Zone: [LAN] (Any PC on our LAN can now
send our PC information/requests)
Remote IP: Any (remember, InBound Rules will always have a Remote of our PC [whether we specifically set its IP address, its subnet / Zone, or use Any])
IP Protocol: Any (
All request/communication types [similar to Rule A, except this time we are Allowing])
And there is our
Second Network Control Rule!
Rule CSo far we have set the way we want CPF to handle
incoming communication to our PC that
wasn't requested by us. So I guess our next rule should take care of
incoming replies to requests we made for communication, like to support our IE/Firefox requests for webpages, or us trying to join a friend who is hosting a LAN game.
I want to... Allow responses to come back to my PC from anywhere (the Web or the LAN) that were requested from my PC.Using the Rule building blocks: (just as with
Rule B, we could select to
Add a new Rule and move it above
Rule A, or you could
right-click Rule A...
Add Rule...
Add Before [either way works])
Action: Allow (we want to make a rule to
let our PC receive a response to a request it made)
Protocol/Direction: IP Out (
We are starting a request that will return a response)
Source IP: Any (remember, OutBound Rules will always have a Source of our PC [whether we specifically set its IP address, its subnet / Zone, or use Any])
Remote IP: Any (
let the responder to our request come from anywhere, LAN or Web)
IP Protocol: Any (All request/communication types [similar to
Rule B])
And there is our
Third Network Control Rule!
Rule DNow sometimes a response to our communication request is going to
come in on a diferent port. Take
Bittorrent for example,
we request a file and the download starts on a
predetermined/configured TCP/UDP port, i.e. 6881 by default. For each file we want to download simultaneously, we need a new TCP/UDP port, i.e. to download 4 we would need 4 ports... 6881, 6882, 6883, & 6884. Similar to opening the ports on our Firewalls/Routers (without the need for forwarding, as the communication is already
comming into our PC).
I want to... Allow requests for incoming TCP/UDP communication (on ports 6881, 6882, 6883, & 6884) from any PC on the web to my PCUsing the Rule building blocks: (just as with
Rule B, we could select to
Add a new Rule and move it above
Rule A, or you could
right-click Rule A...
Add Rule...
Add Before [either way works])
Action: Allow (we want to make a rule to
let requests be made)
Protocol/Direction: TCP/UDP In (Even though we asked to dowload a file [feels outbound], the
response is coming back on a different port than our request; therefore, it is going to look like the
remote PC is trying to request in inbound communication)
Source IP: Any (
Let the request come from anywhere... somewhere on the web in this case)
Remote IP: Zone: [LAN] (remember, InBound Rules will always have a Remote of our PC [whether we specifically set its IP address, its subnet / Zone, or use Any])
Source Port: Any (we don't care what port it left the remote PC on in this case)
Remote Port: A set of ports [6881,6882,6883,6884] (we only want to
allow the remote PC to sent to the ports we configured Bittorrent to use)
And there is our
Fourth Network Control Rule!
Hopefully this has been enough combinations to give you the basis for thinking of new
Network Control Rules you may need to define.
And if you're still awake after reading my little novel here... I hope you learned as much reading it as I did learning about it before I was inspired to write this....
And I'm spent... 
(V)