SCADA Firewalls Need to be Stateful

Wednesday, April 11, 2012 @ 04:04 PM gHale


Editor’s Note: This is part one of a three-art series and is excerpted from the Practical SCADA Security blog at Tofino Security.

By Joel Langill
Deep Packet Inspection (DPI) is an important factor in security, but an equally vital discussion revolves around 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 most common in modern day industrial control systems (ICS) and SCADA applications.

RELATED STORIES
Defense in Depth: Layers to Bank On
How to Stop Stuxnet’s Children
Justifying Security Investment
Defense in Depth: No Singular Approach

DPI is actually analyzing and making decisions based on the information contained in the upper layer of the model typically used in TCP/IP communications for ICS and SCADA systems. The upper 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.

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.

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 dependent 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; which last sent a message; was the last message rejected because of errors, and so on. Without this, communications quickly break down.

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.

Part 2 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. In the meantime, let me know your questions or comments about stateful inspection.
Joel Langill is the chief security officer at SCADAhacker.com. His email is joel@scadahacker.com. Eric Byres, chief technology officer at Byres Security, collaborated on this report.
Click here to read the full version of the Practical SCADA Security blog.



Leave a Reply

You must be logged in to post a comment.