Get the LinuxSecurity news you want faster with RSS
Powered By
Linux Kernel 2.4 Firewalling Matures: netfilter
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:
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:
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:
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
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 netfilter-request@lists.samba.org with "subscribe" in
the subject to subscribe. Visit the netfilter web site for more information. Click
to subscribe
Application Gateways and Stateful Inspection:
This is a good document that explains the differences between the
various types/forms of firewalls.
http://www.avolio.com/apgw+spf.html
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 (In)Security Through IP Packet Filtering
One of the original documents that describe some of the deficiencys with
packet filtering.
http://www.greatcircle.com/pkt_filtering.html
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.
http://www.oreilly.com/catalog/linag2/chapter/ch09.html
Only registered users can write comments. Please login or register.
