Stop Brute force attacks on wp-login.php xmlrpc.php

I have not been very happy for the last couple of days every second there have been ‘brute’ force login attempts into my cloud server WordPress site.  So I am going to put down a few words about how I dealt with it and how to deter or stop brute force attacks on wp-login.php xmlrpc.php.

And 643 was a low estimate I think before I actually managed to block them.

Anyways back to the situation for about 48 hours I was receiving 1 or 2 attempts every second to access wp-login via xmlrpc, I only noticed after about 24 hours when I started investigating why my server had ground to a halt.  I tail -f ‘d the access log (it was too big to do anything else with!) and saw it full of this

Ignore the 401 errors for the moment they were only there after I took action there were 301 redirects prior to that.  The main issue I had that WordFence couldn’t help me with is that after 5 login attempts another IP would come along and do another 5 login’s.

I tried lots of things first I tried to disallow the IP’s that were trying but they seemed to be limitless so I did a bit of digging around and one of the solutions was to put password authorisation on the wp-login file.

This was actually a good solution for me because my logins are handled by the theme and a plugin so I don’t need this for day to day use, however it will cause me a problem when accessing by mobile I believe but I just wanted to get rid of the hackers and then I can start switching things back on.

So I added this in my .htaccess file in the web root directory

Doing this meant I also had to create a .htpasswd file using http://www.htaccesstools.com/htpasswd-generator/ in the corresponding AuthUserFile location.  One other thing of note here too in order to get this to work I had to AllowOverRide a couple of options in my virtual host configuration.

Once I did this I got some of my server resources back and the hackers started getting 401 Unauthorized errors on the call to wp-login – however there was still an issue.

They were still attempting 1 or 2 times every second and the xmlrpc was still allowing them to contact it and provide a 301 redirect which again looked like it was using resources.  So whereas disabling the wp-login didn’t really affect me – I know the xmlrpc would have more of a negative impact but I just wanted to get rid of them – so I took the same action on the xmlrpc

And that gave me a good feeling because I just knew they were wasting their time then as both xmlrpc and wp-login were now returning 401’s.

After about 2 hours they gave up, so I like to think I won the war!

There is a good post on WordFence regarding this exact same issue https://www.wordfence.com/blog/2015/10/should-you-disable-xml-rpc-on-wordpress/ and it explains it in more technical detail than I did.  Although the consensus seems to be generally you shouldn’t switch off xmlrpc, I was at the end of my tether and will probably switch it back on tomorrow when I know they have gone for sure!

I suppose the only upside to this is my Jetpack and GA stats have gone through the roof! Maybe a good time to start advertising 😉

UPDATE

The hackers have finally given up now they can’t get access to those two files any more, they have probably started bothering some other poor victim!  I still have those two files blocked and am probably going to keep them so.

I still have full functionality of my website and can log in and register users/sites etc.

As an added bonus I can still use WordPress on Android too which I was under the impression might stop working.

I will keep this post updated with any issues I encounter having those two files blocked with the method I have used.

 

Paul H

IT consultant with 20+ years experience specialising in Oracle Database, Oracle Business Intelligence, Web/Mobile development, Application Express development, cloud technology and more

Leave a Reply

Your email address will not be published. Required fields are marked *