Olaf Kirch - Linux Network Administrator Guide, Second Edition

The ipchains software package is supplied with three support scripts. The first of these we've discussed briefly already, while the remaining two provide an easy and convenient means of saving and restoring your firewall configuration.

The ipfwadm-wrapper script emulates the command-line syntax of the ipfwadm command, but drives the ipchains command to build the firewall rules. This is a convenient way to migrate your existing firewall configuration to the kernel or an alternative to learning the ipchains syntax. The ipfwadm-wrapper script behaves differently from the ipfwadm command in two ways: firstly, because the ipchains command doesn't support specification of an interface by address, the ipfwadm-wrapper script accepts an argument of -V but attempts to convert it into the ipchains equivalent of a -W by searching for the interface name configured with the supplied address. The ipfwadm-wrapper script will always provide a warning when you use the -V option to remind you of this. Secondly, fragment accounting rules are not translated correctly.

The ipchains-save and ipchains-restore scripts make building and modifying a firewall configuration much simpler. The ipchains-save command reads the current firewall configuration and writes a simplified form to the standard output. The ipchains-restore command reads data in the output format of the ipchains-save command and configures the IP firewall with these rules. The advantage of using these scripts over directly modifying your firewall configuration script and testing the configuration is the ability to dynamically build your configuration once and then save it. You can then restore that configuration, modify it, and resave it as you please.

To use the scripts, you'd enter something like:

ipchains-save ›/var/state/ipchains/firewall.state

to save your current firewall configuration. You'd restore it, perhaps at boot time, with:

ipchains-restore ‹/var/state/ipchains/firewall.state

The ipchains-restore script checks if any user-defined chain listed in its input already exists. If you've supplied the -f argument, it will automatically flush the rules from the user-defined chain before configuring those in the input. The default behavior asks you whether to skip this chain or to flush it.

While developing IP Firewall Chains, Paul Russell decided that IP firewalling should be less difficult; he soon set about the task of simplifying aspects of datagram processing in the kernel firewalling code and produced a filtering framework that was both much cleaner and much more flexible. He called this new framework netfilter .

NOTE:At the time of preparation of this book the netfilter design had not yet stabilized. We hope you'll forgive any errors in the description of netfilter or its associated configuration tools that result from changes that occurred after preparation of this material. We considered the netfilter work important enough to justify the inclusion of this material, despite parts of it being speculative in nature. If you're in any doubt, the relevant HOWTO documents will contain the most accurate and up-to-date information on the detailed issues associated with the netfilter configuration.

So what was wrong with IP chains? They vastly improved the efficiency and management of firewall rules. But the way they processed datagrams was still complex, especially in conjunction with firewall-related features like IP masquerade (discussed in Chapter 11) and other forms of address translation. Part of this complexity existed because IP masquerade and Network Address Translation were developed independently of the IP firewalling code and integrated later, rather than having been designed as a true part of the firewall code from the start. If a developer wanted to add yet more features in the datagram processing sequence, he would have had difficulty finding a place to insert the code and would have been forced to make changes in the kernel in order to do so.

Still, there were other problems. In particular, the "input" chain described input to the IP networking layer as a whole. The input chain affected both datagrams to be destined for this host and datagrams to be routed by this host. This was somewhat counterintuitive because it confused the function of the input chain with that of the forward chain, which applied only to datagrams to be forwarded, but which always followed the input chain. If you wanted to treat datagrams for this host differently from datagrams to be forwarded, it was necessary to build complex rules that excluded one or the other. The same problem applied to the output chain.

Inevitably some of this complexity spilled over into the system administrator's job because it was reflected in the way that rulesets had to be designed. Moreover, any extensions to filtering required direct modifications to the kernel, because all filtering policies were implemented there and there was no way of providing a transparent interface into it. netfilter addresses both the complexity and the rigidity of older solutions by implementing a generic framework in the kernel that streamlines the way datagrams are processed and provides a capability to extend filtering policy without having to modify the kernel.

Let's take a look at two of the key changes made. Figure 9.8 illustrates how datagrams are processed in the IP chains implementation, while Figure 9.9 illustrates how they are processed in the netfilter implementation. The key differences are the removal of the masquerading function from the core code and a change in the locations of the input and output chains. To accompany these changes, a new and extensible configuration tool called iptables was created.

In IP chains, the input chain applies to all datagrams received by the host, irrespective of whether they are destined for the local host or routed to some other host. In netfilter , the input chain applies only to datagrams destined for the local host, and the forward chain applies only to datagrams destined for another host. Similarly, in IP chains, the output chain applies to all datagrams leaving the local host, irrespective of whether the datagram is generated on the local host or routed from some other host. In netfilter , the output chain applies only to datagrams generated on this host and does not apply to datagrams being routed from another host. This change alone offers a huge simplification of many firewall configurations.

Figure 9.8: Datagram processing chain in IP chains

In Figure 9.8, the components labeled "demasq" and "masq" are separate kernel components responsible for the incoming and outgoing processing of masqueraded datagrams. These have been reimplemented as netfilter modules.

Consider the case of a configuration for which the default policy for each of the input, forward, and output chains is deny. In IP chains, six rules would be needed to allow any session through a firewall host: two each in the input, forward, and output chains (one would cover each forward path and one would cover each return path). You can imagine how this could easily become extremely complex and difficult to manage when you want to mix sessions that could be routed and sessions that could connect to the local host without being routed. IP chains allow you to create chains that would simplify this task a little, but the design isn't obvious and requires a certain level of expertise.