• Resolved frank tredici

    (@frank13)


    I have this mu-plugin running on my Multisite Network:

    <?php
    // this script is designed to prevent anyone from gaining access to login wp capabilities unless originating from an IP in the authorized IP array()
    
    function loginController_func() {
        $authorizedIPs = array(
            '123.456.789.012', // my dedicated Home Office Machine
            '987.654.321.098' // my dedicated Work Office Machine
        );
    
        if ( !in_array($_SERVER['REMOTE_ADDR'], $authorizedIPs) ) {
            wp_redirect( 'https://example.com/', 301 );
            exit;
        }
    
    }
    add_action('wp_authenticate', 'loginController_func'); // hook for wp-admin
    add_action('login_init', 'loginController_func'); // hook for wp-login all actions
    ?>

    Yet, most every morning, I have a stack of email alerts from Wordfence informing me that hackers have been prevented from logging in because they are using invalid usernames.

    From: WordPress <[email protected]>
    Date: Sun, Oct 18, 2015 at 8:55 AM
    Subject: [Wordfence Alert] example.com User locked out from signing in
    To: [email protected]
    
    This email was sent from your website "My WordPress Base Site" by the Wordfence plugin at Sunday 18th of October 2015 at 08:55:06 AM
    The Wordfence administrative URL for this site is: https://example.com/wp-admin/admin.php?page=Wordfence
    
    A user with IP address 79.176.51.241 has been locked out from the signing in or using the password recovery form for the following reason: Used an invalid username 'test' to try to sign in.
    User IP: 79.176.51.241
    User hostname: bzq-79-176-51-241.red.bezeqint.net
    User location: Tel Aviv, Israel
    
    NOTE: You are using the free version of Wordfence. Upgrading to the paid version of Wordfence gives you
    two factor authentication (sign-in via cellphone) and country blocking which are both effective methods to block attacks.
    A Premium Wordfence license also includes remote scanning with each scan of your site which can detect
    several additional website infections. Premium members can also schedule when website scans occur and
    can scan more than once per day.

    How do I block these attempts from ever reaching the login form?

    https://www.ads-software.com/plugins/wordfence/

Viewing 15 replies - 1 through 15 (of 15 total)
  • Thread Starter frank tredici

    (@frank13)

    I think your plugin has bugs. It reports false positives. Case in point: as a test I deleted login.php from my WordPress core. I continue to get endless emails every 2-3 minutes that someone is attempting to login using “test” as the username.

    Something unexplainable is going on here.

    Plugin Author WFMattR

    (@wfmattr)

    Wordfence hooks into the wp_authenticate action with priority “1”, so currently it will be processed before the mu-plugin that you are using. If you add the same priority to yours, I believe it will be processed first, since mu-plugins load before regular plugins. Adding the priority 1 in the add_action() call, like this should do it:
    add_action(‘wp_authenticate’, ‘loginController_func’, 1);

    For the login_init hook, Wordfence uses the default, so yours should currently run first.

    A lot of bots attempt to use xmlrpc.php to log in to sites, so if renaming wp-login.php did not make a difference and you don’t have any other plugins affecting the login process, then that is probably what they are using.

    XML-RPC is the same method used by the WordPress app, plugins like Jetpack, and other features like trackbacks and pingbacks.

    Disabling XML-RPC is possible (there are a number of plugins that do it, such as “Disable XML-RPC”) but it may cause other possible problems. If you decide to disable it, you might want to check out this post first:
    Should you disable XML-RPC on WordPress?

    -Matt R

    Thread Starter frank tredici

    (@frank13)

    Thanks @wfmattr. I’ll give your feedback a look and post back later.

    Thread Starter frank tredici

    (@frank13)

    I guess I don’t understand the significance of setting the priority @WPMattR.

    When I test my mu-plugin script from an IP not in my authorized array(), I get the effect of the redirect every, every time.

    So how is it that the hackers do not. That is the essence of my initial question.

    priority “1” can’t be the answer. It has to be XML-RPC. Agree?

    Thread Starter frank tredici

    (@frank13)

    Also, if wp-login.php doesn’t even exist in my Multisite network, (1) how are hackers even able to try to login, and (2) how is it that your security plugin stills sends me emails to the effect they “hackers” are attempting to login. If the login avenue is completely shutdown…I just don’t get it. I did read your article on XML-RPC and that did not shed any light on this particular situation.

    Plugin Author WFMattR

    (@wfmattr)

    Yes, XML-RPC should be the reason you’re still seeing login attempts, even after wp-login.php has been renamed.

    Using the priority of “1” will still make sure that your redirect happens before Wordfence checks for locked out IPs and looks up user information, which will save some unnecessary database queries. If you have a long lockout period in your options (up to 60 days), and if you still have IPs locked out from their previous attempts, it will make sure they get the redirect from your mu-plugin instead of the Wordfence lockout message, too.

    From what I see in the current version, not much else happens in this hook in Wordfence right now, but if there are changes in future versions, using a higher priority will also make sure your code still runs first. Let us know if you have any other questions!

    -Matt R

    Thread Starter frank tredici

    (@frank13)

    Yep, huge question. “If there is no way for someone to login because wp-login.php does not exist, then what is going on?”

    (1) how are hackers even able to try to login, and (2) how is it that your security plugin stills sends me emails to the effect they “hackers” are attempting to login. If the login avenue is completely shutdown…I just don’t get it.

    Plugin Author WFMattR

    (@wfmattr)

    I posted after your fourth post, so in reply to your fifth post above, xmlrpc.php allows logins by a different method, and doesn’t require wp-login.php to exist. The WordPress app uses that method to authenticate, and hackers can, too. You can find the call to wp_authenticate() in /wp-includes/class-wp-xmlrpc-server.php, that allows that to happen.

    -Matt R

    Thread Starter frank tredici

    (@frank13)

    Ok, makes a little more sense although admittedly since I’m not a hacker I guess I am ignorant to hacker tactics which is why I install plugins like wordfence and securi.

    I need to research more about this XML-RPC to better secure my Multisite network.

    If I can offer a plugin enhancement suggestion (assuming you are the plugin author ) you should somehow figure a way to discover how the hack attempt is being executed and provide more info in the alert email to that effect. Example, XML-RPC is being exploited …

    Thanks

    Plugin Author WFMattR

    (@wfmattr)

    That is a good suggestion, as xmlrpc.php is getting a lot more attention lately. I have sent this post on to the development team, and FB1031 is the reference number for this request.

    I can’t promise that every suggestion we get will make it into a release, or when it might be implemented, if so, but every suggestion we get is evaluated carefully and considered seriously. Thank you for the input!

    -Matt R

    Thread Starter frank tredici

    (@frank13)

    Thanks for your help @wfmattr. It was definitely the XMLRPC that was he vulnerability. I shut it down via .htaccess and the email alerts stopped. Plus I tracked it in my dom access logs. See this article for the “how to”…

    https://www.blogtips.org/block-wordpress-brute-force-attacks-via-xmlrpc-php/

    I have a similar problem with my sites.

    I use .htaccess Password Generator (https://www.tools.dynamicdrive.com/password/) and the Wordfence plugin on my site. In the last couple weeks I have gotten a few Wordfence notifications saying hackers from this country or that have been “locked out” from signing into my site for too many incorrect attempts.

    My question is how did the hackers even get to this page to try and sign in? The hackers should not even have gotten access to the wp-admin page without going through the .htaccess Password Generator (pop-out type username and password) first. They get blocked from the site entirely after 5 false attempts. And my hosting company is not getting the hacker’s IP address on the blacklist.

    Could they also be accessing through XMLRPC?
    Any help is appreciated.

    Thread Starter frank tredici

    (@frank13)

    One way to (a) ensure your WPMS server is better secured, and (b) to see if you nip-it-in-the-bud is to implement the .htaccess directives at https://www.blogtips.org/block-wordpress-brute-force-attacks-via-xmlrpc-php/

    Good luck @doylegirl

    I’ll add that code to one of my sites’ .htaccess file to see if it stops it. If I don’t get any more notifications for a week or so, I will apply to all. Thanks Frank!

    doylegirl

    (@doylegirl)

    It’s been a month and your code has helped a lot. Thank you Frank Tredici!

Viewing 15 replies - 1 through 15 (of 15 total)
  • The topic ‘How do hackers bypass roadblocks to reach the login page?’ is closed to new replies.