The IP Chains facility has been availabe starting with the 2.2 kernel and is offered with 2.4 as well. Unfortunately, in the 2.4, kernel developers did not bother to support port forwarding or a few protocols that had been supported under 2.2, such as game server (something very relavent to me), Real Audio and other specialty servers with IP Masquerading. Even though it has been superseded by IP Tables, IP Chains is still present for those who either want to use it, or have to use it (and there are situations where you would have to use it).
The basic concept with IP Chains is that you specify which packets will be allowed to continue. The restriction can be any combination of source and destination system IP addresses, protocol type, port numbers, whether the packet is the "SYN" packet that initiates a TCP/IP connection, and interfaces on which the packet came in.
IP Chains implements what is called a stateless firewall, meaning that the decision to allow a packet through is made solely by the state of the individual packet. Conversely, a stateful firewall can accumulate a sequence of TCP packets, acknowledge each of them itself, and the decide whether to allow continued communication.
One feature that is present in commercial firewalls that goes beyond the features of IP Chains is content filtering. This is where the firewall looks beyond the protocol headers, instead looks at the actual data in the packets, and does some filtering based on that data. However, this is not as big of a problem as one would think because (as we have seen previously) we have a broad range of content filters associated with the various services our Linux boxes run (SpamAssassin, Vipul's Razor, Amavis for mail; Squid, Cerberian for web; etc. etc.).
IP Chains allows the kernel to do one of three different things to a packet:
It can accept the packet and allow it to continue to its requested destination, possibly subjecting it to other tests first.
It can deny the packet; this means throwing it away without any notice to the sending system.
It can reject the packet; this causes the sending system to be told that the packet was rejected, by sending an ICMP packet back to it.
Chains of Rules
The kernel starts with three lists of rules; these lists are called firewall chains or just chains. The three chains are called input, output and forward. When a packet comes in (say, through the Ethernet card) the kernel uses the input chain to decide its fate. If it survives that step, then the kernel decides where to send the packet next (this is called routing). If it is destined for another machine, it consults the forward chain. Finally, just before a packet is to go out, the kernel consults the output chain.
A chain is a checklist of rules. Each rule says `if the packet header looks like this, then here's what to do with the packet'. If the rule doesn't match the packet, then the next rule in the chain is consulted. Finally, if there are no more rules to consult, then the kernel looks at the chain policy to decide what to do. In a security-conscious system, this policy usually tells the kernel to reject or deny the packet.
The following illustrates the complete path:
Here is a blow-by-blow description of each stage:
Checksum:
This is a test that the packet hasn't been corrupted in some way. If it has, it is denied.
Sanity:
There is actually one of these sanity checks before each firewall chain, but the input chain's is the most important. Some malformed packets might confuse the rule-checking code, and these are denied here (a message is printed to the syslog if this happens).
input chain:
This is the first firewall chain against which the packet will be tested. If the verdict of the chain is not DENY or REJECT, the packet continues on.
De-Masquerade:
If the packet is a reply to a previously masqueraded packet, it is demasqueraded, and skips straight to the output chain. If you don't use IP Masquerading, you can mentally erase this from the diagram.
Routing decision:
The destination field is examined by the routing code, to decide if this packet should go to a local process (see Local process below) or forwarded to a remote machine (see forward chain below).
Local process:
A process running on the machine can receive packets after the Routing Decision step, and can send packets (which go through the Routing Decision step, then traverse the output chain).
lo interface:
If packets from a local process are destined for a local process, they will go through the output chain with interface set to `lo', then return through the input chain with interface also `lo'. The lo interface is usually called the loopback interface.
local:
If the packet was not created by a local process, then the forward chain is checked, otherwise the packet goes to the output chain.
forward chain:
This chain is traversed for any packets which are attempting to pass through this machine to another.
output chain:
This chain is traversed for all packets just before they are sent out.
