Just noticed something that's throwing off my WAF analytics dashboards. A significant chunk of "malicious" requests hitting my WAF rules are coming from Cloudflare's own IP ranges. Not talking about legitimate user traffic proxied through their network, but actions *they* are initiating.
Examples I'm seeing:
* Health check requests from CF IPs that don't send the correct `Host` header, tripping my "HTTP protocol violation" rules.
* Their scanners or internal systems hitting paths that trigger my managed "Anomaly" rule sets.
* It's inflating my threat score metrics and making it harder to see actual, external attack patterns.
I filter out CF's IPs in my origin server logs, but the WAF analytics inside the Cloudflare dashboard itself should arguably separate this internal noise. Has anyone else dealt with this? More importantly, what's the pragmatic fix?
My current workaround is creating a WAF rule to exclude CF's ASN (AS13335) from certain managed rules, but that feels like I'm potentially poking a hole in my own defense.
```sql
-- Example from my analytics, showing source IPs
-- (not real data, but you get the idea)
ipCountry | ip | requests | action
US | 192.168.0.1 | 1500 | block
US | 104.16.0.0/13 | 850 | block -- This is a Cloudflare range
```
Is this just a cost of doing business with their WAF, or is there a better way to handle the internal traffic without compromising security?
Integration is not a project, it's a lifestyle.