Most attacks try to get in. A denial-of-service attack only tries to stand in the way. It wins by using up something finite, a link, a table, a pool of workers, so that real people cannot be served. This chapter is about the three things that run out, why a few small packets can become a flood, and the layered defenses that let networks absorb what they cannot prevent.
Common mix-up: a reflection attack does not come from the servers that send it. The DNS or NTP servers flooding a victim were tricked into answering a question the victim never asked. Blocking or "hacking back" at them is aiming at the postman. The fixes live at the networks that let the forged question out, and at the services that answer anyone.
Read first: this chapter assumes the three-way handshake and the difference between connection-oriented TCP and fire-and-forget UDP from TCP, UDP & ports, how BGP carries routes between networks from Dynamic routing: OSPF & BGP, and why a router rewrites addresses at the edge from NAT & port translation.
Every service on the internet is a stack of finite resources. The building has a doorway of a certain width; inside, the clerks can keep only so many half-finished conversations in their heads; behind the counter, each order takes real time to fill. A denial-of-service attack, DoS for short, picks one of those resources and uses it up. When the attack comes from many machines at once it is a distributed denial of service, DDoS. RFC 8612 defines a DDoS simply as an attack in which traffic from multiple sources is directed at a target, and that distribution is what makes it hard: there is no single address to block.
The many sources are usually a botnet, a fleet of compromised devices (often cheap internet-connected cameras, routers and servers with default passwords or unpatched software) that take orders from one controller. Each device contributes a trickle; together they make a river. The owners rarely know. From a defender's point of view, the important facts are that the sources are numerous, widely spread, often on ordinary consumer connections, and that the traffic they send can look exactly like traffic from real users.
Send more bytes than the victim's link can carry. Routers upstream drop packets at random, good and bad alike. Reflection and amplification live here. The server may be perfectly healthy and still unreachable.
Send packets that each make a device remember something: a half-open TCP connection, a firewall session, a NAT mapping. Tables have fixed sizes. SYN floods are the classic case. Small packets at high rates do the most damage.
Send valid-looking requests that are expensive to answer: searches, logins, report exports, cache-busting URLs. Bandwidth is fine and connections complete; the database or CPU melts.
The three tiers fail differently, so they are measured differently. A link is sized in bits per second (bps), and a volumetric attack is reported in gigabits or terabits per second. A router or firewall has a forwarding budget in packets per second (pps): it spends roughly the same work on a 64-byte packet as on a 1,500-byte one, so a flood of minimum-size packets can exhaust it at a small fraction of the link's bit rate. An application is sized in requests per second (rps), and a single HTTP request that triggers a slow database query can cost thousands of times more than one that returns a cached page. Watching only one of the three numbers hides the other two kinds of attack.
| Tier | Unit that fills up | What breaks first | First-line defense |
|---|---|---|---|
| Volumetric | bps on the access link | the link, upstream of anything you control | upstream capacity: anycast, scrubbing, provider filtering, blackholing |
| Protocol | pps and table entries | SYN backlog, firewall or load-balancer session tables | stateless handling (SYN cookies), table limits, filtering at the edge |
| Application | rps and CPU-seconds | database, worker pool, upstream APIs | caching, per-client rate limits, queues with limits, load shedding |
On Ethernet, a minimum frame is 64 bytes, and with the preamble and inter-frame gap each one occupies 84 bytes of wire time. A 10 Gbit/s link can therefore carry about 14.88 million minimum-size frames per second. The same link full of 1,500-byte packets carries only about 0.81 million. A device that is "10-gig capable" in a datasheet may forward 10 Gbit/s of large packets comfortably and fall over at a fifth of that bit rate when the packets are tiny, because its per-packet work, not its bandwidth, is what runs out.
MITRE ATT&CK files the volumetric and protocol tiers under T1498, Network Denial of Service, and attacks that exhaust a host or application under T1499, Endpoint Denial of Service. The underlying software weakness, a resource that can be consumed without a limit, is CWE-400, Uncontrolled Resource Consumption.
A TCP connection opens with three messages: the client's SYN, the server's SYN-ACK, the client's ACK. Between the second and third, the server is in an awkward position. It has promised a connection to someone it has never heard from twice, and it must remember that promise, the client's address and port, its initial sequence number, the options it asked for, so that the ACK can be matched when it arrives. That memory is a half-open connection, and operating systems keep them in a fixed-size queue usually called the SYN backlog.
A SYN flood sends SYNs and never sends the ACK. Often the SYNs carry forged source addresses, so the SYN-ACKs go to machines that either do not exist or silently discard them. Each forged SYN occupies one slot in the backlog until a timer expires, and the timer is generous on purpose, because real clients on slow or lossy links need several retransmissions to finish. RFC 4987, the IETF's survey of SYN flooding, describes exactly this: the attack works by exhausting the memory the server sets aside for connections in this state, and once it is full the server cannot accept new connections from anyone.
The arithmetic is the whole story. If the flood sends F SYNs per second and each holds a slot for T seconds, then on average F × T slots are full of flood. A server with a 1,024-slot backlog and a 30-second timeout is fully occupied by a flood of just 35 SYNs per second, a rate a single home connection can produce without noticing. Bigger backlogs and shorter timeouts help a little, and RFC 4987 lists them, but they only move the line; the attacker simply sends faster.
The fix that changed everything is to stop keeping the memory. A SYN cookie answers every SYN with a SYN-ACK whose initial sequence number is not random but carefully constructed: it encodes the facts the server would have stored, protected by a keyed hash. The server then forgets the connection entirely. A legitimate client acknowledges that sequence number plus one, so when its ACK arrives the server can recompute the hash, confirm it made that cookie recently for that address and port, decode the stored facts, and only then create the connection. A forged SYN costs the server one outgoing packet and zero memory. RFC 4987's appendix gives the classic layout:
The cookie has only 32 bits of room, so it cannot carry everything a modern SYN negotiates. RFC 4987 notes that commonly implemented schemes are incompatible with some TCP options unless the scheme accounts for them: window scaling and selective acknowledgement (SACK) do not fit in the sequence number. For that reason, it says, SYN cookies typically are not used by default; they are enabled under high-stress conditions indicative of an attack, or by an administrator. Later designs borrow bits from the TCP timestamp option, which the client echoes back, to carry more of the negotiated state.
The result is a sensible hybrid: keep a normal backlog while it has room, and fall back to cookies only for SYNs that arrive while it is full. Real clients during a flood get slightly less tuned connections; real clients the rest of the time notice nothing.
Two limits remain. SYN cookies protect the backlog, not the bandwidth: a SYN flood large enough to fill the link still wins at the volumetric tier. And because the server answers every SYN, it also sends a SYN-ACK to every forged address, which is why a SYN flood with spoofed sources is a small reflection attack against whoever owns those addresses.
This chapter is being finished. The sections above are complete and checked; still to come are a narrated walkthrough, the backlog simulator, and sections on reflection and amplification, source-address validation (BCP 38 and BCP 84), anycast and scrubbing, and application-layer rate limits.
Until then, the sources below cover the same ground, and Chapter 05 and Chapter 08 cover the filtering and routing defenses this chapter builds on.