The packet filter/firewall available in current versions of the Linux kernel is iptables. It was introduced in the 2.3.x development kernels, and is part of the upcoming 2.6.x kernels.
Another type of firewall is implemented as a set of programs that intercept network traffic. These programs are commonly known as proxies. They typically are not part of the operating system kernel. Proxy-based firewalls can handle very complicated protocols, but they are slower than packet filters. Some firewalls combine features of both packet filters and proxies.
Unlike the previous version of the kernel packet filter (known as ipfwadm), iptables can keep track of open connections by creating rules dynamically. This feature is important because it improves the effectiveness of the filters we create.
Using iptables allows the definition of rule sets, which are named lists of rules that are searched sequentially until a rule is found that terminates the search. Three rule sets are predefined: INPUT, OUTPUT, and FORWARD. Others can be defined by the user, and rule sets can be linked together.
Many of the features provided by iptables are contained in kernel modules that can be loaded on an as-needed basis. Note that iptables has many features, such as Network Address Translation, which we do not describe in this document. Refer to the documents listed in the "Related Resources" on page 22 for more information.
The iptables firewall uses one of three predefined rule sets to decide whether a packet should be discarded. First, packets are classified into one of three categories:
Outgoing packets: packets originating on the host, destined for other computers
Incoming packets: packets originating elsewhere, destined for the host
Forwarded packets: packets that are forwarded by the host
FIGURE 1 illustrates how incoming and outgoing packets are processed.
FIGURE 1 Processing Incoming and Outgoing Packets
Outgoing packets are passed to the OUTPUT rule set. Incoming packets are passed to the INPUT rule set. If the host is configured to act as a router, the forwarded packets are passed to the FORWARD rule set. We do not use the FORWARD rule set in our example because using Linux iptables to build a routing firewall is outside the scope of this article.
The iptables Command
The kernel packet filter is configured using the iptables command. This command has many options, and we do not use all of them in this article. The command must be run under the root account, because the system calls used to change filter settings in the kernel are privileged. Add firewall rules one rule at a time, using multiple iptables commands. For a comprehensive list of options, refer to the iptables(8) manual page.
The iptables command accepts positional parameters and flags. The command syntax can appear quite cluttered, and the resulting rule sets are far from easy to read. To give a few examples:
# iptables flush # deletes are filter rules in all chains # iptables delete-chain # deletes all user-defined chains # iptables append INPUT -p tcp --dport 80 -j ACCEPT # allow incoming TCP packets to port 80
Dynamic Packet Filtering
Traditional packet filters do not retain any state of packets that pass through them (except for logging information). Each packet is handled independently. It is very difficult to create a secure firewall using this type of packet filter. For instance, it is impossible to block Transport Control Protocol (TCP) port scanning of hosts protected by such a firewall; therefore, we consider a packet filter to be of limited use in protecting hosts.
The current generation of Linux packet filters is able to maintain state about TCP and User Datagram Protocol (UDP) sessions, making it much easier to create a selective set of rules that block port scanning and that correctly handle difficult cases such as dynamic naming service (DNS) queries and file transfer protocol (FTP) sessions.
Maintaining session state for every connection comes at a cost: It requires system resources to maintain this state, and it leaves the system open to denial-of-service (DOS) attacks that try to overload the filtering code. The rule set design presented later in this article attempts to mitigate this problem by only maintaining state for those sessions for which it is really necessary: outbound sessions from ephemeral ports and inbound FTP sessions. This approach should make it much harder to perform denial of service (DOS) attacks against the host.
Unless you use a host as a router, make sure that the host does not forward packets. On Linux systems, this technique is achieved by making sure the following line is included in the file /etc/sysctl.conf:
net.ipv4.ip_forward = 0
Use the following command to verify that routing is disabled:
$ sysctl net.ipv4.ip_forward
For more information, refer to the Sun BluePrints OnLine articles titled "Securing Sun Linux Systems, Part I, Local Access and File Systems and Securing Sun Linux Systems, Part II, Network Security."
The iptables firewall is somewhat lacking in its support of logging. When it generates a log message, this message is passed through the standard interface for kernel messages, which is not designed to handle a large volume of messages. The logging daemon syslog then writes the message to a log file. The syslog daemon uses a synchronous write that flushes every message to disk, a slow operation that causes message loss when the firewall rule set generates a lot of messages.
The rule set design we present in this article is designed to limit the rate at which log messages are produced. For the approach used, this is the most suitable method.