Home
You are here: Home > Firewalls >

Your Firewall is Blind to Web Application Security

Time:2009-01-10 16:05Source:未知 Writer:admin Click:
Earlier we looked at how the firewall has changed roles in the enterprise. The focus was on desktops but we can't discuss the changing role of the firewall unless we talk about the newest regulations that justify the very existence of such devices.
  Earlier we looked at how the firewall has changed roles in the enterprise. The focus was on desktops but we can't discuss the changing role of the firewall unless we talk about the newest regulations that justify the very existence of such devices.

When the perimeter was all that IT security pros had to worry about, the firewall filled a very basic role, not much different than a security guard. Today, the firewall is a vital component of regulatory compliance, more so in the network segmentation requirements seen in some of the more popular regulations.

The first thing we need to consider when deploying firewalls are the traffic flows that are vital to business operations. Many times you're going to find that if you're lucky enough to map out rule sets that work, regulatory compliance may trump the protocols and ports you have open. PCI, for example, only allows for web protocols such as SSL.

Layering firewalls and managing these deployments is going to be a tall order. Many organizations have tried their best but have found themselves in an administrative nightmare. Certainly this is not the ideal situation but most have no choice because they must adhere to regulations.
Web Application Firewall

Another type of firewall that has been born in modern network deployments is the WAF, or Web Application Firewall. Traditional firewalls protected networks against traditional attacks. While effective in the old model, modern attack vectors run circles around the firewalls of yesterday. Architectures now have heavy web application tiers, and as such, they demand a different approach towards protection.

SQL injections and XSS (cross-site scripting) are the usual suspects in Web server attacks.

For example, here is a code injection into an HTML image src tag. In other words, XSS scripting.
<img src="javascript:txt='OH NOEZ!!! My Screen Just FROZE!!!'; txt2='Good stuff hehe *S*';x=0;y=80; function niceguy(){nice=confirm(txt2); if(nice==1){window.setTimeout('parent.window.moveTo(0,0)',2100)};} function ha(x){parent.window.moveTo(x,y);if(x==1800)alert('Hehehe...cya ; )'); window.setTimeout('if(x!=1800){ha(x+=30);};else{niceguy()}',25)}; alert('Well thats enough of that');ha();">

A traditional firewall wouldn't know what to do with something like this, however a WAF is designed to look for things like this.

SQL injection takes place when inputs are not sanitized properly. A WAF can act as a maid and clean up inputs so that SQL injection probes such as this:
anything' OR 'x'='x

...will not be able to execute and potentially return data to the attacker that was not meant to leave your databases. Again, a traditional firewall wouldn't know what to do with such payloads.

The WAF has another very special feature that traditional firewalls do not. A WAF can offload SSL traffic, decrypt it in order to examine payloads then only pass along good requests to the web server.

In addition to these features, a WAF also has the ability to deal with authentication protocols such as HTTP/0.9, HTTP/1.0, and HTTP1.1. Some WAFs handle basic authentication, digest authentication, client SSL certificates and two-factor authentication. Again, things that were not even conceived, let alone envisioned, uses for a traditional firewall.
Weighing the Negatives and Positives

You can deploy WAFs in some sense like a traditional firewall in that you can use "white list/black list" or in today's speak, "negative/positive" architectures. Which you select depends heavily on your environment and resources, but the basic differences here are as follows.

In a negative architecture, all transactions are allowed by default. It's a signature-based deployment and of course relies on the vendor updates.

A positive model is behavioral and the WAF will deny all transactions by default and will rely on rules to allow only transactions that are known to be safe. This method requires a significant amount of "training" for the firewall to learn which transactions are legitimate.

Earlier we mentioned that PCI requires firewalls within your environment. Recently, PCI DSS recognized the WAF as a substitute for code reviews. While I would not recommend dropping code reviews in place of a WAF, regulators have enough faith in this new firewall architecture to actually name it as a viable component to your regulatory compliance architecture.

Again, the WAF should be a supplement to your security stance, not a replacement for another key component. The point is, given the feature rich suite of tools offered in WAFs, the modern firewall has found a new job in modern network architectures.
------fengexian----------------------------
Recommended Content