DDoS and Availability Attacks
Availability is a security property. An attacker does not need your data if they can make you unreachable — and the cheapest attacks rent for the price of a coffee.
The three shapes
| Class | Mechanism | Example | Size |
|---|---|---|---|
| Volumetric | Saturate bandwidth | UDP flood, DNS/NTP/memcached amplification | Hundreds of Gbps |
| Protocol / state | Exhaust a state table or handshake queue | SYN flood, fragmented packets | Millions of pps |
| Application | Look like real users, expensive per request | HTTP flood, slowloris, API abuse | Low bandwidth, high cost |
Application-layer attacks are the ones that get through volumetric scrubbing, because they use valid TCP connections and valid TLS.
Amplification: why the attacker's bandwidth does not matter
Spoof the victim's source IP in a query to an open resolver; the resolver sends a much larger answer to the victim.
| Reflector | Port | Amplification (approx.) |
|---|---|---|
| DNS | 53 | 30–50× |
| NTP (monlist) | 123 | 200–500× (mostly mitigated now) |
| Memcached | 11211 | 10,000–50,000× |
| SSDP | 1900 | 30× |
| CLDAP | 389 | 50–70× |
The defence is BCP 38 (ingress filtering) at every network edge, so spoofed sources cannot leave — plus not running open reflectors.
What mitigation actually looks like
- Anycast — announce the same prefix from many locations; attack traffic lands near its source.
- Scrubbing — divert traffic to a provider that filters and forwards clean traffic.
- Rate limiting — per-IP, per-connection, per-endpoint; blunt but effective against floods.
- SYN cookies — the kernel stops allocating state until the handshake completes.
- Connection limits and timeouts — slowloris dies when a half-open request has a deadline.
- Caching and static fallbacks — a CDN absorbs the load that a database cannot.
- Autoscaling with a budget — capacity helps until the bill arrives; set ceilings.
The operational side
Availability is also a process problem:
- Know your capacity baseline and your attack signature (which endpoint, which method).
- Have a runbook that says who can enable scrubbing and at what threshold.
- Keep a static "we are under attack" page served from infrastructure that is not the target.
- Rehearse. The first DDoS is not the time to discover the provider's activation lead time.
Where it goes wrong
- Scrubbing enabled after the link is saturated. Activation needs lead time; detection must be earlier than intuition suggests.
- Blocking by IP during an attack. Attacker IPs rotate; you block a shared NAT and take out a customer.
- Auto-scaling into bankruptcy. Elastic capacity is a billing attack surface.
- Health checks that fail under load. The load balancer removes backends that are merely slow, making the outage worse.
- State exhaustion on the firewall. The firewall becomes the outage: conntrack full, new flows dropped, everything looks like a network failure.
- Forgetting the recursive DNS and the auth DNS. If DNS is down, nothing else matters, including the mitigation provider's hostname.
- No baseline. Without normal, an attack looks like a busy Tuesday until it is too late.
Related Notes
- Network Security Fundamentals — the wider threat model
- BGP And Internet Routing — anycast and prefix announcements
- Load Balancing — where rate limits live
- Telemetry And Monitoring — detecting the baseline change