global .htaccess-protection of wp-login, automatic rewrite when adding new domains?

[torsteino]

Hi,
I want to use htaccess to protect wp-login from those annoying bruteforce attacks, something like this - /http://halfelf.org/2013/wp-login-protection-htaccess/

however - it would be really nice if the htaccess-file could be updated automatically when adding new domains in cpanel/whm. Is there any smart/easy/standard way to do this?

Or maybe it is possible to only allow the "current" domain as referrer, so that the htaccess-file doesn't need to be updated for each new domain at all?

 

[cPanelMichael]

Hello

While it's possible to develop a custom script to automatically update a file, the easier solution may be to use custom Mod_Security rules since you have root access to your system. The same website you referenced also offers Mod_Security rules for blocking this type of attack.

Thank you.

 

[torsteino]

Hi, thanks for the answer!

Yes, I'm already using this - /http://halfelf.org/2013/wp-login-protection-modsec/ . But that one still let the villains try a few times, and really - the cpu-time they use is more annoying than the chance that they will actually guess my passwords.

So the ideal solution would be something like what he does in that .htaccess-file, but working globally, and preferrably, without needing to add each and every domain I want to allow. Something like only allowing the "current" domain to use "their" copy of wp-login and wp-comments-post.

 

[quizknows]

Mika is a she

Anyway, that first post basically checks to make sure the wp-login post request has a valid referrer of the correct domain. A lot of the attacks lack a referrer completely. If they have one, it's the right domain, so really, I just check to see if there even is one. The same thing can be done with modsecurity, however, most bots have already adapted to that and started using valid referring URL's anyway. The rule you're using (that locks after 10 tries) is "good enough."

That said, if you want to drop any wp-login request with no referrer which will basically have the same effect as what you linked in your first post, use this:

#Block WP logins with no referring URL
SecRule REQUEST_URI "/wp-login.php" "deny,status:401,id:5000130,chain,msg:'wp-login request blocked, no referer'"
SecRule REQUEST_METHOD "POST"  "chain"
SecRule &HTTP_REFERER "@eq 0"

This won't hurt anything, and it's recommended anyway, but it doesn't filter nearly as much traffic as it used to thanks to being a widely known solution at this point.

What I personally do is disallow any login that tries 'admin' as the username. Sadly, that won't work if your users are using the default admin username. If they aren't, that's also an easy modsec rule to add, and will drop 90% or more of all brute force traffic.

#Deny 'admin' as WP login. Do not use 'admin' as the admin username or you will be unable to log in.
SecRule REQUEST_URI "/wp-login.php"  "deny,status:401,id:5000131,chain,msg:'wp-login request blocked, default user admin disallowed'"
SecRule REQUEST_METHOD "POST" "chain"
SecRule REQUEST_BODY "^log=admin&" "t:lowercase"

 

[cowboymike]

Quizknows,

I have 2 personal wordpress websites on the same server and I have removed the username 'admin' for both accounts. Would the code you posted go in the .htaccess file for each website? In the .htaccess files for each I also have the 2013 5G Blacklist found here: 5G Blacklist 2013 | Perishable Press

Thanks, mike

 

[quizknows]

Quizknows,

I have 2 personal wordpress websites on the same server and I have removed the username 'admin' for both accounts. Would the code you posted go in the .htaccess file for each website? In the .htaccess files for each I also have the 2013 5G Blacklist found here: 5G Blacklist 2013 | Perishable Press

Thanks, mike

The code I provided normally needs to go in the modsecurity configuration. While newer versions of modsec support some .htaccess directives, I usually do not use them. I'm not sure if these rules would work in .htaccess, but you could try it.

If you added the rule(s) to /usr/local/apache/conf/modsec2.user.conf they would affect every domain on the server. This is what I do on my personal servers, since no wp accounts use "admin" as admin. The first rule (drop logins with no referrer) is always safe server-wide.

You should be able to add the rule(s) to domain specific includes files in the /usr/local/apache/conf/userdata directory (i.e. /usr/local/apache/conf/userdata/std/2/USERNAME/DOMAIN.CONF/your_custom.conf

After creating the custom conf files you'd want to run /scripts/rebuildhttpdconf and restart apache.

If you did that for more than one domain you'd have to increment or change the numeric ID's of the rules; each modsec rule needs its own unique ID.