Olaf Kirch - Linux Network Administrator Guide, Second Edition

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 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.

- 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.

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 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:

# 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 -n

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 AND and XOR flags, the interface name, the mark, and the outsize.

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 diagram.