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.

Why Intrusion Detection Systems Fail As Well

The second most common misconception is the role that Network Intrusion Detection Systems (NIDS) play in web security scenarios. NIDS are a reactive strategy rather than a protective strategy. This does not mean that they do not serve an important service. They are fairly effective in identifying known web based attacks, but actually acting upon the malicious requests is another matter. This is due in part to their deployment location ont he network.

Most often, NIDS are deployed in a passive, third-party way such that they do not interfere with the network traffic. An example network diagram for a common NIDS deployment is shown below.

They are simply able to view the data by utilizing data from a SPAN port or TAP. They are often reconfigured to remove their IP stack, as to minimize the chance of responding to network activity. While this strategy does help to conceal the presence of a NIDS sensor on the network, the flip side is that this makes it more difficult to execute any sort of flexible response on identified attacks. By flexible response, Im refering to the capability to attempt to reset TCP connections by sending spoofed TCP Reset packets to both ends of the connection.

There has been numerous documented tests for Snort's flexible response capabilities. The effectiveness of this setup is mixed if you consider the different result catagories of most web attacks:

• Denial of Service. In DoS attacks against web servers, the malicious packets just need to make it to the web server. The attackers do not usually need to have any data returned for the attack to be successful.
  
• Command Execution/Injection. Similar to DoS attacks, these malicious requests normally only need to make it to the web server in order for the attack to be successful. If Snort prevents the outbound data from being returned to the attacker, this does make it more difficult for the attacker to accurately conduct a large command execution attack, as they do not have any verification of success/failure of their commands. This becomes a "blind" execution attack.
• Obtaining Information. The goal of the attack is to obtain information from the web server, such as the contents of the /etc/passwd file. In this attack, if the attacker does not receive the results of the command, then the severity of the attack has been lessened as you have prevented information disclosure.

From the results of such documented test, due to the speed and overhead of creating the TCP reset packets, Snort was just not quick enough to tear down the malicious requests connections prior to reaching the web server. This means that it was not successful at mitigating the DoS and Command Execution attack categories. On the flip side, it was rather successful at preventing the information discolsure attacks by terminating the connection prior to the data reaching the attacker.

Don't get the wrong impression with test result you may find on the net about NIDS preventing web attacks. NIDS serve a critical purpose in web security; however, prevention of attacks will not be achieved unless the architectural deployment strategy of NIDS is changed. This is where the concept of an "inline" IDS emerged.


Next, we'll look at Deep packet Inspection Firewalls, Inline IDS, and Web Application Firewalls