Deep Packet Inspection Firewalls, Inlin IDS, and Web Application Firewalls

Due to the increase of attackers targeting web applications and the limitations outlined previously for firewalls and NIDS, the vendor market had to make some changes. Nowhere was this realisation more clear that in the infamous Gartner report of 2003 titled (*giggle uncontrollably)) "Gartner Information Security Hype Cycle Declares Intrusion Detection Systems a Market Failure," or as it's more commonly called, the "IDS is Dead" report (I wonder is IDS got a funeral?). Anyway, on with it... In the report, Gartner writes

"Intrusion detection systems are a market failure, and vendors are now hyping intrusion prevention systems, which have also stalled," said Richard Stiennon, researchvice president for Gartner. "Functionality is moving into firewalls, which will perform deep packet inspection for content and malicious traffic identifying and blocking, as well as antivirus activities."

Although most people didn't agree with everything said in the report, such as the prognostication that IDS would be out of the market by 2005 (yeah right, and Microsoft is going Open Source...), the majority of security practitioners did concur with the need to implement some form of new approach to preventing these network attacks. Gartner suggested that the capabilities of IDS technology should be implemented into firewall technology. This is exactly what happened, as the firewall vendors were already in the prime network architecture position of having a device that all traffic must pass through. All they needed to do was to implement logic for the firewall to be able to inspect OSI Layer 7 application data. Thus, the deep packet inspection firewall was born.


Deep Packet Inspection Firewall

The basic concept behind deep packet inspection firewalls is that they have access to the data payload of the packets. Having access to this information allows the device to apply certain security checks that were not possible without this data. If we take an updated look at the NIMDA attack request that was logged by a Checkpoint Firewall-1 host, we can see that the firewall is now able to log/trigger on the "resource" data of the web request:

14:55:20deny firewall.foo.com >eth0 product VPN-1 & firewall-1src 24.18.186.245 s_port 4523 dst 69.229.28.252 http proto tcp xlatesrc 192.168.1.101 rule 6
resource=http://hostname.com/scripts/root.exe?/c+dir

With this information, the firewall can now take appropriate action and deny the connection.