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 offer.
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:
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.
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 rule specification.
Delete the rule residing at position
in the specified chain. Rule positions start at one for the first rule in the
Replace the rule residing at position
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 is specified.
Flush the rules of the specified chain, or for all chains if no chain is specified.
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.
Set the default policy of the specified chain to the specified policy.
Valid firewalling policies are
REJECT have the same
meanings as those for the tradition IP firewall
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
all. You may also specify a
protocol number here to match other protocols. For example, you might use
4 to match the
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
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
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.
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
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
-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
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 future.
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
-, the value is added or subtracted from the existing
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
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:
ipchains -F forward#
ipchains -P forward DENY#
ipchains -A forward -s 0/0 80 -d 172.16.1.0/24 -p tcp -y -j DENY#
ipchains -A forward -s 172.16.1.0/24 -d 0/0 80 -p tcp -b -j ACCEPT
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
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:
ipchains -A forward -s 0/0 20 -d 172.16.1.0/24 -p tcp -y -j DENY#
ipchains -A forward -s 172.16.1.0/24 -d 0/0 20 -p tcp -b -j ACCEPT#
ipchains -A forward -s 0/0 21 -d 172.16.1.0/24 -p tcp -y -j DENY#
ipchains -A forward -s 172.16.1.0/24 -d 0/0 21 -p tcp -b -j ACCEPT
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:
ipchains -L -nChain input (policy ACCEPT): Chain forward (policy DENY): target prot opt source destination ports DENY tcp -y---- 0.0.0.0/0 172.16.1.0/24 80 -> * ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 80 ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 80 -> * ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 20 ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 20 -> * ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 * -> 21 ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 21 -> * Chain output (policy ACCEPT):
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
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
-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
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
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
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.
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.
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
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.
This time the second rule in the
input chain does
match and it specifies a target of
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
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
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.
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 ACCEPTipchains -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 built-in chains.
Our example creates user-defined chains for each of the
www services in each
connection direction. The chain called
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
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.