Was the site working with SSL prior to adding it to Cloudflare?
Yes
What is the current SSL/TLS setting?
Full (strict)
What are the steps to reproduce the issue?
This is not a bug report but more of an FYI. Cloudflare support haven’t been receptive nor interested in resolving issues around the ‘manage definite bots’ rule being mega flaky. They suggested we turn it off…
So far we have had webhook traffic from GoCardless and Stripe blocked, today we noticed that HireFire, a scaling service we have used for years, also stopped working due to the ‘manage definite bots’ rule.
I think it should be renamed to ‘block traffic that may be a bot’ because it 100% is not definite, in fact I can provide examples where it definitely is not and I fail to understand how what is clearly a legitimate webhook payload from a never changing range of IPs gets blocked after years of working fine.
More surprisingly, Cloudflare reacts casually with a ‘turn it off then’.
If you don’t want to disable the rule, you can create a skip rule to keep the rule turned on. For example, if you know the IP address from HireFire, you can add it to the skip rule. Cloudflare will not be able to expose how the managed rule performs its detection.
Thanks, I’m aware that I can work around Cloudflare’s broken rules and flawed detection algorithm and that’s exactly what we’ve done.
Cloudflare has a market cap of over $30billion. It’s not unreasonable that such a company makes efforts to fix and improve their products.
My point stands: ‘definitive bots’ should be exactly that. Moreover, when traffic clearly originates from easily identifiable providers who have consistently sent non-malicious web hook traffic for years then the detection algorithm can easily be updated.
Evidence suggests that Cloudflare either doesn’t read these types of suggestions or worse, they read them but then ignore them.
The impact to customers when ‘built in’ rules don’t work reliably is not something that should be casually fobbed off.
I am encountering a similar issue, which appears to be a malfunction in Cloudflare’s WAF, for the second time in the past month. I have already described this issue in a separate ticket, but unfortunately, I have not received any response.
The first occurrence resolved itself after four days without any changes made on my part—just as it had appeared on its own. Unfortunately, the same issue has arisen again today.
Previously, due to the false positive detections in Cloudflare’s WAF, I created a rule to skip traffic from specific IPs originating in a particular country. However, this is now the second time within a month that Cloudflare’s WAF has flagged all incoming traffic as an HTTP attack, and it is not even applying the skip rule I created.
To be clear, this rule was functioning perfectly prior to the WAF malfunction. However, due to the current issue, the WAF behaves as though the skip rule does not exist at all.
I would greatly appreciate your assistance in resolving this recurring problem and addressing the apparent malfunction in the WAF system.