Chapter 12: Networks
Netfilter functionality can be enhanced by modules loaded into the kernel at run time. A defined rule set
informs the kernel when to use the code from the individual modules. The interface between the kernel
and netfilter is kept very small to separate the two areas from each other as well as possible (and as little
as necessary) in order to prevent mutual interference and improve the network code stability.As frequently mentioned in the preceding sections,netfilter hooksare located at various points in the
kernel to support the execution of netfilter code. These are provided not only for IPv4 but also for IPv6
and the DECNET protocol. Only IPv4 is discussed here, but the concepts apply equally to the other two
protocols.Netfilter implementation is divided into two areas:❑ Hooksin the kernel code are used to call netfilter code and are at the heart of the network imple-
mentation.
❑ Netfilter modules whose code is called from within the hooks but that are otherwise indepen-
dent of the remaining network code. A set of standard modules provides frequently needed
functions, but user-specific functions can be defined in extension modules.Iptables used by administrators to configure firewall, packet filter, and similar functions are simply
modules that build on the netfilter framework and provide a comprehensive, well-defined set of library
functions to facilitate packet handling. I won’t bother describing how the rules are activated and managed
from within userspace; see the abundance of literature on network administration.Calling Hook Functions
Functions of the network layer are interrupted by hooks at which netfilter code is executed. An important
feature of hooks is that they split a function into two parts — the first part runs before the netfilter code
is called, the second after. Why are two separate functions used instead of calling a specific netfilter func-
tion that executes all relevant netfilter modules and then returns to the calling function? This approach,
which at first may appear to be somewhat complicated, can be explained as follows. It enables users (or
administrators) to decide not to compile the netfilter functionality into the kernel, in which case, the net-
work functions can be executed without any loss of speed. It also dispenses with the need to riddle the
network implementation with pre-processor statements that, depending on the particular configuration
option (netfilter enabled or disabled), select the appropriate code sections at compilation time.Netfilter hooks are called by theNF_HOOKmacro from<netfilter.h>. The macro is defined as follows if
netfilter support is enabled in the kernel:<netfilter.h>
static inline int nf_hook_thresh(int pf, unsigned int hook,
struct sk_buff **pskb,
struct net_device *indev,
struct net_device *outdev,
int (*okfn)(struct sk_buff *), int thresh,
int cond)
{
if (!cond)
return 1;
return nf_hook_slow(pf, hook, pskb, indev, outdev, okfn, thresh);
}