Can Stateful Inspection Evolve?

3,109 people reacted 1 5 min. read
Nir Zuk

By

Category: Uncategorized

Tags: ,

One of my many roles as a founder and CTO is to meet with customers and talk about their network security issues. These visits are not only informative, they can be humorous as well. For example, a recent visit to a large, fortune 500 company, they told me that one of our firewall competitors explained that Stateful inspection would evolve to include application visibility and control. As one of the original engineers working on Stateful inspection, I found this statement extremely humorous.

We created Stateful Inspection at a time when applications could be controlled using ports and source / destination IPs because applications were tightly tied to ports and protocols. But today, applications of all types no longer adhere to port and protocol which means they can no longer be controlled, let alone identified by today’s port-based (Stateful Inspection) firewalls.

Today’s applications use either well-known open ports or a variety of evasive tactics to easily bypass firewalls. Sadly, most 11th graders can go into any corporate network and use any application they want, go anywhere on the internet and do anything they want through the corporate network and there is nothing firewalls can do about this. The fundamental reasons that Stateful inspection can be easily evaded include they rely on fixed ports, they look only at the first packet and they are unable to inspect SSL traffic.

The question then becomes one of whether or not Stateful inspection can evolve in the same manner that the applications have. The answer is no. Stateful inspection is architected to classify traffic based specifically on ports and protocols. The use of port and protocol traffic classification is hard coded – it is arguably the most fundamental component of Stateful inspection because it is used as the basis of the security policy. The allow or deny decisions are based on the port and protocol, so modifying Stateful inspection to replace port and protocol with application identity means a complete re-write of the software, a monumental task, given the foundational importance of traffic classification. Here is why Stateful inspection cannot evolve.

Stateful Inspection firewalls enforce policy decisions for a complete TCP or UDP connection upon receiving the first packet of that connection. Once the policy decision is made, further inspection and associated policy lookup is not required because every packet carries the same port number and the following packets from the same connection are not going to provide any additional information about the connection. This form of classification and policy enforcement cannot control many of the applications we see on enterprise networks.

Classifying traffic based on applications must continuously examine packets and check the policy table in order to determine how to treat a given connection. For example, the first packet might have a destination of port 443. The firewall performs a policy check and determines that the connection should be accepted. After a few more packets, the firewall might learn that this an SSL connection (it could have been non-SSL on port 443). Again, the firewall consults the policy to determine whether to allow the connection and also figure out whether this SSL connection needs to be decrypted. After a few more packets, the firewall might learn that this is HTTP inside SSL on port 443. Again, the policy lookup needs to be performed. Additional inspection might determine that this is Yahoo! Instant Messenger, which again requires a policy look up and an allow or deny decision. The traffic classification and policy lookup process continues in this manner for all traffic across all ports.

During the continuous classification process, firewalls that classify traffic based on applications do more than just multiple policy lookups. They need to determine when to log new information they discover—which is a continual process, given the comparatively dynamic nature of application traffic. In addition to continual policy lookup and logging, the application is used as the basis for route lookups, QoS decisions, threat prevention and so on.

Now, let’s assume a complete rewrite of Stateful inspection is achievable, it is only one of the two components required to deliver an enterprise-class firewall that controls applications. The second component is the hardware required to support application layer inspection across all ports and on all traffic. It is well documented that this level of inspection requires significantly more processing power then mere port-based scanning. For example, in a Stateful inspection firewall, a flow that is established can move to a “fast-path” because it does not requires any more policy lookups. As described above, this is not the case with an application aware firewall. The continual inspection and policy lookup requires appropriate processing be applied to maintain performance. Existing Stateful inspection vendors would therefore be forced to not only re-write the software from scratch—they would need to develop in tandem, a new hardware platform with appropriate processing power.

In short, Stateful inspection, cannot evolve to control applications. A new approach is needed – one that identifies applications as soon as the traffic hits the box, ignoring ports, protocols, evasive tactic or SSL encryption. That is what we created here at Palo Alto Networks.

5 Reader Comments

  1. Hi:
    I reviewed the SC Magazine Awards 2010, and the Enterprise Firewall winner was … CheckPoint? What?.

    I dont know how they evaluate the appliances, i believe that the winner must be PA-4000, the xx-ID its a great innovation in Firewall technology.

    When will begin the NGFW to replace the stateful inspection firewall only?

    When the sc magazines editor read Gartners recommendations 🙂

  2. Matt

    Victor – thanks for the support. We continue to make progress great strides in demonstrating how we can help customers identify and control applications more effectively than any other product on the market. Do not let this award sway you.

    Matt

  3. I love the Logic. It seems to obvious that this is the way forward and I cant believe this logic has not been become mainstream. I cant understand why people buy firewalls that don’t use this logic of App detection.

  4. Hi Nir,

    Have you read “Securing the Borderless Network” by Tom Gillis ? especially the last chapter that outlines the broderless network security architecture which Cisco is heading for. The implementation and logic seems extremely similar to what Palo Alto network architecture is, especially the endpoints agent that is a connection manager that is able to redirect traffic from endpoints to nearest scanners. You said in a recent interview that there are no other vendors that implement this logic currently, but it looks like Cisco is actively working towards this goal.

    Regards,

    Sunil

  5. Hi Sunil,

    Cisco still isn’t sending their ASA’s to NSS Labs to be tested like all other firewall manufacturers. Is there something they don’t want us to know? I can’t trust their appliances based on sales brochures. ASA is still running on the same underlying architecture from 1993 and has not improved on the stateful firewall. They absorbed SourceFire (just like PIX) then rebranded it FirePOWER (just like ASA) I assume to bridge the gap where their primary network security device failed to meet today’s requirements. Whenever a security product, which has never been their forte, gains traction due to their brand name only, it is soon shut down and not replaced e.g. MARS, CSA, and many others.

Got something to say?