After my initial post about wordpress and mod_security, I decided to have a bit more of a look around to find what rules other people had needed to disable to get it working.

I found a really good post over at – Mod security and wordpress the final config which had a few additional rules mentioned, but did not solve the problems I was having initially. So I thought I would draw on what they had posted and what I have learnt to produce a fully working list of rules that need to be disabled in order for WordPress 2.9.1 and mod_security Core Rules 2.0.3 to work together.

Below follows an example vhost file the important elements of it being the LocationMatch tags containing the SecRuleRemovedById.

<VirtualHost *:80>

    DocumentRoot /var/www/
    <Directory />
        Options +FollowSymLinks
        AllowOverride FileInfo

    <LocationMatch "/>
        SecRuleRemoveById 910006 # Google robot activity - Useful in someways but noisy for sites where you want them crawled
        SecRuleRemoveById 960015 # Request Missing an Accept Header -  Allow for Google Reader

    <LocationMatch "/wp-includes/">
        SecRuleRemoveById 960010 # Request content type is not allowed by policy - Allows for amongst other things spell check to work on admin area
        SecRuleRemoveById 960012 # Require Content-Length to be provided with every POST request - Same as above

    <LocationMatch "(/wp-admin/|/wp-login.php)">    
        SecRuleRemoveById 950005 # Remote File Access Attempt - This rule probably doesn't need to be disabled by everyone but it stops me putting /etc/ in posts and other such linux paths.
        SecRuleRemoveById 950117 # Remote File Inclusion Attack - Disable to allow http:// to be passed in args

    <LocationMatch "(/wp-admin/post.php|/wp-admin/options.php|/wp-admin/theme-editor.php|/wp-includes/)">
        SecRuleRemoveById 950006 # System Command Injection - Another rule that probably doesn't need to be disabled by everyone it stops .exe and various other extensions being passed in args.
Share this post


  1. Hi This helped me a lot.

    Because I’m on cPanel I moved the whitelist.conf which I had built for modsecurity2 which handles globally, into the cpanel vhosts template area (which is different depending on your apache build)

    cPanel builds the httpd.conf file up from external includes. So you have to use an external include .conf file put in the right place. Look in the httpd.conf file for exactly which directory to put it in.

    In the end this was my whitelist.conf file

    SecRuleRemoveById 300016

    SecRuleRemoveById 300016

    And now it’s being run for just one user account that for some reason had trouble with modsecurity2.


Leave a Reply

CAPTCHA (required) Time limit is exhausted. Please reload CAPTCHA.