Why Firewalls Fail To Protect Web Servers / Applications

`During the next month I am going to b focusing on Web Application firewalls. Particularly ‘role our own’ type application firewalls. I will be putting 3-4 blogs on this technology, what works and what doesn’t.

During the final week, I will write about the howto and results of an interesting project I have been focusing on. The “Proxypot” is basically a Honeypot Web Proxy server, which logs all usage traffic, it returns a “200 OK” to malicious traffic but it blocks and logs the malicious traffic.

So on with it ….



WHY FIREWALLS FAIL TO PROTECT WEB SERVERS/APPLICATIONS

There are very common misconceptions made by staff in organizations about the effectiveness of various network security tools for preventing web attacks. The most common and stupid one is that a firewall can handle this task (this one usually comes from “budget conscious” managers!).

Firewalls were originally created to inspect the IP and TCP layers of the OSI network model, meaning the original task of the firewall was to focus on IP address sand port numbers of the connection and not the application layer information. Historically, the characteristics of the packets could be used by the rule sets were the following:


Source IP

Destination IP

Source Port

Destination Port


So we have this fancy, expensive, state of the art firewall, we are doing everything to the highest standard. We are dropping every packet which isn’t explicitly allowed and only allow TCP 80 through from anywhere to our very large and expensive e-commerce web server.

With a configuration such as this, when a web request would come into the firewall, it would allow it based on rule number ‘bla’ and then forward it into the web server. An example log entry is shown below (Ten points to you if you guess which firewall this is from! ) :


14:55:20 accept firewall.foo.com >eth0 product VPN-1 & Firewall-1 src 24.18.186.248
s_port 4523 dst 69.229.28.252 service http proto tcp xlatesrc 192.168.1.101 rule 6


The problems arise when the full web request that was passed by the firewall is something like this:


24.18.186.248 - - [05/Feb/2005:14:55:20 -0500] "GET /scripts/root.exe?/c+dir HTTP/1.0"
404 1041 "-" "-"


An example network diagram illustrating this firewall setup is show below.






Oops, this request appears to be part of a NIMDA worm attack. This could be bad news if the target web server is running IIS and is not patched. Of only the firewall had some knowledge of layer 7 payload, it could have blocked this attack; however, this data is not normally available as evidenced by the preceding firewall log entry.


Next port wil explain why Intrusion Detection Systems Fail as Well !