If you run WordPress you’ve seen these in your web server logs:
22.214.171.124 - - [29/Oct/2020:13:58:41 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" 126.96.36.199 - - [29/Oct/2020:13:58:44 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" 188.8.131.52 - - [29/Oct/2020:13:58:48 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" 184.108.40.206 - - [29/Oct/2020:13:58:52 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" 220.127.116.11 - - [29/Oct/2020:13:58:55 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-" 18.104.22.168 - - [29/Oct/2020:13:58:58 -0500] "POST /xmlrpc.php HTTP/1.1" 200 259 "-" "Apache-HttpClient/4.5.2 (Java/1.8.0_151)" "-"
Fucken scanners just slamming xmlrpc.php looking for a way in. When this happens CPU usage just goes through the roof for as long as the scan lasts and it could be five minutes, could be six hours, could be all week; before it ends. The gods help you if you’re paying by CPU usage.
So you have to block access to the file. You could just block all access to XML-RPC but doing this will prevent the WP mobile app from working.
We’ll just block that specific IP address but we need to be quick about it; just do a quick one liner on the terminal before the OS just topples over and becomes completely unresponsive or worse.
This should work for any Linux distribution that has iptables out of the box which is basically all of them.
# iptables -I INPUT -s 22.214.171.124 -j DROP
-I: Insert the rule as the first rule to be applied in the INPUT chain. You could use
-A(append) but the sooner we get rid of that traffic the less work the CPU has to do.
-s: Source address, in this case 126.96.36.199, which belongs to Tencent.
-j: jump to the DROP target. If you use the REJECT target you’re just creating more work for the CPU.
As it is part of both FreeBSD and OpenBSD base installations it should be enabled in
/etc/rc.conf but from reading the (almost useless) documentation and looking around the web You need to fuck around with
pf.conf first, then you can manipulate the table. This is the first result on the web when you search for “pf block ip address”. So no one-liner that can save your life.
/etc/pf.conf and add
table <badhosts> persist block on fxp0 from <badhosts> to any
- Create table named
badhosts, and set it to be persistent in kernel memory
- Block, on interface
fxp0(you’ll want to change this), traffic from rules in the
badhoststable to any destination.
Once you have this you can manipulate the table from the command line with
# pfctl -t badhosts -T add 188.8.131.52
pfctlwill manipulate the
-Twill show statistics
addaddress 184.108.40.206 to the table
# pfctl -t badhosts -T add 203.0.113.0/24
Which will create the badhosts table automatically without having to fuck around with
/etc/pf.conf. Don’t know if this will work on FreeBSD though.
It is part of the FreeBSD base installation so it does depend on ipfw being enabled in
/etc/rc.conf but it looks like you can go
# ipfw add deny all from 220.127.116.11 to any
- Add rule denying any and all fraffic from 18.104.22.168 to any destination
At least these rules are succint and easy to read. Whomever wrote the documentation seemed to pay more attention to usage at least.
Still, fuck FreeBSD.
Super easy now that PowerShell is built into Windows itself:
PS C:\WINDOWS\system32> New-NetFirewallRule -DisplayName "Block traffic from 22.214.171.124" -Direction Inbound -LocalPort Any -Protocol Any - Action Block -RemoteAddress 126.96.36.199
-DisplayName: The human-readable name of the firewall rule
-Direction: Can be Outbound or Inbound. We want Inbound obviously.
-LocalPort: Going with any ports because fuck crackers.
-Protocol: Same, block all port
-Action: Block traffic
-RemoteAddress: Specifying only 188.8.131.52
The documentation for the commandlet is super nice. No, I’m not typing ‘cmdlet’.
The old way involved so, so manny clicks. PowerShell makes it easy.
Now all of the previous bits of code cease to have any effect after a system reboot so if you want the rules to be permanent… don’t. Blackhats will just scan from different hosts and different networks so blocking an IP address permanently is just unproductive.
A better solution is to use fail2ban:
- Block xmlrpc.php attacks with fail2ban + iptables wordpress.
- https://www.digitalocean.com/community/tutorials/how-to-protect-wordpress-with-fail2ban-on-ubuntu-14-04. This one requires a plugin
There is also CrowdSec but I haven’t personally used them.
This post came to be cos I spent 30+ minutes trying to figure out how to block traffic on a FreeBSD host and their documentation is just… inscrutable. Should you ask for help in their forums you’ll just get told to RTFM.
You end up going in circles, consuming yourself in rage and frustration which does not feel nice. Rage-posting is where it’sat.