It is not an uncommon story today to hear how people were first exposed to linux. Many people found linux an excellent and reliable masquerading firewall in the mid-1990s and slowly became more and more accustomed to working with linux as a result of the low total cost of ownership. The capabilities of packet filtering tools available under linux today dwarfs that of early linux (ipfwadm, anybody?) yet retains the reliability and expressive flexibility of the older tools. For networks and machines directly connected to the Internet, packet filtering is no longer an option, but a need. This chapter will introduce the packet filtering tools available under kernels 2.2 and 2.4. Since there is much available documentation on packet filtering, host protection and masquerading with a packet filter, this chapter will refer liberally to external resources. This chapter begins with an introduction to and the history of packet filtering with linux. After covering some of the weaknesses of packet filtering, it will cover the netfilter architecture, and then delve into using iptables. An introduction to the use of ipchains will follow along with introductions to host and network protection. The chapter will close with an overview of further resources.

Packet filtering refers to the technique of conditionally allowing or denying packets entering or exiting a network or host based on the characteristics of that packet. There are two fundamental types of packet filters. A static packet filter is a set of rules against which every packet is checked, and allowed or denied. A dynamic packet filter keeps track of the connections currently passing the firewall. This is usually described as a stateful or dynamic packet filtering engine. Netfilter provides the capability for linux (2.4+) to operate as a stateful packet filtering device. For a brief digression, consider the term stateful packet inspection. This term has been used in two distinctly different meanings. At least one commercial security company differentiates between stateful packet filtering and stateful packet inspection See the following PDF from NetMaster Digital Security. Although I may disagree with their use of terms, I can appreciate their clear attempt to explain their use of these two terms. . Supposedly, a stateful packet inspection engine is able to examine the contents of a packet and make a limited guess as to the legitimacy of the application layer content. While I would call this an application layer proxy, I do not use the product. For the purposes of this documentation, the terms stateful packet inspection and stateful packet filtering are synonomous. Packet filtering, the network layer portion of a firewall solution, is one part of a good security stance. As the embodiment and manifestation of an organizational security policy for network layer traffic, the packet filter restricts traffic flows between networks and hosts. There is tremendous value from a security perspective in enforcing these traffic flows, instead of allowing arbitrary traffic flow. The use of packet filtering to enforce these traffic flows is not restricted to routers and firewalls alone. Standalone servers and workstations can use these same tools to protect themselves. There are a couple of common approaches to packet filtering. Generally, network security professionals subscribe to the notion that the filtering policy should deny or drop all traffic and selectively allow desired traffic. An alternate, more open, policy suggests allowing everything, selectively blocking undesirable traffic. The languages used in most packet filtering tools for describing IP packets allow for a great deal of specifity when identifying traffic. This specifity enables an administrator a great deal of flexibility for protecting resources and limiting traffic flows.

Packet filtering under linux has a long history, punctuated by major alterations in the packet filtering systems included in the kernel. In the mid- and late-1990s, ipfwadm exposed the three packet filtering chains of kernel 2.0 to the user: in, forward, and out. Individual entries added to these chains would be traversed in order in each ruleset. The first matching rule in each chain would be used, and every packet passing through a router would traverse these three chains. With the advent of linux 2.2, users could create their own chains and chain structures. The kernel architecture was different from that of the earlier kernel, but from the user's perspective, the manner in which the rules were written was only slightly different. Rule chains, traversed rather like subroutines and manipulated with ipchains, could be arbitrarily complex and nested. The built-in packet filtering chains had names: input, output and forward. The first matching rule in any chain called from one of the built-in chains would be used. Every packet passing through a router would traverse (at least) the three built-in rule chains. There is backward compatible support for ipfwadm syntax via a wrapper shell script which converts the command to an ipchains syntax. In kernel 2.4, the netfilter architecture which provides functionality other than packet filtering, allows users to create the arbitrary chains and chain structures similar to those supported by linux 2.2. The built in chains are INPUT, FORWARD, and OUTPUT. A major difference in the use of chains was introduced in linux 2.4; packets passing through a router will traverse the FORWARD chain only. User-defined iptables chains resemble branches rather than subroutines. Under linux 2.4, ipchains compatibility is maintained with a kernel module. For ipfwadm compatibility, the kernel module and the aforementioned wrapper shell script function adequately. The packet filtering support under linux has grown increasingly complex and mature with successive kernels and development efforts on the user space tools. The netfilter architecture of linux 2.4 represented a tremendous step forward in the packet filtering capabilities of linux with support for stateful packet filtering.

Although the functionality offered by linux kernels for protecting network resources with packet filtering allows tremendously specific network layer access control and auditing capability, it alone cannot successfully and completely protect network resources. There are weaknesses in and limits to the usefulness of packet filters.

In cases where a packet filter restricts access to a resource based on the source IP address attempting to access that resource, the packet filter cannot verify whether the packets originate from the real device or from a host or router spoofing this source address. A transparent proxy illustrates this problem perfectly. A transparent proxy frequently runs on a masquerading or NAT host which is connected to the Internet. This machine intercepts outbound connections for a particular protocol (e.g, HTTP), and simulates the real server to the client. The client may have a packet filter limiting outbound connections to a single IP and port pair, but the transparent proxy will still operate on the outbound connection. This is an innocuous example, indeed. A potentially more threatening example is an ssh server which accepts connections only from an IP range. Any router between the two endpoints which can spoof IP packets will be able to pass the packet filter, whether it is a stateful or a static packet filter. This should underscore the importance of solid application layer security in addition to the need for judiciously employed packet filtering. A packet filter makes no effort to validate the contents of a data stream, so data passed over a packet filter may be bogus, invalid or otherwise incorrect. The packet filter only verifies that the network layer datagrams are correctly addressed and well-formed In truth, there is some examination of data inside the network layer datagram. Almost all packet filtering engines allow the user to distinguish between the different IP protocol types, such as GRE, TCP, UDP, ICMP, and even attributes of these datagrams and segments. The important thing to realize is that a packet filter makes no effort to examine the data stream. . Many security devices, such as firewalls, include support for proxies, which are application aware. These are security mechanisms which can validate data streams. Proxies are often integrated with packet filters for a tight network layer and application layer firewall. Tunnels are one of the most common ways to subvert a packet filter. They come in wide varieties: ssh tunnels which allow users to transport TCP sessions into or out of a network; GRE tunnels, which allow arbitrary packets to be encapsulated in an IP packet; UDP tunnels; VPN tunnels; TAP/TUN tunnels; and application layer transport tunnels, such as RPC over HTTP/HTTPS. Some of these tunnels are very difficult to prevent with packet filtering, while others are trivial to block. Perhaps it is apparent, why **FIXME** adversarial relationship between packet filters and content....limitation of packet filter....hence proxies...blah blah blah. Use of ICMP, when to block ICMP; tunneling through lax packet filters with ICMP (trinoo, ICMPchat). Another area of network security which is not addressed by packet filtering is encryption. Encryption can be used at a number of different layers in a networked environment. Compare IPSec, encrypted packets, with Secure Sockets Layer (SSL), which encrypts a single application layer session. IPSec operates at layer 3, while SSL operates above layer 4. Packet filtering does not directly address the issue of encryption in any way. Both are tools used in an ongoing effort to maintain and secure a network. There are a few good starting place for those needing guidelines on securing machines. First, the Security Quickstart HOWTO is a good place to begin. There is also the Security HOWTO. These and several other good general security resources are also available via linuxsecurity.com's documentation area. Much of the previous discussion applies to packet filtering in general, and linux suffers from the same limitations of packet filtering. It is folly to assume that a good packet filter makes a network immune from security issues.

The weaknesses of static (or stateless) packet filters and stateful packet filters are different in a few ways. Stateless packet filters frequently block SYN scans of networks, but .... Stateless packet filters. (cf. iptables connection tracking), cf. state vs. stateless discussion. confounded application layer protocols like FTP, H323 Because of the nature of connection tracking and state awareness, stateful packet filters are vulnerable to resource exhaustion and deliberate attempts to trip rate-limiting features. DoS on connection tracking packet filters DoS on rate limiters ?

minimum ICMP required to meet the networking needs; xref PMTU discussion source quench parameter problem inbound destination unreachable outbound destination unreachable fragmentation needed optional: echo request and echo reply optional: outbound destination unreachable optional: time exceeded

packet filtering engine in kernel 2.2 (skip history, adequately documented elsewhere) packet filtering engine as part of netfilter in kernel 2.4, backwards compatible support for ipchains differences between the packet traversal in ipchains and iptables. link to Stef Coene's KPTD (kernel 2.4). Anybody know of a link to a KPTD for kernel 2.2?

selecting on interface different chains, INPUT, OUTPUT, FORWARD big picture; how chains are traversed selecting on interface -i -o targets; ACCEPT, DROP, REJECT....

the three builtin chains, input, output, forward policy per chain, see targets jumping from chain to chain, -j $TARGET; wher TARGET=chain the big picture; how chains are traversed targets (other than chains) ACCEPT, DENY, REJECT.... selecting on interface

Host protection in the past was typically performed with application layer checks on the originating IP or hostname. This was (and still is) frequently accomplished with libwrap, which verifies whether or not to allow a connection based on the contents of the system wide configuration files /etc/hosts.allow and /etc/hosts.deny. Host protection is one part of protecting a host, by preventing inbound packets from reaching higher layers. This is no substitute for tight application layer security. Strong network and host-level packet filters mitigate a host's exposure when it is connected to a network. [root@masq-gw]# iptables -I FORWARD -p tcp -d 209.10.26.51 --dport 22 -j REJECT [root@tristan]# ssh 209.10.26.51 ssh: connect to address 209.10.26.51 port 22: Connection refused [root@masq-gw]# tcpdump -nnq -i eth2 tcpdump: listening on eth2 22:16:59.111947 192.168.99.35.51991 > 209.10.26.51.22: tcp 0 (DF) 22:16:59.112270 192.168.99.254 > 192.168.99.35: icmp: 209.10.26.51 tcp port 22 unreachable (DF) [tos 0xc0]

The use of linux packet filtering features is mature and well-documented in many places throughout the Internet. One of the most thorough introductions to the use of iptables has been collected by Oskar Andreasson at his Iptables tutorial. For further reference material on the use of iptables consult this resource. For those continuing to use ipchains the ipchains HOWTO courtesy of TLDP provides an introduction to the world of ipchains. For kernel 2.4, understanding the sequence of packet mangling, filtering and network address translation is key. The kernel packet traveling diagram provides a visual representation of the path a packet takes through the kernel. Here you will see the netfilter hooks, traffic control, and routing stages. A similar picture of kernel 2.4's packet path is available in a single page PDF entitled Linux Kernel 2.4 Packet handling. See also and in the appendices for a more complete set of references and links.