DDoS Protection: Layered Defense Guide

A DDoS attack does not try to steal your data. It tries to make your service unavailable — and it succeeds by exhausting whichever resource runs out first: your bandwidth, your connection table, your CPU, or your database.

That is why the honest answer to "how do I protect against a DDoS attack" is not a single product or a firewall rule. Different attacks exhaust different resources, and each layer of defence covers a different failure. This guide walks through the layers in the order they actually stop attacks, then gives you a runbook for the moment one is already happening.

If your site is down right now, skip ahead to what to do during an attack — or contact our incident response team directly.

What a DDoS attack actually exhausts

Attack family	Examples	What it fills up	Where it must be stopped
Volumetric	UDP floods, DNS/NTP amplification, carpet bombing	Your network pipe	Upstream, by your host or a scrubbing network
Protocol / state exhaustion	SYN floods, ACK floods, connection floods	Connection tables on servers, firewalls, load balancers	Edge rate limits + kernel tuning + SYN cookies
Application layer (L7)	HTTP floods, cache-busting, slowloris, API abuse	CPU, workers, database connections	CDN/WAF, caching, application-level rate limits

The practical consequence: if the attack is larger than your uplink, nothing you configure on the server matters. The packets have already won by the time a local firewall rule sees them. Volumetric protection has to live upstream. Everything else you can harden yourself.

The nine layers of DDoS protection

1. Put a mitigation layer upstream of your origin

Every serious defence starts with capacity you do not own. Cloud scrubbing and anycast networks spread attack traffic across dozens of locations, filter it, and forward only clean requests to your server.

What to do:

Put your public traffic behind a CDN or reverse proxy with DDoS mitigation included (Cloudflare, AWS CloudFront + Shield, Azure Front Door, Gcore, Bunny, Fastly).
Ask your hosting provider what mitigation capacity sits in front of your IP, and whether it is always-on or only triggered on detection. On-demand protection leaves a gap at the exact moment the attack starts.
Prefer anycast. It dilutes volumetric floods geographically instead of asking one datacentre to absorb them.

The common mistake is assuming a CDN alone is enough. It is layer one of nine.

2. Lock down your origin IP

This is the step most teams skip, and it silently undoes layer one. If an attacker learns your real server IP, they simply bypass the CDN and hit the origin directly — a technique called direct-to-origin (D2O).

Where origin IPs leak:

DNS history archives — old A records from before you moved behind the proxy.
Certificate transparency logs — TLS certificates issued for the origin hostname.
Subdomains — mail., vpn., ftp., dev. often resolve straight to the same server.
Email headers — outbound mail can carry the origin IP in Received: lines.
Legacy records — MX, SPF and TXT entries pointing at infrastructure outside the CDN.

What to do: rotate the origin IP after the CDN is live, firewall the origin so only the CDN's published IP ranges can reach ports 80/443, and re-check your own exposure quarterly.

3. Deploy a WAF for layer 7

A network firewall sees a valid TCP connection and waves it through. A WAF reads the HTTP request, which is where application-layer attacks live: malformed requests, exploit attempts, bot floods against login and search endpoints.

Enable managed rule sets first (OWASP core rules plus your vendor's threat intelligence), then add targeted custom rules for your own application: block oversized bodies on upload endpoints, challenge requests to admin paths, and rate-limit per endpoint rather than per site.

4. Rate limit at every tier

Rate limiting is the most cost-effective control you have, and the most commonly misconfigured. Rules applied only at the web server do nothing against traffic that saturates the network first, and rules keyed only on IP address do little against a botnet with thousands of source addresses.

Layer your limits:

Edge: requests per IP, per ASN, per country where appropriate.
Application: per session, per API key, per authenticated user.
Endpoint-specific: tight limits on login, password reset, search and checkout — the expensive routes attackers target.

Use token-bucket or sliding-window limits rather than hard per-second caps, and return 429 with a Retry-After header so legitimate clients back off instead of retrying aggressively.

5. Harden the TCP stack

SYN floods fill the connection table before a single HTTP request arrives. The fixes are old, boring, and effective:

Enable SYN cookies.
Raise the listen backlog and tune somaxconn / tcp_max_syn_backlog to match real concurrency.
Shorten tcp_fin_timeout, and reduce keepalive times on load balancers.
Cap concurrent connections per source at the edge.

Test the change under load — tuning values copied from a blog post without measuring your own baseline usually makes things worse.

6. Make caching do the work

A request served from cache never reaches your origin, so it never consumes a worker or a database connection. Anything that can be static should be static: images, CSS, JS and HTML for anonymous visitors.

Two details matter under attack:

Cache-busting is an attack technique. Randomised query strings force every request through to origin. Configure your CDN to ignore irrelevant query parameters on cacheable routes.
Cache hit ratio is a security metric. If it drops from 85% to 20% during an incident, you are paying origin cost for attack traffic.

7. Instrument a baseline and alert on deviation

You cannot defend against what you cannot see. Before an attack, record what normal looks like: requests per second, bytes in and out, 4xx/5xx rate, p95 latency, connection counts, top URLs.

Then alert on deviation, not on absolutes: a 5x spike in RPS with a stable 5xx rate is often a marketing win, while a flat RPS with climbing latency and connection counts is a state-exhaustion attack. NetFlow or IPFIX data plus application logs gives you both views.

8. Write the runbook before you need it

Under attack is the worst time to decide who calls the host, who talks to customers, and who has permission to enable "under attack" mode. Write a one-page runbook:

Who declares an incident and where they announce it.
Who contacts the hosting provider or CDN support (with account numbers).
Which controls get enabled in what order, and who can enable them.
Who communicates with customers, and what the holding statement says.
When to invoke legal or law-enforcement options, especially for extortion.

Rehearse it once a quarter with a tabletop exercise. A runbook nobody has read is decoration.

9. Buy capacity with a contract, not a hope

For businesses where downtime directly costs revenue, mitigation capacity should be contractual: a scrubbing SLA, a defined scrubbing threshold, named escalation contacts, and a support tier that answers during an attack.

Cheap or free tiers are excellent for small sites and terrible for businesses that lose thousands per hour of downtime. Match the tier to the actual cost of an outage.

If you are under attack right now

Work in this order — it moves from least disruptive to most:

Confirm it is an attack. Check traffic sources, request patterns, top URLs and geography. Compare against a legitimate campaign before blocking anything.
Identify the layer. Saturated bandwidth points upstream; connection-table exhaustion points at L3/L4; CPU and latency on specific endpoints point at L7.
Open a ticket with your provider immediately. Upstream mitigation takes time to activate — start it before you finish diagnosing.
Enable your edge controls. Under-attack mode, managed WAF rules, tightened rate limits, and a JS challenge on the most abused routes.
Protect the origin. Confirm the origin only accepts traffic from the CDN, and block direct-to-IP requests.
Communicate. Status page first, support channels second. Silence generates more damage than the attack.
Preserve evidence. Keep logs, packet captures and timestamps — they matter for the provider, for insurance, and for any legal follow-up.

If the attack is combined with extortion — a demand for payment to stop — do not negotiate on the attacker's terms. Our incident response team handles active attacks, extortion attempts and post-incident hardening, and can work alongside your host while mitigation is in progress.

The 10-minute readiness checklist

Public traffic routes through a CDN or scrubbing service with DDoS mitigation.
Origin IP is rotated, firewalled to the provider's ranges, and not discoverable via DNS history or certificate logs.
WAF is enabled with managed rules plus custom rules for admin and login paths.
Rate limits exist at the edge, in the application, and on expensive endpoints.
SYN cookies are on and connection limits are tuned against a measured baseline.
Static assets and anonymous HTML are cached with a high hit ratio.
Dashboards and alerts cover RPS, bandwidth, error rate, latency and connections.
A one-page incident runbook exists, is current, and has named owners.
The hosting or CDN contract specifies mitigation capacity and support response.
Someone has run this checklist in the last quarter.

Any unchecked box is a gap worth a third-party assessment — we test the path an attack would take, from edge configuration down to application behaviour, and report what fails first.

What DDoS protection actually costs

Rough tiers, from most to least accessible:

Option	Typical cost	Good for
CDN free/pro tier (Cloudflare, Bunny)	$0–$25/month	Blogs, small business sites, low-risk SaaS
Cloud provider protection (AWS Shield Standard)	Included with infrastructure	Workloads already on that cloud
Managed WAF + DDoS (Gcore, Imperva, AWS Shield Advanced)	~$55–$3,000+/month	Revenue-critical applications, compliance needs
Dedicated scrubbing (Akamai, Radware, Link11, Myra)	Enterprise contracts, often $5,000+/month	High-value targets, gaming, finance

The number that matters is not the subscription cost — it is the cost of an hour of downtime, multiplied by how often you expect to be targeted. For most small businesses, the honest answer is that a well-configured free or low-tier setup plus a tested runbook beats an expensive appliance nobody knows how to operate.

Common mistakes that keep sites down

Blocking the CDN's own IP ranges. It looks like an efficient block during an attack and takes your site down completely.
Per-IP limits only. Botnets rotate source addresses; key on behaviour as well.
Protecting the homepage but not the API. Attackers find the expensive endpoint.
Ignoring L3/L4 entirely. A SYN flood never appears in your HTTP logs.
No origin protection. The CDN absorbs the flood while the attacker hammers the real IP.
Untested runbook. Under pressure, people default to the wrong action first.

FAQ

Can a DDoS attack be prevented completely? No. Anyone can send traffic toward a public service. The realistic goal is to absorb and filter it while keeping legitimate users online, which is what layered protection does.

Is a CDN enough to stop a DDoS attack? A CDN handles volumetric floods and a lot of L7 abuse, but it does not fix origin exposure, application-level abuse of expensive endpoints, or state exhaustion. It is one layer.

How do I tell a DDoS attack from a traffic spike? Look at composition, not volume: a spike from one geography or one URL, with unusual user agents, rising latency and a flat conversion rate, is an attack. A spike spread across your normal sources is usually a campaign working.

What should a small business do first? Put traffic behind a CDN with mitigation, lock down the origin IP, enable managed WAF rules, and write the one-page runbook. That order covers the most common attacks for the least money.

Do I need a dedicated DDoS provider? Only if downtime costs more than the contract. Start with the CDN tier, measure your real exposure, then upgrade when the economics justify it.

Where to go next

Layered defence is mostly configuration hygiene: an upstream layer with capacity, an origin nobody can find, request controls that match your application, and a runbook the team has actually rehearsed. Our cybersecurity consulting team can review your current setup against all nine layers and hand you a prioritised fix list — and if you have already been hit, contact us for incident response rather than waiting for the next wave.

Related reading: the top ten signs your company is compromised for detection indicators, the dark web price index for what attack services cost on criminal markets, and AI-powered phishing for the social-engineering side of the same threat landscape.