Kernel Configured with IP Firewall
The Linux kernel must be configured to support IP firewalling. There isn't much more to it than selecting the appropriate options when performing a make menuconfig of your kernel.[60] We described how to do this is in Chapter 3, Configuring the Networking Hardware". In 2.2 kernels you should select the following options:
Networking options --->
[*] Network firewalls
[*] TCP/IP networking
[*] IP: firewalling
[*] IP: firewall packet logging
In kernels 2.4.0 and later you should select this option instead:
Networking options --->
[*] Network packet filtering (replaces ipchains)
IP: Netfilter Configuration --->
.
<M> Userspace queueing via NETLINK (EXPERIMENTAL)
<M> IP tables support (required for filtering/masq/NAT)
<M> limit match support
<M> MAC address match support
<M> netfilter MARK match support
<M> Multiple port match support
<M> TOS match support
<M> Connection state match support
<M> Unclean match support (EXPERIMENTAL)
<M> Owner match support (EXPERIMENTAL)
<M> Packet filtering
<M> REJECT target support
<M> MIRROR target support (EXPERIMENTAL)
.
<M> Packet mangling
<M> TOS target support
<M> MARK target support
<M> LOG target support
<M> ipchains (2.2-style) support
<M> ipfwadm (2.0-style) support
The ipfwadm Utility
The ipfwadm (IP Firewall Administration) utility is the tool used to build the firewall rules for all kernels prior to 2.2.0. Its command syntax can be very confusing because it can do such a complicated range of things, but we'll provide some common examples that will illustrate the most important variations of these.
The ipfwadm utility is included in most modern Linux distributions, but perhaps not by default. There may be a specific software package for it that you have to install. If your distribution does not include it, you can obtain the source package from ftp.xos.nl in the /pub/linux/ipfwadm/ directory, and compile it yourself.
The ipchains Utility
Just as for the ipfwadm utility, the ipchains utility can be somewhat baffling to use at first. It provides all of the flexibility of ipfwadm with a simplified command syntax, and additionally provides a "chaining" mechanism that allows you to manage multiple rulesets and link them together. We'll cover rule chaining in a separate section near the end of the chapter, because for most situations it is an advanced concept.
The ipchains command appears in most Linux distributions based on the 2.2 kernels. If you want to compile it yourself, you can find the source package from its developer's site at http://www.rustcorp.com/linux/ipchains/. Included in the source package is a wrapper script called ipfwadm-wrapper that mimics the ipfwadm command, but actually invokes the ipchains command. Migration of an existing firewall configuration is much more painless with this addition.
The iptables Utility
The syntax of the iptables utility is quite similar to that of the ipchains syntax. The changes are improvements and a result of the tool being redesigned to be extensible through shared libraries. Just as for ipchains, we'll present iptables equivalents of the examples so you can compare and contrast its syntax with the others.
The iptables utility is included in the netfilter source package available at http://www.samba.org/netfilter/. It will also be included in any Linux distribution based on the 2.4 series kernels.
We'll talk a bit about netfilter's huge step forward in a section of its own later in this chapter.
Three Ways We Can Do Filtering
Consider how a Unix machine, or in fact any machine capable of IP routing, processes IP datagrams. The basic steps, shown in Figure 9.2 are:
Figure 9.2: The stages of IP datagram processing
· The IP datagram is received. (1)
· The incoming IP datagram is examined to determine if it is destined for a process on this machine.
· If the datagram is for this machine, it is processed locally. (2)
· If it is not destined for this machine, a search is made of the routing table for an appropriate route and the datagram is forwarded to the appropriate interface or dropped if no route can be found. (3)
· Datagrams from local processes are sent to the routing software for forwarding to the appropriate interface. (4)
· The outgoing IP datagram is examined to determine if there is a valid route for it to take, if not, it is dropped.
· The IP datagram is transmitted. (5)
In our diagram, the flow 1→3→5 represents our machine routing data between a host on our Ethernet network to a host reachable via our PPP link. The flows 1→2 and 4→5 represent the data input and output flows of a network program running on our local host. The flow 4→3→2 would represent data flow via a loopback connection. Naturally data flows both into and out of network devices. The question marks on the diagram represent the points where the IP layer makes routing decisions.
The Linux kernel IP firewall is capable of applying filtering at various stages in this process. That is, you can filter the IP datagrams that come in to your machine, filter those datagrams being forwarded across your machine, and filter those datagrams that are ready to be transmitted.
In ipfwadm and ipchains, an Input rule applies to flow 1 on the diagram, a Forwarding rule to flow 3, and an Output rule to flow 5. We'll see when we discuss netfilter later that the points of interception have changed so that an Input rule is applied at flow 2, and an Output rule is applied at flow 4. This has important implications for how you structure your rulesets, but the general principle holds true for all versions of Linux firewalling.
This may seem unnecessarily complicated at first, but it provides flexibility that allows some very sophisticated and powerful configurations to be built.
60
Firewall packet logging is a special feature that writes a line of information about each datagram that matches a particular firewall rule out to a special device so you can see them.