Denial of service, the TCP handshake, and SYN flooding

What denial of service actually is

A denial-of-service attack is an action that prevents or impairs the authorised use of a system by exhausting a resource. That definition is worth reading twice, because it contains no mention of breaking in. Nothing is stolen, no access control is bypassed, no privilege is gained. The attacker simply arranges for there to be none of something left for anybody else.

There are only three kinds of something, and every attack in this chapter is an instance of one of them.

1. Network bandwidth. The link between an organisation and its ISP is almost always the thinnest pipe in the path — the ISP's own internal links are far fatter. Fill that link with junk and the router at the far end has no choice but to discard packets. It discards them without malice, in proportion to what arrives, so the legitimate minority is crowded out by the malicious majority. Note carefully that a router discarding packets on an overloaded link is normal, correct TCP/IP behaviour. The attack does not break anything; it supplies the overload and lets the protocol do the rest.
2. System resources. Not the link but the host: packet buffers, process slots, and — the one this lesson is built around — the table of open connections. A separate flavour of the same category is the poison packet, a single malformed datagram that trips a bug in the target's protocol stack and crashes or hangs it. Ping of death and teardrop were of this kind. Notice that a poison packet needs one packet, not a flood, which is precisely why classifying it as a bandwidth attack is wrong.
3. Application resources. Requests that are entirely valid but expensive: a search that scans the whole catalogue, a report that joins six tables, a signature verification. The attacker's cost per request is a few hundred bytes; yours is a second of CPU. When the ratio is bad enough the traffic volume can be modest and the service still dies. The term for this is cyberslam.

Two names this course keeps apart

Fix the two labels before anything else, because this lesson examines the difference between them and much of the industry does not.

• SYN spoofing is the state attack. Forged SYNs fill the server's table of half-open connections until it can accept nothing more. Its currency is table entries, and a few kilobits per second buys enough of them.
• SYN flooding is the bandwidth attack. SYN segments are sent purely as bytes, to fill the link, exactly as an ICMP or UDP flood does. Its currency is bits per second, and it needs as many of them as the victim's pipe is wide.

Be warned that the term “SYN flood” is used loosely almost everywhere else — in vendor documentation, in incident reports, and in the later chapters of many textbooks — to mean the half-open connection-table attack that this course calls SYN spoofing. That looser usage is not a mistake out in the world; it is simply not the split this course examines. Here the discriminator is always the resource — table entries versus link capacity — never the packet type, which is identical in both. The full argument is in the last section of this lesson.

Why the source address is a lie

Before the handshake, one fact about IP. There is no default means in TCP/IP of verifying that a packet's source address actually belongs to the sender. The sender writes the source field; nothing on the path checks it. The raw socket interface, kept for historical compatibility, hands that capability to any program running with enough privilege.

Everything in this module's defence lesson is a workaround for that single omission. It is also what destroys traceback: reading a spoofed source address tells you nothing, and tracing the packet hop by hop requires the active cooperation of every router operator on the path — not something a victim under attack can request automatically at 3 a.m.

Spoofing is not free for the attacker, which is the reason attacks exist that do not use it. Sending with your real address costs you two things: you are explicitly identified, and every reply the target sends comes straight back at you, consuming your own link.

Worked example — the handshake, and the same handshake with a lie in it

A TCP connection opens in three messages.

Message 1 — SYN. The client sends a segment with the SYN flag set and its own initial sequence number, say x. The server receives it and — this is the fact the entire attack turns on — records the half-open connection in its connection table straight away, before anything at all has been verified about the client.

Message 2 — SYN-ACK. The server replies with SYN and ACK set, carrying its own initial sequence number y and an acknowledgment of x + 1. It now waits.

Message 3 — ACK. The client acknowledges y + 1. The entry moves from half-open to established, and data can flow.

Now put a lie in message 1. The attacker sends a SYN whose source address is forged and unreachable — an address in unallocated space, or belonging to a host that has already been knocked offline. The server dutifully records the entry and sends its SYN-ACK to that forged address. Nobody is there. No ACK comes back.

What the server does next is the expensive part. TCP is reliable because it retransmits unacknowledged segments, so the server sends the SYN-ACK again, and again, several times, over tens of seconds, and holds the table slot for the whole of that timeout. Repeat a few thousand times a second and the table is full. Once it is full, every further connection request is refused — including every legitimate one. The service is down, and no host was ever compromised.

Notice why the attacker chooses an unreachable forged address rather than a random one. A real host that receives an unsolicited SYN-ACK answers with an RST, and an RST frees the slot immediately. A forgery that provokes an RST is a forgery that undoes itself.

The distinction the exam wants: spoofing versus flooding

Both attacks send TCP SYN packets. That is the trap, and it is the whole of the trap.

• SYN spoofing targets the connection table. Its currency is table entries, and an entry costs the attacker one small packet and costs the server tens of seconds. The bandwidth required is trivial — kilobits per second is enough to keep a table full — so a single broadband connection can take a large company's server offline. It is also hard to trace, because every source address is fictional.
• SYN flooding, like ICMP and UDP flooding, targets raw link capacity. Its currency is bytes per second, and it needs as many of them as the victim's pipe is wide. That is why floods are launched from botnets: no one host has the bandwidth.

Same packet type. Different resource. Bandwidth requirements that differ by four or five orders of magnitude.

Once more, because it is the easiest mark in this module to throw away: outside this course, “SYN flooding” usually names the connection-table attack above — the one called SYN spoofing here. Recognise the loose usage when you meet it, and answer this course's questions on this course's stricter split.

One more note on flooding by protocol, because the escalation is instructive. Attackers began with ICMP echo (ping). Sites blocked ping. Attackers moved to destination unreachable and time exceeded — precisely the ICMP types that normal TCP/IP needs, so blocking them degrades the network for everyone. Those messages are also attractive because they quote part of the offending packet, which means the attacker can make them large. UDP floods often target the diagnostic echo service, and it does not matter whether the port is open: by the time the target answers with a port-unreachable message, the link capacity is already spent.