# Completed on Wed Apr 24 10:19:17 2002

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:17 2002

*nat

:PREROUTING ACCEPT [0:0]

:POSTROUTING ACCEPT [3:450]

:OUTPUT ACCEPT [3:450]

COMMIT

# Completed on Wed Apr 24 10:19:17 2002

This contains a few comments starting with a # sign. Each table is marked like *, for example *mangle. Then within each table we have the chain specifications and rules. A chain specification looks like : [:]. The chain-name may be for example PREROUTING, the policy is described previously and can, for example, be ACCEPT. Finally the packet-counter and byte-counters are the same counters as in the output from iptables -L -v. Finally, each table declaration ends in a COMMIT keyword. The COMMIT keyword tells us that at this point we should commit all rules currently in the pipeline to kernel.

The above example is pretty basic, and hence I believe it is nothing more than proper to show a brief example which contains a very small Iptables-save ruleset. If we would run iptables-save on this, it would look something like this in the output:

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002

*filter

:INPUT DROP [1:229]

:FORWARD DROP [0:0]

:OUTPUT DROP [0:0]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -i eth1 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

-A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT

COMMIT

# Completed on Wed Apr 24 10:19:55 2002

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002

*mangle

:PREROUTING ACCEPT [658:32445]

:INPUT ACCEPT [658:32445]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [891:68234]

:POSTROUTING ACCEPT [891:68234]

COMMIT

# Completed on Wed Apr 24 10:19:55 2002

# Generated by iptables-save v1.2.6a on Wed Apr 24 10:19:55 2002

*nat

:PREROUTING ACCEPT [1:229]

:POSTROUTING ACCEPT [3:450]

:OUTPUT ACCEPT [3:450]

-A POSTROUTING -o eth0 -j SNAT --to-source 195.233.192.1

COMMIT

# Completed on Wed Apr 24 10:19:55 2002

As you can see, each command has now been prefixed with the byte and packet counters since we used the -c argument. Except for this, the command-line is quite intact from the script. The only problem now, is how to save the output to a file. Quite simple, and you should already know how to do this if you have used linux at all before. It is only a matter of piping the command output on to the file that you would like to save it as. This could look like the following:

iptables-save -c > /etc/iptables-save

The above command will in other words save the whole rule-set to a file called /etc/iptables-save with byte and packet counters still intact.

The iptables-restore command is used to restore the iptables rule-set that was saved with the iptables-save command. It takes all the input from standard input and can't load from files as of writing this, unfortunately. This is the command syntax for iptables-restore:

iptables-restore [-c] [-n]

The -c argument restores the byte and packet counters and must be used if you want to restore counters that were previously saved with iptables-save. This argument may also be written in its long form --counters.

The -n argument tells iptables-restore to not overwrite the previously written rules in the table, or tables, that it is writing to. The default behavior of iptables-restore is to flush and destroy all previously inserted rules. The short -n argument may also be replaced with the longer format --noflush.

To load a rule-set with the iptables-restore command, we could do this in several ways, but we will mainly look at the simplest and most common way here.

cat /etc/iptables-save | iptables-restore -c

The following will also work:

iptables-restore -c < /etc/iptables-save

This would cat the rule-set located within the /etc/iptables-save file and then pipe it to iptables-restore which takes the rule-set on the standard input and then restores it, including byte and packet counters. It is that simple to begin with. This command could be varied until oblivion and we could show different piping possibilities, however, this is a bit out of the scope of this chapter, and hence we will skip that part and leave it as an exercise for the reader to experiment with.

The rule-set should now be loaded properly to kernel and everything should work. If not, you may possibly have run into a bug in these commands.

This chapter has discussed the iptables-save and iptables-restore programs to some extent and how they can be used. Both applications are distributed with the iptables package, and can be used to quickly save large rulesets and then inserting them into the kernel again.

The next chapter will take a look at the syntax of a iptables rule and how to write properly formatted rule-sets. It will also show some basic good coding styles to adhere to, as required.

This chapter and the upcoming three chapters will discuss at length how to build your own rules. A rule could be described as the directions the firewall will adhere to when blocking or permitting different connections and packets in a specific chain. Each line you write that's inserted in a chain should be considered a rule. We will also discuss the basic matches that are available, and how to use them, as well as the different targets and how we can construct new targets of our own (i.e.,new sub chains).

This chapter will deal with the raw basics of how a rule is created and how you write it and enter it so that it will be accepted by the userspace program iptables, the different tables, as well as the commands that you can issue to iptables. After that we will in the next chapter look at all the matches that are available to iptables, and then get more into detail of each type of target and jump.

As we have already explained, each rule is a line that the kernel looks at to find out what to do with a packet. If all the criteria - or matches - are met, we perform the target - or jump - instruction. Normally we would write our rules in a syntax that looks something like this:

iptables [-t table] command [match] [target/jump]

There is nothing that says that the target instruction has to be the last function in the line. However, you would usually adhere to this syntax to get the best readability. Anyway, most of the rules you'll see are written in this way. Hence, if you read someone else's script, you'll most likely recognize the syntax and easily understand the rule.

If you want to use a table other than the standard table, you could insert the table specification at the point at which [table] is specified. However, it is not necessary to state explicitly what table to use, since by default iptables uses the filter table on which to implement all commands. Neither do you have to specify the table at just this point in the rule. It could be set pretty much anywhere along the line. However, it is more or less standard to put the table specification at the beginning.