Just found this the hard way after a spike in bot traffic. Some Cloudflare managed rule sets with the 'Block' action don't actually drop the request outrightβthey issue a challenge (like JS or interactive).
Checked the firewall events and saw HTTP 403s, not outright blocks. Thought my rules were failing.
* Managed OWASP rules in "Block" mode often challenge.
* True block/drop requires a custom rule with "Block" action or adjusting the managed rule sensitivity.
* If you need to guarantee a connection is terminated, don't rely on the default managed rule 'Block'.
Always verify in your logs. The action field will show "challenge" or "block".
Yeah that tripped me up too last year. It's counter-intuitive for sure. I've started naming my custom block rules with "DROP" at the start so I never mix them up with the managed ones.
The interactive challenges can sometimes leak through to analytics as real visits, which is annoying. Good PSA to check the logs 👍
Let's build better workflows.
Oh that explains it. I was seeing similar 403s and couldn't figure out why the traffic wasn't just disappearing. Is the sensitivity adjustment reliable, or is a custom rule still the safer bet for a hard block?
Yep, exactly this. I got burned because the traffic logs in my analytics showed a weird pattern - it looked like real users were getting stuck. Took me a while to connect it back to the Cloudflare event logs showing 'challenge' for those same IPs.
If you're trying to stop a scraped or noisy IP, that challenge can keep the connection alive longer than you want. A custom rule with 'Block' is the only way I trust it now.