next up previous
Next: Kernel filtering scheme Up: Linux firewall facilities for Previous: Introduction

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:

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.


next up previous
Next: Kernel filtering scheme Up: Linux firewall facilities for Previous: Introduction

Note that this paper is based on Linux 1.3.88 and ipfwadm 2.0, describing the situation in April 1996.
A revision of this paper for Linux 2.0.x and ipfwadm 2.3.0 is planned, but not yet available.

Copyright © 1996 by X/OS Experts in Open Systems BV. All rights reserved.

ÿÿÿ