XMLRPC filtering through htaccess not working

My websites are hosted on a shared instance. They face regular xmlrpc DDoS. I've tried to put in place several mitigation practices to block those attacks :

  1. Installed a dedicated extension that disables xmlrpc

  2. Blocked xmlrpc through htaccess, on all hosted wordpress site on that instance, using two different codes :

Files xmlrpc.php
order deny,allow
deny from all
/Files

and

    RewriteRule ^xmlrpc\.php$ http\:\/\/0\.0\.0\.0\/ [R=301,L]

Yet I keep getting requests on that file. An example of access log i get is :

    website.com 162.zzz.yy.xxx - - [22/Jul/2021:09:51:56 +0000] (0 s) POST /xmlrpc.php HTTP/1.1 403 199 - Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

I believe I should be supposed to get a 301 rather that a 403, yet I don't understand what I'm doing wrong here.

I've reached out to my service provider, which has only been able to confirm that the mod.rewrite module was indeed active, and to put in place the previously provided htaccess lines of code. To no avail. He then told me to reach out to the wordpress community, which is where I am right now.

Topic xml-rpc htaccess security Wordpress

Category Web


The directives in .htaccess (on your application server) would seem to be working as expected.

Yet I keep getting requests on that file.

Blocking the request in .htaccess doesn't stop the request reaching your server (and being logged). As you can see from the log entry, it is being "blocked" and your server is responding with a 403 Forbidden HTTP response status (as a result of the <Files> / deny from all directives). The xmlrpc.php file is not being processed.

The only way to stop the request reaching your application server is to implement some kind of firewall or front-end proxy server that basically sits in front of your application server and "screens" all the requests before passing them on to the backend server that ultimately deals with the request. But since you are on a "shared hosting" platform, this is probably not something that is available to you.

I believe I should be supposed to get a 301 rather that a 403

The mod_authz_host (or mod_access_compact on Apache 2.4) directives inside the <Files> container will take priority over the mod_rewrite directive, despite the order of directives in the .htaccess file, so no redirect occurs.

Remove the <Files> block and place the RewriteRule directive at the top of the .htaccess file, clear your browser cache and you should see a redirect. (Note that 301s are cached persistently by the browser, so subsequent "test" requests might not hit your server until the browser cache is cleared.)

However, it would be preferable to block these requests with a 403, rather than try to issue a 301 redirect. Bots are unlikely to follow the redirect anyway, so it's simply seen as a non-success (200) response. The mod_rewrite directive is easier to accidentally override and is more dependent on the ordering of directives in .htaccess.

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Note that Order and Deny directives are Apache 2.2 and officially deprecated on Apache 2.4. If you are on Apache 2.4 then you should be using Require all denied instead.


Aside:

RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]

The RewriteRule substitution string (2nd argument) is an "ordinary" string, not a regex, so colons (:), slashes (/) and dots (.) do not need to be backslash-escaped here. (Although even if it was a regex, only the literal dots would need to be escaped as the other characters carry no special meaning here. This unnecessary escaping is quite typical of cPanel.)

About

Geeks Mental is a community that publishes articles and tutorials about Web, Android, Data Science, new techniques and Linux security.