I certainly see alot of power in the way CPF has structured it’s rules ability. But for a relative TCP/IP security noob, there was alot to be said for the seemingly “no-brainer” way of applying application rules in ZA.
So, I stand before you ready to learn the CPF way.
For example, in ZA I could set an application for:
Access Trusted Zone? True
Act as Server on Trusted Zone? True
Access Internet Zone? False
Act as Server on Internet Zone? False
The first issue (to my untrained eye) seems to be that their is no way to define the “Internet” zone. Second, does “Act as Server” simply mean open for Inbound access?
So how would I go about setting up the rule(s) in CPF to enforce the behaviour outlined in my example for any application? (Like wgatray.exe for example)
Another related question comes to mind here… depending on the application (usually games i think), some would require another “zone” to be setup… “255.255.255.255”… is this broadcast? Is it safe? Or would a rule related to this address circumvent security in some way? ( I can’t help but to think of the subnet mask when I see an addresss like that… looks global)
Assuming you have a setup with more than one PC behind a router, it is fairly easy, though not as simple as ZA, to create the rules. Incidently, wgatray.exe has ‘nothing to say’ to the trusted zone.
Running Tasks/Wizards/Add A Trusted Zone on each of the PCs will find the
private IP address range (eg 192.168.1.0 to 192.168.1.255) associated with their respective ethernet
card, assign a name to the Zone, and create the default ‘allow all traffic’ rules for inbound and
outbound data. Knowing the trusted zone IP range, we can now add the rules for the application.
In our example, if there are any existing rules for wgatray.exe, remove them.
Select Application Monitor/Add and browse to C:\Windows\System32\WgaTray.exe.
Now click on the Skip Parent radio button. On the General tab below, make sure Allow/Tcp or UDP/In are the options. The Remote IP tab and Remote Port tab should both have the Any radio button checked. Click OK.
We have now added a rule to allow wgatray.exe to listen for connections from anywhere.
To block it from phoning home, add a new rule as above, but on the General tab, use Block/TCP or UDP/Out,
on the Remote tab, select the ZONE radio button, then check Exclude. Click OK.
At the next reboot, Activity/Logs will show that wgatray.exe was denied access to the internet.
(R)
Hmmmm … 255.255.255.255 smells like a subnet mask, which is conceivable for a game to want to reach other players on the LAN. If you’ve run through the trusted zone wizard, this should all be taken care of, as the wizard creates an allow rule for the local lan.
Action : ALLOW
Protocol :IP
Direction : In/Out
Source : ZONE
Remote : ZONE
Make sure you have a rule like this in network monitor. This rule should be at the top of the list to give it the highest priority.
Sorry I didn’t pick up on the second part of the query, m0ng0d
255.255.255.255 as a subnet mask would be catered for exactly as Ewen outlines.
As an IP, it is reserved to broadcast to everywhere on your network and this can be fraught, leading to a possible
[url]http://computer.howstuffworks.com/lan-switch13.htm[/url] broadcast storm. I can’t think of a valid reason to try to
formulate a rule for that IP - Hint - try pinging 255.255.255.255
On a M$ O/S it will tell you it can’t find that host; a Linux system will tell you if you want to ping broadcast…
I decided to test this with a LAN game, using another PC on my network as the competitor. In order to connect successfully without receiving any additional popups, I needed 3 rules:
Application Rule #1
App/Parent: SKIP
Action : ALLOW
Protocol :TCP/UDP
Direction : Out
Remote : ZONE:[Home Network]
Remote Port: Any
Misc: ALLOW Invisible
Application Rule #2 (this one blocks the 255.255.255.255 broadcast I’m sure :))
App/Parent: SKIP
Action : BLOCK
Protocol :TCP/UDP
Direction : Out
Remote : NOT IN ZONE:[Home Network] ← Exclude checked
Remote Port: Any
Misc: ALLOW Invisible
Application Rule #3
App/Parent: SKIP
Action : ALLOW
Protocol :TCP/UDP
Direction : In
Remote : Any
Remote Port: Any
Misc: ALLOW Invisible
Now Rules #2 & #3 are basically exactly what Lauren stated. What was odd however is that it seems Rule #2 “Block non-[Home Network]” doesn’t imply “Allow [Home Network]”… hence why I created Rule #1. Does this seem odd? Or did I expect too much?
In any event, unless someone can show me what I did “wrong” to make 2 Rules not enough, these 3 Rules are my new “Big Brother is watching, so seal off the exists” trilogy of goodness. (I almost have a false sense of security that I can now “safely” use downloaded NOCD’s and save my precious originals, without the imbedded trojans pulling down their payload… NOT!!!)
It was also important to understand where these Application rules fit into the CPF “Order of Rules” followed…
@Panic,
I did have a network rule as you suggested.
Thank you everybody! (S)
Oh, wow… I just noticed I progressed from a Newbie to a Comodo Member… And just in time as I learned something “powerful” (J)
