Friday, January 11, 2013

PoCS : Synfloods and SynCookies

This is the first part of hopefully quite a few posts to come in the "Papers in Computer Security" series taken from [1]. Today we will have a look at "Syn Cookies"[2], [3].

A SynFlood is a kind of DoS attack where you create try to get a server to open more "half-open" TCP connections than it can handle, eventually reaching a state where legitimate requests to the server dont get served. A half-connection happens when a client sends over a SYN, the server responds with a SYN-ACK and waits for a ACK back from the client, but does not receive it.

A classic pattern that can be noticed in DoS attacks is that it costs nothing for a client to send out a new connection request but the server has to spawn a new thread/process to handle each request -- there is a certain asymmetry in that scenario.

A solution to this problem would be to recognize an ACK to belong to the same TCP stream as the SYN that came initially but not have a thread waiting for the ACK at the same time. One of the solutions would be to use SYN Cookies.

A SYN Cookie is a choice of a TCP sequence number.

First a quick review of how TCP sequence numbers work in a TCP handshake :-

Client -> Server : Syn(n)
Server -> Client : Syn(n+1), Ack(m)
Client -> Server : Ack(m+1)

"n" and "m" are the sequence numbers chosen at random by the client and the server respectively. Also, please note that an ACK(m) typically means "I have received all packets upto m-1, send me the packet corresponding to m". In this case, it doesn't really apply however.

When using SYN cookies, the sequence number "m" is chosen such that :-

  • The top 5 bits are a counter mod 2^5, which increments every 64 seconds
  • The next 3 bits is an encoding of the MSS selected by the server in response to the clients MSS
  • The last 24 bits is a secret function of t, client IP and port, server IP and port
Now when the server receives (m+1), it recomputes "m" using a recent value of "t"(I'm not very sure how "t" is kept track of) and it is compared with the sequence number in the ACK it just received.

In order to allow SYN Cookies in Linux you'd have to do :-

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

Now when an attacker spoofs the source address and sends over a SYN when the server has a full SYN queue, the server does not drop the connection -- instead it operates as it would have had there been additional space in the SYN queue and sends over an ACK with a sequence number computed as mentioned above.

Its of utmost importance however, that attackers be unable to predict "m".

Also, its quite obvious that this does not solve the problem of DDoS attack caused by say, a botnet as full connections are established with clients in that case.


No comments:

Post a Comment