Manual

With the manual version, you use the iptables commands and tools. The iptables-save command reads the current firewall rules. Because the program sends them to standard output, you need to redirect the output to a file by using the (>) redirection operator (Listing 2). This file has a specific, compact format.

You can restore these rules later with the command iptables-restore (Listing 2, last line). This approach is simple and clear-cut, but still not automated. However, you can manage that task with the variations that follow.

Automated

Runlevels contain shell scripts that run with a system runlevel change. To load the previously stored firewall rules, you need to create an appropriate shell script. In it, you can either call iptables-restore or create a separate call to iptables in the desired order for each individual rule.

The variant presented here is far more customized. It involves expanding the entries for the network interfaces in the /etc/network/interfaces file. The entries allow you to specify a script or command that runs when the system activates or disables a network interface (Listing 3).

The first command in line 3 is specified after the keyword pre-up and executes the command before activating the interface. The post-down statement in line 4 refers to the time after disabling the interface. Therefore, the firewall only processes certain rules when a particular interface is switched on.

Resourceful Debian developers also identified the problem and devised a solution, which they dubbed iptables-persistent [5]. It has been included since Debian 5 "squeeze" and combines the variants featured in Listing 3.

For this to happen, iptables-persistent creates two files – /etc/iptables/rules.v4 for IPv4 and /etc/iptables/rules.v6 for IPv6 – and stores the current firewall rules during package configuration. Additionally, it creates a suitable init script named /etc/init.d/netfilter-persistent, which you can call via service netfilter with the usual switches: start, stop, reload, and restart.

Future Useful Information

In the context of iptables, several small programs facilitate everyday admin life. They include iptables-apply and iptables-xml, both of which are part of iptables, as well as iptables-converter.

The iptables-apply shell script helps you test firewall rules remotely. It allows you to roll back rule changes if they would take down the current connection.

To do this, the script asks whether the changes to the rules are okay. If you do not respond within a certain period of time, it rolls back the changes. This reduces the risk that you lock yourself out when changing the firewall rules, although you still have the option of communication via the serial interface, but only if the remote computer is set up for it, because the firewall rules do not take it into consideration under normal circumstances.

Access would also be possible via a KVM switch, which acts as a toggle switch that connects a set of devices (keyboard, video, mouse) to more than one computer. In this way, you can control multiple computers with one keyboard, mouse, and monitor.

The iptables-xml script contains firewall rules in XML format. Several graphical tools for firewalls understand and process this format. Figure 1 shows an example of an XML file generated by this tool.

Figure 1: The iptables-xml tool converts iptables rules to an XML structure that you can reuse in other applications.

The iptables-converter program is useful, as well. It converts iptables statements to the format that iptables-save and iptables-restore use. Thus, you can convert existing shell scripts with sequences of iptables statements directly to the required format. The graphical fwbuilder (Firewall Builder) tool [6] also reads the files and generates customized package checks (Figure 2).

Figure 2: Graphically editing rules in Firewall Builder. You can see the imported rules created by iptables-converter.