*Update at end of post”
Looking for a way to further protect XML-RPC without letting it flap in the wind or fully disabling it. Up to now, everything that I’ve found online has been “suck it up” or “completely block it”.
Got into Cloudflare this morning and fully blocked XML-RPC then tried to access my site using the WordPress app. Snagged some helpful data in the Cloudflare firewall logs then created a quick and dirty firewall rule to block access to XML-RPC while still allowing the WordPress app to access the site. Granted this could also be bypassed, but it should help slow down the most automated of attacks.
So I let this soak for 24 hours and noticed that I had some legitimate bots and apps being blocked. iPhone app, Android app, BingBot, etc. I tried using “URI contains” with “AND” does not contain “OR” does not contain “OR” does not contain all chained together. That broke all access.
I then tried “URI contains” with “AND” does not contain “OR” “URI contains” with “AND” does not contain. That seemed like the logical choice but that too did not work.
Cloudflare support said I would need an enterprise account to really get in the weeds and that seemed like a money grab (Cloudflare support has really been getting worse over the last year IMO – just pushing to higher paid plans).
Through various proxies and VPNs around the globe, I kept banging away at the Cloudflare front door and came up with this custom expression. Now, I tried “OR” statements but it did not work with multiple keywords but when I switched to “AND” statements it worked as I would have thought “OR” statements would have worked. Using this expression, I can string together multiple user agents in one rule thus saving my max rules with the account that I have (hence the move to enterprise suggested by Cloudflare support).
(http.request.uri.path contains "/xmlrpc.php" and ((not http.user_agent contains "Agent1") and (not http.user_agent contains "Agent2") and (not http.user_agent contains "Agent3") and (not http.user_agent contains "https://duckduckgo.com/duckduckbot") and (not http.user_agent contains "http://www.bing.com/bingbot.htm") and (not http.user_agent contains "http://www.google.com/bot.html")))
Following up since the updated post. This seems to be doing the trick. My SIEM logs are silent on attacks against user accounts hosted in WordPress.