The Legacy ipfwadm and ipchains

Starting with kernel version 1.2.1, Linux has offered a number of utilities to configure the rules used by the kernel to accept or discard IP packets. The first incarnation of this utility was Alan Cox and Jos Vos' ipfwadm utility, which was based on BSD's ipfw utility and worked with kernel versions 1.2 through 2.1. The last version of ipfwadm was released in July 1996. Starting with kernel version 2.1.102 and later, ipfwadm has been replaced by Paul "Rusty" Russell and Michael Neuling's ipchains, which addresses some of ipfwadm's limitations, namely:

■ 32-bit counters, which were previously unable to keep track of packets coming into high-speed network interfaces

■ Inability to deal adequately with IP fragmentation

■ No support for transport layer protocols other than UDP and TCP

■ No support for inverse rules, where you look for the opposite of a condition (e.g., -i !eth0).

If your Linux distribution only supports ipfwadm, you are running an old system and you should upgrade to a newer version. Most recent Linux vendors include the ipchains utility in their standard distribution. The next section explains how to use the ipchains command and includes some real-life examples of how you can use it to build a network layer firewall.

Using ipchains

The name ipchains refers to the fact that the Linux kernel consults three separate chains, or sequence of rules, when it receives a network layer packet. There are three chains that come built-in with the Linux kernel:

Input Chain The input chain handles packets that arrive at one of the server's interfaces and are bound for the local host.

Output Chain The output chain handles packets that are originated by the local system and are bound for a remote host.

Forward Chain The forward chain handles packets that arrive at one of the server's interfaces and are bound for a remote host.

Each of these three chains can contain a set of rules that define access controls based on the source/destination address, the TCP/UDP port, or the protocol ID. By specifying a set of rules that enforce the provisions of your security policy, you can build a firewall device using the Linux kernel as the underlying system and ipchains as your configuration tool. Let's take a look at the syntax of the ipchains command.

The ipchains utility uses the following syntax:

ipchains command chain rule-specifications [options] -j action

The command field is used to maintain the list of rules for a given chain and defines, for example, whether you're adding a rule, deleting a rule, or simply listing the rules that have already been defined for that chain. Table 9.1 contains a list of valid commands supported in ipchains.

Table 9.1 ipchains Commands

Switch	Meaning
-A	Add a rule to a chain (append to end of the chain).
-D	Delete a rule from a chain.
-C	Create a new chain.
-R	Replace an existing rule in the chain.
-L	List all rules in the chain.
-I	Insert numbered rules in the chain.
-F	Flush all rules from the chain (empty the chain).
-Z	Zero (reset) the packet and byte counters on all chains.
-N Create a new chain.
-X	Delete the user-defined chain.
-P	Set policy for the chain to the given target.
-E	Rename the chain.
-M	View currently masqueraded connections.
-C	Check a given packet against a selected chain.

Change the timeout values used for masquerading.

PART 4

The chain field can be one of INPUT, OUTPUT, or FORWARD, or it can be a user-created chain (in the case of the -C command). You'll learn more about user-created chains later in this section.

The rule-specifications field is where you can specify one or more rules to be applied to each packet. Each incoming packet is compared to the parameters included in each rule, and, if a match is found, the appropriate action is taken for that packet. Table 9.2 lists the set of available constructors for the ipchains rules.

Table 9.2 ipchains Rule Specification Parameters

Parameter	Meaning
-p [!]protoco7	Protocol ID to match. This can be tcp, udp, icmp, or any numeric or alphabetic representation of a service in /etc/services.
-s [!]address[/mask]	Source address to match. This can be a host name, an IP address, or a network name in network/mask format.
--sport [port:[port]]	Specification of source port or source port range.
-d [!]address[/mask]	Destination address to match. Same rules as the -s parameter apply here.
--dport [port:[port]]	Specification of destination port or destination port range.
-j target	Action to take when the rule finds a match (e.g., accept, drop). Note that in addition to being the name of an action, target can also be a user-specified chain or a built-in chain.
-i [!]interface	Interface through which the packet was received, such as eth0.
-o [!]interface	Interface through which the packet is to be sent, such as eth0.
[!] -f	Packet is a second or subsequent fragment of a larger fragmented packet.
-y	Only match TCP packets with the SYN bit set.

The parameters listed in Table 9.2 allow you to define any combination of source/destination IP address, port, protocol ID, and interface, along with the inverse of each of these conditions, by simply preceding the parameter with the exclamation mark [!].

Finally, the ipchains command needs to be told what action to take with each packet that matches the given rule. The action field is preceded by the -j option (which literally stands for jump), and can be one of the following:

■ chain : This can be a user-defined chain. This allows you to "call" a chain within another chain, similar to the case where a subroutine calls another to perform a defined operation.

■ accept: Let the packet through.

■ deny: Quietly drop the packet on the floor.

■ reject: Drop the packet and inform the sender via an ICMP message.

■ masq: Modify (masquerade) the packet's source IP address as if it had originated from the local host. This action only applies to the forward chain and to any user-defined chains.

■ redirect: Forward the packet to a local socket even if its destination is a remote host. This action only applies to the input chain and to any user-defined chains.

■ return: Exit the present chain and return to the calling chain.

Ipchains Examples

Let's take a look at some examples of the ipchains command. Consider a Linux server called watchtower.example.com with the following interfaces:

■ eth1: 38.110.200.1 (private interface)

Let's start by flushing the three built-in chains from all previously specified rules using the following commands:

ipchains -F input ipchains -F output ipchains -F forward

To set up a policy whereby all packets that are not matched by a specific rule within the chain will be rejected, use the following commands:

ipchains -P input REJECT

PART 4

ipchains -P output REJET

ipchains -P forward REJECT

The previous three commands set up a restrictive policy where you have to explicitly define the kinds of traffic that you want to allow through your firewall. Suppose that your security policy allows incoming mail, HTTP, and telnet connections from any public host. You enforce by adding the appropriate rule to the forward chain:

ipchains -A forward -s 0.0.0.0/0 -d 38.110.200.0/24 -dport smtp -j^ ACCEPT

ipchains -A forward -s 0.0.0.0/0 -d 38.110.200.0/24 -dport http -j^ ACCEPT

ipchains -A forward -s 0.0.0.0/0 -d 38.110.200.0/24 -dport telnet -j^ ACCEPT

ipchains -A forward -s 38.110.200.0/24 -d 0.0.0.0/0 -sport smtp -j^ ACCEPT

ipchains -A forward -s 38.110.200.0/24 -d 0.0.0.0/0 -sport http -j^ ACCEPT

ipchains -A forward -s 38.110.200.0/24 -d 0.0.0.0/0 -sport telnet -j^ ACCEPT

Note that the first three rules will match incoming connections, while the last three rules will match outgoing responses to those connections. Since you have only added rules to the forward chain, you're not yet allowing any connections to the Linux firewall itself. Perhaps you want to be able to telnet to the server for maintenance, but only from a known internal host of IP address 38.110.200.10 (ideally, the system administrator's workstation). The following two rules will allow this:

ipchains -A input -s 38.110.200.10 -dport telnet -j ACCEPT

ipchains -A output -d 38.110.200.10 -sport telnet -j ACCEPT

As with the previous example, you need to allow both incoming access for the telnet traffic, but also outgoing access for the responses.

Finally, let's say that you want to guard against packet spoofing by ensuring that all traffic that leaves the internal network has the proper source address:

ipchains -A forward -i eth1 -s !38.110.200.0/24 -j REJECT

This command uses an inverse rule by stating that all traffic that enters the server at interface eth1 (the private interface) and does not contain a source IP address in the 38.110.200.0 class-C network should be rejected.

As of Linux kernel 2.4 (the latest stable version at the writing of this book), the functionality once provided by ipwfadm and ipchains is now being provided by Netfilter and its iptables user space tool. I recommend that you deploy your Linux firewall on a 2.4 kernel machine and that you use the Netfilter package for packet filtering. This is the topic of discussion of the next section.

Continue reading here: The Present Netfilter

Was this article helpful?

0 0