Mod_Security Broke My Wordpress!

I really want to say something rude, but I'm going to try to be constructive. My server auto-updated to WHM 11.40.1 last night, and I have been unable to login to ANY Wordpress site on my server since. After [COLOR="#FF0000">4 hours beating my head against a wall trying everything (you can read the whole saga here on Wordpress.org), I finally figured that the SERVER was blocking wp-login.php at every turn. I tried disabling plugins, tried the default theme, tried increasing PHP's memory, tried disabling .htaccess for that account, tried everything. I was only able to determine that something at the server level was causing problems after DELETING the wp-login.php file, resubmitting the cached form, and still getting a "." result rather than a 404. I went into Mod Security and found a page full of these reported entries:


2014-01-08	12:00:11	208.104.55.77	/wp-login.php HTTP/1.1	******.com	Access denied with code 402 (phase 2). Operator EQ matched 0 at ARGS. [file "/usr/local/apache/conf/modsec2.user.conf"> [line "1852"> [id "10124455">	402

2014-01-08	11:57:22	66.90.168.63	/wp-login.php HTTP/1.1	******.com	Access denied with code 402 (phase 2). Operator EQ matched 0 at ARGS. [file "/usr/local/apache/conf/modsec2.user.conf"> [line "1858"> [id "10124455">	402

After I commented out two following mod_security rules, I was immediately able to login to Wordpress again:

#Wordpress brute force signature, different variant  ~JoeB 2013-05-14
#Added valid actions to @pm part ~ArielP 2013-06-09
SecRule REQUEST_FILENAME "wp-login\.php" "phase:2,deny,log,status:402,t:lowercase,chain,id:10124454"
SecRule REQUEST_METHOD "^post$" chain,t:lowercase
SecRule &ARGS:wp-submit "@eq 0" chain,t:urlDecodeUni,t:lowercase
SecRule ARGS:action "!@pm logout lostpassword postpass register resetpass rp" t:urlDecodeUni,t:lowercase

#This is needed for the protection when action is not specificed during login
#Wordpress brute force signature, different variant part 2 ~JoeB 2013-05-14
SecRule REQUEST_FILENAME "wp-login\.php" "phase:2,deny,log,status:402,t:lowercase,chain,id:10124455"
SecRule REQUEST_METHOD "^post$" chain,t:lowercase
SecRule &ARGS:wp-submit "@eq 0" chain,t:urlDecodeUni,t:lowercase
SecRule &ARGS:action "@eq 0" t:urlDecodeUni,t:lowercase

[COLOR="#A0A0A0">Again, I'm trying to be constructive, but if you guys are going to force 2,000 lines of security rules on people, please make sure they don't break the innocent login of the #1 blog platform on the web. And maybe the first time a rule is tripped, an e-mail should be sent to the accountholder? Turns out these mod_security rules were added by my webhost. :( :(

cPanelMichael

January 08, 2014 16:39

Hello :) The rules you referenced are not added to the default Mod_Security rules that cPanel provides. Are you sure you are not using a set of third-party rules or have not entered custom rules manually? Note that you can find the default rules listed under "Default Configuration" in "WHM Main >> Plugins >> Mod Security". Thank you.

feldon27

January 08, 2014 16:54

Yep, through some sleuthing, I've confirmed that these were added by my webhost. :( Thank you for your patience with my rant.

quizknows

January 08, 2014 18:07

I've used a lot of modsec rules to stop WP brute force, but those ones don't really make that much sense to me. It looks like they're trying to avoid logins where "wp-submit" or "action" are null. Most of the brute force traffic I've analysed has these properly set anyway. Perhaps the rules are erroneous, out-dated, or your login method wasn't specifying those variables. They should audit those rules for functionality with the latest versions of WP (Assuming you're running the latest version). For what it's worth, I tested these rules with my WP installs of the latest version and they do not cause any problems. If you're running an out-dated version, that might explain it.

Mod_Security Broke My Wordpress!

Comments

Didn't find what you were looking for?