I have a pretty good amount of experience with WAFs, although none in an actual deployed state (other than mod_security as an Apache module). I reviewed one of the earliest Teros version before they even had a shipping product. I also spent a lot of time talking to web site owners and security people that have attempted to deploy these devices/software products. I learned a few things over the years:
1. If you have a high volume site I can’t recommend deploying a WAF. They all are pretty terrible when it comes to handling load.
2. I have never seen one deployed in block mode. Always in IDS mode (alert but don’t drop). The various block modes have there issues especially with higher traffic volumes. Also Baba O’Riley is not going to be very happy when he can’t use your site.
3. This is not your network firewall. WAFs take a LOT of care and feeding. Not only in the first time setup but every time the app changes you need to do some work. Depending on your environment this can be extremely time consuming. This is the main reason I believe they are not deployed in block mode.
4. Do you really want another device between your customers and your website? If it fails your site is down (at least for inline deployments). Yes you can buy 2 but your price grows 2x as well.5. A WAF will not protect you against any flaws in the business logic of your application. Can I change my account id and see someone else’s info? Your WAF can’t really help you there.6. I have not seen a WAF that handles encoded attacks very well. They do a good job of blocking a script tag but not a good job of blocking
%3c%73%63%72%69%70%74%3e
which is the HEX encoded script tag. Many applications will happily convert that for you to an executable tag.
7. The technology is still really immature and the technology it is trying to protect is rapidly changing. Not a good combination in my book. I develop web application scanners for a living so I can tell you that at least once a week I see something that makes be go WTF?!?!. We have the advantage of seeing it, analyzing it, writing code and releasing it in a very short time frame. WAFs do not have that luxury and if they are in block mode you are potentially blocking a ton of legitimate traffic. Your business owner is not going to like you. ;D
8. You (as the owner of the firewall) must have a very intimate knowledge of the app in order to configure it to allow the things in need to allow and block the bad stuff. Think about this, the app should be doing this checking, we are now trying to put this logic in a piece of gear that is very, very far away from the code.
9. Every time the app breaks, you will have to spend at least an hour convincing people it is not the WAF. If it is the WAF, expect the dev. team to assault your cube with pitch forks and torches. Once they are done with you the business owner will re-enact the last scene from Brave Heart on you. I have personally witnessed this, it is not pretty.
10. All WAF’s auto learning engines suck. Not only do they not get everything they take a lot of load while trying to figure it out. This of course amplifies the speed issues.
So where are WAFs feasible?
1. Legacy apps they are still in production but not being actively developed. Got some old ASP classic app. that is riddled with SQL injection? Slap a WAF in front while the dev. team keeps porting it to .NET.
2. Apps that only change every 12 months or longer. You still have performance issues and config issues but you have less config overhead.
3. You are a web app sec expert. It takes one to properly configure these devices. Don’t believe the magic learning elf hype.
4. You don’t like your job and want to get fired so you get a nice severance package.
5. You know exactly where all the vulns are in your site, your site won’t change and you feel like writing all those WAF rules.
If you enjoyed this post, make sure you subscribe to my RSS feed!
