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 Terminology
Rule 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%29
Port - 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_port
Direction: 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 A
Where 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 B
So 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 PC
Using 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 C
So 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 D
Now 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 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 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.
0 comments:
Post a Comment