Firewall Rules Creation Using ipchains Utility
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.
Using ipchains
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. 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 rule sets related to firewalling that are always present. The
standard rule sets are direct equivalents of those used with ipfwadm, except they have names: input, forward and output.
Let's
first look at the general syntax of the ipchains command, then we'll look at how we use ipchains instead of ipfwadm without worrying about
any of the advanced chaining features.
ipchains Command Syntax
The ipchains command syntax is
straightforward. We'll now look at the most important of those. The general
syntax of most ipchains commands is:
ipchains command rule-specification options
Commands
There
are a number of ways we can manipulate rules and rulesets with the ipchains command. Those relevant
to IP firewalling are:
-A chain
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.
-D chain
Delete one or more rules from the specified chain that matches the
rule specification.
-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 chain.
-R chain rulenum
Replace the rule residing at position rulenum in the specific chain with the supplied rule
specification.
-C chain
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.
-L [chain]
List the rules of the specified chain, or for all chains if no
chain is specified.
-F [chain]
Flush the rules of the specified chain, or for all chains if no
chain is specified.
-Z [chain]
Zero the datagram and byte counters for all rules of the specified
chain, or for all chains if no chain is specified.
-N chain
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.
-X [chain]
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, REJECT, REDIR, or RETURN.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.
Rule specification parameters
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:
-p [!]protocol
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 -sparameter.
-j target
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.
-i [!]interface-name
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 devices.
[!] -f
Specifies that this rule applies to everything but the first
fragment of a fragmented datagram.
Options
The
following ipchains options are more general in nature. Some of them control rather
esoteric features of the IP chains software:
-b
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.
-v
Causes ipchains to be verbose in its output. It will supply more information.
-n
Causes ipchains to display IP address and ports as numbers without attempting to
resolve them to their corresponding names.
-l
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.
-o[maxsize]
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.
-m markvalue
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 markvalue.
-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 andmaskand 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.
-x
Causes any numbers in the ipchains output to be expanded to their exact values with
no rounding.
-y
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.
Example
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
# 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 forwardruleset 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:
# 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
# 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
Listing Our Rules with ipchains
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 -n
Chain input (policy ACCEPT):
Chain 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 self-explanatory.
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 ANDand XOR flags, the interface name, the mark, and the
outsize.
All
rules created with ipchains have datagram and byte counters associated with them. 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.
User-defined chains
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 diagram.
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 thetcpin chain that matches any datagram that was sourced from outside our
local network; the rule takes no action. The next two rules match any
datagram that is destined for our local network and either of the ssh orwww 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 diagram:-
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.
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.
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.
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 built-in chains.
Our
example creates user-defined chains for each of the ssh and www services in each
connection direction. The chain called www out 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.
