Stop WordPress Login Brute Force Attacks

WordPress Brute Force Attacks

WordPress’ popularity not only attracts bloggers but also hackers. Hackers try to compromise
WordPress installations to send spam, setup phishing exploits or launch other attacks.

While there are many sophisticated attacks against WordPress, hackers often use a simple brute force
password attack. In these attacks, botnets try to guess your admin password.

You may think that such attacks would fail, but they exploit one of the weakest links in the security
chain: You.

People don’t like complex passwords. As a result, low security passwords get put into production.
Even if you have good password policies and use password management tools (personally I prefer
Keepass and/or Enpass), simple passwords slip through.

By adding an extra layer of security to your systems, you can stop WordPress brute force attacks.

Stop Attacks with HTTP AUTH

WordPress actually has a great list of WordPress hardening tips. Some of these are complex and
require server level or code level changes. However, in my experience brute-force and XSS attacks
against WordPress are common exploit tactics. Simply by blocking access to the login and admin
areas using HTTP Authentication, you can add an additional layer of security.

You are probably already familiar with HTTP AUTH. Many people refer to it simply as password
‘protecting a directory’ or site with .htaccess. Technically, when you add these directives to .htacess
you are enabling the HTTP authentication tools built into the Apache web server.

By setting up a htaccess to limit access to WordPress login functions, you can stop most brute force
attacks.

Setting up HTTP AUTH

I recommend limiting access to the wp-login.php page to stop WordPress brute force attacks.

You can do this easily by setting up htaccess password protection.

There are plenty of tutorials online about how to set up htaccess files and generate the password files.

Plesk, cPanel and other systems often have this built into their control panels. So I am going to assume
you know how to set up htaccess and setup a htpasswd file (if not Google is your friend).

Also, use different usernames and passwords for the htaccess and your blog !

Once you have your password file setup, you need to add the following to your htaccess file:

# Protect WordPress Login

AuthUserFile /path/to/my/password_file/.htpasswd
AuthName “Authorized Access Only”
AuthType Basic
Require valid-user
Order deny,allow
Deny from all
Allow from x.x.x.x
Allow from x.x.x.x

These settings will cause an additional HTTP pop-up before you login to WordPress.

In addition the ‘Order deny,allow’ directive denies ALL networks except those specially allowed via the
‘Allow from’ statements, in this case substitute ‘x.x.x.x’ with your specific IPs. You can add Ips or networks such as your home, office, and other trusted networks here. I’d recommend at least 3 in the event an IP changes at one location you have another route in. This sets up a very tight access control to even get that first HTTP AUTH prompt.

You will need to enter the username and password you setup in your htpasswd file to get passed this
box. Once you login to here, you will then see the normal WordPress login screen.

Note that the username and passwords used in your htaccess files have nothing to do with those used in
WordPress. If you have multiple bloggers, you could use a single username and password for the HTTP
Authentication phase and then have the bloggers use their own access details to log into WordPress.

How this Stops Brute Force Attacks

With the HTTP Authentication added, you block the attack. The POST request above will succeed only
if are on a allowed network IP or range and they then guess the HTTP AUTH username and password.
The chances of a maliscious hacker or botnet coming from trusted allowed IP networks you designate
are unlikely.

You may ask, “Well couldn’t they just try to brute force the HTTP AUTH?” Yes they can, but most
botnets are not setup to do this. Also, for these types of attacks, it would be more efficient for them just
to move on to another server then try to hack through two passwords. Additionally if the deny, allow
directive is also used, they must be on those specific trusted networks to begin with.

For more details, check out WordPress’s own Brute force attack section.

Why Not Use a Security Plugin?

There are many WordPress security plugins that attempt to automatically block such brute-force
attacks. Some of these are fantastic plugins. While these may work, I generally do not recommend them
unless they provide significant other benefits.

Here’s a few reasons why:

  • The plugins still rely on PHP code. The protection is only as good as the code.
  • Another installed plugin to maintain that could introduce other application layer vulnerabilities.
  • The brute force attack still executes through the PHP layer. Under high rates of attack, this can
    cause load issues.
  • The likelihood of an exploit occurring simultaneously Apache’s authentication methods and in
    WordPress is low.

If you implement HTTP Auth on your login page, you can basically block brute force attacks on
WordPress. While there are plenty of other security concerns, you will not have to fret about a
WordPress brute force attack