DDoS Protection CDN: What It Actually Stops and What Still Gets Through

A CDN absorbs a volumetric attack because it has more network capacity than the attacker, and it defeats an application-layer attack only if you configure it to, and it does nothing at all if your origin address is still reachable directly.

That last clause is the one that catches people. Teams put a CDN in front of their site, see the marketing about terabits of capacity, and assume they are covered. Then an attacker resolves an old DNS record, finds the origin, and addresses it directly, and every one of those terabits is irrelevant.

This is what the protection actually consists of, by attack layer, and the configuration that makes it real rather than nominal.

Table of contents

• The three layers of attack, and which the CDN handles
• Origin protection is the step that makes any of it real
• Configuring for the layer 7 attack you will actually get
• What a CDN does not protect
• What to do before an attack, in priority order
• How this fits the rest of the stack
• FAQ

The three layers of attack, and which the CDN handles

Denial of service attacks are usually grouped by which layer they exhaust, and the mitigation differs sharply between them.

Volumetric, at the network layer. Amplification and reflection attacks that simply send more traffic than your connection can carry. This is what CDN capacity genuinely solves: the traffic lands on a distributed network with far more headroom than your origin, and never reaches you. This is the easiest category to defend and the one most marketing is about.

Protocol, at the transport layer. SYN floods and similar, exhausting connection state rather than bandwidth. Also handled well at the edge, because the proxy completes the handshake before forwarding anything, so half-open connections never reach your server.

Application, at layer 7. Requests that look legitimate, aimed at whatever is expensive: a search endpoint, a report generator, a login form. Volume can be modest. This is the category a CDN does not stop by default, because each request is individually valid, and it is the category that actually takes sites down these days.

The practical consequence: the default configuration handles the first two well, and the third needs work from you.

Origin protection is the step that makes any of it real

If an attacker can find and reach your origin address, the CDN is a suggestion. Bypassing it is a matter of sending requests directly to the address rather than the hostname.

Origin addresses leak more easily than people expect:

• Historical DNS records, archived by services that specialise in exactly this.
• An MX record pointing at the same machine that serves the website.
• Outbound connections from your server, such as a webhook or an email header revealing the sending address.
• A subdomain not proxied through the CDN, which is often a staging or admin host.
• TLS certificate transparency logs listing hostnames you did not intend to publish.
• An error page or a debug endpoint that prints the server address.

The fix is to make the origin unreachable except from the CDN. At the firewall, allow inbound 80 and 443 only from your provider’s published address ranges, and drop everything else.

# Deny by default, then allow only the CDN ranges.
sudo ufw default deny incoming
sudo ufw allow OpenSSH
for range in $(curl -s https://your-cdn-provider.example/ips-v4); do
  sudo ufw allow from "$range" to any port 443 proto tcp
done
sudo ufw enable

Then verify it from outside. If curl --resolve against your origin address returns your site, you are not protected yet.

curl -sv --resolve example.com:443:ORIGIN_IP https://example.com/ 2>&1 | head -20

Rotating the origin address after you enable protection is worth doing, because the old one is already in historical DNS archives and firewalling it does not remove it from those records.

Configuring for the layer 7 attack you will actually get

The realistic attack is a few thousand requests per second against your most expensive endpoint from a rotating set of addresses, and no amount of edge capacity blocks it because every request is valid.

What works is a set of specific rules rather than a global setting:

1. Rate limit by endpoint, not globally. Your login route, your search, your password reset and your report generator each deserve a limit sized to legitimate use. A single site-wide limit is either too loose to help or too tight for real users.
2. Rate limit authentication by account as well as by address. Distributed credential stuffing defeats address-based limits by design.
3. Cache aggressively so the expensive paths are fewer. Every request served from the edge is a request your origin never sees, which means a good cache hit ratio is a denial-of-service control as well as a performance one.
4. Challenge rather than block for ambiguous traffic. A managed challenge costs a real user a moment and costs a simple bot everything, and it fails safe in a way that an outright block does not.
5. Have a prepared lockdown mode. A rule set you can enable in one click that challenges everything, so during an attack you are toggling something you tested rather than authoring policy under pressure.

Test the rules before you need them. A rate limit you have never triggered is a rule you have never verified, and the common discovery during an incident is that it was scoped to a path that does not match.

What a CDN does not protect

Worth being explicit, because the assumption that everything is behind the CDN is usually wrong somewhere.

• Anything not proxied. Records set to bypass the CDN, which frequently includes mail, FTP, SSH and staging hosts, are exposed directly.
• Non-HTTP services. A game server, a database port or a custom TCP protocol needs different products entirely.
• Your API consumed by mobile clients, if those clients pin certificates or bypass the proxy for their own reasons.
• Slow-drip attacks below your rate thresholds that are still expensive per request. This is where caching and query optimisation matter more than any edge rule.
• Application vulnerabilities. A single unauthenticated endpoint that runs an expensive query is a denial of service waiting to be discovered, and no edge configuration fixes a design where one request costs you thirty seconds of database time.

What to do before an attack, in priority order

Ordered by how much risk each removes for the effort involved.

1. Firewall the origin to CDN ranges only, and verify from outside that a direct connection fails.
2. Rotate the origin address so historical records are stale.
3. Confirm every DNS record is proxied, including the ones added months ago for a service you forgot.
4. Add per-endpoint rate limits to the expensive paths and actually trigger them once in testing.
5. Raise your cache hit ratio, because it is the cheapest capacity you will ever add.
6. Write the one-page runbook: who to call, which rule to enable, where the traffic dashboard is.
7. Set alerting on origin request rate rather than only on error rate, so you see the attack before it succeeds.

The first three are an afternoon and remove most of the realistic risk. The rest is the difference between a bad hour and a bad week.

One structural note: the fewer things you expose, the less of this applies. A deployment where the application is reachable only through the platform’s routing, and the database only over private networking, has a much smaller surface to defend than a VPS with a public address and several open ports. The database network security docs cover that half on RunxBuild.

How this fits the rest of the stack

Denial of service protection is one of those costs that looks optional until the week it is not, and it sits alongside bandwidth, compute and the database in the same budget. Working out what the whole stack costs, including the egress an attack can generate, is worth doing before rather than during. The RunxBuild hosting calculator puts those line items together, and bandwidth is the one to look at hardest, since a sustained attack against an uncached path is a bandwidth event as much as an availability one.

Useful related references:

• Cloud Edge: Edge Computing, CDN, and 5G MEC
• WHOIS Privacy Protection: What It Hides and What It Cannot
• Container Runtime Protection: Why Scanning the Image Is Only Half the Job
• Services on RunxBuild

FAQ

Does a CDN stop all DDoS attacks?

No. It handles volumetric and protocol attacks well, because the edge has far more capacity than your origin and completes handshakes before forwarding. Application-layer attacks, where each request looks legitimate, require explicit rate limiting and caching rules that you configure yourself.

How can attackers bypass my CDN?

By finding your origin address and connecting to it directly. Addresses leak through historical DNS records, MX records on the same host, unproxied subdomains, certificate transparency logs and outbound connections from your server. Firewalling the origin to only accept the CDN address ranges is what closes this.

Should I rotate my origin IP after enabling a CDN?

Yes, if the address was ever public. Historical DNS archives keep records indefinitely, so an address that served your site directly is discoverable regardless of what your current records say. Rotating gives you an address with no public history, and firewalling keeps it that way.

What rate limits should I set?

Per-endpoint rather than site-wide, sized to legitimate use for that specific path. Authentication endpoints deserve tight limits by account as well as by address. A single global limit is either too loose to stop an attack on an expensive route or too tight for normal users on cheap ones.

Does caching help against DDoS?

Significantly, and it is the most underrated control here. Every request served from the edge cache is a request your origin never processes, so a high hit ratio directly multiplies the traffic you can absorb. Improving cacheability is often cheaper and more effective than any dedicated mitigation feature.