In part 1 we covered the environment in which firewalls operate, but what do they actually do? In general firewalls examine data packets as they arrive, compare what they see with a list of rules they have been given, and then allow the packet through, or not, depending upon those rules.

To use a crude analogy, the nightclub bouncer has been given a rule that no one wearing trainers can come in. As each person arrives at the door the bouncer examines their feet and if they have trainers on he turns them away, otherwise he lets them in. Incidentally, in firewall terms this is known as a default allow policy, i.e. if someone doesn't match the rule they are let in. This is usually considered a bad thing since it's harder to predict all the possible things that might come your way rather than just to list what you will allow. You may not want clients in your club who wear pink boots with flashing toecaps (who would?) but since you haven't thought to specifically tell the bouncer this, he will let them in.

Firewalls come in two flavours, packet filtering and proxying. Since all personal firewalls use packet filtering this is what we will focus on. The difference is concerned with the level they operate at in the protocol stack. If there's a demand within the conference to examine the difference we can deal with it in a later FAQ.

Packet filters typically examine at least the following aspects of a packet: source address, source port, destination address, destination port. They may additionally examine which interface (i.e. modem, network card), the packet came in on, and what flags were set, (see below). Some firewalls will allow even more detailed examination. Rules can be set which tell the firewall what to do with a packet based on these various attributes. Typically there will be rules saying which packets are allowed through and at the end a default deny rule. The firewall works its way down the rule set and if it finds a matching rule it will let the packet through to its destination. If none of the allow rules match it will eventually reach the default rule and the packet will be rejected or denyed. The difference between rejected and denyed is that when a firewall rejects a packet it sends back an error message saying so. If it denys a packet it quietly drops it without giving any indication to the sender.

So, to give an example of a very simplistic rule set (note: different firewalls have their own syntax for actually defining these):

Rule No.
1. Any source IP address, port 80, going to mycomputerIP, any port - allow
2. MyISP's mailserverIP, port 110, going to mycomputerIP, any port - allow
3. Any source IP address, any port, going to any IP address, any port - deny

Let's imagine your ISP's mailserver is 10.10.10.1 and you have been allocated 192.168.1.10, and imagine we've received a packet with the following details:
Source 172.192.1.56:110 (the :110 bit means port 110), destination 192.168.1.10:1056.

Our idealised firewall would start with rule 1 and compare the packet. It doesn't match because rule 1 is referring to port 80 and the incoming packet is port 110, so it moves on to rule 2. Rule 2 matches on the port (110), but fails because the source IP address isn't your ISP's mailserver. Finally the firewall reaches the last rule which matches with any packet and so carries out the instruction - deny.

Next a packet is received with:
Source 10.10.10.1:110, Destination 192.168.1.10:1025

This doesn't match rule 1 because of the port number, but does match the criteria of rule 2, so the firewall carries out the instruction for rule 2 - allow, and the packet is sent on it's way (probably to your email client program).

Flags. In part 1 an outline of the TCP connection process was given. In more detail, the initial connection is achieved using a 'three-way' handshake. Comp A sends an initial packet to Comp B that has part of the packet header, known as a flag, set to 1. This particular flag is known as SYN (from synchronise) and signifies that this packet is the first packet in an attempt to set up a new connection. If Comp B is accepting connections to whichever port was specified in the SYN packet, it sends a reply packet with the SYN flag set, plus another flag called ACK(nowledge). Then to complete the handshake Comp A acknowledges B's acknowledgement with a packet with just the ACK flag set. This is still a somewhat simplified version of what goes on but it covers the details we need for this FAQ. If you want more detail about TCP/IP there are thousands of websites on the subject such as http://www.techfest.com/networking/prot.htm

You might also want to browse a decent bookshop for books on the subject. One I found helpful was 'Using TCP/IP' by John Ray, Pub. Que ISBN 0-7897-1897-9