Itnetic TechnologiesMitigation vs. protection
The two words get used interchangeably in marketing, but they describe different things. DDoS protection is the product you buy. DDoS mitigation is the mechanism inside it: the continuous work of separating attack traffic from real visitors and discarding the former without inconveniencing the latter.
That distinction matters when you compare vendors. Almost every hosting provider and network claims "DDoS protection." What they often mean is that they will absorb a volumetric flood aimed at their own infrastructure — and null-route your IP address if your site becomes expensive to keep online. That is protection for the provider, not mitigation for you.
The four stages of DDoS mitigation
| Stage | What happens | What good looks like |
|---|---|---|
| 1. Detection | Traffic is compared against a baseline of normal behavior per host, endpoint and client | Seconds, automatic, no human paging required |
| 2. Diversion | Traffic is routed through a filtering layer instead of straight to your origin | Already in place before the attack (always-on) |
| 3. Filtering | Attack traffic is dropped; legitimate requests pass through | Bad traffic gone, real visitors never see a CAPTCHA |
| 4. Adaptation | Rules tighten as the attack shifts, and every verdict is logged | Adjusts within the attack, not after it |
Most failures happen at stages 2 and 4. Diversion set up mid-incident costs you the whole propagation window while you are down, and a filter that cannot adapt gets defeated the moment the attacker rotates tactics — new source ranges, a different endpoint, randomized query strings to bust your cache.
Where mitigation happens
On-premise appliances sit in your own rack. They see your traffic in full detail, but they are behind your uplink — so a flood large enough to saturate that uplink wins before the appliance can act. Useful as a complement, useless as your only line.
ISP or hosting-level scrubbing stops volumetric floods upstream, where there is capacity to absorb them. It rarely understands your application, so Layer 7 attacks pass straight through as "valid HTTP."
Cloud edge mitigation terminates connections at points of presence distributed around the internet, filters there, and forwards only clean traffic to your origin. This is where modern mitigation lives, because it combines upstream capacity with request-level application awareness.
Always-on vs. on-demand
On-demand mitigation is dormant until someone — or something — decides you are under attack, then reroutes your traffic into a scrubbing center. It is cheaper, and it is the wrong trade.
| Always-on | On-demand | |
|---|---|---|
| Time to mitigate | Effectively zero — traffic already flows through the filter | Minutes to tens of minutes of downtime while diversion propagates |
| Short bursts | Absorbed silently | Often over before mitigation activates |
| Layer 7 detection | Continuous baseline of your normal traffic | Cold start with no behavioral history |
| Operational risk | None during an incident | Requires a correct decision under pressure |
The practical argument is simple: attacks are cheap to launch and often arrive in short waves specifically to stay under an activation threshold. If your mitigation has to be switched on, the attacker sets your downtime.
How your traffic reaches the filter
There are two common ways to get traffic into a mitigation network.
DNS / reverse proxy — you point your domain's records at the mitigation provider, which becomes the public front door for your site. HTTP and HTTPS requests terminate at the edge, get filtered, and are forwarded to your origin. Setup takes minutes and needs no network engineering, which is why it is the standard route for websites and APIs. This is how Itnetic's DDoS protection works: two DNS records, protected in about five minutes.
BGP announcement / anycast — the provider announces your IP prefix and returns clean traffic over a tunnel. It protects every protocol, not just HTTP, but it requires your own address space and a network team. This is the route for ISPs, hosting companies and large enterprises.
Whichever you use, mitigation is only as good as your origin lockdown. If your server's real IP address is still reachable from the internet, attackers will skip the filter entirely and hit it directly. Firewall the origin to accept traffic only from your mitigation network — the full checklist is in how to hide your origin IP address.
Mitigation techniques, by layer
Volumetric and protocol attacks (Layers 3–4) are mitigated with raw capacity and stateless filtering: absorbing gigabits across a distributed network, dropping spoofed and malformed packets, cutting off amplification sources, and validating handshakes so SYN floods never reach your connection table.
Layer 7 attacks cannot be filtered this way, because every individual request is well-formed and plausible. Mitigation there is behavioral:
- Browser verification — a lightweight, invisible check that the client is a real browser rather than a script pretending to be one.
- Client fingerprinting — TLS and HTTP signatures that reveal automation regardless of the declared user agent.
- Traffic baselines — per-host, per-endpoint models of normal rhythm, so a flood on your login or search endpoint stands out even at modest volume.
- Rate limits and WAF rules — deterministic limits on expensive paths, plus allow/block/challenge by path, header, method, country or fingerprint.
- Edge caching — every cache hit is a request your origin never serves, which is why a CDN doubles as attack armor.
How to choose a mitigation provider
Six questions cut through most marketing:
- How fast is time to mitigate? Ask whether protection is always-on and what happens in the first thirty seconds of a new attack pattern.
- What happens to real users? A filter that challenges everyone is trading your conversion rate for uptime. Legitimate visitors should pass without friction.
- Is attack traffic billed to me? Being attacked should not produce an invoice. Itnetic never meters attack traffic against bandwidth quotas — see pricing.
- Can I prove what was blocked? You will need per-request evidence for post-incident review and for anyone asking why a customer was affected. That is what request logs and analytics are for.
- Does it cover APIs, not just browsers? API clients cannot solve browser challenges, so API paths need rate limits and signature-based filtering that return proper status codes instead of HTML.
- Where are the filtering locations? Mitigation happens at the edge nearest your visitors; coverage determines both latency and absorption capacity. Ours is listed on the network page.
Common myths that cost uptime
"We will just add more servers." Attackers add capacity faster and more cheaply than you can. Scaling to meet an attack is paying to serve it.
"Our firewall handles it." Firewalls evaluate single requests. Application-layer floods are made of individually valid requests — the attack exists only in the aggregate.
"We are too small to be targeted." Attack capacity rents by the hour for a few dollars. Small shops, game servers and community sites are hit constantly, often by competitors or extortionists. Public guidance from CISA makes the same point.
"We will turn it on if it happens." See the always-on table above. The first minutes of an attack are the worst possible time to configure infrastructure.
Where Itnetic fits
We are not trying to out-scale the hyperscalers on raw gigabits — volumetric floods are absorbed by the underlying network before they reach the application layer. Our focus is the traffic that hides inside your real traffic: slow drips, credential stuffing, fake checkouts, bots that look like customers. Filtering runs continuously at every edge PoP, real visitors pass without CAPTCHAs, every block is logged, and attack traffic is never charged to you.
If you want mitigation in place before the next wave, Itnetic's DDoS protection is two DNS records and a free Starter plan. Start with what a DDoS attack is if you want the attacker's side of the story first.