Securing the WordPress Login page

Of late I have seen quite a lot of brute force attempts to login into the admin account of this blog. The source IPs are wide and varied, ranging from Istanbul, Germany, Greece, US and more. In fact according to ArsTechnica article this has been happening for sometime now on a huge scale. I see a POST request on my site every few hours. Recently I submitted a list of such IPs to Deutsche Telekom Abuse Team for the offending IPs from their network.

Protection from the attack ArsTechnica suggested using

Limit Login and WP Better Security plugins. Limit Login is a simple and must have plugin. It blocks an IP for some hours our repeated failure attempts. Of course for this to be useful you need to have a strong password like mine, which is ….. . However, WP Better Security is the best but makes some drastic changes to your site. I don’t like to make so many changes, and would prefer that WordPress came bundled with those features. One of those features is modifying the login url. By default it is like http://blog.host/wp-login.php. This makes it an easy target. One simple way to fix this is change it.

Changing your login url

I do not want to physically rename wp-login.php, since that would mean after a WordPress upgrade the change would be gone. The other way is to rename it in your web-server configuration. Below is my relevant Nginx configuration. (If you are still using Apache then you may want to switch to Nginx.)

#!cink
server {
    server_name blog.host;
    # Other configs like root etc...
    location ^~ /wp-login.php {
        include phpparams.conf;
        if ($request_method = POST) { return 444; }
    }
    location ^~ /your-secret-login-page-name.php {
        rewrite ^ /wp-login.php break;
        include phpparams.conf;
    }
    # ...
}

The above config blocks all POST request to wp-login.php but allows GET requests. So, wp-login.php would show up but if someone tries to submit on that page then the server will close the connection (status 444 is a special code which instructs Nginx to close the remote connection). Since we are using ^~ to prevent Nginx from matching to any more regex locations so, if you have any location directive to match .php won’t be used. So, effectively your wp-login.php file source would be sent to the user instead of executing them. That is why I have included phpparams.conf. See the Nginx migration guide for the contents of phpparams.conf.

One Caveat

Now even if you open your-secret-login-page-name.php, the form will still send POST requests to wp-login.php, because after all that is the page which is being served. So, either you need to use web developer tools like Inspector to modify the web code or better write a GreaseMonkey or TamperMonkey script to do that for you.

One Comment

  1. Hi,

    This sound very promising! But I have no clue how to go further. Or what a hell was the point in here!? Okay, I understood that much it’s not going to approve POST requests anymore. Not send from wp-login.php and not from “your-secret-login-page-name.php”. Changing method to GET from Chrome’s developer tools it just doesn’t make any difference.

    So.. What I should do now to get some effort from using “your-secret-login-page-name.php” than just wp-login.php?

    Reply

Leave a Reply to appornix Cancel reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.