This chapter is from the book
This chapter is from the book
This chapter is from the book
Stateful Inspection
The term "stateful" covers a wide range of methods. Sometimes a stateful inspection firewall is simply a static packet filter with some intelligence built in, examining the contents of a packet and deciding if it is in response to a request already allowed. Or it could be what is termed a circuit-level proxy, creating a pathway between client and server.
So, at the lower end of the spectrum, we have a product that works a little like a dynamic packet filter. It works at the network layer of the OSI model like a static packet filter, but examines the packet headers to determine if a packet is part of an existing session. It looks at not only source and destination IP addresses and ports, but also uses the TCP flags and sequence numbers to aid in this decision. A dynamic packet filter can open the required ports to allow a communication session to be established. With a static packet filter, you had to define rules to allow the return packets back into your system. In this way, a dynamic packet filter can be said to be stateful—it understands the "state" of a TCP session.
OK, you're asking yourself, "What is state?" Recall the three-way handshake illustrated in Chapter 2? With TCP, a session is opened with an exchange of three packets—the initial SYN from a client, a SYN-ACK from the server, and finally an ACK from the client. Once the handshake is complete, we say the "state" of the session is established and data can be transferred back and forth. A state table on the firewall keeps track of fully established sessions, and then deletes the session entry once it has been properly torn down, gracefully via the FIN-ACK sequence or forcibly with a RESET.
So, with this type of firewall, our rule set is less complicated. With a rule to allow internal systems to access Web sites only, the return traffic will be allowed in automatically. However, incoming requests that are not part of an established Web site communication request will be blocked. Figure 3–6 shows how the state table is built when the internal client requests a Web page from the server at http://www.example.com.
)
FIGURE
3–6 State table. The client requests the Web page from http://www.example.com;
an entry is placed in the state table to reflect the SYN packet that is sent.
The server replies with a SYN-ACK. This packet is passed to the client because
it matches the SYN request listed in the state table even though such a packet
would be denied by the rule set. The client completes the handshake with an
ACK and the state table is updated to reflect an established session. Traffic
flows between the client and server until one host sends a FIN packet to end
the session.
The ability to decide if traffic is part of an established session certainly simplifies the rules that must be defined. The method used to make this decision, though, can be a weakness. Some dynamic packet filters assume that all traffic with the ACK flag set must be part of an existing session. Certainly, that is the way we expect packets to behave. We could fool it and slip something through by specifically crafting packets with the ACK flag set. This isn't really keeping track of state; it's just recognizing that packets that are part of an established session should be the only ones with the ACK flag set. As shown in the static packet filter section, we can fool this mechanism.
We expect that a stateful firewall will look at the entire header to decide if it is part of an established session. What information in the header is used to decide? The flags are important, but so are the sequence numbers. The state table is an important component of tracking sessions as well. It is only by comparing packets to the state table that we can be sure they are part of a valid session.
Sequence Numbers
The sequence numbers in a TCP header provide important information that can help track the state of communications.
The first sequence number in a SYN packet is chosen at random by the initiating host. The remote host then replies with a SYN-ACK packet that contains a random sequence number chosen by that host and an ACK number that matches the sequence number of the last byte of data received from the initiating host, in other words, the next expected sequence number from that host. Finally, the first host replies with an ACK packet that contains the next sequence number in order and an ACK number that matches the last byte of data received from the remote host. Table 3–4 shows the numbers of the first few packets in a session.
TABLE 3–4 Sequence Numbers
|
Packet |
Sequence number |
ACK number |
Data length |
Sending host |
|
SYN |
125364 |
0 |
|
Local host |
|
SYN-ACK |
258456 |
125365 |
|
Remote host |
|
ACK |
125365 |
258457 |
|
Local host |
|
Data |
125365 |
258457 |
32 |
Local host |
|
Data |
258457 |
125397 |
40 |
Remote host |
|
Data |
125397 |
258499 |
32 |
Local host |
So, by keeping track of sequence numbers, we can tell if packets are part of an established session.
We have a problem when it comes to UDP and ICMP traffic, though. These two protocols don't have "state." They are connectionless. So how can a firewall keep track of traffic that is in response to a request from an internal client? Well, we can sort of track state for these protocols. For UDP, we can write a table entry that includes the source and destination IP addresses and ports and assigns a time-out value. Then, for the duration of that time value, any traffic that matches the source–destination pairing is allowed. Figure 3–7 looks at what would happen when a client makes a DNS request.
)
FIGURE
3–7 UDP state table. The client sends a packet to the DNS server. A
state table entry is made to reflect this request. This entry holds a source
address and port for the client (172.16.1.1:1256) and server (dns.example.com:53)
and is valid for 60 seconds. When the server returns the information to the
client, the IP addresses and ports match those held in the state table. If the
time-out value of 60 seconds has not been exceeded, the packet will be allowed.
A firewall can do something similar for ICMP packets, using the ICMP type and code values instead of ports. The program will need some intelligence to handle this, though, since the reply to an ICMP type 8, code 0 message is not a type 0, code 8, or even type 8, code 0. Type 8, code 0 is an ICMP echo request packet (ping), the response is an ICMP type 0, code 0, or echo reply. In reality, ICMP generally isn't handled in a stateful manner.
Firewall rules have to be specially defined to allow this protocol to work.
At the other end of the spectrum in what are referred to as stateful inspection firewalls come the circuit-level gateways or proxies (see Figure 3–8). This type of firewall actually performs at the session layer of the OSI model, sitting between the operating system and the application. It builds a bridge between a client and server; all traffic must pass through the proxy. Unlike application proxies, a circuit proxy is not aware of the data in a packet. It does not validate that the data traveling to the application actually adheres to the protocol rules for data on that port. So, if I wanted, I could set up a mail server on port 80 and the circuit level proxy will allow clients to access my mail server if it is configured to allow access to port 80.
)
FIGURE
3–8 Circuit-level proxy. The client computer requests the page http://www.example.com
from the proxy(1). The proxy checks that HTTP (port 80) traffic is allowed,
then requests the Web page directly from http://www.example.com (2).
The server replies to the proxy (3). The proxy sends the reply to the client
(4).
A circuit-level proxy can hide the internal host from the Internet. All traffic for a remote host appears to come from the proxy. All replies from the Internet host are returned to the proxy. We could say the proxy actually copies the data between authorized sources and destinations for defined ports. There is no intelligence to this copying; if the source and destination addresses and ports are allowed, then the traffic is passed.
Clients must be configured to use circuit-level proxies. It may be possible to simply configure the applications to recognize the proxy. In some cases, though, it may require modifications to the TCP/IP stack of the client.
How Stateful Inspection Is Implemented in Personal Firewalls
The neat thing is most personal firewalls hide state information from you. You never see a state table, you never worry about such things. You simply use the provided GUI to select your level of comfort. Even with iptables, the stateful replacement for ipchains, you don't actually modify the state table in any way. You simply define rules in a manner similar to ipchains. In fact, for someone switching from ipchains to iptables, scripts are provided to port your rules across.
BlackICE PC Protection uses some level of stateful inspection. Why? Well consider the preconfigured Firewall protections levels—Paranoid, Nervous, Cautious, and Trusting. Paranoid refuses all unsolicited inbound traffic. That means, when a packet arrives at your computer, if it is not a reply to something you requested, it is blocked. How does it know whether you requested the traffic? It checks the state.
ZoneLab's ZoneAlarm starts with basic rules, but allows you to configure different zones. We could consider the application protection features of ZoneAlarm a component of stateful inspection. Once you have configured ZoneAlarm to allow a particular application to access the network, then all traffic necessary for the application is allowed. However, except where the remote host is part of a trusted zone, remote hosts are not allowed to initiate communication even with a trusted application. So, the state of sessions with specific applications is maintained.
Products That Use This Method
There are some hardware products—e.g., SMC's Barricade Cable/DSL router and the Netgear Internet gateway routers—that offer stateful packet inspection. These are a step up from the static packet filtering that my Linksys cable router performs. Certainly, if you are interested in the other features of a hardware device, such as NAT and sharing your Internet connection, a stateful inspection firewall is a nice feature to include.
Thanks to the broad range of functions covered by the term "stateful," we could easily place nearly all personal firewalls in this category. Since companies realize that consumers don't want to figure out the complex rule sets necessary for static packet filtering, they employ methods that will allow the user to do what they want easily. For the majority of users, this means allowing Web, mail, and FTP without thinking. Some other applications obviously are important, but they may need to be manually adjusted.
Now, if you do want to really get into things, iptables on the Linux 2.4 kernel and above will allow you to write your own rules. Iptables is the stateful replacement for ipchains. The two products are similar, but there are noticeable differences. For one, in ipchains, a packet can travel through up to three of the built-in chains: input, forward, and output. Iptables reduces the number of chains traversed by a packet to one. So you really need to pay attention to how you create your chains, if you come from an ipchains background.
Otherwise, there are a multitude of commercial products that provide some stateful inspection. Products like ZoneAlarm, BlackICE PC Protection, the built-in Windows XP Internet Connection Firewall, Norton Personal Firewall, McAfee Personal Firewall Plus, and even Norton Personal Firewall for the Macintosh. Gosh, even with all those listed, I'm still probably missing a lot.
Advantages
You can block incoming traffic. It really wouldn't be a useful firewall if you couldn't. However, you can block all incoming, yet still have replies to requests from your client come in without the complex rule sets you would need for a static packet filter. This is where stateful technology wins over static packet filters.
Like a static packet filter, you can block outgoing traffic—at least in theory. There are some specific products—the XP firewall comes to mind—that simply don't give you those configuration options.
All this, and stateful inspection firewalls are fast. If we're looking at something that simply does dynamic packet filtering, it operates at the Network layer, meaning it doesn't waste a lot of processor power on the packet. It will be only marginally slower than a simple static packet filter. On the other hand, if we have a circuit-level proxy firewall, it will still perform better than an application proxy since it doesn't have to validate the data.
Disadvantages
Stateful inspection slows down processing as packets are examined. OK, I said they were fast not one paragraph ago. They are, especially with today's computing power. But technically, they could be slower. A circuit-level proxy stands the best chance of being noticeably slower than a static packet filter, but not by much.
A stateful inspection firewall will take up more resources than a static packet filter. This may make it less desirable to run on a system with limited power like, say, a hardware device.
Circuit-level proxies do not validate the data. Since they simply relay packets after authentication, they cannot stop unacceptable services from tunneling through an allowed service port. In other words, if your security policy forbids the use of FTP but allows HTTP, a user could still transfer files by using port 80 for the traffic. Your circuit-level proxy wouldn't stop them.
Where Stateful Inspection Fits in the Design of a Secure Environment
Stateful inspection is probably one of the most straightforward methods of protecting your computer (see Figure 3–9). You simply define what is allowed and the rest takes care of itself. Purists will argue, however, that it doesn't provide enough protection. That is because the range of methods used to maintain state varies so much, you might not be getting the best level of protection for your requirements. It is a concern, not knowing exactly how the firewall is deciding on state. That's where a circuit-level proxy would be better.
)
FIGURE
3–9 Network design with stateful firewall. In this design, we place
a stateful firewall on each host but also place them behind a NAT box, which
also is configured to perform some initial packet filtering. If you've
already implemented NAT for communications reasons, it makes sense to use all
the features provided to protect your assets. Since we are not offering any
services, we can deny access to all lower ports (0–1023) from the outside
world.
If you are already using a hardware device to perform rudimentary packet filtering, you might want to perform some stateful inspection to the traffic that makes it though your first defense. Perhaps you've decided that you need an Internet router, then choose one with stateful packet inspection features as well. This will just add another layer to your defenses.
The implementation in personal firewall software may be confusing—when a product warns you that specific software is trying to access the network, will you be knowledgeable enough to understand if this is good or bad? Will you know if the new program is something you installed or a Trojan with a similar name?