• Resolved Daniel15

    (@daniel15)


    Hi,
    I’m seeing a large number of brute force attacks to xmlrpc.php, even though I’ve got WordFence installed and the brute force protection is enabled. It looks like brute force protection is working for the regular login page, but not for XMLRPC. Does WordFence not block XMLRPC attacks by default?

    The client IP is in a Google IP range (34.68.88.222, hostname: 222.88.68.34.bc.googleusercontent.com) but this is actually a Google Cloud customer. Is it possible Wordfence is incorrectly thinking this is Googlebot indexing the site, and thus not blocking it?

    Thanks,

    • This topic was modified 4 years, 1 month ago by Daniel15.
    • This topic was modified 4 years, 1 month ago by Daniel15.
Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Support wfpeter

    (@wfpeter)

    Hi @daniel15 thanks for contacting us regarding this.

    Wordfence doesn’t specifically block access to the xmlrpc.php file. It will only stop authentication attempts via xmlrpc.php if the Disable XML-RPC authentication feature is enabled in Wordfence > Login Security.

    If you wish to completely block access to it you can add the code below to your .htaccess file.

    # Block WordPress xmlrpc.php requests
    <Files xmlrpc.php>
    order deny,allow
    deny from all
    </Files>

    Let me know how you get on.

    Thanks,

    Peter.

    Thread Starter Daniel15

    (@daniel15)

    Hey @wfpeter, thanks for your reply. I did already have the “Disable XML-RPC Authentication” feature enabled, however these brute force attacks were still causing a very heavy load on my server even with that feature disabled. It seems like WordFence doesn’t fully block the requests. I’m not using Apache but I’ll do the equivalent in my Nginx configuration.

    Thanks,
    Daniel

    Plugin Support wfpeter

    (@wfpeter)

    Hi @daniel15,

    Access to that page may have been allowed for other reasons. Commonly, the WordPress app if you have 2FA or ReCAPTCHA enabled and the Jetpack plugin amongst other services do require access to XML-RPC. As a result of this, it is a common route to be tried.

    Definitely try the Nginx method of blocking access to xmlrpc.php to see if the activity ceases first, and let us know if there are any reasons why this might not be a suitable long-term solution given the information above.

    Thanks,

    Peter.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Brute force attacks to XMLRPC’ is closed to new replies.