First some background about web applications firewalls for the uninitiated. If you already know what a web app firewall is then you can skip down to the bottom of the post for some mod_security rules that will help you with Drupal Views, the GMap module admin pages, and Google Webmaster Tools.

Web security is a hot topic these days. By now almost everyone should know that running a packet filtering firewall is a MUST on a server or workstation that is connected to the Internet. But a firewall won't help if you have to allow ports through the firewall for applications to function. One of the most (if not the most) allowed is port 80 for HTTP traffic to a web server.

According to a 2007 study conducted by the Web Application Security Consortium (WASC), " more than 7% of analyzed sites can be compromised automatically." (http://www.webappsec.org/projects/statistics/). Given more detailed analysis, the "probability to detect high severity vulnerability reaches 96.85%." Also, "over 70% of all attacks [are] now carried out over the web application level." (http://www.modsecurity.org/documentation/faq.html#d0e47). Those numbers should scare ANYONE who is running a web site.

One of the best methods of protection for web applications is a firewall that runs at layer 7 (the Application Layer) of the OSI (check out the Wikipedia article on the OSI model for more information - http://en.wikipedia.org/wiki/OSI_model). These types of firewalls are called Web Application Firewalls. They look at traffic patterns heading to your web server and block "bad" traffic based on rules that are specified when configuring the firewall.

Various vendors sell web app firewall appliances or build a WAF into their appliance products. At the day job we use a great product call a Netscaler (http://www.citrix.com/English/ps2/products/product.asp?contentID=21679) which is sold by Citrix which has a WAF built in if you buy the proper licensing. If your company has the budget I HIGHLY recommend a Netscaler. They are the Swiss Army Knife of web application delivery and security.

For those of us running small sites with limited funds, a Netscaler is probably not in the budget. However there is an open source web aplication firewall that plugs straight in to one of the most popular web servers out there - Apache.

It's called ModSecurity - http://www.modsecurity.org/

mod_security is a full-function web application firewall that is available as a package for most Linux distributions. Those packages also come with what is called the Core Rule Set (CRS). These are stock rules that detect and can block most well-known web application attacks such as Cross-Site Scripting (XSS), SQL Injection, Information Leakage, and a host of other web application vulnerabilities.

Now for the Drupal goodness.

If you're running mod_security with the rule engine on and blocking (you should be if you're not), then the Drupal Views admin pages don't seem to work. You try to change a parameter in your view and nothing happens. The Views admin pages use AJAX to change the page. Behind the scenes mod_security is security blocking access to those requests but you don't see any error on the page. You can also have the same problem with the GMap Drupal module.

In order to fix this problem I added the following rules to my modsecurity_localrules.conf file:


# Google webmaster tools
#
SecRule REQUEST_URI "^/googleHASH_HERE.html$|^/noexist_HASH_HERE.html$" phase:1,log,pass,ctl:ruleEngine=Off



# Drupal 6 ajax admin pages
#
SecRule REQUEST_URI ".*admin/build/views/ajax/.*" phase:1,log,pass,ctl:ruleEngine=Off
SecRule REQUEST_URI ".*admin/settings/gmap_location$" phase:1,log,pass,ctl:ruleEngine=Off


Watch line wrap on the above rules. Each rule should be on it's own line that starts with SecRule

These rules turn off the rule engine if the requested URI matches the regular expression specified. This is a pretty open rule. You may want to tighten it down more to suit your needs, but these rules WorkForMe(TM). Also, replace the HASH_HERE with the full URI to your Google Webmaster Tools verification URI.

mod_security is a very powerful tool for protecting your site, but it can be tricky to configure. My advice is to setup a duplicate test site of your production website and play with mod_security. In detection-only mode, mod_security will log all the issues it finds and then you can tweak your rules to get everything right. Once you think everything is working, turn on the rule engine and run through your test site. If you get blocked where you shouldn't, check the logs and tweak or add more rules. Repeat the process until you have everything working and then add mod_security to your production site.

Here are some links that I found helpful:

The ModSecurity FAQ
ModSecurity Documentation
Web Security Articles at the Web Application Security Consortium

Good luck securing your sites,
Flux.