How to prevent and restrict brute force login attacks in WordPress? Yesterday was just a regular Sunday for me, until it wasn’t. I woke up to a bunch of emails in my inbox about numerous too many failed login attempts. I quickly got into my WordPress, trying to figure out what was going on. And before I could wrap my head around the whole situation, I received two more similar notifications.
Panicked and never-experienced-this-before, I calmly told myself that, at least, I can still get in. However, I also became anxious about what to do if this happens in the future?
Like anyone, I rummaged through the internet and found the answers I was looking for. Turns out, it’s actually quite easy to secure your login from brute force attacks.
Although, before I discuss what to do at the minimum, let me go over the types of logins possible in WordPress.
Types of Logins/Gateways in WordPress
There are two types of WordPress Logins, through which, users can gain access.
- WP Login (the regular one): This is what most of us are used to. To login via this method, you just have to go to the URL of either–>website.com/wp-admin, or website.com/wp-login.php.
- XMLRPC: This type of login is reserved for remote access. Either through the WordPress app on your phone, or other methods, by which you can remotely publish blogs. While a great feature for those who really need it, it makes your site more vulnerable to attacks; which is exactly what happened with mine! Most of my login attempts were made with XMLRPC.
You May Also Want to Check Out:
Now that you know of both possible logins, let’s dive into the minimum number of things/items you should execute on, to prevent brute force login attempts in WordPress.
Item 1: Disable XMLRPC
If you hadn’t guessed already, this became my top priority. Disabling XMLRPC is the first most basic step anyone can take to prevent brute force login attempts in WordPress.
An argument can be made for remote access, but the question I’d ask you is this. Would you risk a brute force attack over deactivating XMLRPC?
In any event, to disallow logins via XMLRPC, you can use one of the top recommended plugin out there (there are others too), or you can write the following code (below), at the very end of your .htaccess file.
I chose to go with the .htaccess route. I always try to prevent using plugins, unless I really have to. Also, like the plugin, you can make accommodations for allowing specific IP addresses that can still get into the site via XMLRPC. This post goes over it.
How to Ensure That XMLRPC Is Indeed Disabled?
It’s one thing to disable XMLRPC, but it’s another to ensure that.
There are two methods through which you can check (I’d recommend both).
Method 1: Plugging In Your Site URL on https://xmlrpc.eritreo.it/
This is as simple as it sounds. Once disabled, plug in your site URL here. You should get some type of error message if you did it right. Otherwise, the tool will proceed to the next step. For instance, look at the screenshot below for my site.
Method 2: Verifying Using the WordPress App
- Here, you’d try to log into your site by site address method.
- Then, enter your domain name or your homepage.
- If done correctly, you’ll get an error message along the lines of XMLRPC can’t be accessed. See what I get for my site below. It matches the 403 I get on https://xmlrpc.eritreo.it/.
Item 2: Hide Your “WP Login” URL
Hiding your WP Login URL, in my opinion, is one of the best defenses. As discussed above, a typical WP login is something like website.com/wp-admin, website.com/wp-login.php.
What clever brute force attackers do is that they randomly append the typical WP Login URLs to a website. If it turns out that the website indeed is using WordPress, that URL will work, and then they move on to make login attempts.
The best antidote here is to devoid the hackers from the satisfaction. Using the “WPS Hide Login” plugin will help you achieve exactly that! See the screenshot that follows.
One additional setting here would be to redirect users/bots to a 404 page when they do encounter or go to the 2 WP Default Login URLs. This option is available right underneath the “Login url” setting.
Item 3: Limit Login Attempts
Brute force login attacks are typically automated where bots try to guess the username and password. They use multiple combinations of the same, until they get it right. Usually, they start with obvious credentials like “admin” for the username, or “password” for the password.
What’s also usual is the number of tries someone gets. I believe it is an expected norm to at least allow 3 tries. After 3 attempts, there is a lockout or time restriction on when someone with that same username can try again.
Naturally, the question that comes to mind is, what if you wanted to reduce that? The answer is yes, you can, by using the “Limit Login Attempts Reloaded” plugin, or similar.
I’ve gone crazy with it and put in super strict restrictions (screenshot to follow) because I have a secondary way of logging into my WP account.
I have the following configurations:
- Someone gets 2 tries to log-in.
- Upon failure, they get locked out for 9,999 minutes.
- One lockout increases their lockout time to 9,999 hours. In light of this, the second point above becomes moot.
- They’ll have to wait for the same number of hours until they can retry.
As said, I wouldn’t recommend you to follow the same settings; however, if you have another way in, go for it!
Lastly, if you’re concerned about accidentally locking yourself out, you can always add your username in the “whitelist.” You can do the same for other folks who might have access.
For now, I am pretty happy with the extra security steps that I’ve taken. And luckily, I haven’t had any more brute force attacks.
But, be that as it may, one additional item I am going to look into is enabling two-factor authentication. Online, there are some high praises about Wordfence plugin; so, I’ll check that out too. Although, in all likelihood, I may not install it as I don’t prefer to add any more plugins that I need.
At any rate, if you were also wondering how to prevent and restrict brute force login attacks in WordPress, I hope this post helps!
Note: For all intents and purposes of this blog, let’s assume that XMLRPC = XML-RPC