Jump to content
MDDHosting Forums

WordPress Brute Force attacks and wp-login.php. If you're running WordPress it's important that you view this topic.


Recommended Posts

Hello,

 

WordPress is used by millions of users around the world and, as such, it is a huge target for hackers/bots/spammers. With a clever Google search string one can locate well over 125,000 individual sites that contain "wp-login.php" in their URL. There is, unfortunately, a rather large botnet that is brute-forcing sites running WordPress with an exposed wp-login.php. This botnet is large enough and attacking enough sites that it can and has affected performance on our servers requiring us to take direct and immediate action.

 

As an example of an attack hitting numerous users one of our servers and us having to take action you can view these graphs:

http://www.screen-shot.net/2014-03-08_08-55-15.png

http://www.screen-shot.net/2014-02-28_14-09-27.png

 

As you can see from the graphs the attack comes on very quickly and causes Idle CPU to plummet and Load to skyrocket. The important thing to keep in mind here is that there is no one particular server or customer that is under attack and that this botnet is simply attacking any and all instances of WordPress that it can find. Another interesting fact is that this botnet has enough compromised systems that it can perform thousands of attempts to a single site without ever repeating an IP more than once making most WordPress brute-force/login failure count scripts ineffective at stopping this attack.

 

About the only thing we've found effective short of limiting access to the wp-login.php script by IP is the "Rename wp-login.php" plugin.

 

This plugin is available directly from the WordPress plugin library via Dashboard -> Plugins -> Add New -> Search for "Rename wp-login.php" or can be downloaded to install manually at http://wordpress.org/plugins/rename-wp-login/.

 

We strongly advise you take a full backup of your database and/or your cPanel account prior to installing or configuring either of these plugins just in case. It is possible if you're running an outdated version of WordPress, outdated plugins, or outdated themes that you could run into issues.

 

Once the "Rename wp-login.php" plugin is installed you can change the "wp-login.php" to anything you'd like without interfering with site functionality at all via the Settings -> Permalinks options:

http://www.screen-shot.net/2014-03-08_09-16-29.png

 

The option looks like this:

http://www.screen-shot.net/2014-03-08_09-17-16.png

 

In my case I simply changed it to "login-wp" but it really doesn't matter what you change it to as your wp-admin will redirect there automatically just as it would normaly do with the default wp-login.php.

 

We strongly advise you take a full backup of your database and/or your cPanel account prior to installing or configuring either of these plugins just in case. It is possible if you're running an outdated version of WordPress, outdated plugins, or outdated themes that you could run into issues.

Link to comment
Share on other sites

The plugin Rename wp-login.php already disables login through wp-admin. If you visit that page without being already identified, it just shows an error message:

<body id="error-page">
	<p>You must log in to access the admin area.</p></body>
</html>

And since I got conflicts when using it together with Better WP-Security hide-admin, I ended up only using Rename wp-login.php for that. Is also important to configure the cache plugin as explained, if you're using one.

Link to comment
Share on other sites

Is this a different vector of attack that what we saw last year around this time? Curious if the customers you saw being hit were using CloudFlare, if not that may be an option since they are actively protecting against bot based brute force attacks against Wordpress.

I can't speak as to whether it's a different vector - I would assume not. Users could certainly use CloudFlare if they wanted but the option I'm presenting will work whether CloudFlare is in use or not.

 

Is using Google Authenticator as effective? Its what I currently use. Betterwp just slows down wordpress signficantly.

I couldn't say, I honestly do not know. I do very little webmastering :).

 

The plugin Rename wp-login.php already disables login through wp-admin. If you visit that page without being already identified, it just shows an error message:

<body id="error-page">
	<p>You must log in to access the admin area.</p></body>
</html>

And since I got conflicts when using it together with Better WP-Security hide-admin, I ended up only using Rename wp-login.php for that. Is also important to configure the cache plugin as explained, if you're using one.

Good to know - I'll update the original post.

Link to comment
Share on other sites

Hi,

 

Is using Google Authenticator as effective? Its what I currently use. Betterwp just slows down wordpress signficantly.

 

Google Authenticator will help with the security aspect (e.g. the brute-force attack will be unsuccessful), but you will most probably still experience the increased CPU load :|

 

 

Take care,

Alex

Link to comment
Share on other sites

Hi Michael,

 

I was wondering if you recommended using a plugin like Bullet Proof Security or OSE Firewall or another solution you like better to further fend off attacks. I already use .htaccess to protect certain files & redirect the stupider of bots for all of my clients. But, if the addition of a security plugin is beneficial and gives a greater level of protection... I am willing to deal with the initial setup headaches (cough, cough... caching plugins).

 

I put the code I use below in case anyone else needs it. I'm sure it could be far more robust, so any additions are welcome.

# Protect php.ini
<Files php.ini>
order allow,deny
deny from all
</Files>
# protect .htaccess
<files .htaccess>
Order Allow,deny
deny from all
</files>
# protect wpconfig.php
<files wp-config.php>
order allow,deny
deny from all
</files>
#Redirect Spambots to referring URL
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .81ah81ah.php
RewriteCond %{HTTP_REFERER} !yourwebsite.com [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://%{REMOTE_ADDR}/$ [R=301,L]

Thanks,

Link to comment
Share on other sites

I use in my .htaccess the following and works great. Saves a LOT of junk traffic from bots. Also if you block those with .htaccess their hits do not count as traffic .....

 

https://github.com/bluedragonz/bad-bot-blocker/blob/master/.htaccess

 

Problem with that approach is Litespeed doesn't support SetEnv directives. (I had an old ticket on that issue with a link provided to doc's, but evidently old tickets aren't kept around here.) I use RewriteRules to achieve the same result.

Link to comment
Share on other sites

 

Problem with that approach is Litespeed doesn't support SetEnv directives. (I had an old ticket on that issue with a link provided to doc's, but evidently old tickets aren't kept around here.) I use RewriteRules to achieve the same result.

 

You are right and thanks for the tip. When i moved here, i left the code at it is and apparently it doesn't work.

 

Just replaced it with rewrite code for all bots from here:

 

Ultimate htaccess Blacklist | Perishable Press

 

is that any good list ?

 

Also i see a small performance drop after that. Maybe it is my eyes only.

Link to comment
Share on other sites

 

Problem with that approach is Litespeed doesn't support SetEnv directives. (I had an old ticket on that issue with a link provided to doc's, but evidently old tickets aren't kept around here.) I use RewriteRules to achieve the same result.

We had something like 27,000 tickets stored - archived the old ones and dropped them from the database to keep the support system speedy :).

 

We're moving MDDHosting to a SSD-based server which will help with larger MySQL tables, just not done yet.

Link to comment
Share on other sites

  • 3 weeks later...
  • 3 weeks later...
  • 3 weeks later...

Michael,

 

I am presently using Wordfence - operational overview of sorts presented here: https://www.wordfence.com/docs/enhancing-wordpress-security/

 

I am not a "Premium" subscriber, but even the core has brute force login protection. Are you aware of this plugin? Do you find its capabilities sufficient in thwarting a brute force login attack? Otherwise, I will see if the "rename-wp-login" plugin works with my theme framework and doesn't bork anything out.

Link to comment
Share on other sites

The problem with that plugin is the same as all the rest that don't actually hide the wp-login.php.

 

If I have 1 IP hitting your wp-login 1000 times WordFence will stop it. If I have 1000 IPs hitting your wp-login.php once each - generally most plugins will do nothing about this. The only way WordFence could do anything about it is if it detected XX amount of login attempts per minute and then simply disabled logging in but the larger problem is detecting it and then rejecting them still uses CPU power and hits the MySQL database so it still causes issues.

 

Hopefully due to the prevalence of these attacks WordPress will, at some time in the near future, build in the option to rename wp-login.php.

Link to comment
Share on other sites

The problem with that plugin is the same as all the rest that don't actually hide the wp-login.php.

 

If I have 1 IP hitting your wp-login 1000 times WordFence will stop it. If I have 1000 IPs hitting your wp-login.php once each - generally most plugins will do nothing about this. The only way WordFence could do anything about it is if it detected XX amount of login attempts per minute and then simply disabled logging in but the larger problem is detecting it and then rejecting them still uses CPU power and hits the MySQL database so it still causes issues.

 

Hopefully due to the prevalence of these attacks WordPress will, at some time in the near future, build in the option to rename wp-login.php.

 

Okay. I will also communicate this to Wordfence. I was pretty sure this would be your response, Michael, as I didn't see any way for Wordfence to shunt the traffic which is the bigger issue for you as the hosting company. I was just hoping you might have a deeper understanding of how it works and that there was a mechanism within it to deal with these attacks that I wasn't seeing. I will certainly keep using it because it does a lot of other good things, but will ask that they consider the wp-login renaming as an additional feature they could work into the mix. Plugin bloat is becoming a real concern.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...