ModSecurity is a great tool to help prevent certain attacks on websites but, sometimes, the included rules can be a bit restrictive. There are ways to disable ModSecurity or to deactivate it on certain websites, but turning it off is like throwing out the baby with the bathwater. Better to find out which specific rules are causing problems, and then disabling those for specific web-pages.
Checking your system logs is the first place to look to solve your specific issue.
At first glance, this may look confusing but it’s a concise log of what went wrong (or right, depending on your perspective). Breaking it down, we get:
This tells us that ModSecurity blocked access and a 501 error was sent to the browser instead. The “Pattern match” code that follows tells us what the acces fell foul of.
This line tells us that the intercept triggered rule ID 950006 which is at line 135 of your modsec.user.conf file.
In your log “www.domain.tld” will show the hostname of the website that was being accessed at the time (useful if you run more than one site on your server). And, finally, the “uri” tells us which page/script was being called at the time.
If you feel that this rule is too restrictive and you need to allow access to what that script was doing, you should add an exception to your whitelist.
First, locate your whitelist on your server. It may be somewhere like this:
You can either edit that file in a terminal, or download it via SFTP and reupload after altering it.
You would add lines similar to the following to the end of your whitelist.conf file:
# 950006 throws 401 error when modifying custom css file
<LocationMatch “/wp-admin/theme-editor.php”>
SecRuleRemoveById 950006
</LocationMatch>
The “LocationMatch” line should be the path to the file that needs the exception. The SecRuleRemoveById line needs to be the rule ID number.
After you’ve saved your whitelist, or re-uploaded it, remember to restart Apache.
Job done!
