Improving WordPress Login Security – Revisted

In a previous article, I spoke of a method for restricting access to the WordPress login screen by directing requests for “wp-login.php” away to a standard WordPress 404 page.

Server Ethernet Ports
https://www.flickr.com/photos/jemimus/8469760647

Recently I came across a situation with one site that I manage, where an unrelated change meant that this was no longer working. Interestingly, on some sites I manage it still works, and on others it does not – despite the underlying configuration of the web host being no different.

I believe I do know why it stopped working on some sites – but I choose not to explain the reason at this time for security purposes.

To get the “non-working” sites to work again, the included configuration needed to replace the configuration construct with the following, using the “Require” directive instead:

<Location />        
  ErrorDocument 403 /idontthinksotim
</Location>
<Files .htaccess>
  Require all denied
</Files>
<Files wp-login.php>
  Require all denied
  Require ip aa.bb.cc.dd
</Files>


Refer to the previous article for complete understanding, but the “Require all denied” directive here is equivalent to the combination of “order deny,allow” and “deny from all” directives in the previous example. It basically says “by default, deny everyone from the file.”

Each allowed IP is then listed in sequence below that – in this example “Require ip aa.bb.cc.dd”. This of course will need to be the IP address you wish to allow access from, and as before, can also use CIDR notation to allow entire ranges of IP addresses.

Other than the use of the “Require” directives, the concept of this article remains the same as the previous, and once again, don’t assume your website is 100% protected if you do this. Hackers are clever people, and if they are determined they will find a way.

Basically, each version could and should work – but if you find you’ve tried one, and it doesn’t work – try the other!

Improving WordPress Login Security

WordPress is the most common CMS used by websites, recently topping 43% market share of all sites currently on the internet.

With such a significant presence, it is also the largest target for website hackers, and given that it is open-source, good and bad actors are always examining the code for vulnerabilities.

There are plenty of things you can do to tighten defences – the Wordfence plugin is an excellent start, that I highly recommend.

https://flickr.com/photos/136770128@N07/40492737110

Another thing you can do is restrict access to the “wp-login.php” script, based on IP address – however, note that this solution will only work if you have a fixed and known IP address from which you will be logging in to your site.

If you move around, you’re probably locking yourself out of your own website console unless you’re at the IP address we’ll use in the example below. The example below is specific to Apache web servers, but the same principle can be applied to other configurations.

Let’s say my IP address is “aa.bb.cc.dd”. Put the following in the virtual host configuration for your WordPress website, and you can now only log in to your website from that IP address. Your site is still completely visible to the internet, but even if someone has your username and password, that login will be denied – they won’t even get to the login page.

<Location />
  ErrorDocument 403 /idontthinksotim
</Location>
<Files wp-login.php>
  order deny,allow
  deny from all
  allow from aa.bb.cc.dd
</Files>

The “order deny,allow” command tells Apache that it should follow any “deny” command access to “wp-login.php” first. The “deny from all” command is the only example of that that we need here. The “allow from aa.bb.cc.dd” command allows only the specifically listed IP address to get to “wp-login.php”.

You can of course add multiple “allow from” commands, and if you understand CIDR notation, you can use that to specify ranges of IP addresses you might want to allow with a single entry.

The above code means every other IP address on the internet is denied access to “wp-login.php”, and causes a “403” error to be thrown. To make things nice and neat and pretty, I have redirected “403” errors to a URL that does not exist – so that visitors are greeted with a proper “404” page from your WordPress site, rather than the standard “403” Apache error screen.

One final note – there are lots of other ways for bad actors to compromise a website – this is just another potential tool in your bag of tricks to keep them out. Don’t assume your website is 100% protected if you do this. Hackers are clever people, and if they are determined they will find a way.