“America is all about speed. Hot, nasty, bad-ass speed.”
– Eleanor Roosevelt, intro to Talladega Nights
Here at Risk I/O we’re really, really big fans of speed,.. and data. Given the right data you can make good decisions very rapidly. It’s one of the core values we try to build into each release of Risk I/O. With that in mind, we thought we’d show off some work we’ve done to bring ModSecurity and the OWASP Core Rule Set to the Opscode Chef project.
There are really two sides to the work we’ve done. On one hand our cookbook makes it easy to deploy and configure ModSecurity in your infrastructure if you’re using chef. On the other, even if you’re not already using chef to manage your environment, you can use our cookbook to rapidly find out how adding ModSecurity could protect you. ModSecurity, like any Application Firewall is complicated and adding it to any production network is a serious project and should be considered carefully. However, I really hope that we’ve devised a method for you to prototype how it could benefit your security program quickly, and in a relatively non-intrusive way.
- Launch a cloud server with Apache, mod_security, and the OWASP core rules configured to act as a proxy.
- Run a vulnerability scan through the proxy against our site to gather a baseline.
- Enable the main core rule set and/or any others we find interesting.
- Run a new vulnerability scan to see if we’ve made any improvement.
There are a lot of ways to set up a server with chef. I chose to use the hosted service provided by Opscode with a cloud server provided by Rackspace running Ubuntu 10.04 LTS, as it seemed like the fastest, cheapest way to get started. I also chose to test against Testfire site from Watchfire, hoping to see lots of fun vulnerabilities, but of course you’d likely use your own sites. Let’s get started!
1. Launch an Ubuntu 10.04 server from Rackspace. Any size will do.
2. Create your Opscode account and run through the Quick Start through step 5.
3. Use knife to install chef-client, build-essential, apache2, and mod_security cookbooks in your chef-repo directory.
4. Create a base role in
chef-repo/roles/base.json. Mine looked like:
5. Configure the proxy. For the test I chose to do this by modifying
chef-repo/cookbooks/mod_security/recipes/default.rb rather than by creating a separate cookbook just for this bit.
6. Load the role and cookbooks up onto the chef server
7. Bootstrap the server
Now, we have our shiny new server all setup and configured. We need to run our baseline. I chose to use w3af as my scanner, mainly since its open-source, and I could run it straight from the server with little trouble. You’d probably use whatever scanner(s) you normally test against your environment.
1. SSH to the server as root.
2. Update the
/etc/hosts entry to alias the proxy to our localhost interface. Mine looks something like:
3. Install scanner with
apt-get install w3af
4. You may want to open a second connection to your server and watch the ModSecurity audit log.
/var/log/modsec_audit.log to see what flies past.
5. Run your baseline scan. I just did a basic scan, all vulnerability plugins, and output to xml and html. Here’s the command script I used.
Hopefully, by now we have a baseline scan to start from and we’ve seen ModSecurity inspect traffic in “DetectionOnly” mode. Time for some real fun!
We’ll want to change ModSecurity from being in the passive “DetectionOnly” mode to actually block something. Then we’ll want to pick and choose what rule sets to enable. In reality, this went through a few iterations, but to try to keep this post from getting too long, I’ll skip to the end config for our role. We want to:
1. Enable blocking. The core rules are enabled by default.
2. Increase the Regular Expression related limits to help out a few rules.
3. Disable the rule set that blocks bad robots based on client signature, like our scanner “w3af”.
4. Enable the SpiderLabs Research rules and a CSRF rule because they seem interesting.
5. Upload our updated role back to the chef server.
Rescan, Rinse, Repeat
At this point, we’d go back and rerun our scan and see how things improved, or didn’t. And, again. And, again. In my testing I went from 11 legitimate vulnerabilities, down to six, all classified by the scanner as low. It was an interesting process, with some surprises. For instance w3af was still able to find SQL injection attacks after enabling the SQLi related rules. But, after enabling the output filtering rule, the SQLi vulnerabilities vanished.
Why does this all matter? Because we can measure the value of adding a tool like ModSecurity and the OWASP Core Rule Set into our production environments with really minimal investment. A couple hours and a few dollars to rent a cloud server, and you can start collecting data on whether or not they’re worth your time. That’s pretty amazing to me, particularly for a security project. I recall initial planning and kick-off meetings that cost me more.
This post really was about how to rapidly prototype and measure the effectiveness of a particular security tool, and I hope it inspires you all to really think about how you can measure the effectiveness of various parts of your own initiatives.
For us here at HoneyApps, we’ll continue to improve the chef cookbook for as long as folks find it useful. The next big feature will likely be creating arbitrary ModSecurity rules, rather than only relying solely on the (terrific) OWASP CRS. Check out the code here, and please let us know if you run into any trouble along the way.
A huge thanks to all the people that have worked on the OWASP rules, ModSecurity, chef, and w3af. Any errors are likely my own.