I use a service called micro.blog that periodically grabs the RSS feed from my website and posts the contents to the service’s timeline. For about a month or so, the service has been displaying an error of “invalid RSS feed”. I’ve been working with the folks at micro.blog to figure out what is causing this.
micro.blog says that when their bot goes to my site to get my RSS feed, instead of the RSS feed, they get an HTML page that says “Please wait while your request is being verified”.
Doing some searching online, I’ve seen folks having a similar issue but it seems to have something to do with Wordpress and Imunify360 not playing nicely with Cloudflare. I’m not running Wordpress, however, my webhost does use Imunify360. I’ve been told by my webhost that I can disable some of the aspects of the web application firewall by disabling mod_security, so I did a few tests to see if I could figure this out. Here’s what I tried:
Added micro.blog’s IP to Cloudflare’s Security > WAF > Tools and set to Allow
Disabled mod_security on my webhost, cleared Cloudflare cache
Disabled Cloudflare DNS proxy on my A and CNAME records
Only #3 disabling the Cloudflare DNS proxy resolves this issue. micro.blog is able to grab my RSS feeds without issue if the proxy is off. Once I turn it back on, the issue returns. Does anyone have any suggestions on next steps to try?
Just a coincidence that past reports came from WordPress users, but the Imunify360 issue is unrelated to the CMS platform.
Whoever told you this probably don’t know. Imunify360 is normally adopted by web hosting services for the protection of their whole infrastructure, not to protect individual accounts, and for that reason it cannot be disabled in shared hosting environment. Many hosts don’t even train their support team about it.
The issue is a compound of Cloudflare caching with origin server firewall. An user triggers the webhost firewall, which sends an HTML (in this case XML) response with 200 status code (cacheable by Cloudflare if you use APO, Cache Rules, or Page Rule with Cache Everything), and the cached response is then returned to all subsequent visitors.
To break out of this cycle, you can create a Cloudflare Redirect Rule to redirect any request containing wsidchk= in its query string, then block the target URL. This will make the request that triggered Imunify360 to be blocked, and subsequent requests will get the proper response.
Thank you for that insight on how to break out of this. Looking at the the Redirect Rules page, I see that I can create a Redirect Rule that matches wsidchk= in the URI Path, but how do I block the target URL?
Thanks for all of the help and tips! I set this up, but no joy. micro.blog still seems to be getting blocked from getting to my rss feeds. I’m not using any Page Rules, just the default “standard” caching level. I also don’t see any Security events in Cloudflare. I wonder if there is something else going on.
I’ll need to check with the folks at micro.blog and ask if they’re still seeing the same issue. I can’t see the issue on my end. Going to my RSS feed via a web browser seems to work and my RSS feed reader doesn’t have any issues either.
That tells me that the request from your monitoring service is what is triggering the Imunify360 response, not another bot request that was being cached as I had suspected.
Also, you should talk to your RSS monitor service, so they understand it’s their IP being rejected by Imunify360, and they need to investigate it and perhaps reach out to Imunify360 developers to try to figure out what’s the issue.
My hosting provider got back to me and this is what they say:
Regretfully, at this point there is nothing else we’re able to do. As you have confirmed that the issue only arises when using Cloudflare’s proxy service, it is exceedingly unlikely that anything on our server is causing the issue. Our recommendation would be to disable Cloudflare proxying or press Cloudflare’s support to further investigate the issue as it is originating with their service.