How to Block XML-RPC Attacks on CentOS & cPanel Servers

XML-RPC is a protocol that uses XML to encode the calls and HTTP as a transport layer for its communication. XML-RPC means literally: XML Remote Procedure Call. It’s widely used in web applications, specilly by CMS like WordPress. Today we will show you how to Block XML-RPC Attacks easily.

WordPress uses this XML-RCP to extend its functionality and features, it was enabled by default since WordPress v.3.5.

Why would I need XML-RPC enabled on WordPress?

More than 50% of WordPress users don’t need this XML-RCP feature enabled, but there is no easy way for WordPress users to disable the feature from an option from the WP administration panel.

On the other hand, there are WP users who do use this function, but they don’t know it. Remote plugins and apps who launch requests against xmlrpc.php script need this. For example a popular WordPress Plugin called JetPack, or the official WordPress Mobile Apps, to mention another example.

The downface of XML-RCP

In the past years, web hosting providers, ISPs and WP end users, have seen many WordPress installations taken down by DDOS attacks against this XMLRPC functionality, it is still used to launch floods and exploit outdated WordPress installations.

So, that’s why today we are going to review some ways to stop the WordPress XML-RPC attacks, from user side and from server administrator side.

How can I Block XML-RPC Attacks on WordPress?

Let’s see how to Prevent WordPress XML-RPC attacks on the two most popular web servers: Apache and Nginx

1) Block access to xml-rpc.php files from your website

For Apache users:

Place this code inside a .htaccess file:

# Block WordPress xmlrpc.php attacks on Apache
<Files xmlrpc.php>
order deny,allow
deny from all
allow from XX.XX.XX.XX
</Files>

Make sure you replace XX.XX.XX.XX with your real IP in case you want to whitelist some server IPs or your static ISP IP in case you need to launch request against xml-rpc.php file.

For Nginx users:

# Block WordPress xmlrpc.php attacks on Nginx
location /xmlrpc.php {
      allow   192.168.1.0/24;
      deny all;

Reload Nginx to apply changes:

service nginx reload

2) Stop XML-RPC attacks using Mod_Security Rules

ModSecurity is a web application firewall that helps users to stop common web based attacks like sql injections, DOS and other kind of common HTTP attacks. In this case, it’s useful top stop xml-rcp attacks.

I’ve found two rule-sets that seem to be working, but I haven’t fully tested so far.

First one comes from StackOverflow:

SecAction phase:1,nolog,pass,initcol:IP=%{REMOTE_ADDR},id:690010     
<LocationMatch "/xmlrpc(\.php)?$">
SecAction phase:2,nolog,pass,deprecatevar:ip.count_a=1/20,id:690010
SecRule IP:COUNT_A "@gt 5" "phase:2,deny,status:403,log,msg:'WAF Rules : XMLRPC - Ratelimited to one call in 20 seconds',id:690012"
SecRule RESPONSE_BODY "fault(Code|String)" "phase:4,pass,nolog,setvar:ip.count_a=+1,id:690013"

And the second comes from Ryan White’s Blog, who shows a full protection against XML-RPC attacks from single connections, as it is not so effective from distributed hosts:

SecDataDir /tmp
 
SecResponseBodyAccess On
SecResponseBodyLimitAction ProcessPartial
SecResponseBodyMimeType text/xml
 
# SecStreamInBodyInspection requires ModSecurity 2.6.0 or greater
SecStreamInBodyInspection On
 
SecAction "phase:1,nolog,pass,id:19300,\
    initcol:ip=%{REMOTE_ADDR}"

<FilesMatch "xmlrpc.php">
    SecRule RESPONSE_BODY "faultString" "id:19301,nolog,phase:4,\
        t:none,t:urlDecode,setvar:ip.xmlrpc_bf_counter=+1,\
        deprecatevar:ip.xmlrpc_bf_counter=1/300,pass"

    SecRule STREAM_INPUT_BODY "wp\." "id:19302,log,chain,\
        deny,status:406,phase:4,t:none,t:urlDecode,\
        msg:'Temporary block due to multiple XML-RPC method call failures'"

    SecRule ip:xmlrpc_bf_counter "@gt 4" "t:none,t:urlDecode,\
        t:removeWhitespace

3) Block XML-RPC Attacks using CSF Firewall

Important: this method seems to be no longer working on latest CSF and CentOS versions. If you decide to proceed it’s not guarantteed that this may stop XML-RCP attacks on your server.

There is another server-side method (found at ConfigServer Forums) to block XML-RPC attacks using your server firewall. In this case, we will block this attack using a custom regex rule with the all mighty CSF Firewall

We will configure CSF to block the offending IP if exceeds the 10 POST or GET requests to the xml-rpc.php file in less than 3600 seconds..

Edit your regex.custom.pm file:

nano -w /usr/local/csf/bin/regex.custom.pm

Close to the end of the file, you will see an empty space. That is where we are going to place our new anti-xmlrpc rule (marked in red on the next screenshot)

Blocking XML-RPC attacks with Regex Rules from CSF Firewall

The rule is the following, just copy and paste:

# XMLRPC Defense, block IP if 10 requests in 3600 sec
if (($globlogs{CUSTOM2_LOG}{$lgfile}) and ($line =~ /(\S+).*] "\w*(?:GET|POST) \/xmlrpc\.php.*" /)) {
return ("You have been banned, please do not attack us",$1,"XmlrpcAttackDetected","10","80,443,21,25,22,23","1");
}

Once you add the rule, it should look like this:

Block XML-RPC Attacks
Block XML-RPC Attacks using CSF Firewall

Save the file, and edit CSF Configuration ,as you see here:

nano -w /etc/csf/csf.conf

Search for this variable: CUSTOM2_LOG and set is as you see below:

CUSTOM2_LOG = "/var/log/xmlrpcattacks"

Save the changes and create your log file:

touch /var/log/xmlrpcattacks

Now restart CSF and LFD to apply changes:

csf -r
service lfd restart

If you need to deactivate this XML-RPC block rule, just clear the rule by editing regex.custom.pm, and after that restart csf and lfd once again.

 Conclusion

As you see there are a few ways to Block XML-RPC Attacks on WordPress, the first options we explained on this post use a simple allow/deny for Apache and Nginx webservers, however, if you are suffering a big attack, you can enable a server-side iptables based solution using CSF Firewall.

What is your experience defending against XML-RPC web based attacks?

About the Author: Martin Keler

6 Comments

  1. I assume with the CSF firewall solution I need to modify my apache or run a separate script to populate the /var/log/xmlrpcattacks log but it would great if that was clarified above. Thanks

    1. You don’t need to modify any other thing than the explained in this tutorial. No apache or nginx modifications needed. The /var/log/xmlrpcattacks is defined inside csf.conf file, as explained before.

      1. I made the changes as specified and I know a number of sites on my server get xmlrpc.php attacks. I just looked at all the apache logs and i’ve had 38640 over the mast 19 hours. Yet my /var/log/xmlrpcattacks remains empty. Does this setup assume I have made some other changes in my csf.conf? How can I test that this is working? Thanks

        1. Pretty weird, we’ve tested this configuration on many of our cPanel servers and it’s always logging the attacks on the pre-defined log path, and also of course we’ve seen a decrease in server attacks after this.

          We should inspect your server to check what’s going on to be sure.

          1. The same thing happens to me too. The /var/log/xmlrpcattacks remains empty, and i can still see the attacks taking my server down (using apachestats). I am using the latest CSF (v9.28) on latest WHM (60.0 build 26) on CENTOS 6.8. What else to try?

Leave a Reply

Your email address will not be published. Required fields are marked *