This article is a collaboration between Joel Langill and Eric Byres. Joel is the CSO at SCADAhacker.com. He can be reached at [email protected].

Following on from Eric Byres’ discussion of Deep Packet Inspection (DPI), this article discusses a second and equally important aspect of effective firewall security referred to as “stateful inspection”.

In order to understand exactly what is meant when we talk about “state”, we need to look at the specifics behind the TCP communication sessions that are most common in modern day industrial control systems (ICS) and SCADA applications. The figure below illustrates the model.

abstractionlayers


Figure 1: The abstraction layers typically used in TCP/IP communications for ICS and SCADA systems.


The DPI that was previously discussed is actually analyzing and making decisions based on the information contained in the upper layer of the model. This layer is where you would typically see specific application operands such as a Modbus Read Coil (e.g. function code 2) or a Modbus Write Single Register (e.g. function code 6).

Clearly this DPI provides the highest level of granularity when it comes to managing communication between hosts on a network. An example of an industrial firewall that offers this is the Tofino Modbus TCP Enforcer.

It is also possible for appliances to offer what is called “Shallow Packet Inspection” or SPI, which looks at data lower in the protocol stack. This is where the concept of “state” becomes important.

State in Data Communications

Just like communications between people, communications on a network rarely just involves a single message. There is a constant exchange of packets, where each is in some way dependant on previous packets. For example, if your computer receives a message containing a web page from a web server, it can only be interpreted with the knowledge of what request was sent earlier. If your computer never sent a message asking for the page, then the only reasonable thing to do with the message is to discard it.

This understanding of the previous traffic is what we call “state”. Basically the computers involved in the information exchange have to understand the “state” of the exchange at all times. They need to know state information such as which device started the session, who last sent a message, was the last message rejected because of errors and so on. Without this, communications quickly breaks down.

How Can We Assist You Today?The Hazards of Stateless Security

Compared to the devices actually communicating, a security device has a little more flexibility regarding understanding the state of the traffic it is securing. In theory, it can try to manage the traffic while ignoring the state of the sessions on the network. Unfortunately, ignoring state comes at a price – badly degraded security. Let’s explore why this is so.

A “stateless” or “packet filter “appliance only analyzes each packet in isolation of other information relating to the communication session. It has a series of static rules and uses them to take action upon received packets on an individual basis. It bases decisions to allow or deny packets on simple filter criteria such as:

  • the source and destination IP addresses in the message (Layer 3)
  • the source and destination protocol number in the message (first part of Layer 4).

The following rules can easily be handled by a stateless packet filter firewall:

  • Accept Domain Name Service (DNS) response packets on User Datagram Protocol (UDP) port 53;
  • Block any traffic to or from Internet Protocol (IP) address 24.116.25.21;
  • Prevent web surfing by blocking outgoing packets from accessing Transmission Control Protocol (TCP) ports 80, 443, 3128, 8000 and 8080, unless they are directed to the corporate intranet web server's IP address.


Unfortunately, a packet filter firewall’s inability to understand the relationships between a series of packets is a serious weakness. For example, the broad rule "Accept DNS response packets on UDP port 53" contains a serious flaw. What if no DNS query was ever issued, but a spoofed DNS "response" packet came in instead? This simplistic firewall would accept the packet and deliver it to the "requesting" host, possibly causing it to become confused.

In Part 2 of this article, I will explain how straight forward it is to hack a stateless firewall. Part 3 will discuss how stateful firewalls operate and provide some design considerations for ICS security systems.

Related Content


[1] the model discussed in this article is a simplification of the OSI 7-Layer Model