Defending against and responding to a DoS attack

Start with the honest sentence

Denial of service cannot be prevented outright. Enough legitimate-looking traffic will overwhelm any link, and the network cannot tell the difference between a botnet and a popular news story — which is why the accidental version has its own vocabulary: a flash crowd. The realistic goal is to raise the attacker's cost, shrink the window in which they succeed, and recover fast. The general-purpose answers are unglamorous: excess bandwidth and replicated, distributed servers.

With that said, defences sort cleanly onto four lines.

### 1. Attack prevention and preemption — before

Measures taken while nothing is wrong. Resource-consumption policies that cap what any one client can take. Backup capacity that can be brought on demand. Protocol-level changes that remove the asymmetry an attack depends on — SYN cookies are the canonical example. And ingress filtering, which is the closest thing the Internet has to a cure for spoofing.

### 2. Attack detection and filtering — during

Recognise the attack pattern in the traffic and drop the matching packets. This requires a baseline of normal traffic; without one, the first indication is a user complaint and the first hour is wasted deciding whether this is an attack, a misconfiguration or a hardware failure.

### 3. Source traceback and identification — during and after

Finding out where it actually came from. The book is blunt that this rarely produces results fast enough to help with an attack in progress, because spoofing makes the source field useless and hop-by-hop tracing needs the cooperation of every router operator on the path.

### 4. Attack reaction — after

The incident plan: who is called, what is captured for evidence, what is restored, what is changed.

Worked example — SYN cookies

Recall the problem: the server allocates a table entry on the first packet, before anything is verified, and the attacker never sends the third.

A server using SYN cookies refuses to allocate. Instead it takes the connection information — the addresses, the ports, a coarse timestamp — and cryptographically encodes it into the initial sequence number it returns in the SYN-ACK. Then it forgets everything and stores nothing.

If a real client is there, it answers with an ACK acknowledging that sequence number plus one. The server takes the returned number, subtracts one, checks the cryptographic encoding, and reconstructs the connection state from the ACK itself. A completed handshake is now evidence of a real, interacting client, and only then does the server spend memory.

The result: a forged SYN costs the server one SYN-ACK and zero bytes of table. The flood has nothing to fill.

Two real costs come with it, and an exam answer should name them. There is computation on every SYN to build and later verify the cookie. And there is loss of TCP options, such as large windows and selective acknowledgment, because there is no room to encode them in a 32-bit sequence number.

Two weaker siblings are worth knowing. Selective or random drop discards an incomplete entry when the table overflows, on the reasoning that most entries in an overflowing table belong to the attack. Parameter tuning — a bigger table and shorter timeouts — does not prevent the attack; it only raises the rate the attacker needs.

Worked example — ingress filtering, and why it has to be somebody else's job

Ingress or antispoofing filtering means dropping a packet whose source address could not legitimately have arrived on the interface it arrived on. An ISP knows which address ranges it allocated to which customer link, so it can check. The check may be an explicit access rule, or a reverse-path check: does the route back to this source address point out of the interface the packet came in on? If not, discard.

The filtering must be applied as close to the source as possible — at the ISP that knows which addresses it gave out. Nobody in the middle of the Internet has enough information to make the judgement.

And here is the sharp consequence: reflection attacks depend entirely on spoofing, so universal ingress filtering would make them simply impossible. SYN spoofing and raw flooding, by contrast, still work perfectly with genuine source addresses. Filtering shrinks the attacker's toolkit; it does not empty it.

Responding, at 3 a.m.

The sequence is: capture traffic, identify the attack type, design a filter that matches it, and have the ISP install that filter upstream. Each step depends on preparation that cannot be done during the incident.

The detail everybody forgets until they need it: the response plan must hold ISP contact details reachable by non-networked means, and the division of responsibility between organisation and ISP must be pre-agreed. You cannot negotiate an escalation path over the link that is down.

A handful of specific measures round this out, each tied to a specific attack rather than offered as a list. Rate-limit ICMP and diagnostic UDP traffic — safe, because those are normally a tiny fraction of the total. Block IP-directed broadcasts, which is the direct answer to broadcast amplification. Block impossible source/destination port pairs: the DNS reflection loop uses combinations that never occur in legitimate traffic, which makes the filter both cheap and free of false positives. Rate-limit or CAPTCHA-gate expensive application requests. And, less selfishly, do not become an intermediary — close your open resolvers.