I’ve recently moved to the Cloudflare free plan for DNS and web proxying of my WordPress web site, which I host on a cloud-based OpenLiteSpeed server. I use Open Live Writer to publish blog articles, but https://www.mydomain.com/xmlrpc.php is now returning 403 Forbidden. If I turn off Cloudflare proxying for the www CNAME, I can access xmlrpc again, but I’d prefer to leave the proxy enabled.
From my research, Cloudflare is blocking xmlrpc as part of WAF managed rule WP007. (https://developers.cloudflare.com/support/third-party-software/content-management-system-cms/wordpress-jetpack-and-cloudflare/#default-jetpack-protection-from-cloudflare).
According to https://blog.cloudflare.com/waf-for-everyone/, I should be able to configure the free managed ruleset to turn logging on or off or to disable any rule. “All options are easily accessible via the dashboard.” But when I visit Security > WAF > Managed rules in the dashboard, my only option is to Upgrade to Pro, so I have no insight into what the rules are and no way to configure them. Is there some way to configure managed rules?
I’ve tried adding a custom rule, but requests to xmlrpc.php are still blocked with 403 Forbidden.
Well now I’m really confused. I thought I had checked this but now I see that the 403 is coming from LiteSpeed on my server, not from Cloudflare (so no ray ID).
But if I turn off Cloudflare proxying, access to xmlrpc.php works. Huh? I don’ think I have another firewall blocking XMLRPC but I’ll have to check.
Did I at least set up the rule correctly? Where in the CF dashboard can I manage/disable the “free managed ruleset,” or has that feature been removed?
If I comment that out, I can again access XMLRPC from my IP. Unfortunately, that also opens it up to the entire world. Within a short while, I was getting multiple hits on xmlrpc per second:
Okay good news, the Real Visitor IP feature finally kicked in. There must be some cache that caused it to lag for half an hour or so. So my .htaccess is once again blocking the xmlrpc requests from unknown IPs.
That leaves the question: isn’t Cloudflare’s WAF supposed to do that? How do I view and configure the default rules? I’d rather have that stuff blocked before it hits my server.
If you tell it to, but not on its own. I block XMLRPC access from anywhere other than the Automattic ASN to allow only Jetpack. You could create something similar that limited access to your IP.
This is what I don’t get. According to the documentation (the two links in my original post), CF deploys a free WAF ruleset to all new domains, one that includes xmlrpc blocking with Jetpack already excepted. That’s also the documentation that says I should be able to manage that ruleset (add logging, override rules). But when I try to manage the managed rules, all I see is this and upgrade advert:
Am I misinterpreting something? Not finding the right spot in the dashboard? Or is the documentation wrong?
The forum does not yet allow me to post links. The best I can do is put them in bacticks so they are available as text:
Not really. Cloudflare could not block /xmlrpc.php as a default, as many plugins use this service, not only Jetpack. If you look carefully, what’s in the documentation is that requests having the specific “for=jetpack” query string will only be allowed when coming from Jetpack’s IP addresses.
The screenshot with requests to your origin, for instance, reflects requests to /xmlrpc.php without any query string. You’d need to create your own Custom Rule to block those requests. Though promised in the referred blog post for the “coming months”, the availability of WAF Managed Rules for the Free Plan does not seem to have materialized yet.
An alternative to a Custom Rule is to create a Zero Trust Access policy for that path. That way only authenticated users can access that path (or any other path for which you create Access policies).
Thanks @cbrandt. It does seem like CF is not blocking xmlrpc as much as I thought (though there are plenty of WordPress advisors who say it should be completely blocked). Without the ability to even view the WAF rules, if not log or override them, it’s just trial and error to see what works.
I see that the blog article allows comments via Reddit. I’m curious whether mine will get back to CF staff for a reply: https://www.reddit.com/r/CloudFlare/comments/teoufj/waf_for_everyone_protecting_the_web_from_high/.
I may have to look into the Zero Trust setup. For the WordPress back-end, that’s probably what I want.
