Stateful Packet Inspection
This section discusses the more advanced technique of packet inspection: Stateful Packet Inspection (SPI). To understand how SPI operates, you must briefly review the TCP/IP model.
Note
Many people are confused about the relationship between the OSI reference model and the TCP/IP model—simply put, the use of OSI is a reference for developers whereas, in education, functionally TCP/IP is used. Therefore, you must use the TCP/IP model when inspecting packets.
Figure 5-5 shows the five layers of the TCP/IP model. The stateful inspection component is concerned with how TCP (Layer 4—transport) makes connections. Tracking the state of the TCP connection is done via Layer 4 of the TCP/IP model.
In most cases, SPI occurs in a firewall, which sits behind the secure router that connects your network to the Internet. If you have implemented packet filtering with ACLs on the router as your first line of defense (and you should), the next line/layer of defense will be SPI at the firewall, as shown in Figure 5-6.
Figure 5-6 Placement of Stateful Packet Inspection
Note
There is an Internet standard known as RFC 2827, which can guide you through the process of creating your first line of defense. This RFC is titled “Network Ingress Filtering: Defeating Denial of Service Attacks,” which employs IP Source Address Spoofing.
This placement and added security enables the defense in depth to be layered at yet another level, with the goal of completely securing the network via multiple layers of protection.
SPI is usually implemented in a firewall, so the TCP/IP connections can be inspected more closely. Thus, this technology is considered connection-aware in that SPI monitors and understands that a connection between two computers usually consists of many packets that flow back and forth between the computers. This connection-aware functionality happens because the firewall is tracking every connection that comes into it and out of it to track the state of the connection. Yes, this connection was opened by one of my internal users (permit) or no, it was not opened (deny).
Stateful inspection of packets occurs during the first packets used to create this connection. As the connection is inspected, an entry is created in a table. Then, as future packets are received, they are verified against entries in this table to see whether they belong to an existing and recorded connection. If the packets pass this verification phase, they are allowed to pass. At a high level, that is how SPI occurs. The following section examines this process in more detail.
Detailed Packet Flow Using SPI
Because this book strives to always present best practices regarding network security and the associated technologies, this more detailed discussion is based on the assumption that the external router is in place and that it is configured to prescreen connection attempts into the network by using packet filtering. Therefore, picking up the packet as it passes through the router and its packet filtering, the next step is the packet arriving at the firewall:
1. When a packet arrives at the firewall, a decision must be made to determine whether the packet should be allowed (forwarded) to the internal network.
2. The device performing the stateful packet inspection takes each arriving packet and inspects its headers to determine whether they match the set of rules that control what kind of packets are allowed.
3. When inspecting the packet’s headers, the inspection includes the packet’s source and destination addresses, its protocol type (TCP, UDP, ICMP, and so forth), its source and destination ports, flags set on the packet (SYN, ACK, FIN, RST, and so on), or other such basic header information. Incoming packets are inspected until enough information has been gathered from the packets received (using information such as TCP sequence numbers) to determine the connection’s “state.”
4. This inspection data is compared against the rule set that has determined what should be allowed and what should be denied. For example, all HTTP traffic only might be allowed to a web server, whereas other traffic should be denied trying to access the web server. This is a common rule wherein only a certain type of traffic should be allowed to only a certain server.
5. Depending on the connection status, this inspection information is then compared to a stateful table that would have entries for each TCP/IP connection the device has enabled. For example, most devices enable everyone from inside the network to access anything they want outside the network, and that connection would have formed an entry in the state table. Rather than enabling all packets that meet the rule set’s requirements to pass, only those packets that are part of a valid, established connection are permitted.
6. Ultimately, packets are either permitted or denied depending on these inspection steps. Because these rules/tables are consulted only once, complex inspection rules do not greatly impact performance.
7. All permitted and denied access should be logged to a secure syslog server that has accurate NTP sync. These logs can be fed into a security information management system for further analysis and reporting. In Cisco Security Manager (CSM), rules can be audited and hit counts analyzed to make sure that rule usage is being monitored, templates are followed, and there is no rule overlap or mistakes in existing rules.
SPI rules are not as easy to create as packet-filtering rules because of the added level of complexity. However, they are certainly worth the money and effort because they add an additional level of security to your network. They are also fast and can handle large amounts of network traffic. If the metrics recorded for the connection do not match the entry in the connection database, the connection is dropped.
Note
Usually, firewalls are the devices of choice for performing stateful packet inspection; however, routers can also be used in this role. However, this is not advised because mixing network devices’ roles alters the functions they were designed to perform. Some might argue that you can successfully combine roles and devices; perhaps this might be appropriate in the distant future—for today and for the networks I am responsible for securing, I advise against it.
Limitations of Stateful Packet Inspection
Although SPI devices have improved scalability and benefits over packet filtering, they are not the ultimate point of protection for your network; again they are but a layer in a layered defense. Consider the following two major disadvantages of stateful packet inspection:
• No application-level inspection: SPI cannot look at a packet any higher than Layer 4 of the OSI reference model. In practice, this is how attacks can succeed against servers that are accessible in some manner and protected by firewalls performing stateful packet inspection. Keep in mind that many attacks today are focused on Layer 4 and higher.
• No connection state for every TCP/IP protocol: Certain protocols within TCP/IP have no method of tracking the state of their connection between computers. Specifically, ICMP and UDP have no connection state; thus, in the layered defense model, these protocols should be subjected to packet filtering because they have no connection state to track.
This section discussed the capability of security devices, such as firewalls, to track the state and thereby the validity of a connection to determine whether it should be allowed into the protected area of your network. The next section focuses on the various means of further ensuring the validity of packets entering your network by using additional security to inspect them at Layer 5 (application) of the TCP/IP model or Layer 7 of the OSI model to provide a map of the layers in the models.