Stopping WordPress /xmlrpc.php Apache requests with UFW on Ubuntu

The WordPress XML-RPC ping attack is pretty annoying. For large sites and coordinated attacks, the XML-RPC issue can get insane. For my site, the /xmlrpc.php queries/post attempts are more of a log annoyance. Still, it is a hassle that I wanted to kill. The various WordPress plugins to help with this and the .htaccess commands really didn’t give me the closure I wanted, so it was time to leverage the bundled firewall, UFW, on my Ubuntu server.

Here is the problem. A quick grep of the /var/log/apache2/access.log will show the issue.


The various plugins for WordPress, the Apache .htaccess allow/deny commands or the rewrite don’t really stop the query to the webserver service but they do minimize the response traffic required. For most of these servers doing the attacks, there is no value in even having them connect to server anymore once they have pinged it to death for hours. These are not users, these are bots and I’d rather not even let them have a response.

I had very minimal firewall rules around web and mail services on this server prior to going after the xmlrpc.php attacks. But, it was time to add a few to the serial offending ips coming after my xmlrpc.php and WordPress. If your server is getting attacked by hundreds or thousands of IPs, than this method is more laborious that what you want to do. You can try to go with the fail2ban framework with WordPress and Linux. On my server running Ubuntu, the request problem is pretty contained to just a few IPs from time to time trying their luck with my WordPress xmlrpc.php. So, the path of blocking them outright is an easy thing to do.

The UFW community page at Ubuntu is great. I have always hated manual IPTables rules, so UFW is nice and clean to deal with.I reset ufw to default rules to clean-out all my old setups and start from scratch again. Add the rules you need for basic services and ports via the standard or advanced methods. There is also a GUI tool, GUFW, to handle this, but it has it’s limitations. You need to enable UFW if it isn’t active and add some rules to kill off the bad guys from even connecting to the server. If you can do this via a perimeter firewall, great. This is a home server, so the router in doesn’t have much beyond basic port forwarding functionality.

The issue with Apache and UFW is that Apache will read the rules in numeric order. So, any deny commands you do by IP or IP/port/service need to be ahead of the 80/http and 443/https allow rules. If you try to block and do your deny rules below the Apache2 allow rule for 80/443, it will not do anything for you. Get those deny rules up!

You can do this through the insert ufw command.

After pumping in a few of them, your rules will start to look like this:

First few rules via ufw status numbered
First few rules via ufw status numbered

I could have been specific to the IP and incoming port and only block http or https, but why with these IPs either evil bots or compromised servers. My allow for port 80 and 443 rules are further down the numeric list. Issuing a reload and watching the apache2 access.log will provide validation that these servers aren’t going to bug you anymore. You can also flip the ufw logs to medium to get a better sense of the activity it is deflecting if you need proof.

Add comment

Leave a comment or reply