Mod_security2 is an Apache2 module which blocks requests to the web server based on a list of server-side rules, also known as a Web Application Firewall (WAF). Rules include blocks against common server attacks, and they filter requests to vulnerable software. This additional security feature is activated by default on our servers in order to provide maximum protection from hacker attacks for the websites of our customers. However, it is possible for certain legitimate requests/scripts to match a rule and be blocked. When this happens, the error message returned by the server is 412 Request Blocked (Precondition failed). You can disable certain blocking rules, or completely disable mod_security2, by using an .htaccess file.
Disabling mod_security2 for XML-RPC files
The XML-RPC protocol is used by some WordPress modules to communicate with external resources, most notably - the Jetpack plugin and the official WordPress mobile apps. All Jetpack IP addresses are whitelisted on our servers, so you do not need to disable mod_security2 to use the Jetpack plugin. To read more on how to allow access to this file through the WordPress Manager in the Control Panel, please check our Enabling access to XML-RPC article.
If your website is using an xmlrpc.php file, but it is not WordPress-based, you can still disable mod_security2 for it with an .htaccess file – it should contain the following piece of code:
The .htaccess file can be easily created using the File Manager in the hosting Control Panel. The settings in this file apply to the directory in which it is located and recursively to its subdirectories.
Finding which mod_security2 rule triggers error 412
If you encounter an error 412 when browsing a specific page, you can easily find which mod_security2 rule triggers the error by inspecting the server error logs for your website. Here is how to do this:
- Navigate to the hosting Control Panel > Logs section > Live HTTP logs subsection.
- Allow about a minute for the Live HTTP logs subsection to start displaying the logs in near real time.
- Open the page of your website where you get the 412 error.
- Check the Error log screen from the Live HTTP logs subsection, where you should find an entry like this one:
example.com [Fri Aug 13 14:46:30 2021] [error] [pid 9179] apache2_util.c(273): [client YOUR_IP_ADDRESS:59893] [client YOUR_IP_ADDRESS] ModSecurity: Access denied with code 412 (phase 2). Match of "ipMatchFromFile /apache/conf/includes/mod-security-jetpack-ip-whitelist.txt" against "REMOTE_ADDR" required. [file "/apache/conf/includes/mod_security2.conf"] [line "42"] [id "114"] [hostname "example.com"] [uri "/xmlrpc.php"] [unique_id "YRZblp0P33pV7fcztwccfAAAAQE"]
The exact mod_security2 rule and file that trigger the error will be listed in the id and uri fields in the error message. The Match part of the mod_security2 message will contain more information about the triggered security rule. In the given example, access to the xmlrpc.php file was blocked by the mod_security2 rule with id 114 as access to the file is allowed only from JetPack IP addresses.
Disabling a specific rule
By default, a number of abusive bots are blocked from visiting customer websites with specific mod_security2 rules. These are the currently blocked bots, as well as their mod_security2 IDs:
"^Mozilla\/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1;?( SV1)?;?\)$" id:373
"^Mozilla\/3\.0 \(compatible; Indy Library\)$" id:392
If you need to allow any of the above bots to access your website, you can disable the specific mod_security2 rule with an .htaccess file in the main folder of your website. Just use the SecRuleRemoveById directive followed by the ID of the specific rule. For example, to allow access to your website from the DotBot bot (which is blocked in mod_security2 with rule ID 410), you should add this code to your website's .htaccess file:
Disabling mod_security2 altogether
|Completely disabling the mod_security2 module would decrease the security of your website considerably, so we strongly advise against doing that. Instead, follow the steps above to check the logs and find which mod_security2 rule blocks the execution of your script, then disable the specific rule.|
If you are certain about disabling the mod_security2 module, you can create an .htaccess file (or edit the existing one) in the directory where you want to disable it. The file should contain the following piece of code: