Home > Articles > Security > Network Security

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 6FIGURE 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


Sequence number

ACK number

Data length

Sending host





Local host





Remote host





Local host





Local host





Remote host





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 7FIGURE 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 ( 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 8FIGURE 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.


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.


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 9FIGURE 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?

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020