Next: Kernel filtering scheme
Up: Linux firewall facilities for
Previous: Introduction
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.
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.