Netfilter Hooks

Netfilter is a subsystem in the Linux 2.4 kernel. Netfilter provides an generic and abstract interface to the standard routing code. This is currently used in Linux kernel for packet filtering, mangling, NAT(network address translation) and queuing packets to the userspace.I have been using netfilters in my final year project(in VoIP security) as a packet capture mechanism.Netfilter makes connection tracking possible through the use of various hooks in the kernel’s network code.

These hooks are places that kernel code, either statically built or in the form of a loadable module, can register functions to be called for specific network events. An example of such an event is the reception of a packet.

Linux , since 2.4,  supports hooks for IPv4 and IPv6. Netfilter defines five hooks for IPv4. The declaration of the symbols for these can be found in “linux/netfilter_ipv4.h”. These hooks are displayed in the table below:

Hook	Called at
NF_IP_PRE_ROUTING	After sanity checks, before routing decisions.
NF_IP_LOCAL_IN	After routing decisions if packet is for this host.
NF_IP_FORWARD	If the packet is destined for another interface.
NF_IP_LOCAL_OUT	Packets coming from local processes on their way out.
NF_IP_POST_ROUTING	Just before outbound packets “hit the wire”.

The NF_IP_PRE_ROUTING hook, called as the first hook after a packet has been received, has been used for packet capture in this project. The following diagrams diagrammatically represents where exactly does each of these hooks operate at.

At any of these hooks we can define Callback functions which act as handler routines. These functions are invoked when the corresponding network event occurs. Now the fate of the packet is determined by the return code of the hook function. Various return codes available are:

Return Code	Meaning
NF_DROP	Discard the packet.
NF_ACCEPT	Keep the packet.
NF_STOLEN	Forget about the packet.
NF_QUEUE	Queue packet for userspace.
NF_REPEAT	Call this hook function again.

The NF_DROP return code means that this packet should be dropped completely and any resources allocated for it should be released. NF_ACCEPT tells Netfilter that so far the packet is still acceptable and that it should move to the next stage of the network stack. NF_STOLEN is an interesting one because it tells Netfilter to “forget” about the packet. What this tells Netfilter is that the hook function will take processing of this packet from here and that Netfilter should drop all processing of it. This does not mean, however, that resources for the packet are released. The packet and it’s respective sk_buff structure are still valid, it’s just that the hook function has taken ownership of the packet away from Netfilter. Unfortunately I’m not exactly clear on what NF_QUEUE really does so for now I won’t discuss it. The last return value, NF_REPEAT requests that Netfilter calls the hook function again. Obviously one must be careful using NF_REPEAT so as to avoid an endless loop.

I will try to add more details on the same with sample codes in my future posts.

PS: The post contains adopted contents. Content was actually prepared for the project documentation purpose.