The definition of stateful filtering seems to vary greatly among various product vendors and has developed somewhat, as time has gone on. Stateful filtering can mean anything, from the ability to track and filter traffic based on the most minute of connection details to the ability to track and inspect session information at the application level. With this loose interpretation in mind, let's define these terms for the purpose of this chapter.

Stateful filtering has been used to define the stateful tracking of protocol information at Layer 4 and lower. Under this definition, stateful filtering products exhibit no knowledge of application layer protocols. At the most basic level, such products use the tracking of the IP addresses and port numbers of the connecting parties to track state. As mentioned previously, this is the only way that connectionless protocols can be tracked, but at best, this is only "pseudo-stateful." What about using this same method of stateful filtering for the tracking of the connection-oriented TCP? As mentioned previously, this method does not in any way track the TCP flags. TCP's flags define its connection states; therefore, although this method might be tracking some information from the various communication sessions, it is not truly tracking the TCP connection state.

More advanced forms of stateful filtering can also track sequence and acknowledgment numbers and the TCP packet flags. With the addition of these criteria, we can get truly stateful connection tracking for TCP, although we still lack the ability to differentiate traffic flows at the application level.

Stateful inspection, in contrast, has come to be used as a description of the devices that track state using all the Layer 4–type information listed previously, as well as the tracking of application-level commands. All this information can be combined to offer a relatively strong definition of the individual connection's state. Also, because Layer 7 information is being examined, extra insight into nonstandard protocol behaviors is available. This allows normally troublesome protocols such as FTP and H.323 to be securely passed by the device without complication.

In both stateful filtering and stateful inspection, the tracked state information is most often recorded into a state table that tracks the information until a connection is torn down (as with TCP) or until a preconfigured timeout is reached (TCP, UDP, and ICMP). Every vendor has its own implementation of these methods, and in the next several sections, we will look at some vendors' definitions of stateful filtering/stateful inspection as used in their products.

Stateful Firewall Product Examples

As stated previously, various firewall products handle the tracking of state in many different ways. This section lists some popular firewall products and provides explanations of how they handle state. We also show examples of each product's state table and examine a sample configuration of a stateful firewall.

Netfilter/IPTables

Netfilter and IPTables are the two main pieces of the most recent incarnation of a firewall product that is freely available for Linux distributions. IPTables is the construct that is used to build the firewall rule sets. Netfilter is the bridge between the Linux kernel and the IPTables rule structure. Netfilter/IPTables is the successor of the ipfwadm and IPChains products, with an ever-increasing list of features and functionality. Now thanks to its connection-tracking feature, IPTables offers stateful filtering capability.²

Connection tracking records the state of a connection based mostly on protocol-specific information. Administrators create rules specifying what protocols or specific traffic types should be tracked. When a connection is begun using a tracked protocol, IPTables adds a state table entry for the connection in question. This state table entry includes such information as the following:

• The protocol being used for the connection

• The source and destination IP addresses

• The source and destination ports

• A listing with source and destination IP addresses and ports reversed (to represent response traffic)

• The time remaining before the rule is removed

• The TCP state of the connection (for TCP only)

• The connection-tracking state of the connection

Following is an example of a state table entry for IPTables:

tcp 6 93 SYN_SENT src=192.168.1.34 dst=172.16.2.23 sport=1054 dport=21 [UNREPLIED]
src=172.16.2.23 dst=192.168.1.34 sport=21 dport=1054 use=1

The first line starts out listing the protocol in question, followed by the protocol's numerical designation (6 for TCP). The next value, 93, represents the time remaining before the entry is automatically cleared from the state table. Then is shown the state that the TCP connection is in. The source and destination IP addresses follow, and then the source and destination ports are listed. Because this is an initial connection (as demonstrated by the connection's TCP state), this line lists that IPTables sees this connection as [UNREPLIED] and hasn't increased its timeout value yet. Next in the listing, we see a reversal of the original source and destination address and port information to allow return traffic. After the connection is established, the state table entry is altered, as you can see in the next example:

tcp 6 41294 ESTABLISHED src=192.168.1.34 dst=172.16.2.23 sport=1054 dport=21
src=172.16.2.23 dst=192.168.1.34 sport=21 dport=1054 [ASSURED] use=1

The [UNREPLIED] marker is removed after the first return packet. Upon establishment of the connection, the [ASSURED] marker is placed on the entry, and the timeout value (41294) is greatly increased.

Now let's consider the rules of IPTables.

To begin, we'll look at the syntax and how it works. This first sample rule is considered an output rule because it defines which traffic can leave through the firewall (-A specifies that this rule will be appended to already existing rules):

iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT

This output rule determines which outbound communication will be accepted (as specified by the –j option). This particular rule deals only with the TCP protocol, as specified by the –p tcp option.

It specifies in the -–state section that NEW and ESTABLISHED traffic is allowed out of our network. This rule, as listed, allows no egress protection. All new outbound TCP traffic will be allowed because the NEW option is specified. NEW tells the firewall to watch for packets with a lone SYN flag that are initiating a connection and to create entries in the state table for every such occurrence. The ESTABLISHED option allows traffic that is part of an existing session that has previously been recorded in the state table to pass as well, which means that any standard TCP communications will be able to leave the network.

Another part of the command worth mentioning is –m state. The –m denotes what module should be used for the rule in question—in this case, the standard state module that comes with IPTables. Now let's examine the rule that will allow the return traffic for our connection back into our network:

iptables –A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT

This command appears identical to the preceding one, except that it is an input rule, and only ESTABLISHED is listed under the –state section of the command. This means that only return traffic will be allowed inbound to our network, as defined by the state table. Iptables determines whether incoming traffic is return traffic for the connection entered into the state table by checking it against the reversed connection information located in the state table entry. No new connections will be able to enter our network from the outside.

Even though most of the requirements of TCP stateful tracking are available in Iptables, one exception to this is the tracking of sequence and acknowledgment numbers, which can be added with the tcp-window-tracking patch.³

From our previous definition of the items held in the state table, you can see that the items needed to do a pseudo-stateful job of tracking ICMP and UDP are present. Examples of basic UDP output and input rules would be as follows:

iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT

These rules appear identical to those specified for TCP, except for the –p udp option listing.

ICMP rules look about the same:

iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT

The main differences are the –p icmp specification for protocol and a new entry in the --state section: RELATED.

The RELATED option is the means by which Iptables allows traffic that is already in some way associated with an established traffic flow to initiate a new connection in the state table and be passed through the firewall. This related traffic might be an ICMP error message that is returned for a UDP or TCP connection already held in the state table. It could also be the initialization of an inbound FTP data channel on TCP port 20, after state table information had already been logged for an inside station starting a control channel connection on TCP port 21.

As listed, our rule allows ICMP traffic inbound and outbound that is related to existing ESTABLISHED traffic flows. Therefore, errors returned in response to existing TCP and UDP connections will pass. Because the NEW option is listed for outbound traffic, requests from ICMP programs such as ping will be able to leave our network, and the ESTABLISHED option specified for inbound traffic will allow the replies to said traffic to return back through. However, inbound ping requests will not be allowed in because the NEW option is not specified inbound.

The rules of conduct for defining related traffic are included in connection-tracking modules. They facilitate the examination of application-specific commands, such as the way the ip_conntrack_ftp module facilitates the inspection of FTP's port command to allow the secure handling of standard FTP traffic. (For more information on how stateful firewalls handle FTP traffic, see the "File Transfer Protocol and State" section, earlier in this chapter.) These modules can be added on as new protocols are used in your environment.

To implement a module such as ip_conntrack_ftp to allow standard outbound FTP communications to be properly initialized through our IPTables firewall, it first has to be loaded with a command such as the following:

modprobe ip_conntrack_ftp

Next, a specific rule has to be created to inspect the related traffic. This can be accomplished in the case of FTP by making an INPUT rule that allows inbound TCP port 20 traffic with the state option of RELATED. This will allow the inbound port 20 traffic to connect if the inspection process deems it related to an existing connection in the state table. Here is a listing of such a rule:

iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISHED,RELATED -j ACCEPT

An OUTPUT rule will be needed as well to allow response traffic to return:

iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT

Notice that the –sport 20 option representing the source port in the INPUT rule has changed to the –dport 20 (or destination port) option in the OUTPUT rule. This change is due to the reversal of communication roles for outbound versus inbound traffic.