bn520995
By:
bn520995

How do I stop brute force attacks against xmlrpc.php from crashing my WordPress server?

April 27, 2016 20.6k views
WordPress One-Click Install Apps Ubuntu

This happens all the time. I thought Jetpack Protect was supposed to stop this?

Over and over my server is taken down by attacks against xmlrpc.php frequently where the attacker is spoofing Google Bot or some version of Windows.

[MY SERVER IP]:80 185.103.252.170 - - [27/Apr/2016:04:05:09 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.103.252.170 - - [27/Apr/2016:04:05:10 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.130.4.120 - - [27/Apr/2016:04:05:10 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.130.4.197 - - [27/Apr/2016:04:05:10 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.130.4.120 - - [27/Apr/2016:04:05:11 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.130.4.120 - - [27/Apr/2016:04:05:11 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.103.252.170 - - [27/Apr/2016:04:05:12 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.130.4.197 - - [27/Apr/2016:04:05:13 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.130.4.120 - - [27/Apr/2016:04:05:13 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"
[MY SERVER IP]:80 185.130.4.197 - - [27/Apr/2016:04:05:15 -0400] "POST /xmlrpc.php HTTP/1.0" 500 592 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

Cloudflare also isn't blocking this (unless the attacker somehow uncovered my server IP). Why does WordPress still have such a glaring vulnerability in at this stage of development and why isn't Protect doing its job? It is so easy to crash a server this way.

I would love to just block xmlrpc.php entirely but too many plugins depend on it, including Jetpack.

3 comments
10 Answers

if you are using apache

Add the highlighted lines below between the <VirtualHost> tags.

<VirtualHost>
…    
    <^><files xmlrpc.php>
      order allow,deny
      deny from all
    </files><^>
</VirtualHost>

if you are using nginx

server {
…
<^> location /xmlrpc.php {
      deny all;<^>
    }
}

dont forget to restart your webserver after adding above lines.

  • I know how to block access to the file but that cannot be done because some plugins (including Jetpack) require that file to be accessible.

    • WordPress is a popular and powerful CMS (content management system) platform. Its popularity can bring unwanted attention in the form of malicious traffic specially targeted at a WordPress site. There are many instances where a server that has not been protected or optimized could experience issues or errors after receiving a small amount of malicious traffic. This guide will show you how to protect WordPress from XML-RPC attacks on an Ubuntu 14.04 system.
      • Well let's see...

        As I mentioned in my first post, method 1 (install Jetpack and Jetpack protect), is already done.

        Method's 2 and 3 are not relevant. They are just more ways to block all access to xmlrpc.php but that will stop Jetpack and other plugins from functioning correctly (I use Jetpack for more than just protect which obviously isn't doing much "protection").

        • If you refuse to do what needs to be done to protect it, you're kinda screwed.

          xmlrpc.php is a horrible thing, and too many plugins rely on JetPack, which relies on it. If you don't want to be brute-forced constantly, the only other option is to switch blogging platforms.

          • Switching platforms is not exactly a simple quick fix.

            I wish WordPress would just fix the damn problem. You would think there would be more demand and outcry considering they power upwards of half the internet.

  • This does not work for Nginx! I just tested it.

    The correct code is:

    location = /xmlrpc.php { deny all; } # protect against brute force attack
    

    The difference is the = sign after location.

I had the exact same attacker on my server today, and it completely shutdown my wordpress installation in a production environment. What you are experiencing is an xmlrpc.php DDoS. The only solution to stop the flood is to remove xmlrpc.php, or if you like to have some fun...
1) Backup the old xmlrpc: cp xmlrpc.php ~/
then create a new one

2)

<?php
/* Redirect browser */
header("Location: http://127.0.0.1");

exit;

?>

All of the attackers payloads will simply redirect to their own PC. This has effectively stopped the attacks for me today! Good luck. :)

  • I had similar thoughts....

    Also what seemed to work was using the firewall:

    iptables -I INPUT -p tcp -s IP_ADDRESS -j REJECT

  • It might not be DDoS it could be brute force attempt to crack your passwords, make sure they are secure. If I am not mistaken some things like desktop editor software/apps use xmlrpc.php to login and communicate with the WordPress server.

Hi! We are just suffering the same kind of "attack" (I'm not sure how to name it).

As all requests were from the same subnet, we were able to block them from firewalld.

Hope it helps.

sudo iptables -A INPUT -s 185.103.252.170 -j DROP
sudo iptables -A INPUT -s 185.130.4.120 -j DROP
sudo iptables -A INPUT -s 159.122.224.173 -j DROP
sudo iptables -A INPUT -s 185.130.4.197 -j DROP

sudo iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 50/minute --limit-burst 200 -j ACCEPT

I think many of had the same problem so

  1. Have you done all necessary updates of plugins and wordpress ? if no just do it AND after this operation you have to remember to clear your page, object cache. IT is very important because some plugins may have changed theirs database structure and later they just call to non-existing database structure and here you are your wordpress crashed !!!.

  2. Second Please look what of your plugins use crontask - it could be one of your plugin is not well done it makes that problem with many requests from outsite. I mean remove all unnecessary plugins and of course clear wordpress cache after that.

  3. Block brute force IP's with IPtables, examples are given below so won't repeat ;).

Hello,

We were a victim of this IP and attack recently. Therefore, I took the following steps to harden all my web services. All our web services are protected by CloudFlare. Somehow, the attacker got the direct IP address.

I took the following steps:

  1. Block all port 80,443 requests unless it originates from CloudFlare. (IPTables, see below)
  2. Allow only HTTPS requests and rewrite all HTTP requests to HTTPS (Optional)
  3. Turn on Origin Authentication in web server & CloudFlare. (Optional)

The above has efficiently blocked out all attacks. You can further use CloudFlare rules to redirect xmlrpc.php to another url to prevent them from even hitting your web server. However, doing so will prevent the use of remote apps such as Wordpress App etc as they make use of xmlrpc.php

IPTable Rules:
-A INPUT -s 103.21.244.0/22 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 103.22.200.0/22 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 103.31.4.0/22 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 104.16.0.0/12 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 108.162.192.0/18 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 131.0.72.0/22 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 141.101.64.0/18 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 162.158.0.0/15 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 172.64.0.0/13 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 173.245.48.0/20 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 188.114.96.0/20 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 190.93.240.0/20 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 197.234.240.0/22 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 198.41.128.0/17 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 199.27.128.0/21 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 103.21.244.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 103.22.200.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 103.31.4.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 104.16.0.0/12 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 108.162.192.0/18 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 131.0.72.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 141.101.64.0/18 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 162.158.0.0/15 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 172.64.0.0/13 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 173.245.48.0/20 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 188.114.96.0/20 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 190.93.240.0/20 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 197.234.240.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 198.41.128.0/17 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 199.27.128.0/21 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j DROP
-A INPUT -p tcp -m tcp --dport 443 -j DROP

Here is a new IP address with the same attack today: 161.202.90.202

Others may wish to preemptively block it.

This can affect me on a nodejs server installation?

  • Yes, I always see POST requests for this file on my Node server. I took the advice above to redirect the request to 127.0.0.1.

Have another answer? Share your knowledge.