One of our clients called us today and told us that they were trying to save an Event in the DPCalendar extension, and they were getting an Internal Server Error. They said that the same problem was happening when they were trying to save a blog in EasyBlog.
From our experience, the majority of Internal Server Errors are caused by Apache’s mainstream security module, ModSecurity (an example of this can be found here).
So, the first thing that we did was that we checked the ModSecurity log file (which is the modsec_audit.log file located under the /usr/local/apache/logs folder) and we found the following errors:
Message: Access denied with code 500 (phase 2). Pattern match “(insert[[:space:]]+into.+values|select.*from.+[a-z|A-Z|0-9]|select.+from|bulk[[:space:]]+insert|union.+select|convert.+\\(.*from)” at ARGS:jform[description]. [file “/usr/local/apache/conf/modsec2.user.conf”] [line “371”] [id “300016“] [rev “2”] [msg “Generic SQL injection protection”] [severity “CRITICAL”]
Message: Rule 10ab6e8 [id “3000086“][file “/usr/local/apache/conf/modsec2/rootkits.conf”][line “155”] – Execution error – PCRE limits exceeded (-8): (null).
Aha! So, it was it was ModSecurity (Tweety?). We had 2 options, we either had to disable ModSecurity for everyone (we can’t just disable it for our client since they had a dynamic IP), or we had to address the problem differently. We chose the latter.
In order to solve the problem, we created a file called whitelist.conf under the /usr/local/apache/conf/modsec2 folder with the following content:
<LocationMatch "/administrator/index.php"> SecRuleRemoveById 300016 3000086 </LocationMatch>
(Note that the numbers in red are the same as above.)
We saved the file and restarted Apache, and the problem was solved!
But why was the problem solved?
It’s because in the file whiltelist.conf, we instructed ModSecurity not to enforce rules 300016 and 3000086, which were causing the problem.
But what about disabling ModSecurity altogether? Wouldn’t that solve the problem?
Yes – it would, but doing so will have some severe adverse effects when it comes to the website’s (and the server’s) security. We don’t really recommend doing this as ModSecurity is extremely efficient for filtering out malicious requests to the server. It is possible to disable ModSecurity at the .htaccess level or the (virtual) server level if you have a VPS or a dedicated server. However, if you are using a shared hosting solution, it might be that your host does not allow the disabling of the ModSecurity module. In the latter case, you have no other option but to try to talk to your host to make an exception for your website.
If you are running into Internal Server Errors when you are trying to add/edit something on your website, then most likely this is a ModSecurity issue. Just follow the above guide and you should be OK. If it doesn’t work for you or if you feel it’s a bit complicated, then please contact us – we’ll help you address the problem in no time and for a very affordable fee!