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.
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!