Question

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

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.

Subscribe
Share

Regarding how it’s not easy to transfer off WP:

https://www.ghostforbeginners.com/how-to-transfer-blog-posts-from-wordpress-to-ghost/ Then check out a script I wrote. It makes moving to Ghost easy, but it’s written for NGINX: https://github.com/jonsjava/derpycloud-scripts/blob/master/docker/docker-ghost-site-creator.sh

You’ll also want to follow this guide to set up Docker: https://docs.docker.com/engine/installation/

And make sure to install docker-compose: https://docs.docker.com/compose/install/

If you decide to go this route, and want help, look at the whois of my username with COMmon TLD, and e-mail me there.

Ghost is good for simple blogging but it isn’t appropriate for a full business website with commerce and all kinds of stuff like that.

This comment has been deleted


Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

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 ;).

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

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.

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

<?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. :)

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.

This can affect me on a nodejs server installation?

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

Others may wish to preemptively block it.

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

This comment has been deleted