In yet another set of advancements to the kernel IP packet filtering code, netfilter allows users to set up, maintain, and inspect the packet filtering rules in the new 2.4 kernel. This document explains those changes and tips on how to get started.

The netfilter subsystem is a complete rewrite of previous packet filtering implementations including ipchains and ipfwadm. Netfilter provides a large number of improvements, and it has now become an even more mature and robust solution for protecting corporate networks.

Netfilter provides a raw framework for manipulating packets as they traverse through various parts of the kernel. Part of this framework includes support for masquerading, standard packet filtering, and now more complete network address translation. It even includes improved support for load balancing requests for a particular service among a group of servers behind the firewall.

The stateful inspection features are especially powerful. Stateful inspection provides the ability to track and control the flow of communication passing through the filter. The ability to keep track of state and context information about a session makes rules simpler and tries to interpret higher-level protocols.

Additionally, small modules can be developed to perform additional specific functions, such as passing packets to programs in userspace for processing then reinjecting back into the normal packet flow. The ability to develop these programs in userspace reduces the level of complexity that was previously associated with having to make changes directly at the kernel level.

Packet Filtering Intro:

----------------------------- Packet filtering, sometimes called filtering gateways or screening routers, is a component of a firewall system that either permits or denies packets from passing through it based on a pre-defined policy. It examines the packet for source and destination information, as well as ports, such as telnet or ftp, and either permits it to pass or otherwise rejects it.

For example, a firewall policy (typically called "rules") may be defined to permit incoming http access to a particular host, but deny access from other hosts. The packet simply traverses the list of rules until it matches a pattern -- one that either permits it or rejects it.

The advantages of packet filtering are that they are fast, flexible, and inexpensive. A 486 with 16 megabytes of RAM and two ethernet cards can be converted into a packet filtering firewall that can protect a large number of hosts behind it. They also typically provide a good deal of logging information which can be crucial to tracking a potential intruder.

The advantage of packet filtering is also one of its disadvantages. The packet filter does nothing to analyize the contents of the packet to determine if there is any malicious content within it. It simply routes based on a predefined set of rules. Another disadvantage is that it operates based on the information contained in the packet header, and can make no decisions based on the user accessing the remote resource. There is no built-in authorization mechanism.

The final disadvantage is that while it's flexible, it's also difficult to maintain. Often times on networks with many hosts to protect, the set of rules become unwieldy and difficult to manage. An intimate knowledge of the underlying IP protocols must be understood in order for the firewall to be effective. A misunderstanding of how one of the protocols work, or even an inadvertant configuration change can lead to undesired consequences. This is obviously an issue with any security system, but a misconfiguration could easily go unnoticed.

As mentioned in the initial sentence, packet filtering is a component of a firewall system. For a more robust solution, combine packet filtering with an application level gateway program such as squid.

Basic Packet Filtering:

------------------------------ It's now possible to match on owner, group, system ID, or process ID of a connection, allowing you to match locally-generated packets based on who created them. This would be great for restricting outgoing connections on an ISP machine, for example.

The packet filtering in 2.2 kernels provided the ability to limit spoofed packets from entering the network. Packets originating on the internal network should not appear to be entering the external firewall interface. The 2.4 kernel expands on this support by providing an 'unclean' extension that checks for such suspicious packets, as well as other types of malformed or non-standard packets, and sends them to the bit bucket.

In previous versions of the packet filtering code, it was only possible to determine whether the SYN flag was set, indicating whether or not the packet was an established connection or the beginning of a new connection.

The new packet filtering code allows you to filter on specific TCP flags, not just the SYN flag. This permits a much greater level of control over the packets that can enter or leave your network. For example, to examine all six TCP flags, checking specifically for the SYN and ACK flags to be set: 

# iptables -A INPUT -p tcp --tcp-flags ALL SYN,ACK -j DROP
Additionally, it is also possible to filter on MAC address. This is used for matching incoming packet's source Ethernet (MAC) address.

The ability to match TCP or UDP packets based on a series of source or destination ports is also now available. Previously, a rule could only match a single range of ports. This might be used to set up a filter to block telnet, ftp, and finger, for example:

# iptables -A input -t DENY -p tcp --destport telnet,ftp,finger
Finally, no longer do return packets appear to be destined for the server itself on input filtering and appear to be originating from the server itself on output filtering.

Filtering Modules:

------------------------ Netfilter includes several shared library add-on modules that provide additional functionality not found in previous packet filtering versions. Each rule target is a separate module, allowing for easy expansion. In addition to the standard REJECT, DENY and ACCEPT, there are several other targets including:
  • TOS: This option adds a "TOS" target, which allows you to create rules in the "mangle" table which alter the Type Of Service field of an IP packet prior to routing.

  • MIRROR: Reverse source and dest and send back out to the sender.

  • MARK: This target allows you to create rules in the "mangle" table which alter the netfilter mark field associated with the packet prior to routing. This can change the routing method and can also be used by other subsystems to change their behavior.

  • MASQUERADE: Masquerading is a special type of NAT and the one most of us are familar with from ipchains. All outgoing connections are changed to seem to come from a particular interface's address, and if the interface goes down, those connections are lost.

  • DNAT: This target specifies that the destination address of the packet should be modified.

  • SNAT: This target specifies that the source address of the packet should be modified, including all future packets in this connection.

  • REDIRECT: Redirect is another special type of NAT. All incoming connections are mapped onto the incoming interface's address, causing the packets to come to the local machine instead of passing through. This is useful for transparent proxies.

For example, to redirect traffic originating from the 192.168.1.0 network destined for the 192.168.1.1 web server to the 192.168.1.100 server, we might run the following command: 
# iptables -t nat -A POSTROUTING -s 192.168.1.0/24 \
	-d 192.168.1.1 -p tcp --dport 80 -j DNAT \
	--to 192.168.1.100
The iptables extended packet matching modules supply additional capabilities in the form of shared library add-ons and small kernel modules that provide additional functionality.

Stateful Inspection:

---------------------------- The netfilter framework now includes stateful inspection, also referred to as stateful filtering or sometimes dynamic filtering.

This connection tracking mechanism provides the ability to associate all the packets of a particular connection with each other. Stateful inspection attempts to interpret the higher level protocols such as NFS, http and ftp. The behavior of the firewall changes based on the information contained in the packet. If the packet contains information in the header that indicates it is part of an existing connection, and it matches a rule that states it's a permissable service, then it is permitted to pass through the firewall.

Previous implementations had no way of knowing if a particular connection to one of those ports were associated with a legitimate connection or was an arbitrary connection, as would be the case with a port scan or malicious hack attempt.

Many protocols attempt to allocate arbitrary ports for their data to be passed through. Previously there was no alternative but to poke holes in the firewall to allow these arbitrary ports access should there be a connection that requires it at some point during a connection. The new firewalling code allows the firewall to open ports only long enough for that particular packet on an arbitrary port to pass through it.

This greatly increases the overall security of the hosts behind it and is a component of nearly every major commercial firewall implementation.

At the same time, it also greatly reduces the window of opportunity for blackhats to attempt to pass malicious packets through the firewall, despite the source and destination ports and addresses being known. This allows only packets that are recognised as being part of an established connection to pass, instead of previously only depending on destination address and port. This also helps to thwart an attacker's attempt at using packets with modified headers that would have previously subverted a stateless packet filtering firewall.

Rules can now be created to base their routing decision on one of the following states:

  • NEW: This packet is trying to create a new connection

  • RELATED: This packet is related to the existing connection, and is passing in the original direction

  • INVALID: This packet doesn't match any connection

  • ESTABLISHED: This packet is part of an existing connection

  • RELATED+REPLY: This packet is not part of an existing connection, but is related to one, such as an ftp-data transfer when there is already an ftp-control session to that host

As a simple example, to forward across the firewall interfaces packets that are part of a pre-existing connection might look like this: 
# iptables -A FORWARD -j ACCEPT -m state \
	-state ESTABLISHED,RELATED
While stateful inspection provides much better performance than an application gateway such as squid, and also increases the level of protection over a simple packet filter, they can be as deceptively difficult to set up and maintain. It also may potentially require more memory to store the state information than a standard packet filter. Also, unlike application gateways such as squid, a direct connection is still made with the internal hosts which are being protected, exposing them to the exploitable weaknesses present on that host.

Address Translation:

----------------------------- Network Address Translation (NAT) is the process of converting one or more IP addresses into another IP address. This is most commonly seen through the use of "IP Masquerading" where a home or internal network is translated into an IP address that is routable on the Internet. The new packet filtering code in the 2.4 kernels include a much more robust form of address translation.

The 2.4 kernel packet filtering now supports a one-to-one, many-to-one and even many-to-many IP address and port translation. In the simplest case, an internal address may be translated into one that is addressable on the Internet. Previously, this may have been done using something of the form: 

# ipchains -A forward -j MASQ -s 192.168.1.0/24 -d 0/0
This will convert all IP addresses from the 192.168.1.0 network into the address of the external interface of the box it is running on. From there, an entry is made in the internal kernel data structures that tracks the connection and associates it with the particular host from which it originated. This form of proxying is very easy to set up and provides a great solution for internal users with a limited number of Internet-routable IP addresses.

While the masquerading support is still functionally equivalent to its predecessors, additional forms of address translation are now available. The new packet mangling code provides additional forms of translation including the ability to translate the source or destination addresses of a packet, the ports associated with the connection, port forwarding and transparent proxying. Suddenly, with the addition of this improved NAT, load-balancing, fault-tolerance and even high-availability become obtainable. Specifically, the following new NAT options are available:

  • DNAT: This target specifies that the destination address of the packet should be modified. This is a great way to load-balance a connection request amongst several destination servers.

  • SNAT: This target specifies that the source address of the packet should be modified, including all future packets in this connection.

  • REDIRECT: This is a specialized case of DNAT that alters the destination IP address to send the packet to the machine itself. This is useful in circumstances where one wishes to redirect web traffic to a local proxy server, such as squid.

Packets that have had either their source or destination addresses translated will then be retranslated on their return trip, so they are sure to be delivered back to the host with the real IP address. So, to develop a simple and inexpensive load balanacing solution, you might use the following to have your firewall redirect some of the traffic to each of the web servers at 192.168.1.100, 192.168.1.101 and 192.168.1.102, as follows: 
#
# Modify destination addresses to 192.168.1.100, 
# 192.168.1.101, or 192.168.1.102

# iptables -t nat -A POSTROUTING -i eth1 -j DNAT \
	--to 192.168.1.100-192.168.1.102
Other modules exist to do application-specific address translation and extensive documentation exists on how to write these modules.



Packet Mangling:

------------------------- Packet mangling is the ability to change or modify packets both before they are routed and after routing has been decided, specifically, the PREROUTING and POSTROUTING subtables.

Type of Service

--------------------- One example of packet mangling is the ability to prioritize traffic from separate queues, changing the "Type of Service" value in the packet before it is routed on to its final destination.

The Type of Service values can be one of the following:

  • Minimize-Delay
  • Maximize-Throughput
  • Maximize-Reliability
  • Minimize-Cost
  • Normal-Service

For example, to provide interactive performance to telnet while using ftp at the same time: 
	# iptables -A PREROUTING -t mangle -p tcp --sport telnet \
		-j TOS --set-tos Minimize-Delay
	# iptables -A PREROUTING -t mangle -p tcp --sport ftp \
		-j TOS --set-tos Minimize-Delay
	# iptables -A PREROUTING -t mangle -p tcp --sport ftp-data \
		-j TOS --set-tos Maximize-Throughput

Logging:

------------------- Netfilter improves on previous versions by providing the ability to restrict the rate of matches, such as for suppressing extensive log messages, for example when a host makes a number of connections in a predefined interval. This can help to prevent some types of denial of service attacks.

The detailed logging that netfilter provides enables a firewall administrator to not only troubleshoot potential system problems, but also to track a potential intrusion, and correlate it with other systems and events. The example below shows how to reduce the number of packets originating from the 192.168.1.1 host that are logged: 

# iptables -A INPUT -s 192.168.1.1 -m limit --limit 1/second -j LOG
It is also possible to log messages at different log levels and with different prefix notes:

# iptables -A INPUT -s 192.168.1.1 -j LOG --log-prefix ' ##Router## '
This will log all traffic originating from the 192.168.1.1 host and prepend the string " ##Router## " to each entry. It produces the following log output: 
Jan 28 23:18:42 magneto kernel: ##Router## IN=eth0 OUT= 
MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 
DST=192.168.1.206 LEN=312 TOS=0x10 PREC=0x00 TTL=64 ID=9189 DF 
PROTO=TCP SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0
Additionally, it also provides the ability to log packets based on many other criteria. More information in logging in general (MAC address, etc). A rule such as the following:

# iptables -I INPUT -m mac --mac-source 00:60:67:30:AC:E5 -j LOG
produces log output similar to the following: 
Jan 28 23:15:19 magneto kernel: IN=eth0 OUT= 
MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 
DST=192.168.1.206 LEN=528 TOS=0x10 PREC=0x00 TTL=64 ID=7738 DF PROTO=TCP 
SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0 
Jan 28 23:15:19 magneto kernel: IN=eth0 OUT= 
MAC=00:60:67:36:9b:c8:00:60:67:30:ac:e5:08:00 SRC=192.168.1.1 
DST=192.168.1.206 LEN=528 TOS=0x10 PREC=0x00 TTL=64 ID=7738 DF PROTO=TCP 
SPT=22 DPT=1023 WINDOW=32120 RES=0x00 ACK PSH URGP=0

Final Notes:

------------------------ In this article we've covered a majority of the new features available in the new filtering code available in the 2.4 kernel. There are a number of other changes that make using the packet mangling code easier than previous versions. Previously, the forward chain only had information on the outgoing interface, making it more difficult to determine where the packet came from. It's now possible to create packet filter rules independant of interface address.

It's no longer necessary to bind a rule with an interface. It's now possible to specify the "in" interface or the "out" interface for basing filtering decisions.

Ipchains and ipfwadm modules exist for backward compatibility with the old systems. Note that you can only have one loaded at a time. You can't have ipchains and some new iptables rules.

Acknowledgements:

I'd like to express thanks to Kevin Fenzi, my Security HOWTO co-author, and Harald Welte, author of much of the documentation we have today on netfilter, for accuracy-checking my document. Thanks to Benjamin Thomas for proofreading. Any errors are either due to transmission problems or fault of my own, though ;)

Related Resources:

Netfilter Mailing list:
Send a message to This email address is being protected from spambots. You need JavaScript enabled to view it. with "subscribe" in the subject to subscribe. Visit the netfilter web site for more information.
This email address is being protected from spambots. You need JavaScript enabled to view it.

SYN Cookies:
SYN cookies are particular choices of initial TCP sequence numbers by TCP servers.

Stateful inspection in action:
This document shows graphically how Check Point's FW-1 works as a stateful packet filter.
https://www.checkpoint.com/quantum/next-generation-firewall/

Application Gateways and Stateful Inspection:
This is a good document that explains the differences between the various types/forms of firewalls.

What is a Stateful Inspection of a Firewall?
This is a short document that describes the stateful inspection firewall.

Configure firewall logging and alert mechanisms
This brief CERT document describes the concepts behind firewall logging and its importance.
/about/divisions/cert/index.cfm

Linux Network Address Translation
This document describes the various forms of address translation and implementations of it on Linux.
http://linas.org/linux/load.html

Network Address Translation Whitepaper
This is a pretty good document that describes how NAT works.
https://www.extremenetworks.com/resources/white-paper

Network (In)Security Through IP Packet Filtering
One of the original documents that describe some of the deficiencys with packet filtering.

An Architectural Overview of UNIX Network Security
A somewhat dated document now, but still does a great job of pointing out the risks in network security.
https://www.yahoo.com/

Design the firewall system
A firewall document that discusses topology, several types of firewall implementations, trade-off analysis and more.
/about/divisions/cert/index.cfm

Linux Network Administrator's Guide: Chapter 9, TCP/IP Firewall
The full chapter of the NAG. Starts at the beginning and provides several real-world packet filtering examples.