Uninstall ModSecurity & WordPress Challenges

Ok, as simple as a post as this might appear I recently undertook an effort to install and configure ModSecurity on my little server. In the process I quickly learned a number of things, specifically that I needed to uninstall from my production box and push it over to a staging box.

I’m not a system administrator and quickly learned that sometimes its good to follow your own advise, don’t get crazy with changes on a production box without testing on a staging box.

Perhaps its my lack of knowledge, but for some reason I had the hardest time uninstalling ModSecurity. I looked high and right and all I could find are ways to disable ModSecurity on an application via .htaccess or modify the scanner by editing httpd.conf. Neither were things I wanted to do. So how the heck do I get this thing off my box?

That’s when I realized that I had used the yellowdog updater modifier (YUM) to install ModSecurity. This led me to think, well, if I was able to use this:

# yum install mod_security

Then, surely, I could use:

# yum uninstall mod_security

Hahah. I was wrong. Instead, after looking up the MAN page, I realized that while they didn’t have an uninstall option they did have an erase one.

So I gave it a try:

# yum erase mod_security

Boom!!! It worked!!! To think that all the while, this is all I wanted to do and I spent hours trying to remove the module from Apache. Again, likely just a sign of how junior my sys admin skills are.

FYI, be sure to restart Apache:

# service httpd restart

WordPress Challenges

If you’re wondering why I decided to remove it, rest assured that it wasn’t because of its usefulness or applicability to what I was trying to accomplish. No, it was mainly because of its conflicts with WordPress. I realized I needed to spend a little more time testing.

If you tried visiting this site yesterday you would know what I’m talking about. The biggest challenges included:

• AJAX conflicts
• Access issues in wp-admin – Posts, Pages, Plugins, etc..
• Permission issues to theme and style sheets
• Performance challenges

I did get good advice from folks, the most notable was the addition of this:

## WordPress

SecRuleRemoveById 300015 300016 300017

SecRule REQUEST_URI "/wp-comments-post.php" phase:1,nolog,allow,ctl:ruleEngine=Off
#
#SecRuleRemoveById 300015 300016 300017
#


SecRuleRemoveById 300015 300016 300017


SecRuleRemoveById 300015 300016 300017
SecRuleRemoveById 300013


SecRuleRemoveById 300015 300016 300017

Based on what I was reading on these threads it seemed to work for most: http://wordpress.org/support/topic/mod_security-for-wordpress and http://wordpress.org/support/topic/disable-mod-security.

The biggest challenge with this however, for me, was the use of the Rule ID’s, depending on what rules you configure your install with you’ll likely need to update, but first you’ll want to know what each rule is. That’s where I think the key is, what are these rules and why are they causing issues.

An easy option for me, or so I thought, was to try and whitelist my IP in the whitelist.conf, I tried that and it worked like a charm for me but then it started to impact my visitors, specifically introducing permission issues killing my theme. I actually didn’t realize it until it was reported to me because my IP had been whitelisted. Yes, bone head move.

Regardless, I decided it was time to take a better approach. Get things working seamlessly on a staging box, then come back to my production box and give it another whirl. And that’s what I’ll be doing in the coming week.

I want to better understand what is causing the conflicts and see if I can’t put a more comprehensive post on the specific issues and potential mitigation steps. If you’ve had issues and have figured out work-arounds and how tos I’d love to hear from you. Even if you had issues and never got a workaround working, would love to hear that too.

Cheers!