OK, this answer is pretty generic, and may actually be wrong for comodo personal firewall, but I think they’ve managed to implement it “normally” (and in that case this answer will be right)
A standard port access control (what network techs call an “access control list”), is a very simple firewall rule. It the rule is formed as follows:
PROTOCOL, RULE, SOURCE IP, SOURCE PORT, DESTINATION IP, DESTINATION PORT.
Example:
TCP, Permit, 192.168.0.2, all, any, 80
This rule would permit the host 192.168.0.2 to connect to any ip (via tcp) on port 80 (http), i.e. it would permit the host 192.168.0.2 to browse web pages. It applies to all traffic from that host, regardless of what program that accesses it. This is a simple layer 4 access control list (for explanations on the different layers of the osi model, take a look in Wikipedia on OSI Model)
This is your basic filtering, and it requires very little cpu overhead.
However there is one flaw to this type of filtering. Since the filter is “stupid”, and only looks at the source and destination of the packet (i.e. only reads the header of the packet) to see if the packet should be dropped, or forwarded (transmitted).
This type of rules CAN NOT stop applications accessing internet adresses “behind your back”, hence if you get a worm infection, the worm can still spread from your box onto others. And since it doesn’t look at what application is involved (you can use application filters for inbound traffic aswell), it doesn’t block a crafted worm packet entering your system. This is a weak solution.
A much better approach, is to extend the filter to cover layer 7 (application) aswell. This means that the traffic is matched against the software transmitting it, and thus you can specify which applications are actually allowed to “surf the web”.
Since some of the malware hackers install on compromized machines usually is remotely controlled applications (bots), the need to select which applications are actually allowed to connect to the internet is vital. Not only to keep yourself from spreading worms, or having your machine used in a DDoS (Distributed Denial of Service) attack, but also in removing such infections. A lot of the “smarter” flood-drones are capable of being instructed to “upgrade themselves” over the web, and the new upgraded version will of course have a different signature, and be harder to find for your antivirus package.
Thus, if you can stop the application both from being remotely controlled, stop it from being upgraded, and more importantly: Get a warning that an application is connecting to internet without you asking it to, you are in a lot better position to regain control of your machine.
This is of course a worst case scenario.
A more day-to-day version would be to stop spyware connecting “home” to dump their info on you to the marketing corps.
The application layer firewalling is only possible to do on a personal firewall (it can’t be done on a network firewall since the network firewall doesn’t have access to your machines internal task list). The downside to application-layer security, is that it creates a small overhead on traffic. This adds a few clock-cycles extra latency on the first packet of a stream, but for the rest of the stream the latency is minimal (since the connection is already established).
The best setup is to use a mixture of layer 3, layer 4 and layer 7 filtering.
Start out with your layer 3 filtering. First thing to do, is to filter out all adresses that doesn’t belong on an interface. For instance: Your ethernet interface has NO business talking on the 127.0.0.0/24 address space at all. Block it. When you have filtered out all adresses that have no need to pass through that interface, move onto ports (tcp/udp ports, icmp services, etc), and do the same thing there. Filter out all that you can do there, since layer 3 and 4 filtering is “cheap” cpu-wise.
Now that you have a basic ruleset, it’s time to put the application filter into learning mode, and start binding applications to those ports you opened at layer 4.
By filtering this way, you reduce the amount of rules in the application ruleset (since a lot of unwanted traffic is filtered at a lower level), and thus you reduce the cpu load.
Building a firewall ruleset this way is a LOT of work, but the payoff is that you can be 99% secure, without needing the cpu of a Cray supercomputer not anywhere near your budget, alas.
When building your rules, try to aggregate the rules. Instead of opening one port at a time (for a range) specify things as a range. It reduces the number of rules (improves readability, and reduces cpu load).
Remember that a firewall reads the rules from the bottom and upwards.
This means that you can do some tricks.
Let’s say that you want to allow ports 1022,1023,1025,1026 to be allowed.
Use two lines.
deny 1024
permit 1022-1026
The bottom rule opens the entire range (including the one that you don’t want)
The next rule (the one above) denies that port.
For a packet to be successfully transmitted, it has to pass the entire ruleset (from the bottom and up) without being implicitly or explicitly dropped. For a packet to be dropped, it just has to fail one test.
Writing your rulesets this way provides you with control, since it’s readable, and computer networking security is all about KNOWING what traffic goes in and out, and having CONTROL over it. If you write a too complex ruleset, you loose the ability to read it, and thus loose the KNOWLEDGE. Without KNOWLEDGE, you cannot have control, and hence no security.
I hope I made myself somewhat understandable (especially since English is NOT my native language)
//Svein
