We will show you how to implement the required functionality yourself by writing an extension module when the firewall is based on IPTables. What's more, you'll be surprised just how easy it is.

Applying system security policy to firewall rules can be a difficult task, especially if it requires functionality that the basic firewall product does not provide. Fortunately, if the firewall is based on IPTables, you can implement the required functionality yourself by writing an extension module. What’s more, you’ll be surprised just how easy it is.

Anyone even vaguely familiar with the Internet and computers must have heard of firewalls, and anyone who’s ever dealt with IT security must have configured a software firewall at some stage. There’s much variety among available firewall systems, but of course from a technical point of view the crucial factor is the functionality they offer. Commercial firewall vendors will frequently do their best to convince you that their software offers unique and highly advanced features that the competition can only dream of, provides near-infinite filtering capabilities and comes with an inexhaustible supply of helpful and cheerful round-the-clock support.

The problem is that support does indeed tend to be necessary, even though a working product would be much preferable to delightful e-mail exchanges with the support staff. More often than not we would also like to see and understand why something is not working, as it soon turns out that a chosen product’s capabilities are not only finite, but frequently insufficient. The good news is that if you need unique and advanced functionality, you can develop it yourself using open source software such as IPTables, a bit of spare time and (hopefully) this article. (Which of course is not to say that commercial packages are useless).

You can download the IPTables package at www.netfilter.org, and it is supplied as standard with Linux distributions with kernel 2.4 and later. The website also provides a brief overview of the project’s history - it’s been around long enough to be considered a mature and reliable product. In my opinion, one of the package’s most powerful features is its support for custom extensions.

The Netfilter package on which IPTables is based is actually a development framework for filtering and modifying network packets. From a programmer’s point of view, its key features are:

• hooks - specific locations in the system’s network protocol stack from which Netfilter code is called for each packet that traverses the stack,

• functions assigned to particular hooks and called by Netfilter for each packet that traverses the protocol stack,

• the ip_queue driver for queuing packets into user space for asynchronous processing.

The source code is extensively commented - a non-functional, but equally useful feature.

IPTables is essentially a set of modules that use Netfilter functionality to define rule tables, pattern-based packet matching criteria and actions to be taken for matching packets. All this allows Netfilter functionality to be accessed at a higher level of abstraction for clearer and more convenient use. The name IPTables originates from the fact that rule lists are represented as tables, and each named table is stored in memory.

IPTables can generally be divided into two functional components: one for port and network address translation services (PNAT) and the other for filtering services. Both components are extensible. Apart from extension modules, the package also includes user space tools that allow rules to be entered more conveniently.

Extension modules

An IPTables extension module is a typical kernel module that has to use a number of standard structures and implement several module functions. The module code also has to be re-entrant, as it is possible for its execution to be interrupted during processing by a request to process another packet. In SMP systems with large numbers of processors, the chances of interruption are much larger. Here’s a list of the basic functions that a module has to implement:

• init_module() - module entry point, which has the basic task of registering the module within the framework, returning 0 if successful or a negative integer in case of failure,

• cleanup_module() - module exit point; the function code should unregister the module from the Netfilter framework,

• ipt_register_match() - used to register match extensions; takes a struct ipt_match structure as a parameter,

• ipt_register_target() - used to register target extensions; takes a struct ipt_target structure as a parameter,

• ipt_unregister_match() - unregisters a match extension,

• ipt_unregister_target() - unregisters a target extension.

A module is usually used either as a target module or as a matching module, so you need to select the four relevant functions from the collection above. In fact, in actual implementations the function names are a little different, and we can also make use of standard macros. The structures passed to ipt_register_match() and ipt_register_target() are described in the Inset Extension registration structures.

Apart from the functions listed above, we also need to implement extension-specific functions, whose pointers were passed in the module registration structure. Once that’s done, we have a working module. Let’s see how all this works in practice.

Implementing a sample extension

Getting back to commercial products for a while, many of them provide filtering functions that are grouped into packages and accessible through a few clicks within the GUI. A certain commercial solution provides a set of simple operations collectively called Fingerprint Scrambling, which are supposed to hinder operating system fingerprinting. We will implement similar functionality using the ipt_TTL, ipt_IPID and ipt_ISN extensions. The first modifies the TTL field of an IP datagram and is available in the standard package. We will go through creating the second extension below, and developing the third one will be left as homework for the Reader.

The name of the ipt_IPID extension is less than obvious, so let’s discuss its purpose first. One of the factors that aid remote OS fingerprinting is the ability to identify the algorithm used to calculate the value of the ID field in IP datagrams sent by the remote system (you can find more information in the Inset ID field in IP datagrams). Our job will be to modify the ID field in outgoing datagrams so as to hinder such identification.

A d v e r t i s e m e n t

sum:

0 €