These classnotes are depreciated. As of 2005, I no longer teach the classes. Notes will remain online for legacy purposes

UNIX03/Introduction To IPChains

Classnotes | UNIX03 | RecentChanges | Preferences

Showing revision 3
(The following section corresponds to pages 514-543)

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:

  1. It can accept the packet and allow it to continue to its requested destination, possibly subjecting it to other tests first.
  2. It can deny the packet; this means throwing it away without any notice to the sending system.
  3. 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.


Classnotes | UNIX03 | RecentChanges | Preferences
This page is read-only | View other revisions | View current revision
Edited June 20, 2003 8:48 pm (diff)
Search:
(C) Copyright 2003 Samuel Hart
Creative Commons License
This work is licensed under a Creative Commons License.