SYN-Floods and Countermeasures–Part 1

Talking with customers and partners, one thing that I’ve been surprised to learn about is the ongoing prevalence of SYN-floods. When I ask a customer to tell me what attacksthey’ve faced recently, about three-fourths of them will include SYN-flood as an attack vector. It’s such an ancient attack type but clearly it continues to enjoy a measure of popularity. So, I thought it might be prudent to take a closer look at SYN-floods and their countermeasures, which are interesting in their own right.

SYN-floods are easy to generate and ultimately exploit this simple truth: the SYN-flood lets the attacker operate in a stateless manner while forcing the defender to operate in a stateful manner. SYN-floods are easily obscured because each packet looks like a normal TCP setup.

Why does this matter?

Nearly all web-based applications run over some form of the HTTP protocol, which itself runs over the stateful TCP protocol to guarantee delivery and packet order. These web applications are therefore theoretically vulnerable to the lower-level TCP SYN-flood attack. A successful SYN-flood attack will exhaust resources of a stateful device (such as an unprotected web-server). When there are multiple clients attacking in a coordinated fashion, it’s called a distributed denial-of-service (DDoS).

DDoS attacks such as SYN-floods can cause downtime for an undefended target. I talked with one company, a large ad-server, hit with a DDoS attack on Black Friday and it lost $100,000 every 30 minutes during the attack. SYN-floods can cause serious financial pain, yet a moderate SYN-flood can be launched by renting a botnet on the underground market for only a few hundred dollars.

Anatomy of a SYN-Flood

Sequence	Caller	Receiver
1	Dials Phone
2		Hello?
3	Hi Mom!

Table 1: 3-way handshake in a normal phone conversation

The TCP connection setup is a three-way handshake between the client and the server. An analogy I like to think about is the similarity to a telephone conversation. If all goes well on the phone, the exact same three-way handshake sets up the conversation that takes place afterward. But of course, every now and then something goes wrong and the phone rings but there's no-one there. This stalls the receiver as they await an answer to their 'Hello?'

Sequence	Caller	Receiver
1	Dials Phone
2		Hello?
3	<silence>
4		Hello? Is anyone there?
5	<silence>
6		I'm hanging up now.

Table 2: Call, but no caller.

Let’s compare the three-way TCP handshake to the phone call. The TCP “caller” will be called a “client” and the TCP “receiver” will be called “the server.”

To set up a TCP connection the client sends a packet to the server with the special flag SYN set – this is analogous to the caller “dialing” the receiver. The server, upon receiving SYN packet and sends back a SYN-ACK response packet (the “Hello”). For a normal connection, the client sends the third packet which is simply an ACK (“the Hi Mom!”). The normal sequence is SYN, SYN-ACK, and ACK.

	TCP Setup		Phone Call
Sequence	Client	Server	Caller	Receiver
1	SYN Packet		[Dials Phone]
2		SYN-ACK		Hello?
3	ACK		Hi Mom!

Table 3: Comparison of TCP setup to Phone Call

One difference between the telephone analogy and the TCP setup is that for telephones, the caller has to at least keep the phone off the hook or the receiver will hear the dial tone and know there’s no one there. TCP isn’t like that. An attacker can send the SYN packet to start the conversation and then just move on to do something else.

	TCP Setup		Phone Call
Sequence	Client	Server	Caller	Receiver
1	SYN Packet		[Dials Phone]
2		SYN-ACK		Hello?
3	<nothing>		<silence>
4		<waiting>		Hello? Hello?
5	<nothing>		<silence>
6		<waiting>		Hello? Is anyone there?
7	<nothing>		<silence>
8		RESET		Okay, I'm hanging up now!

In the SYN-flood attack, a malicious client sends the SYN packet to the server, but without the intent of setting up a connection. In fact, it does not wait to receive a SYN-ACK, It simply sends another SYN packet, or another thousand or more SYN packets. The server, on the hand, assumes that a connection is about to be established and reserves space the expected conversation in its connection flow table. The expected SYN-ACK never appears, and the server keeps the connection around for approximately 2 minutes before making that space available for a new, valid connection.

Following our analogy of the telephone conversation, liken the server’s connection flow table to a pool of telephone operators like the ones in Fig. 1. There’s more than one operator here, but it’s definitely a finite pool.

So imagine this small pool of phone operators. If a group of attackers wanted to overwhelm the phone operators, they could simply call over and over and not say anything, causing the pool of operators to spend their time just saying “Hello? Hello?” and denying service to other, legitimate phone calls. Get it?

The SYN flood shown in Fig. 2 is the TCP equivalent of this phone-call flood to a pool of phone operators. With the SYN flood, a single malicious client can easily overwhelm the flow-table of a single, undefended host. When the flow-table is full, some hosts panic and reboot, while others simply refuse new TCP connections. Either way, the effect is the same: legitimate connections (customers?) are denied service.

Next week we'll look at countermeasures for the SYN-flood.