IP packet filtering

Before describing the Linux implementation of IP packet filtering, we will briefly introduce the underlying general concepts.

IP packet filters inspect network datagrams (IP packets) and decide whether these packets are allowed to pass the filter or not. These inspections may take place at several stages, like the moment packets arrive on the system or when they are about to be forwarded to another system.

The decision to let a filter block certain packets is usually based on several criteria, being checked against the contents of the IP packet and some environmental parameters:

• Source and destination IP addresses. This allows an administrator to restrict the traffic through the system by allowing only packets coming from (or sent to) a set of well-known hosts or networks. These addresses can be found in the header of every IP packet.
• Protocol, like TCP, UDP, or ICMP, which can also be found in the IP header.
• IP options. One of the more well-known options is the source route option, which can be considered to be dangerous in itself. Packets carrying this option are often refused.
• Source and destination port numbers, associated with TCP or UDP services. These port numbers can be found in the TCP and UDP header. Filters using port numbers can restrict the network traffic to a limited set of services, each of which is associated with a well-known port.
• TCP flags, being part of the TCP header. Most packet filters allow the TCP ACK and/or SYN bits to be checked, indicating whether a new connection is being set up or not. This is particularly useful when you want to allow some TCP sessions being initiated only from one side (e.g., only from hosts in your own network).
• ICMP message types, being defined in ICMP packets. This enables you to restrict ICMP traffic to a limited set of message types. You may, for example, want to refuse Echo Request packets (as used by ping).
• User data, found in the (protocol-specific) data part of the IP packet. This is a tricky one, which normally doesn't belong in IP packet filters.
• Network device, via which a packet is received or is going to be sent. This enables you to let a filter act differently for different network devices (like external and internal interfaces).
• Date and time. This can be used to limit some types of network traffic to office hours, for example.

Some of these criteria are easy to check, such as the ones being part of the IP header. Others may be more difficult to handle, such as the information found in the TCP/UDP headers. One IP packet, for example, may be split up in two or more IP fragments, of which only the first fragment contains the TCP header. Furthermore, IP packets may not pass the filter in sequence, because session control is handled in the TCP layer. Some packet filters address some of these problems, others don't.

An IP packet filter can react in different ways to packets, depending on the filters and the capabilities of the filtering system. The most obvious actions are: let the packet pass the filter normally or drop the packet silently. Some filters also offer the possibility to send some notification (like an ICMP Destination Unreachable message) back to the sender, in case a packet is blocked by the filter. Besides that, filters often include some logging facility, to facilitate the network administrator in detecting if someone is trying to break in.

There are several ways to implement packet filters in a UNIX system. The most efficient way is to implement it in the kernel. One of the disadvantages of this method is that it is not very flexible. Another method is to let some user-level process do the filtering. Such a daemon process has to get the relevant information of all IP packets (at least part of the IP and TCP/UDP headers, possibly even the data part) via some system call, apply its filter rules, and pass the answer back to the kernel. The (freely available) screend package behaves like this. The major drawback of these implementations is the considerable overhead generated by the system calls and process scheduling.

ÿÿÿ