In the ‘bible's Ports Services & Firewalls Guide we installed a firewall to protect the server, but we left open the web ports 80 and 443. If we block those, of course, we block access to our sites. Oops!
What we need are alternative strategies for filtering malicious web traffic, and techniques abound in these pages. Have another, a brilliant web application firewall (WAF) called ModSecurity.
Conceived by Ivan Ristic and developed by a team of head honcho security pros, this open source firewall is a prudent partial umbrella for applications such as WordPress:
It sits in front of a web server to allow or deny requests depending on your rules which can be set on a cross-site and per site basis. It logs the lot and offers real-time analysis.
Installing mod-security, the Apache module
As usual, there are many ways to install this baby. This method is for those who installed Apache from a Debian-based repository, so adapt it to suit your distribution or check the ModSecurity site for the compilation method. Assuming root, this installs and enables the Apache module:
Applying a ruleset
If ModSecurity is the engine, the rules are the fuel. We have two fundamental options.
If you want an easy life – that is, support! – and can afford $100 per year, then consider the rules from Atomicorp. They also offer a 90-day-delayed ruleset for free. Then again, if you're hands-on, then run with OWASP's open source Core Rule Set (CRS):
We'll drive stick here and run with the CRS which provides these, and more, securities:
- Protection from web attacks and, one hopes, zero days
- Trojan detection to curtail rootkits and backdoors
- Automation detection to cull bots and similar miscreants
- Errors hiding to help prevent information leaks
- HTTP protection to help secure the web server
The latest CRS files can be found here, along with others to verify integrity. With the latest version swapped as follows, change to a download folder, and grab the rules:
Having verified the file, it needs unzipping which, for the .gz format, goes like this:
Move into the new folder and become acquainted with its decompressed content:
Among other things, there's a README, so do. There's also an example config.conf that we need, along with base_, experimental_ and optional_rules. What rules you use comes down to a compromise between a tight firewall and not breaking your sites. We'll consider that in more detail soon but, for this example, we'll just use the base_rules.
We'll move the required files into the /etc/apache2 folder now. Let's create a spot and, changing its name, copy over the main conf file along with the base_rules:
We'll echo Apache to keep it in the loop about the new configuration files:
Enabling CRS and logging
Take a good look at that main configuration file. After all, it's your new best friend J.
Close to the top, you'll see this #commented line:
The SecRuleEngine variable tells ModSecurity what to do with the rules. By default, it won't do anything but, by removing the comment, the DetectionOnly value puts ModSecurity into testing mode. Once we've enabled the logs, that's great for us to have a play and see what, if anything, breaks on our sites – such as plugins or wp-admin features – before sending the CRS live by losing the #comment and swapping the value for On:
The final alternative, by the way – Off – means just that.
You can specify variables in any of the rule configuration files, overriding the main file. What's more, you can set your rules up on a per site basis by adding directives between the <VirtualHost> and </VirtualHost> tags in a virtual host file. I'll leave you to prep up on that lot at the MS Wiki which is linked previously.
It'd be a good idea to turn this thing on one day but, for now, uncomment the directive:
And append the file with these lines to turn on logging and debugging:
Tuning your ruleset
To test that it is working and properly logging, try hacking yourself (this won't do any damage, just edit the domain) …
… and check the logs …
Splendid. Now repeat that a few hundred times to test your site, to learn the rules, and come up with a ruleset that suits you. Tell you what, how about another GUI? AuditConsole is Christian Bockermann's marvellous java-powered logs viewer. Run it locally for the request history and to keep tabs on real-time events:
Rulesets and WordPress
You will inevitably encounter false positives, whereby innocent traffic is denied. This, of course, is better than false negatives, where malicious traffic is allowed and, as with any anti-malware solution, the trick is to fine-tune ModSecurity to filter appropriately.
With modular applications such as WordPress, where we introduce numerous scripts chiefly in the shape of plugins, a default ruleset often needs cajoling, depending on the complexity of your site. Some simple Google searches such as these will help your cause:
- site:wordpress.com/support modsecurity
- site:wordpress.com/support mod_security
- site:wordpress.com/support modsecurity [ “plugin name”]
Here are three rulesets coined just for WordPress. The final link is a configuration:
- MS ruleset from Pablumfication
- MS ruleset from Perfector
- MS ruleset on WebHostingDiscussion
- MS configuration at TopWebHosts
Bear in mind that rulesets and configurations should reflect your requirements. That said, hopefully this gives some pause for thought.
Don't just leave your rules set in stone because to do so is to ignore newly known threats. Register with your ruleset provider – and with alternative providers, for that matter – to receive news and, when there are updates, consider them carefully.
Don't say I don't care! There's lots to learn after all so, lucky you, here's more help:
And that's a wrap on ModSecurity. If you've got any tips to add to this WAF guide, please, drop by the forum and let me know …