Never a panacea: ModSecurity drawbacks

I’ve written before of using ModSecurity for reducing bots traffic, especially for those bots that are not important to the success of a site, like almost all of the so-called “marketing bots”. Unfortunately, installing and setting up ModSecurity with the defaults parameter can cause quite a bit of headaches, especially for technically-oriented applications.

There are indeed quite a few different drawbacks to the use of that module, in particular related to the Core Rule Set that ships with it; some of the rules are quite taxing to the web server (since it has to parse eventually a lot of data), and others are simply hitting false positives quite easily.

For instance, the rule with id 960017 (Host header is a numeric IP address) while very valid usually breaks for the Nagios HTTP check, while the very draconian 950005 will stop any application to receive posts that talks about most Unix paths, including /etc. Luckily enough, mod_security does have means to handle whitelisting from rules with multiple methods: you can use rules that hit on user-agent (bad idea for whitelisting) or source IP (better), or you can use Apache environments.

For instance, my Typo instance has the following entry in its vhost definition to apply both my antispam rules and exclude the draconian rule:

Include /etc/apache2/vhosts.d/modsec_antispam.include
SecRuleRemoveById 950005

(Yes there are a few things that still needs to be cleared up, especially regarding the trackbacks that should probably have different antispam rules from the comments; in particular, trackbacks probably shouldn’t arrive from browsers at all).

So unfortunately, before modsec can be set up as standard piece of software for Apache servers, time has to pass…

Leave a Reply

Your email address will not be published. Required fields are marked *