# 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

1. **Anycast** — announce the same prefix from many locations; attack traffic lands near its source.
2. **Scrubbing** — divert traffic to a provider that filters and forwards clean traffic.
3. **Rate limiting** — per-IP, per-connection, per-endpoint; blunt but effective against floods.
4. **SYN cookies** — the kernel stops allocating state until the handshake completes.
5. **Connection limits and timeouts** — slowloris dies when a half-open request has a deadline.
6. **Caching and static fallbacks** — a CDN absorbs the load that a database cannot.
7. **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.

## Teaching hook

**The phone-line analogy.** Volumetric is jamming the exchange; protocol is dialling thousands of times and never speaking; application is 10,000 callers asking a question only one clerk can answer. Each needs a different defence, which is why "we have a big pipe" solves exactly one third of the problem.

Exercise: give learners a traffic graph (normal + attack) and ask which of the three shapes it is, and which control they would enable first. Most pick bandwidth; the graph is usually an HTTP flood.

## Related Notes

- [[Security/Network-Security-Fundamentals.md]] — the wider threat model
- [[Routing/BGP-And-Internet-Routing.md]] — anycast and prefix announcements
- [[Network-Services/Load-Balancing.md]] — where rate limits live
- [[Automation-Observability/Telemetry-And-Monitoring.md]] — detecting the baseline change