Kenna Security is now part of Cisco

|Learn more

Rapid Prototyping the ModSecurity Application Firewall with Chef

Oct 17, 2011
Ed Bellis
Chief Technology Officer, Co-founder

Share with Your Network

“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.

The Plan:

  1. Launch a cloud server with Apache, mod_security, and the OWASP core rules configured to act as a proxy.
  2. Run a vulnerability scan through the proxy against our site to gather a baseline.
  3. Enable the main core rule set and/or any others we find interesting.
  4. 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 Startthrough step 5.

3. Use knife to install chef-client, build-essential, apache2, and mod_security cookbooks in your chef-repo directory.

knife cookbook site install chef-client
knife cookbook site install build-essential
knife cookbook site install apache2
knife cookbook site install mod_security
view hosted with ❤ by GitHub

4. Create a base role in chef-repo/roles/base.json. Mine looked like:

name: base,
chef_type: role,
json_class: Chef::Role,
description: The base role for our test,
run_list: [
view rawbase_role.json hosted with ❤ by GitHub

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.

# Add proxy for demo
mod_secure_proxy testfire do
#enable_https true
view rawproxy_snippet.rb hosted with ❤ by GitHub

6. Load the role and cookbooks up onto the chef server

knife role from file roles/base.json
knife cookbook upload chef-client
knife cookbook upload build-essential
knife cookbook upload apache2
knife cookbook upload mod_security
view hosted with ❤ by GitHub

7. Bootstrap the server

knife bootstrap SERVER_IP -r role[base] -x root -P ROOT_PASSWORD
view hosted with ❤ by GitHub

Baseline Test

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: localhost localhost.localdomain
view rawhosts hosted with ❤ by GitHub

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.

set target
discovery webSpider,allowedMethods,serverHeader,frontpage_version
audit all
output htmlFile
output config htmlFile
set fileName /tmp/testfire_baseline.html
output xmlFile
output config xmlFile
set fileName /tmp/testfire_baseline.xml
view raww3af_script hosted with ❤ by GitHub

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!

Configure ModSecurity

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.


name: base,
chef_type: role,
json_class: Chef::Role,
description: The base role for our test,
run_list: [
override_attributes: {
mod_security: {
rule_engine: On,
crs: {
base: {
slr: {
view rawbase_role.json hosted with ❤ by GitHub

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.

Next Steps

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.

Read the Latest Content

Research Reports

Prioritization to Prediction Volume 5: In Search of Assets at Risk

The fifth volume of the P2P series explores the vulnerability risk landscape by looking at how enterprises often view vulnerabilities.

5 Things Every CIO Should Know About Vulnerability Management

If you view vulnerability management (VM) as just a small part of your operation, it might be time to take another look.  Managing vulnerabilities is...



Get Started Using the Exploit Prediction Scoring System (EPSS).

Cyentia Institute’s Chief Data Scientist and Founder Jay Jacobs gives tips on how to get started using the Exploit Prediction Scoring System (EPSS). You...

© 2022 Kenna Security. All Rights Reserved. Privacy Policy.