Cloudflare Blocked 278 Probe Requests on Our Sites in a Day. Our Feed Had Listed 3 of the 13 Probers First. Use the Tools You Already Own.
This afternoon our Cloudflare dashboard showed a jump in "mitigated" traffic. We used it to answer a question every small security team can ask of tools it already pays for: when Cloudflare's own rules block a prober, did our threat feed already know about it? Over one day, Cloudflare's managed rules blocked 278 requests from 13 probers on our sites. Our feed had listed 3 of those 13 before they showed up. On the way to that number we found two counting traps, an old blocklist we had stopped maintaining, and a way that our own fix could have blocked thousands of innocent people. Here is all of it, and what you can do with the same tools.
The number on the dashboard was mostly us
Cloudflare counts an "allow" or "skip" decision as a security event. We run a rule that lets feed and API traffic past the bot checks, so customers' scripts are not challenged. In the 24-hour window that rule produced 13,989 skip events. Real blocks were 1,056. The afternoon jump was real but small: 201 blocked requests in one hour, against a usual 20 to 80, most of it from two scanners looking for configuration files.
If your security overview looks alarming, filter out skip and allow actions first. A good share of what looks like attack volume may be your own exceptions working as designed.
Count requests, not rule matches
Cloudflare's grouped analytics said 380 managed-rule blocks. The raw event list said 278. Both were right. They count different things. One request for a file under a .git folder can trip two or three version-control rules at once, and the grouped view counts each match. In our window, 60 requests matched more than one rule. If you report "blocks" from the grouped view, you will overstate attack volume by about a third, as we nearly did. Count unique requests: Cloudflare gives each one a ray ID.
What our feed already knew
Cloudflare's managed rules block by what a request looks like: the path, the payload, the pattern. Our feed blocks by who is sending it. Those are different jobs, and the overlap tells you something.
Three of the 13 probers were in our feed before Cloudflare's first block of them in the window. They sent 37 of the 278 requests. The longest lead was 26 days: our own edge decoys caught that prober on September 23, and it came back yesterday.
The busiest prober, 163 requests against our sensor host, entered our feed this afternoon from our own decoys, during the same scan. That is fast, but it is not a lead, and we do not count it as one. Our first pass at this number did count it and came out at 79%. The honest figure is 13%.
Nine were not listed. Eight sent one or two requests each, which is background noise. The ninth sent 69 requests across three rule types against our research site. We added it to the feed by hand.
Our feed is not ahead of Cloudflare here, and Cloudflare is not ahead of our feed. Cloudflare catches the request whoever sends it. A feed blocks the sender on every path, including the paths that look normal. You want both.
The old list we forgot about
The biggest single block layer that day was not Cloudflare's rules or our current feed. It was an IP list in a firewall rule we set up last spring, which blocked 431 requests. In May we moved live IP blocking into Edge Shield, the open-source Cloudflare Worker we publish and run on our own sites, and that old list stopped being updated. We sampled 40 of the 204 addresses it blocked that day. Thirty-four are no longer in our feed at all, and the other six first entered it between 172 and 254 days ago.
A blocklist that nobody refreshes keeps blocking. It drifts from "known bad" to "was bad once," and nothing on the dashboard tells you. Check the age of what your lists are blocking, not just the count. Retiring or refreshing this one is our next decision.
The trap we almost shipped
The obvious next step was automation: every day, put any prober Cloudflare blocked into our feed. Many teams do exactly this with fail2ban or a WAF-log script. Our own security review stopped it before the first run.
An attacker cannot fake the address a request comes from. They can send probes from an address they share with thousands of other people: a Tor exit, a commercial VPN, iCloud Private Relay, or a mobile carrier's shared address. Auto-blocklist that address, and you have blocked everyone behind it, for every site that uses your list. Our notes already contained this lesson from an earlier project. We wrote the first version anyway.
The job now only measures by default. Promotion is opt-in, and it requires all of the following: not a Tor relay, not a VPN, relay or mobile-carrier network, seen on at least two different days, and no more than five additions a day. If you auto-block from logs, put the same guards in front of it.
A 200 that was not a leak
Our research site answered "200 OK" to requests for .env, phpinfo.php and aws-secret.yaml. That looks like a disaster. It was not. Every one of those responses was the same search page, byte for byte, because the site serves its single-page app for any unknown path. Scanners read a 200 as "something is here," though, and come back for more. That traffic caused 25 timeouts on the site. It now sits behind Edge Shield, and those paths return 403 or decoys.
If your app has a catch-all route, return a real 404 for dotfiles and server-side script paths. And before you call a 200 a leak, compare it with your home page.
Use what you already own
You do not need to buy anything to do what we did today.
Cloudflare: filter skip and allow out of Security Events, group by IP, and count ray IDs, not rule matches. The managed rules come with paid plans. The Free plan has a smaller free managed ruleset. Turn on whichever you have.
Add a sender layer: a WAF custom rule with an IP list you refresh on a schedule, or our Edge Shield Worker, which pulls the feed for you. Block at confidence 80 or higher. That is the floor we use on our own sites.
Firewalls you already run: pfSense and OPNsense URL-table aliases, FortiGate external threat feeds and Palo Alto external dynamic lists can all pull the same IP list over HTTPS on a schedule.
Your SIEM: compare what your WAF blocked with what your feed held, and track the share that was held before the block. That number is how you judge whether a feed is worth its cost, ours included.
Before any auto-blocking: exclude Tor, VPN and relay networks and mobile carriers, require an address to show up on more than one day, and cap how many you add per day.
The free key that pulls our IP list, for any of the tools above, is at https://analytics.dugganusa.com/stix/register?utm_source=blog&utm_campaign=cloudflare-free-comparator
If this was useful, or if it was not, the rating widget below takes ten seconds and is the only way we know.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=cloudflare-blocked-278-probe-requests-on-our-sites-in-a-day-our-feed-had-listed-3-of-the-13-probers
Comments