Setting Up Stateless Firewall

Tuesday, May 1, 2012 @ 03:05 PM gHale

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

By Joel Langill
Let’s consider a simple session where a client computer issues a request to a web server using the HTTP protocol. As defined in the IETF specifications, this message will contain the IP addresses of both computers (“src.ip” and “dst.ip”). It will also contain the number 80 in the destination port (“dst.port”) field to indicate the TCP packet contains a message for a HTTP server.

The HTTP server will reply with a message that has the “src.ip” and “dst.ip” reversed (since the message is in the reverse direction). The number “80” is moved to the source port field, indicating a reply from a HTTP server.

For completeness there needs to be the “TCP 3-way Handshake.” This handshake will establish communication for all TCP communications and is also part of the “state.” However for this discussion, we are going to skip the details of the 3-way handshake and focus on what happens after that.

Now to manage these communications, insert a simple switch or firewall that is unaware of the “state” of the communications. In other words, the device is unable to determine anything about any previous communication that may have taken place between the two hosts (including the presence or absence of the TCP 3-way handshake). The only information this appliance can inspect are the IP addresses (source and destination) and the protocol port number (source and destination).

In order to allow our simple HTTP session to pass through this appliance, we would need to configure a unique rule for each “direction” of the session — one to allow the outbound HTTP “request” and the other to allow the inbound “response.” These rules might look something like:
Allow src.ip=10.1.1.100 dst.ip=10.1.1.200 dst.prt=80 (Outgoing rule)
Allow src.ip=10.1.1.200 dst.ip=10.1.1.100 src.prt=80 (Incoming rule)

While this looks simple, this type of paired access control rules immediately leads to security vulnerabilities. Since the appliance can only analyze limited source and destination data, it is not possible for it to block “inbound” communication that was not the direct result of an “outbound” request.

To exploit this hole, an attacker could simply change their IP address to match the Application Server (this is known as “spoofing”) and send their malicious packets to the Client marked with TCP port 80 as his source port. (Note: this attack allows the packets into the control system — if you want to get replies back from the client you would require a second technique called arp poisoning, but that is another discussion).

Not only is this simple to perform, it is also difficult to detect since the traffic would appear as normal web browser traffic to monitoring tools. The stateless firewall or switch would only see the traffic as coming from the correct IP Address and as being some sort of HTTP message, and happily let it through.

This is a moderately serious security problem if you have configured your stateless firewall to only allow web traffic to a single server; at least that forces the hacker to pretend to be that one server. But what if you want your user to be able to browse the web?

The resulting stateless rule would allow the entire web to be able to send any packet they want to the poor client computer, provided they mark the packet with source port 80 to indicate HTTP traffic. It won’t matter if it is really HTTP traffic – it would just have to be marked as such. That is a very low bar to jump over. Plus the hacker can send as many of these packets as they want, a wonderful way to flood the control network.

Here is a recap of stateless security
1. A security appliance that is stateless can only analyze each packet using limited source and destination data. It is unable to determine anything about any previous communication that may have taken place between the two hosts.
2. It cannot block inbound traffic that was not the result of an outbound request.
3. Attackers can send malicious packets by using an IP address that matches the Application Server. This is known as spoofing.
4. Spoofing is difficult to detect as it appears as normal traffic to monitoring tools. The volume of traffic is higher, but this will probably not be noticed.

In Part 3 of this series, I will explain Stateful Inspection and how critical it is when securing ICS and SCADA Systems.

Joel Langill is the chief security officer at SCADAhacker.com. His email is joel@scadahacker.com.
Click here to read the full version of the Practical SCADA Security blog.