Pre Host Block xmlrpc but allow jetpack

Hmmm I have it working if I change it to:

<FilesMatch "xmlrpc\.php$">
allow from 185.64.140.0/22
allow from 2a04:fa80::/29
allow from wordpress.com
allow from 2620:115:C000::/44
allow from 76.74.255.0/25
allow from 76.74.248.128/25
allow from 207.198.101.0/25
allow from 198.181.116.0/22
allow from 192.0.64.0/18
allow from 64.34.206.0/24
</FilesMatch>

Does this still protect my site?

order deny,allow
deny from all

Removing this effectively allows all access, so leaving the rest wouldn’t be necessary.

Overall, we don’t suggest this approach since our IP block will change over time, changing the possible IP addresses. It would also prevent any of the mobile apps or other desktop clients from working.

Alternatively, Jetpack requests are routed to /xmlrpc.php?for=jetpack , so matching that string and allowing that is another option. Jetpack has protocols in place to only accept incoming requests that have been signed by our servers.

Thanks Jeremy,

Yes I would like the mobile app to work and I would like to try your suggestion of matching the string. Forgive my lack of knowledge, but can you point me in the right direction of how to do this? Do I still need to block xmlrpc in the pre host file as well?

Thanks again in advance!

Clare

Forgive my lack of knowledge, but can you point me in the right direction of how to do this? Do I still need to block xmlrpc in the pre host file as well?

I’d recommend that you get in touch with your hosting provider about this. They might actually already have security measures in place to protect your site’s XML-RPC file.

Hi

I found some coding on https://forum.ait-pro.com/forums/topic/wordpress-xml-rpc-ddos-protection-protect-xmlrpc-php-block-xmlrpc-php-forbid-xmlrpc-php/

Just wanted to double check that if I were to use the below code in the htaccess file instead:

RewriteCond %{REQUEST_URI} ^.*(xmlrpc\.php|wp-trackback\.php)$
RewriteCond %{HTTP_USER_AGENT} !^(.*Jetpack.*)$
RewriteRule ^(.*)$ - [F]

Will this do the job of matching the string?

Thanks

Clare

Or this:

<FilesMatch "^(xmlrpc\.php|wp-trackback\.php)">
Order Deny,Allow
allow from 185.64.140.0/22
allow from 2a04:fa80::/29
allow from wordpress.com
allow from 2620:115:C000::/44
allow from 76.74.255.0/25
allow from 76.74.248.128/25
allow from 207.198.101.0/25
allow from 198.181.116.0/22
allow from 192.0.64.0/18
allow from 64.34.206.0/24
Deny from All
</FilesMatch>

This will work as long as we don’t update our IP ranges, but the mobile apps will still be blocked

Is there a way to use a domain name instead of an IP? So if you update your ranges, we’ll still be safe?

@mano88

Is there a way to use a domain name instead of an IP?

Unfortunately no, as the requests come from multiple domains.

if you update your ranges, we’ll still be safe?

When we update our IP ranges, your site won’t be able to properly communicate with WordPress.com and you’ll start experiencing issues with some Jetpack features, that rely on that communication.

That’s why we don’t recommend the use of IP whitelists in general. Instead you could use other ways to mitigate XML-RPC attacks. The most popular hosts out there use tools like fail2ban or ModSecurity, for example. On your end, you can use plugins like this one to disable access to one of the methods used by hackers. You can also use Website Application Firewalls like Sucuri or CloudFlare to block hackers before they even reach your site. And finally, Jetpack itself includes a module that will help against Brute Force attacks.

If your hosting provider needs more details, or would like to talk about these different options, we’d be happy to help! They can contact us via this contact form.

I hope this helps.

Something that would work is for Jetpack to publish a whitelist as a DNS TXT record like an SPF record, and for some kind soul (at Jetpack?) to also publish the PHP code to check the REMOTE_ADDR or X-Forwarded-For address against the published whitelist.