Most aspects of Linux are evolving to meet the increasing demands of
its users; IP firewall is no exception. The traditional IP firewall
implementation is fine for most applications, but can be clumsy and inefficient
to configure for complex environments. To solve this problem, a new method of
configuring IP firewall and related features was developed. This new method was
called “IP Firewall Chains” and was first released for general use
in the 2.2.0 Linux kernel.
The IP Firewall Chains support was developed by Paul
Russell and Michael Neuling.
Paul has documented the IP Firewall Chains software in the IPCHAINS-HOWTO.
IP Firewall Chains allows you to
develop classes of firewall rules to which you may then add and remove hosts
or networks. An artifact of firewall rule chaining is that it may
improve firewall performance in configurations in which there are lots of rules.
IP Firewall Chains are supported by the 2.2 series kernels and are also
available as a patch against the 2.0.* kernels. The HOWTO
describes where to obtain the patch and provides lots of useful hints about
how to effectively use the ipchains configuration utility.
There are two ways you can use the ipchains utility. The
first way is to make use of the ipfwadm-wrapper shell
script, which is mostly a drop-in replacement for ipfwadm
that drives the ipchains program in the background. If you
want to do this, then read no further. Instead, reread the previous sections
describing ipfwadm, and substitute
ipfwadm-wrapper in its place. This will work, but there is
no guarantee that the script will be maintained, and you will not be taking
advantage of any of the advanced features that the IP Firewall Chains have to
The second way to use ipchains is to learn its new syntax
and modify any existing configurations you have to use the new syntax instead
of the old. With some careful consideration, you may find you can optimize your
configuration as you convert. The ipchains syntax is easier
to learn than the ipfwadm, so this is a good option.
The ipfwadm manipulated three rulesets for the purpose
of configuring firewalling. With IP Firewall Chains you can create arbitrary
numbers of rulesets, each linked to one another, but there are three rulesets
related to firewalling that are always present. The standard rulesets
are direct equivalents of those used with ipfwadm, except
they have names: input, forward and
Let's first look at the general syntax of the ipchains
command, then we'll look at how we'd use ipchains instead
of ipfwadm without worrying about any of the advanced
chaining features. We'll do this by revisiting our previous examples.
There are a number of ways we can manipulate rules and rulesets with the
ipchains command. Those relevant to IP firewalling are:
Append one or more rules to the end of the nominated chain. If a hostname is
supplied as either source or destination and it resolves to more than one IP
address, a rule will be added for each address.
-I chain rulenum
Insert one or more rules to the start of the nominated chain. Again, if a
hostname is supplied in the rule specification, a rule will be added for each
of the addresses it resolves to.
Delete one or more rules from the specified chain that matches the
-D chain rulenum
Delete the rule residing at position rulenum
in the specified chain. Rule positions start at one for the first rule in the
-R chain rulenum
Replace the rule residing at position rulenum
in the specific chain with the supplied rule specification.
Check the datagram described by the rule specification against the specific
chain. This command will return a message describing how the datagram was
processed by the chain. This is very useful for testing your firewall
configuration, and we look at it in detail a little later.
List the rules of the specified chain, or for all chains if no chain
Flush the rules of the specified chain, or for all chains if no chain is
Zero the datagram and byte counters for all rules of the specified chain, or
for all chains if no chain is specified.
Create a new chain with the specified name. A chain of the same name must not
already exist. This is how user-defined chains are created.
Delete the specified user-defined chain, or all user-defined chains if
no chain is specified. For this command to be successful, there must
be no references to the specified chain from any other rules chain.
-P chain policy
Set the default policy of the specified chain to the specified policy.
Valid firewalling policies are ACCEPT,
DENY, and REJECT have the same
meanings as those for the tradition IP firewall
implementation. REDIR specifies that the datagram
should be transparently redirected to a port on the firewall host. The
RETURN target causes the IP firewall code to return
to the Firewall Chain that called the one containing this rule and
continues starting at the rule after the calling rule.
A number of ipchains parameters create a rule specification
by determining what types of packets match. If any of these parameters is
omitted from a rule specification, its default is assumed:
Specifies the protocol of the datagram that will match this rule. Valid
protocol names are tcp, udp,
icmp, or all. You may also specify a
protocol number here to match other protocols. For example, you might use
4 to match the ipip encapsulation
protocol. If the ! is supplied, the rule is negated and
the datagram will match any protocol other than the protocol specified. If this
parameter isn't supplied, it will default to all.
-s [!]address[/mask] [!] [port]
Specifies the source address and port of the datagram that will match
this rule. The address may be supplied as a hostname, a network name,
or an IP address. The optional mask is the netmask
to use and may be supplied either in the traditional form (e.g.,
/255.255.255.0) or the modern form (e.g., /24). The optional
port specifies the TCP or UDP port, or the ICMP
datagram type that will match. You may supply a port specification
only if you've supplied the -p parameter with one of
the tcp, udp, or
icmp protocols. Ports may be specified as a range
by specifying the upper and lower limits of the range with a colon as
a delimiter. For example, 20:25 described all of
the ports numbered from 20 up to and including 25. Again, the
! character may be used to negate the values.
-d [!]address[/mask] [!] [port]
Specifies the destination address and port of the datagram that will
match this rule. The coding of this parameter is the same as that of the
Specifies the action to take when this rule matches. You can think of
this parameter as meaning “jump to.” Valid targets are
ACCEPT, DENY, REJECT,
REDIR, and RETURN. We described the
meanings of each of these targets earlier. However, you may also specify the name of a
user-defined chain where processing will continue. If this parameter is
omitted, no action is taken on matching rule datagrams at all other than to
update the datagram and byte counters.
Specifies the interface on which the datagram was received or is to
be transmitted. Again, the ! inverts the result of the
match. If the interface name ends with +,
then any interface that begins with the supplied string will match. For
example, -i ppp+ would match any PPP network device and
-i ! eth+ would match all interfaces except Ethernet
Specifies that this rule applies to everything but the first fragment
of a fragmented datagram.
The following ipchains options are more general in nature.
Some of them control rather esoteric features of the IP chains software:
Causes the command to generate two rules. One rule matches the
parameters supplied, and the other rule added matches the corresponding
parameters in the reverse direction.
Causes ipchains to be verbose in its output. It
will supply more information.
Causes ipchains to display IP address and ports as
numbers without attempting to resolve them to their corresponding names.
Enables kernel logging of matching datagrams. Any datagram that matches
the rule will be logged by the kernel using its printk( )
function, which is usually handled by the sysklogd program
and written to a log file. This is useful for making unusual datagrams visible.
Causes the IP chains software to copy any datagrams matching the rule to
the userspace “netlink” device. The
maxsize argument limits the number of bytes from
each datagram that are passed to the netlink device. This option is of most
use to software developers, but may be exploited by software packages in the
Causes matching datagrams to be marked with a value. Mark
values are unsigned 32-bit numbers. In existing implementations this does
nothing, but at some point in the future, it may determine how the datagram is
handled by other software such as the routing code. If a
markvalue begins with a + or
-, the value is added or subtracted from the existing
-t andmask xormask
Enables you to manipulate the “type of service” bits in the
IP header of any datagram that matches this rule. The type of service bits are
used by intelligent routers to prioritize datagrams before forwarding them. The
Linux routing software is capable of this sort prioritization. The
andmask and xormask
represent bit masks that will be logically ANDed and ORed with the type of
service bits of the datagram respectively. This is an advanced feature that is
discussed in more detail in the IPCHAINS-HOWTO.
Causes any numbers in the ipchains output to be
expanded to their exact values with no rounding.
Causes the rule to match any TCP datagram with the SYN bit set and the
ACK and FIN bits clear. This is used to filter TCP connection requests.
Let's again suppose that we have a network in our organization and
that we are using a Linux-based firewall machine to allow our users
access to WWW servers on the Internet, but to allow no other traffic
to be passed.
If our network has a 24-bit network mask (class C) and has an address of
172.16.1.0, we'd use the following ipchains rules:
The first of the commands flushes all of the rules from the
forward rulesets and the second set of
commands sets the default policy of the forward
ruleset to DENY. Finally, the third
and fourth commands do the specific filtering we want. The fourth
command allows datagrams to and from web servers on the outside of our
network to pass, and the third prevents incoming TCP connections with
a source port of 80.
If we now wanted to add rules that allowed passive mode only access to FTP
servers in the outside network, we'd add these rules:
To list our rules with ipchains, we use its
-L argument. Just as with ipfwadm, there
are arguments that control the amount of detail in the output. In its simplest
form, ipchains produces output that looks like:
If you don't supply the name of a chain to list,
ipchains will list all rules in all chains. The
-n argument in our example tells
ipchains not to attempt to convert any address or
ports into names. The information presented should be
A verbose form, invoked by the -u option, provides much more
detail. Its output adds fields for the datagram and byte counters,
Type of Service AND and XOR flags, the interface name, the mark, and
All rules created with ipchains have datagram and
byte counters associated with them. This is how IP Accounting is
implemented and will be discussed in detail in Chapter 10. By default these counters are presented
in a rounded form using the suffixes K and
M to represent units of one thousand and one
million, respectively. If the -x argument is
supplied, the counters are expanded to their full unrounded form.
You now know that the ipchains command is a
replacement for the ipfwadm with a simpler
command-line syntax and some interesting enhancements, but you're no
doubt wanting to know where you'd use the user-defined chains and
why. You'll also probably want to know how to use the support scripts
that accompany the ipchains command in its software
package. We'll now explore these subjects and address the questions.
The three rulesets of the traditional IP firewall code provided a
mechanism for building firewall configurations that were fairly simple
to understand and manage for small networks with simple firewalling
requirements. When the configuration requirements are not simple, a
number of problems become apparent. Firstly, large networks often
require much more than the small number of firewalling rules we've
seen so far; inevitably needs arise that require firewalling rules
added to cover special case scenarios. As the number of rules grows,
the performance of the firewall deterioriates as more and more tests
are conducted on each datagram and managability becomes an
issue. Secondly, it is not possible to enable and disable sets of
rules atomically; instead, you are forced to expose yourself to attack
while you are in the middle of rebuilding your ruleset.
The design of IP Firewall Chains helps to alleviate these problems by
allowing the network administrator to create arbitrary sets of
firwewall rules that we can link to the three inbuilt rulesets. We can
use the -N option of ipchains to
create a new chain with any name we please of eight characters or
less. (Restricting the name to lowercase letters only is probably a
good idea.) The -j option configures the action to
take when a datagram matches the rule specification. The -j option
specifies that if a datagram matches a rule, further testing should be
performed against a user-defined chain. We'll illustrate this with a
Consider the following ipchains commands:
ipchains -P input DENY
ipchains -N tcpin
ipchains -A tcpin -s ! 172.16.0.0/16
ipchains -A tcpin -p tcp -d 172.16.0.0/16 ssh -j ACCEPT
ipchains -A tcpin -p tcp -d 172.16.0.0/16 www -j ACCEPT
ipchains -A input -p tcp -j tcpin
ipchains -A input -p all
We set the default input chain policy to deny. The
second command creates a user-defined chain called
“tcpin.” The third command adds a rule to the
tcpin chain that matches any datagram that was
sourced from outside our local network; the rule takes no action. This
rule is an accounting rule and will be discussed in more detail in
Chapter 10. The next two rules match any
datagram that is destined for our local network and either of the
ssh or www ports; datagrams
matching these rules are accepted. The next rule is when the real
ipchains magic begins. It causes the firewall
software to check any datagram of protocol TCP against the
tcpin user-defined chain. Lastly, we add a rule to our
input chain that matches any datagram; this is
another accounting rule. They will produce the following Firewall Chains shown in Figure 9-4.
Figure 9-4. A simple IP chain ruleset
Our input and tcpin chains are populated
with our rules. Datagram processing always beings at one of the inbuilt chains.
We'll see how our user-defined chain is called into play by following the
processing path of different types of datagrams.
First, let's look at what happens when a UDP datagram for one of our hosts
is received. Figure 9-5 illustrates the
flow through the rules.
Figure 9-5. The sequence of rules tested for a received UDP datagram
The datagram is received by the input chain and
falls through the first two rules because they match ICMP and TCP
protocols, respectively. It matches the third rule in the
input chain, but it doesn't specify a target, so
its datagram and byte counters are updated, but no other action takes
place. The datagram reaches the end of the input
chain, meets with the default input chain policy,
and is denied.
To see our user-defined chain in operation, let's now consider what
happens when we receive a TCP datagram destined for the
ssh port of one of our hosts. The sequence is shown
in Figure 9-6.
Figure 9-6. The rules flow for a received TCP datagram for ssh
This time the second rule in the input chain does
match and it specifies a target of tcpin, our
user-defined chain. Specifying a user-defined chain as a target
causes the datagram to be tested against the rules in that chain, so
the next rule tested is the first rule in the tcpin
chain. The first rule matches any datagram that has a source address
outside our local network and specifies no target, so it too is an
accounting rule and testing falls through to the next rule. The second
rule in our tcpin chain does match and specifies a
target of ACCEPT. We have arrived at target, so no
further firewall processing occurs. The datagram is accepted.
Finally, let's look at what happens when we reach the end of a
user-defined chain. To see this, we'll map the flow for a TCP datagram
destined for a port other than than the two we are handling
specifically, as shown in Figure 9-7.
Figure 9-7. The rules flow for a received TCP datagram for telnet
The user-defined chains do not have default policies. When all rules
in a user-defined chain have been tested, and none have matched, the
firewall code acts as though a RETURN rule were
present, so if this isn't what you want, you should ensure you supply
a rule at the end of the user-defined chain that takes whatever action
you wish. In our example, our testing returns to the rule in the
input ruleset immediately following the one that
moved us to our user-defined chain. Eventually we reach the end of the
input chain, which does have a default policy and
our datagram is denied.
This example is very simple, but illustrates our point. A more practical use of
IP chains would be much more complex. A slightly more sophisticated example is
provided in the following list of commands:
# Set default forwarding policy to REJECT
ipchains -P forward REJECT
# create our user-defined chains
ipchains -N sshin
ipchains -N sshout
ipchains -N wwwin
ipchains -N wwwout
# Ensure we reject connections coming the wrong way
ipchains -A wwwin -p tcp -s 172.16.0.0/16 -y -j REJECT
ipchains -A wwwout -p tcp -d 172.16.0.0/16 -y -j REJECT
ipchains -A sshin -p tcp -s 172.16.0.0/16 -y -j REJECT
ipchains -A sshout -p tcp -d 172.16.0.0/16 -y -j REJECT
# Ensure that anything reaching the end of a user-defined chain is rejected.
ipchains -A sshin -j REJECT
ipchains -A sshout -j REJECT
ipchains -A wwwin -j REJECT
ipchains -A wwwout -j REJECT
# divert www and ssh services to the relevant user-defined chain
ipchains -A forward -p tcp -d 172.16.0.0/16 ssh -b -j sshin
ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 ssh -b -j sshout
ipchains -A forward -p tcp -d 172.16.0.0/16 www -b -j wwwin
ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 www -b -j wwwout
# Insert our rules to match hosts at position two in our user-defined chains.
ipchains -I wwwin 2 -d 172.16.1.2 -b -j ACCEPT
ipchains -I wwwout 2 -s 172.16.1.0/24 -b -j ACCEPT
ipchains -I sshin 2 -d 172.16.1.4 -b -j ACCEPT
ipchains -I sshout 2 -s 172.16.1.4 -b -j ACCEPT
ipchains -I sshout 2 -s 172.16.1.6 -b -j ACCEPT
In this example, we've used a selection of user-defined chains both to
simplify management of our firewall configuration and improve the
efficiency of our firewall as compared to a solution involving only the
Our example creates user-defined chains for each of the
ssh and www services in each
connection direction. The chain called wwwout is
where we place rules for hosts that are allowed to make outgoing World
Wide Web connections, and sshin is where we define
rules for hosts to which we want to allow incoming ssh
connections. We've assumed that we have a requirement to allow and
deny individual hosts on our network the ability to make or receive
ssh and www connections. The
simplication occurs because the user-defined chains allow us to neatly
group the rules for the host incoming and outgoing permissions rather
than muddling them all together. The improvement in efficiency occurs
because for any particular datagram, we have reduced the average number
of tests required before a target is found. The efficiency gain
increases as we add more hosts. If we hadn't used user-defined chains,
we'd potentially have to search the whole list of rules to determine
what action to take with each and every datagram received. Even if we
assume that each of the rules in our list matches an equal proportion
of the total number of datagrams processed, we'd still be searching
half the list on average. User-defined chains allow us to avoid
testing large numbers of rules if the datagram being tested doesn't
match the simple rule in the built-in chain that jumps to them.
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:
to save your current firewall configuration. You'd restore it, perhaps at
boot time, with:
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.