Mod_Security Broke My Wordpress!

[feldon27]

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 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 "[email protected] 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

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]

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]

Yep, through some sleuthing, I've confirmed that these were added by my webhost.

Thank you for your patience with my rant.

 

[quizknows]

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.