DDoS, reflection, and amplification

Distributed denial of service

One attacking host cannot fill a well-provisioned link. Many can, and the standard architecture for organising many is three-tiered: the attacker issues commands to a small number of handlers, and each handler relays them to a large number of agents — compromised machines, commonly called zombies.

Three properties make the structure worth the trouble. A single command to a handler fans out to every agent it controls, so the attacker's effort does not grow with the size of the attack. Automated tooling scans for and compromises new machines continuously. And a freshly compromised agent announces itself to a handler, so the network grows without supervision.

Later tools dropped the dedicated handler software and used IRC, instant messaging or plain HTTP for command and control instead, hiding the traffic inside ordinary protocols, and added cryptographic authentication of agents so that an investigator who captures one agent cannot impersonate the controller. It is worth knowing that the early tools did not spoof source addresses at all: sheer numbers plus the layered command structure already obscured the path back to the attacker. "DDoS means spoofing" is a false equation.

Reflection: making innocent servers do the sending

A reflection attack works like this. The attacker sends ordinary requests to ordinary servers, but puts the victim's address in the source field. Each server does what servers do — it replies to the source address it was given. The replies converge on the victim.

The defining property, and the one that makes reflection hard to defend against, is that the intermediaries are behaving entirely correctly. They are not compromised. They are not running attack code. They are answering questions, which is their job. Traffic from a well-run public server is exactly what a victim's filters are least willing to drop.

Attackers deliberately choose high-capacity, well-connected intermediaries so the attack traffic is a small fraction of that server's normal load, and just as deliberately limit the rate sent to any one intermediary — because if a reflector falls over, it stops reflecting. The attacker needs the intermediaries healthy.

One consequence worth knowing: reflection attacks produce no backscatter. Every attack packet goes to an intermediary and every response goes to the victim, so nothing scatters into unused address space where researchers watch for it. The main measurement technique the research community has for denial of service is blind to precisely the class that is hardest to trace.

Amplification: reflection that pays a dividend

Amplification is reflection with a gain. The request is small; the response is either much larger or there are many of them. Two shapes:

• Broadcast amplification. Aim the spoofed request at a network's directed broadcast address and every host on that network may reply. Smurf did this with ICMP echo; fraggle did it with UDP echo. One packet in, dozens or hundreds out.
• Size amplification. Send one query to one server and get one much bigger answer. DNS is the classic vehicle: a 60-byte query drawing a 512-byte response in classic DNS, or over 4,000 bytes with EDNS extensions, from a single resolver. Open recursive resolvers are the preferred intermediaries because the requested name data does not have to live on them — they will go and fetch it.

There is a clean constraint here worth memorising because it is easy to test: amplification cannot be built on TCP. Broadcast is inherently connectionless, and a connection-oriented protocol requires a handshake with one identified peer, so it cannot be aimed at a broadcast address at all. Amplification lives in UDP and ICMP.

Worked example — computing an amplification factor

The amplification factor is response bytes divided by request bytes. If the attacker sends a 60-byte DNS query and the resolver returns a 3,000-byte answer to the victim, the factor is

$$\frac{3000}{60}=50$$

Read that as leverage: every byte the attacker spends lands fifty bytes on the victim. Now run it backwards, which is the version that makes the danger concrete. Suppose the attacker wants to deliver 10 Gbit/s at the victim. The upstream bandwidth they must actually own is

$$\frac{10000}{50}=200Mbit/s$$

Two hundred megabits is a business connection, not a data centre. Push the factor to 200 — NTP's old monlist query was around that — and the attacker needs 50 Mbit/s. This is why open resolvers and open NTP servers are treated as a public hazard rather than as somebody else's configuration problem.

And the reflector is a victim too. It spends its own bandwidth on the replies, its logs fill with queries it should never have received, and it will be the address the victim's operators see and curse.