Apache mod_security, WordPress, and randomly truncated posts

Occasionally, a managed Apache web server will come with odd mod_security rules that result in WordPress posts being truncated, seemingly randomly. I suspect it is also specific to servers using cPanel/Web Host Manager. This happened a couple times in the CoPress days and started happening again recently for Jonathan Morgan, a PhD student at MSU. While I haven’t confirmed this solves the problem for Jonathan, this approach did solve the problem for us. I’m posting it here for future reference because it was a beast to track down.

To figure out which rule ID is being triggered, run the following command:

tail /usr/local/apache/logs/modsec_audit.log

This will return something like:

--97a7c73b-H-- 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:content. [file "/usr/local/apache/conf/modsec2.user.conf"] [line"355"] [id "300016"] [rev "2"] [msg "Generic SQL injection protection"][severity "CRITICAL"] Action: Intercepted (phase 2) Stopwatch:1233185129379248 482649 (109716* 122107 -) Producer: ModSecurity forApache/2.5.7 (http://www.modsecurity.org/). Server: Apache/2.0.63 (Unix)mod_ssl/2.0.63 OpenSSL/0.9.8b mod_auth_passthrough/2.1 mod_bwlimited/1.4FrontPage/5.0.2.2635 PHP/5.2.6

[id “300016”] is what you need and refers to the rule to disable. Create a .conf file at the following location to be complaint with cPanel (note the directories past “conf” did not previously exist):

/usr/local/apache/conf/userdata/std/<user>/<domain>.com/<whatevernameyouwant>.conf

Inside this file place the following:

<LocationMatch "/">
SecRuleRemoveById 300016 
</LocationMatch>

Add whatever cPanel scripts you need to make sure that it will accept the custom vhost entry and that the new entry will be persistent through various apache reconfigurations/recompiles.

Restart Apache:

/etc/init.d/httpd restart

Thanks to the fabulous folks at LiquidWeb who originally helped us with the solution.

Leave a Reply