One quick thing you can do that should help, is to set up some firewalling and block the specific IP address that is making the connection. If you’re on Ubuntu, using ufw is the simplest way to manage IPTables firewalling. Check out this tutorial for all the info:

• How To Setup a Firewall with UFW on an Ubuntu and Debian Cloud Server

The quick, TL;DR version is to first set up default rules allowing outgoing connections and denying incoming ones:

sudo ufw default deny incoming
sudo ufw default allow outgoing

Then set up the ports you want open:

sudo ufw allow 80/tcp # http
sudo ufw allow 443/tcp # https
sudo ufw allow 22/tcp # ssh, change if you're using a different port

Finally, block the IP address and enable ufw:

sudo ufw deny from attackers.ip.address
sudo ufw enable

This should stop them for now. Of course, the people up to these kinds of unsavory things often manage switch up their IP addresses frequently. Doing this by hand over and over again is not desirable. You can set up fail2ban to do a lot of this for you automatically. For more information on how to do that, check out:

• How Fail2ban Works to Protect Services on a Linux Server

I posted this on a similar question about xmlrpc.php and I found this page when searching for a solution to our problem. Hopefully this will help anyone else in the same boat:

Our solution uses fail2ban like the others, but with actions setup to use ufw commands since we love the simplicity of that firewall. Note that our log file is different from the default and includes the IP address the request was sent to first (othervhostsaccess.log), so remove the first “\S*” and space from regex for the normal access log. For some reason, this was the default when we set up the Wordpress droplet. YMMV.

# cat /etc/fail2ban/action.d/ufw.conf
[Definition]
actionstart =
actionstop =
actioncheck =
actionban = ufw insert 1 deny from <ip>
actionunban = ufw delete deny from <ip>

# cat /etc/fail2ban/filter.d/xmlrpc.conf 
[Definition]
failregex = ^\S* <HOST> .*POST .*xmlrpc\.php.*
ignoreregex =

# cat /etc/fail2ban/filter.d/wp-login.conf 
[Definition]
failregex = ^\S* <HOST> .*POST .*wp-login\.php.*
ignoreregex =

# cat /etc/fail2ban/jail.d/xmlrpc.conf 
[xmlrpc]
enabled = true
filter = xmlrpc
action = ufw
logpath = /var/log/apache2/other_vhosts_access.log
bantime = 43200
maxretry = 2

# cat /etc/fail2ban/jail.d/wp-login.conf 
[wp-login]
enabled = true
filter = xmlrpc
action = ufw
logpath = /var/log/apache2/other_vhosts_access.log
bantime = 600
maxretry = 6
findtime = 60

No changes were required to Wordpress or any plugins to install. This does mean that fail2ban can’t actually tell if there was a failure, it just looks at how often those URLs were accessed.

HTH

Sources:

• https://bjornjohansen.no/using-fail2ban-with-wordpress - I used the ufw custom action from there
• https://rbgeek.wordpress.com/2014/09/11/block-wordpress-xmlprc-php-ddos-attacks-using-fail2ban/ - General rule structure

Try this.

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

I have a few web sites that have been subject to this attack since last night. I’ve blocked the IPs via iptables but the logs show the requests keep coming. Should these IPs be reported to DO Support? I would be surprised if my servers are the only ones affected and am surprised this traffic has not been seen and/or blocked by DO.