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.

Show comments

Submit an answer

This textbox defaults to using Markdown to format your answer.

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

Sign In or Sign Up to Answer

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.

Want to learn more? Join the DigitalOcean Community!

Join our DigitalOcean community of over a million developers for free! Get help and share knowledge in Q&A, subscribe to topics of interest, and get courses and tools that will help you grow as a developer and scale your project or business.

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.