A Lua scripting engine for in-kernel packet processing

Cours informatique LUA, tutoriel & guide de travaux pratiques en pdf.

Background

In this chapter we provide background information about the technologies used in this project. While there are several books, papers, and presentations explaining these technologies in-depth, we provide some general information and point the reader to the different references for further reading. Section 2.1 shortly describes the Netfilter framework as well as how it can be extended. Section 2.2 introduces the Lua scripting environment.

Netfilter
Netfilter [1] is the component of the Linux kernel that is used when the network traffic needs to be inspected and/or manipulated. More specifically, Netfilter inserts five hooks into the networking stack (see Figure 2.1):
• PREROUTING: All packets traverse this hook. It is called before any routing decision is made, but after all IP header sanity checks have succeeded. Typically, Port Address Translation (PAT), the redirection of packets, as well as Destination Network Address Translation (DNAT) are implemented in the PREROUTING hook.
• INPUT: All incoming packets that are destined to the local machine pass this hook. This is the last hook traversed by incoming packets.
• FORWARD: All packets that are not destined to the local machine traverse this hook. This hook is typically used for implementing firewalls.
• OUTPUT: This is the first hook that is traversed by outgoing packets. All packets that leave the local machine pass this hook.
• POSTROUTING: All packets that leave the local machine traverse this hook. It is called after any routing decision. The POSTROUTING hook is typically used to implement Source Network Address Translation (SNAT).
Figure 2.1 illustrates the Netfilter’s hook-system. Netfilter provides an API for registering and unregistering a callback function to a given hook. Such callback functions typically return a value, the verdict that controls how Netfilter should further proceed with the packet. The following verdicts are currently defined in Netfilter:
• ACCEPT: The packet should also traverse any further hook.
• DROP: The packet should be silently discarded.
• QUEUE: The packet is passed to a userspace program, which will handle the packet.
• REPEAT: This verdict forces the packet to traverse the same hook again.
• STOLEN: The packet is silently held until something happens. This verdict enables that packets can be collected for further processing. This is used for dealing with fragmented IP packets.
Kernel modules such as ip_tables, arp_tables, and ebtables use these hooks to provide a more convenient way for defining rules for filtering and transforming packets. A well-known userspace tool for inserting such rules is iptables, which we also extend for loading and unloading the Lua scripts.
Having a closer look at the Netfilter internals, we can see that Netfilter itself does not provide a lot of functionality. It rather offers a framework, where several Linux Kernel Modules (LKM) register their services. In fact, packet matching as well as packet processing (as used for NAT) functionalities are implemented in several LKMs being loaded when needed. In order to simplify the development and integration of such LKMs, the project Xtables-addons [16]wassetup. UsingXtables-addons, thereisnoneedtopatchorrecompile the kernel. Furthermore, this framework can be used to easily install Netfilter extensions that are not yet accepted in the main kernel/iptables packages. PacketScript was hence developed using the Xtables-addons. Typically, Netfilter extension development involves the implementation of a LKM containing all important packet processing functionalities, as well as a userspace plugin needed by iptables when a new rule is injected. The following subsections describe these two software parts.

Userspace Plugin
Theword“plugin” implies that there is a userspace application to be extended. In the case of PacketScript, the userspace tool iptables is extended by the PacketScript userspace plugin. This is necessary in order for iptables to load the corresponding LKM into memory as well as for knowing the proper format to copy the provided parameters from userspace to the LKM. Additionally, the plugin may provide functionality for validating the parameters and for presenting information on the command line about the usage of the module. Xtablesaddons also simplifies the development of the userspace plugin.

Linux Kernel Module

Once a rule is validated by the userspace plugin, the data is copied from userspace to the LKM.TheLKMprovidesacheckentry functionbeinginvokedwheneverdatahasbeencopied to the LKM. Usually, this function does additional validation and some initialization work. ForcallingthecheckentryfunctiontheLKMmustalreadybeloaded. Loadingandunloading is normally done by some userspace tools, such as for example modprobe, rmmod; or in the Netfilter case, iptables may automatically load the LKM. The LKM provides a module_init function,whichisautomaticallycalledwhentheLKMisloaded. Additionally,itprovidesthe module_exit function, beingcalledwhentheLKMisunloaded. Thesefunctionsaretypically used to initialize and shutdown the LKM. For instance a Netfilter extension (un)registers several callback functions within these functions:
• The checkentry function is called when a new rule copies some data from userspace to the LKM. This function validates the passed data, and may initialize some data needed within the target/match function.
• The destroy function is called when a rule is deleted. This function is typically used for freeing the resources allocated within the checkentry function.
• The target/match function is called when a packet is passed to the match/target extension. This function is used to process the packet in order to change its content or just for deciding whether the packet gets either accepted or dropped.
Thereareafewotherfunctions,whicharerarelyusedandremainunusedwithinPacketScript. Further information about developing Netfilter extensions can be found in [17, 18].