Web Application Firewalls

What a great idea!

So good in fact that they have become a compliance checkbox and yet another appliance and maintenance contract that vendors want you to buy.

Cynicism aside, the first question you should ask is:

“is this the right tool for the right job ?”

We can debate the right tool idea all day long and not get very far, each vendor will tell you why they are better than the other guy, but what is — or should be — going on under the covers is about the same.

Layer three stateful firewalls work pretty good at stopping traffic you don’t want to see at all. It’s the internet facing services you want to publish to the world safely that become the problem. Layer three stateful inspection will not save you from SQL injection, cross site scripting attacks,  Iframes, Active-X and all other real and imagined evils comming in over port 80. 

While I like the idea of offloading that inspection of application specific traffic to a dedicated device that knows exactly what to look for, the problem seems to be in the “exactly what to look for part.”

I have put quite a few different versions of this layer 4-7 inspection technology in over the years, some hardware, some software. Some do this via extra firewall inspection modules and slap on a great sounding name.  Other systems are dedicated appliances that act like a proxy and only allow a defined set of commands to go though.

Sadly, you often wind up turning these features off because the rigid inspection breaks someone’s payment application, or you can’t buy things on Ebay because the 1024 byte url limitation broke the buy now button!

The most effective solutions I have worked with personally involve whitelisting valid URL strings. If it’s not a valid request that was already defined in the system then the request is blocked.  The main problem is building and maintaining the white list. 

Even if the application is on the supported list, there is no such thing as plug and play, without a whole lot of playing — post implementation. It usually winds up with about 80% of the functionality that the customer originally wanted so you wind up living with out some original features, or opening things up with wild cards and disabling parameter checks to get around the bugs and site specific glitches. Obviously this results  in the overall posture being less that 100% locked down.

So what’s the solution?

Perhaps this should have been addressed first.

• Are the Internet facing servers isolated to the point that complete take over of the device by a third part does not give them any information, no way further into your company and they can’t break out of the server to go bother someone else?
• Is there sufficent monitoring of these servers to detect when the machine has been compromised and the recovery process is both quick and complete?
• Are the applications agressivley tested, both with credentials and anonymously,  by experienced penetration testers? Do the developers, sys admins and network engineers understand and have the ability to fix the problems? Is the  testing model build into the organization’s system development lifecycle?

If the above are true you probably don’t need to invest in application specific protection.  That said, you can never go without regularly testing these systems. Passing a simple anonymous vulnerability scan two years ago does not mean your systems are still safe today.

• Test regularly through automation
• Test agressivly with skilled third party practitioners  
• Don’t be afraid to have some of your internal staff done a grey hat now and then. 

 If the answer is “no, we have a lot on the line and we are delivering it over http/https” then looking into some type of addtional protection beyond a layer 3 stateful firewall is a must.

Watch for some lab tests over the next month or so. We’ll be putting some of these protection solutions through the paces using  current web application penetration testing techniques.