Cloudflare Can’t Save You From a DoS (I Checked)

Since 2017, I assumed Cloudflare was a silver bullet for denial-of-service attacks. I recommended it to friends, colleagues, and new startups. I understood the theory, but until you are under active attack, you do not really know.

It turns out, it does not stop everything. It does a good job, not a great job.

First Contact

My wake-up call came at 10 PM while serving as CTO for a crypto exchange. My phone started buzzing, not because I'd won a prixe or Cloudflare sent an alert (because they don't, afaik), but because our databases were dying, fast.

I contacted support. It was useless. The agent told me to block the Google ASN (still not sure why, I think the dude was confused about ingress and egress). Since we were hosted on Google Cloud, that would have killed us instantly. I quit the chat, found the offender's ASN, and manually blocked half of Austria to stop the bleeding.

During the call, the agent told me it "wasn't really an attack."

Technically, he was right. It wasn't a massive volumetric DDoS. It was just one bad actor sending specific, high-intent traffic that bypassed the edge and hit us where it hurt.

The Reality Check

Cloudflare is excellent at absorbing massive floods, but it leaves a critical gap between the edge and your kernel. Here is where the protection breaks.

1. Mitigation Thresholds vs. Resource Exhaustion Cloudflare is optimized for massive anomalies. But a low-bandwidth, high-intent attack can be devastating without ever tripping a volumetric alarm. You do not need 100Gbps to kill a service; you just need enough specifically crafted packets to exhaust connection tables or starve a validator. Small attacks slip through the "giant shield" logic but still take you offline.

2. The Origin IP Bypass Cloudflare only protects traffic that proxies through them. If an attacker discovers your origin IP--or if you are running P2P nodes, validators, or RPC services that must expose a public IP--the edge is bypassed entirely. At that point, there is no WAF and no rate limiting. Your network interface is naked.

3. The Layer 7 Limitation Cloudflare operates primarily at the application layer. Many failures happen deeper in the stack. Aggressive SYN floods, malformed packets, and protocol abuse strike the kernel before an HTTP request is even formed. If your defense relies on parsing HTTP, you have already lost the battle against L3/L4 attacks.

4. The Kernel Bottleneck Even if Cloudflare filters 99% of the noise, the 1% that bleeds through still hits your OS. Standard Linux networking (conntrack, interrupt handling) is expensive. Processing garbage traffic in userspace--or even just letting the kernel drop it via standard tables--burns CPU.

5. Centralization Risk Cloudflare is a centralized dependency. If they go down, misroute traffic, or degrade, you inherit that failure. As recent internet history shows, relying entirely on one upstream provider means your availability is no longer under your control.

Conclusion

Cloudflare is necessary, but not sufficient. If you run critical infrastructure, you cannot assume the edge will save you. You need defense that sits inline, on the host, and enforces policy before the kernel commits resources.

Below is a video of my own DoS tool taking down a demo server (running PHP and MySQL) that relied solely on standard protections.

On the left hand side, we're running a homemade monitor. On the right, we're running our adaptive dos tool. Initially we hit the IP and you see it deplete in seconds. Then, we run on a test host we have behind Cloudflare. Initially you can see the first attack is blocked, because Cloudflare DO block slow http attacks well. But as we layer the attack up, the server slowly slows to a crawl.

Arguably, it never actually dies but it's borderline useless right now - and exactly the reason my phone was buzzing at 10pm.

Thanks!

If you want to discuss this with me, drop me a line.