Itnetic TechnologiesA vector is a technique, not a number
Most coverage of DDoS attacks reports one number: peak bandwidth or peak request rate. That number tells you almost nothing about how hard an attack is to stop. What matters is how many different techniques it uses, because each technique has to be defeated by a different mechanism in a different place.
A single-vector attack is one technique: a SYN flood, or a DNS amplification flood, or an HTTP request flood. A multi-vector attack runs several at once, or in sequence, against the same target.
| Layer | Vector in the mix | What it tries to exhaust |
|---|---|---|
| 3 — Network | UDP amplification, reflected floods, ICMP floods | Your uplink bandwidth and upstream capacity |
| 4 — Transport | SYN, ACK and RST floods, TCP state exhaustion | Connection tables and packet-processing budget |
| 6 — TLS | Handshake and renegotiation floods | CPU cycles spent on asymmetric cryptography |
| 7 — Application | HTTP request floods, cache-busting query strings, low and slow | Workers, database connections, origin CPU |
The reason this matters commercially: a 300 Gbps single-vector flood is a capacity problem, and capacity is something you can buy. A 2 Gbps attack that rotates across four of the rows above is an architecture problem, and no amount of bandwidth solves it.
Why attackers rotate vectors
Rented attack capacity is sold by the hour, and the operator wants your downtime for the lowest spend. Rotation is how they find the cheap route in. The sequence is almost always the same:
- Probe. Send a short burst on one vector and watch what happens — does the site slow, time out, return a challenge, return an error page from a different server than before?
- Read the response. A 503 from your origin means the flood reached it. A clean block page means it did not. A degraded-but-alive site means you are nearly at a limit.
- Concentrate. Push the vector that produced the most degradation per unit of rented capacity.
- Switch when it stops working. As soon as mitigation adapts, move to another layer and repeat.
This is why "we survived the first wave" is such a poor signal. The first wave was reconnaissance. Public incident guidance from CISA makes the same point about treating a short outage as a warning rather than a conclusion.
There is a second motive worth knowing about: diversion. A loud volumetric flood occupies everyone's attention and fills every dashboard, while a quiet, low-rate application attack runs underneath it — credential stuffing on your login endpoint, inventory scraping, card testing in your checkout. The flood is not the attack. It is the cover.
A composite incident, minute by minute
The timeline below is a composite of how these incidents actually run, not a single customer's log. The shape is what to recognise.
| Time | What the attacker does | What it looks like to you |
|---|---|---|
| T+0 | 40 Gbps of UDP amplification at the IP | Uplink saturates, everything is unreachable, monitoring pages everyone |
| T+8 | Volumetric stops; SYN flood starts at a few hundred thousand packets per second | Bandwidth graph drops to normal — looks like the attack ended. It did not |
| T+20 | SYN flood stops; 80k requests/sec of plain HTTP GETs with randomized query strings | Bandwidth still normal, CPU at 100%, cache hit rate collapses, origin returns 502 |
| T+35 | Request rate drops to 900/sec, spread across 40,000 residential addresses, hitting only the search and login endpoints | Looks like organic traffic. Database connection pool exhausts. No single IP is above your rate limit |
| T+60 | Slow-read connections opened and held across every worker | Concurrency exhausted at near-zero bandwidth. Nothing in your bandwidth or request-rate alerting fires |
| T+90 | Volumetric returns, now aimed at the hostname rather than the IP | Second incident declared by a team that has already been awake for ninety minutes |
Three things in that table decide the outcome, and none of them is capacity. The bandwidth graph going quiet at T+8 is the trap — it is the moment teams stand down. The T+35 shift is the one that defeats most rate limits, because the limit is keyed on IP and no individual address breaches it. And the T+60 phase is invisible to any alerting built on volume, which is most alerting.
Why single-layer defenses fail here specifically
Each of these defenses is reasonable. Each of them covers some rows of the table above and none of the others.
| Defense | Covers | Blind to |
|---|---|---|
| On-premise appliance | L4 and some L7, in detail | Anything that saturates the uplink in front of it — it never gets the packets |
| ISP or hosting scrubbing | L3/L4 volumetric, upstream, with real capacity | L7 entirely: a well-formed HTTP GET is valid traffic by every metric it measures |
| WAF alone | Malicious individual requests | Floods of individually valid requests, and every packet-level vector |
| CDN alone | Cacheable load, which is genuinely most of it | Cache-busting query strings, uncacheable paths, login and checkout, POST bodies |
| Autoscaling | Traffic you want to serve | Traffic you do not — you are paying to serve the attack, and it scales cheaper than you do |
The failure mode is not that any one of these is bad. It is the seams between them. When the vector changes at T+20, the question is whether the thing that handled T+0 and the thing that handles T+20 are on the same path, sharing state, adapting together — or whether a human has to notice the handoff and go configure something.
The three detection failures that cost the incident
Alerting on volume only. Bandwidth and total request rate are the two metrics almost everyone alerts on, and the T+35 and T+60 phases above breach neither. Alert on error rate, origin latency, cache hit ratio, concurrency and connection-pool saturation as well. If exactly one of those is abnormal, you still have an incident.
Declaring the all-clear on one quiet vector. A vector stopping is not an attack ending. Hold the incident open — and the mitigation on — for a defined quiet period rather than on the first clean graph. Decide the length of that period before the attack, as part of your DDoS response plan.
Rate limits keyed only on IP. Against 40,000 residential addresses sending 0.02 requests per second each, an IP-keyed limit is arithmetically useless — this is the core argument in what is rate limiting. Key expensive endpoints on account, session, API credential or client fingerprint instead, so the limit survives distribution.
How a multi-vector attack is actually mitigated
Mitigation has to be layered the same way the attack is, and it has to already be running. The minutes you spend activating protection are minutes of downtime, which is the whole argument for always-on over on-demand in what is DDoS mitigation.
| Vector in the mix | What stops it | Where it has to happen |
|---|---|---|
| Volumetric L3 floods | Absorption capacity and stateless packet drops | Upstream of your server, where the capacity is |
| SYN and state-exhaustion floods | Handshake validation, SYN cookies, kernel-level drops | At the edge, before a connection is tracked |
| TLS handshake floods | Connection termination at the edge, per-source handshake budgets | At the edge PoP, not your origin |
| HTTP request floods | Edge caching, behavioral baselines, invisible proof-of-work | At the edge, per host and per endpoint |
| Distributed low-rate L7 | Identity-keyed rate limits, JA4 and behavioral fingerprinting | At the edge, keyed on something that is not an IP |
| Low and slow | Aggressive timeouts, request buffering, edge connection termination | At the edge, measured in concurrency not volume |
| Cache-busting query strings | Query-string normalisation and WAF rules on the pattern | At the edge cache |
Two properties make this a defense rather than a list:
One path, shared state. When every layer sits on the same always-on path, a verdict reached about a client at T+20 still applies at T+35, even though the vector changed and the fingerprint moved endpoints. Stitching separate products together loses exactly that continuity at the seams.
Per-vector re-baselining inside the incident. Adaptation is the fourth stage of mitigation and the one that decides a multi-vector attack. A per-host, per-endpoint baseline that re-evaluates in seconds will catch the T+35 shift as anomalous even though its absolute volume is unremarkable. A static threshold set before the incident will not.
And none of it holds if your origin is reachable directly. Attackers rotating vectors will try the IP as readily as the hostname — note T+90 in the table — so firewall the origin to accept traffic only from your mitigation network. The checklist is in how to hide your origin IP address.
What to ask your provider
- Are Layer 3/4 and Layer 7 mitigation both always-on, on the same path? If one of them activates on demand, that is the vector the attacker will settle on.
- How fast does detection re-baseline when the vector changes? The useful answer is in seconds, decided at the edge, without a control-plane round trip.
- Can I key a rate limit on something other than an IP? Account, session, API key or client fingerprint. If the answer is IP only, distributed Layer 7 walks through it.
- Is every mitigation feature available on my current plan? During a rotating attack you will want a WAF rule, a rate limit, a waiting room and raw logs within the same hour. Any one of them sitting a tier above you turns incident response into a procurement call.
- Will the attack traffic appear on my invoice? Volumetric vectors move a lot of bytes. Being attacked should not generate a bill — see how much a DDoS attack costs.
- Can I see per-request evidence during the incident, not after it? You cannot identify a vector rotation you cannot observe. That is what request logs and analytics are for.
While it is happening
Keep the response short and ordered. The full version is how to stop a DDoS attack; the multi-vector-specific parts are these:
- Do not stand down on a quiet graph. Hold mitigation on for the full quiet period you defined in advance.
- Watch the shape, not the size. Which endpoints, which fingerprints, which status codes — the size tells you nothing about what to change next.
- Protect the expensive paths first. Login, search, checkout and anything that writes to the database. These fall at volumes that would not register as an attack.
- Assume cover. While the flood runs, check your login failure rate and your checkout error rate. The quiet attack underneath is the one that costs money.
- Log the rotation. Note each vector change and its timestamp as it happens. It is the only record you will have, and it is what makes the next incident shorter.
Where Itnetic fits
Itnetic is built around the division this article describes. Volumetric Layer 3/4 floods are absorbed upstream of our edge, before they reach the application layer — and we publish exactly which networks do that and how much capacity they have on the network page, rather than implying a number. Everything from the TCP handshake upward is ours: handshake validation, TLS termination, edge caching, behavioral and JA4 fingerprinting, invisible proof-of-work instead of CAPTCHAs, identity-keyed rate limits, and adaptive per-host detection that trips into challenge mode within about a second of a spike and fans that verdict out to every other node.
All of it runs on one always-on path, on every plan including the free one. Our plans differ by domain count and delivered bandwidth and by nothing else, so the vector that arrives at T+35 never turns into an upgrade decision — and attack traffic is never metered against your bandwidth quota.
If you want that in place before the next rotation, Itnetic's DDoS protection is two DNS records and about five minutes, with a free Starter plan and pricing from €5/month. If an attack is running right now, start with the emergency steps instead of reading further.