In short. DDoS protection is built in layers: a filtering proxy or anti-DDoS CDN takes the traffic and strips the junk before your server; a WAF cuts malicious requests to the application; rate limiting blunts the flood; a hidden real IP stops attackers from striking around the protection. No single measure saves you — the combination does. Volumetric attacks (a saturated pipe) can only be filtered externally, by someone with a bigger pipe; application-layer attacks (load on the app) can be partly blunted on your own server. The key rule: enable protection before an attack, not during — under fire that means hours of downtime. Below is what the defense is made of and how to build it.
What "protecting against DDoS" means
The goal isn't to "beat the botnet" but to make yourself an unprofitable target — so the attack costs the attacker more than it yields. DDoS doesn't hack the site; it exhausts a resource — bandwidth, CPU, memory, the connection limit, the database pool — and legitimate users stop getting a response. So protection is about keeping junk traffic away from the scarce resource.
DDoS protection isn't one button but a defense in depth. Each layer's job is to strip as much junk as early as possible, so only real users reach your server.
What to do if an attack is already underway is a separate topic; this is about preparation. The under-attack playbook is in "DDoS attack: what to do in the first hour".
The layers of defense
1. Filtering proxy / anti-DDoS CDN
The base and most important layer. Traffic goes not straight to the server but through a protection network (Cloudflare, Qrator, StormWall and similar): it filters requests with its own capacity and passes your server only clean traffic. Only this layer saves you from volumetric attacks — your own 1 Gbps link can't filter ten gigabits; that must be done by someone with a backbone pipe. How traffic is served through a node network is in the CDN article.
2. WAF — the application firewall
Cuts malicious and suspicious requests to the application itself by rules: anomalous headers, injections, bots. Against application-layer (L7) attacks it's the key tool, and it closes hacking attempts along the way. How it works is in the WAF breakdown.
3. Rate limiting
A simple "no more than N requests per second per IP" cuts a large share of the flood right at the door. It's configured both on the web server and at the protection layer. More in the rate limiting article.
4. A hidden real IP
If the server's real address has leaked (in DNS history, mail headers, subdomains), the protection gets bypassed with a direct hit past the proxy. After enabling filtering, the real IP is changed and never published — otherwise all the previous layers are useless.
5. Capacity headroom and degradation
A cache for serving static, a ready "lightweight" version of the site, autoscaling — everything that lets you survive a spike rather than fall to the first gigabit. Let it run in storefront mode under load, but let it run.
Volumetric and application attacks are defended differently
| Attack type | Target | Defense |
|---|---|---|
| L3/L4 — volumetric | Bandwidth and network stack (UDP/SYN flood, amplification) | External filtering only: an anti-DDoS provider / CDN with a big pipe |
| L7 — application | The app (HTTP flood on heavy pages) | WAF + rate limiting + cache; partly blunted on your own server |
Common mistakes
- Enabling protection during an attack. Onboarding under fire means hours of downtime. A filtering proxy is set up in advance.
- Leaving the real IP exposed. The most common reason "protection didn't help" — the attacker hits past it at the direct address.
- Relying on one layer. Rate limiting alone won't stop a volumetric attack; a CDN without a WAF lets an application one through. You need the combination.
- No plan and no monitoring. Half the damage is the time before anyone notices. More below.
Self-managed or managed: which to choose
For a small or mid-size site, managed protection is almost always the better deal — a cloud anti-DDoS/CDN where the provider handles filtering. Self-managed defense (hardware, tuning, on-call) is justified at large sites under constant threat. It's sensible to start with a cloud proxy + WAF + rate limiting — that covers the vast majority of attacks on a typical site.
The best DDoS protection is the one already switched on before the attack. A filter enabled in advance turns an attack from an outage into a line in the log.
Monitoring: know about the attack first
Even with protection, you need to know an attack or degradation has begun. Uptime monitoring checks the site from several points every 30–60 seconds and alerts on the very first failure or rise in response time — the chart shows the attack starting before an outage. You can set it up on enterno.io; while you're at it, check your current protection and headers with the security scanner.
Frequently asked questions
Will Cloudflare / a free CDN protect against any attack?
Against most volumetric ones — yes, that's the strength of cloud filtering. But free tiers have limits, and application-layer (L7) attacks on heavy pages also need a WAF with rules and rate limiting. And all of it is useless if the server's real IP is open — it'll be hit directly.
Can I get protected entirely for free?
Partly: a free CDN proxy + rate limiting on nginx + a hidden real IP cover a large share of threats for a small site. For a serious or targeted attack, free limits won't be enough — you'll need paid anti-DDoS.
Does a small site need protection?
Yes. Ordering an attack on a small site costs less than a streaming subscription, so regional shops, clinics, and services regularly end up in the crosshairs — most often in season and at a competitor's request. The basic layers (proxy + rate limiting + hidden IP) are worth setting up in advance.
Checklist to remember
- Protection is layers: filtering proxy/CDN → WAF → rate limiting → hidden IP → capacity headroom.
- Volumetric attacks are filtered externally only; application ones can be blunted on the server.
- A hidden real IP is mandatory, or the protection gets bypassed directly.
- Enable protection before an attack, not during.
- Even with protection, keep monitoring — to learn of the attack first.