3

During a large brute force attack, I'd like to shut off the ability to log into WordPress entirely. The only account on the site is mine, so there's no reason for visitors to login and it wouldn't hurt their experience on the site.

When I need to login, I can remove the code. Alternatively, I can limit logins to just my IP address.

I'm trying to achieve this by catching a login attempt as early as possible with the following code

if (isset($_POST['pwd']) || isset($_GET['pwd'])) {
    header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found");
    echo 'logins to the site are disabled';
    die();
}

This is crude but it should work. However, there are still some login attempts getting through and I don't know where they could be coming from.

How else does WordPress accept logins, if it's not with the 'pwd' field?

Is there an existing convention for shutting down logins?

Edit: in addition to stopping wp-login.php, I deleted xmlrpc.php which was being used as another entry into brute forcing logins. My current setup doesn't need it but yours might. Be sure you don't need it before you disable it.

  • May this help you: wordpress.stackexchange.com/questions/62889/… – jas Nov 14 '15 at 16:42
  • I would think a strong password would be sufficient unless the amount of traffic is bringing down your site from large number of PHP processes + DB checks Then you could try HTTP authentication to avoid the bots touching your wp-login.php or xmlrpc.php files (no php + db processes). – birgire Nov 14 '15 at 16:48
  • @jas - I tried deleting the wp-login.php file altogether. I'm still getting "login failed" alerts. They're able to login through different methods, other than the wp-login.php page. – Michael Khalili Nov 14 '15 at 20:42
  • @birgire - I have strong passwords but this is a decent size attack. I'm hoping this will be something I can implement in case of a larger attack, as well. Are wp-login.php and xmlrpc.php the only places someone can authenticate into the site? – Michael Khalili Nov 14 '15 at 20:44
  • I believe the Wordfence plugin offers the ability to block by IP. Brute force attacks are pretty common on a site of any size. It also offers the ability to limit login attempts – cameck Nov 15 '15 at 0:18
3

Failing to authenticate should do the trick for all the kinds of possible authentication - login form, xmlrpc, ajax, whatever

Edit: actually realized there is a way to save sending the user related query to the DB

function wpse208677_authenticate($user,$username,$pass) {
  remove_filter('authenticate','wp_authenticate_username_password',20,3);
  return null;
  // if you want to whitelist your ip check for it and return $user
}

add_filter('authenticate','wpse208677_authenticate', 10,3)
  • That's helpful but I'm looking for a way to short circuit the login from the start. I have sucuri and another plugin in place that alert me on brute force attacks. I'm concerned that this would still trigger the actions on those plugins. – Michael Khalili Nov 14 '15 at 20:40
  • @MichaelKhalili, you can not realistically do that as login attempts can come from all kinds of sources. If you are interested to block only wp-login.php or xmlrpc.php you should do it on the webserve config level (htaccess in apach can do the trick as well) and not let php run at all. The only comparable (performance wise) PHP code will need a modification of wp-config.php which is a file you should avoid touching as much as possible. Any other php based solution will not be better performance wise then the answer. – Mark Kaplun Nov 20 '15 at 5:44
  • I have figured this out, since I posted the question and updated my post. I can put the code which looks for $_POST['pwd'] in a must use plugin (mu-plugins) and disable the xmlrpc.php That seems to be doing the trick. I got most of the attacks stopped with $_POST['pwd'] and the rest stopped after I disabled xmlrpc.php – Michael Khalili Nov 20 '15 at 16:21
  • 1
    The problem with deleting files is that they will be back when you upgrade. better to block in htaccess if you don't use xmlrpc – Mark Kaplun Nov 20 '15 at 17:20
  • 1
    Regarding disabling XML-RPC safely, I found out that you can disable it using a filter add_filter('xmlrpc_enabled', '__return_false'); There are also several plugins that'll do this for you. I used this one wordpress.org/plugins/disable-xml-rpc – Michael Khalili Jan 20 '16 at 1:25
0

The top answer here is horribly bad PHP code, completely broken. Here is a good version. My reputation points are too low to comment on the original answer.

This code can be placed at the very bottom of wp-config.php in a pinch.

function wpse208677_authenticate($user,$username,$pass) {
  remove_filter('authenticate','wp_authenticate_username_password',20,3);
  return null;
  // if you want to whitelist your ip check for it and return $user
}
add_filter('authenticate','wpse208677_authenticate', 1,3)

Another option is to prevent access to the login/register pages. This even works behind a hidden login url for WordPress. This code can be placed at the very top of wp-config.php (after the opening <?php.

if ( in_array( $_SERVER['PHP_SELF'], array( '/wp-login.php', '/wp-register.php' ) ) ){
    die('Site in maintenance mode.');
}
  • 2
    I'm sorry but that's a very bad idea to put the code in the wp-config.php file. Also, I don't see how your code is different than the other answer? – Jack Johansson Mar 19 '18 at 8:39
  • 1
    The previous answer by Mark K answer has been updated by you Jack yesterday, fixing the typo that I had fixed. It is bad idea to put code in wp-config, this was in an emergency scenario for someone who knows what they are doing. The earlier we step in, the less resources WP needs to load to block logins. – Branndon Mar 20 '18 at 14:17
-3

you can fix this issues using

change "wp-admin" directory and protect this directory using .htaccess password

  • 1
    Anyone considering this should remember that public ajax requests are still made to the wp-admin directory. If your site uses ajax, you should unblock the path to admin-ajax.php – Michael Khalili Nov 14 '15 at 21:14
  • 1
    And as WP uses AJAX in core, this is shouldn't be done anywhere. – kaiser Nov 14 '15 at 21:45
  • I agree that is not the solution to "disable" user registration/login, which is the question qhere. But @kaiser, why do you say this shouldn't be done? I do in two websites I personally manage where there is no users registration enable. I also use .htaccess password protection for wp-login.php file. If it is properfly configured, Ajax requests and other stuff from wp-admin (JS, CSS, images) are not a problem at all and it may reduce drastically the success possibilities of brute force attacks. – cybmeta Nov 25 '15 at 6:01
  • @cybmeta you renamed wp-admin? – kaiser Nov 25 '15 at 11:25
  • No, I didn't. That is another option but it is less secure, the admin URL of the site can be easily discovered, no matter what name you have given. Anyway, that doesn't explain why blocking access to that location shouldn't be done at all. Also, I don't see how changing the name is better than blocking the access to some location. Note that the context is that no one except you are going to access there, why blocking the access to anyone else is bad?. Currently, in the case only you is allowed to access to wp-admin, I would block wp-admin with .htaccess even if the name is changed. – cybmeta Nov 25 '15 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.