In my software security class, we had this question:

You are the system administrator for a provider that owns a large network (e.g., at least 64,000 IP addresses). Show how you can use SYN cookies to perform a DOS attack on a web server.

I searched everywhere, I found that SYN cookies are used to prevent DOS attacks. But this question said to perform an attack (I verified with the professor, it's not a typo). Can someone give me some pointers so I can head in the right directions?

4 Answers 4


As far as "the Internet" knows, there is no specific attack vector enabled by SYN cookies. The best I could think of is explained below:

First some explanations on SYN cookies (details matter). SYN cookies are a way to mitigate SYN flood attacks.

The gist of SYN floods is that keeping state for an opening connection is expensive (because it uses RAM somewhere). In a SYN flood, the attacker "cheats" by not keeping state: he sends a SYN but forgets it; on the other hand, the server remembers the SYN.

SYN cookies are the server's cheat: it just forgets them too. Instead, it encodes whatever it should remember in the TCP sequence number that it sends in the response to the SYN (an ACK+SYN packet); when a normal client responds to that, it sends its own ACK with the same sequence number (actually incremented by exactly 1), which allows the server to recover the data it did not bother to remember. A TCP sequence number is 32 bits, so the server must fit the "state" within 32 bits. SYN cookies are defined to use 5 bits for a timestamp, 3 bits for the MSS, and 24 bits of "output of a cryptographic function". These 24 bits are really a MAC computed over the server IP address, client IP address, both port numbers (server side and client side), and the timestamp.

A consequence is that when the server receives an ACK which looks like a response to an ACK+SYN (one with a cookie) then the server must consider it as the third element of a TCP handshake, and thus allocate the resources for a now fully open connection. This happens if and only if the cookie value is correct (when the server recomputes it, it matches the value sent in the ACK). The attacker knows the current time and can guess/observe the three-bit encoding for the MSS value, so there are 24 unknown bits. If the cookie value is computed properly (with a cryptographic hash or something equivalent in this situation), then an attacker has only probability one in 16 millions (16777216, precisely) to hit a correct cookie value. This severely limits the possibilities of the attacker.

There has been some discussion on the CPU cost involved in SYN cookie processing. Consider that a basic Core2 x86 CPU will happily compute 8 millions of MD5 hashes per second, using a single core. It will be hard for the attacker to DoS that way (it would require sending more than 8 millions packets per second to that server...).

What can be done is the following:

  • Attacker sends a normal SYN, then receives the ACK+SYN from the server. The ACK+SYN contains a valid cookie for the source address and port that the attacker used; the cookie is valid for a minute or so (since the timestamp changes typically once every 64 seconds).
  • Attacker repeatedly sends, using the same source address and port, two packets:
    • a packet containing a ACK and the cookie obtained above, and also some applicative data (a 'push') which encodes a valid HTTP request;
    • a second packet which does a RST.

Upon receiving the first packet, the server must assume that it is a valid third packet of a TCP handshake; it then reads the data and processes the HTTP request. While the HTTP server software considers the request (and this can involve considerable resources, especially if the request is a POST and/or requests HTTP-level compression with gzip), the target kernel reads the RST and considers the socket as closing -- the HTTP server will get a write error when it will try to send the HTTP response (but only then, not before).

Since the connection is closing, the source address+port is considered "free" again, so the next ACK+push from the client will be honoured similarly.

The 64000 IP addresses come here as a way for the attacker to "fly under the radar". Repeated connections from a single IP address are likely to be noticed by any half-decent firewall, and blocked early on (before reaching the target Web server). Since the evil admin "owns" 64000 addresses, he can simulate connections from any of the 64000 addresses. The attacker would use a first SYN to get a cookie, then send a hundred or so ACK+push,RST pairs from that address. For increased effect, he would do that with a hundred addresses at a time, regularly getting new ones. He has 64000 addresses to play with, so it will take some time before he has to reuse an address.

In that scenario, the SYN cookies have the following aggravating effect, when compared to the same setup without SYN cookies: they allow the attacker not to wait for an ACK+SYN most of the time. This disables one of the classic countermeasures against DoS, i.e. adding a bit of latency when responding to a SYN.

This is still unconvincing. The SYN cookies, here, do not multiply the attacker's power by a large factor. With 64000 addresses, the attacker could maintain a million open connections (or at least seemingly open, from the server's point of view), with or without SYN cookies, and no Web server will resist that.


SYN cookies are a trade-off between memory and CPU. Since you are using less memory when using them, you are now using more CPU to calculate the values to use in the sequence number. I would expect that any DOS would focus on that unless there's an implementation bug somewhere that can be exploited.

The mention of the size of the network suggests that he is hoping for you to exploit some fundamental limit on SYNCookies. 65,536 IP addresses (a /16 IP range) would match the number of TCP ports available but I'm not familiar enough with the details of SYNCookies to know if there's something exploitable there.

As a side note, SYN floods are normally done with spoofed source addresses since you don't care about and, in fact, don't want the responses. Hence, you don't need to actually control a /16 in order to use 65,536 IP addresses or more in a DDoS attempt. A /16 is also quite easy to block with a firewall and very easy to identify if most of it is associated with the DDoS attempt.

The first challenge you would have to overcome is to get the target into syn-cookie mode. Even if syn-cookies are turned on (and the default is off in at least some distros) you have to exceed the TCP queue length. This is the point at which you would be causing a DoS if it weren't for syn-cookies. This would involve sending a lot of SYN traffic to start with.

Looking through the explanation from Wikipedia the server must calculate a cryptographic function over the IP address and the port and the return value of this function must be 24 bits in length. Since the IP address is 32 bits and the port is 16 bits, there must be collisions. (i.e Two different IP address and port combinations return the same value.) If you control 16 bits worth of IP address space (the first 16 bits are identical) and you can use 16 bits of source port then you should be able to generate all possible cryptographic function values to go in the sequence number. If you could do this within a single second, that would mean that the server had sent out all possible syn-cookies for that timestamp.

Even with a collision, I don't think that would cause a DoS. A legitimate connection would still have a valid sequence number in its final ACK, even if it collided with a different connection that was part of the DoS attempt.

The only other part I can see that might be exploitable is the maximum segment size. There are only three bits set aside for this meaning that the server can only choose 8 distinct values. If you can force the server to want to choose more than 8 distinct values, it may be possible to cause new connections that require an MSS value that's not on the existing list to be dropped. This would depend on the implementation, not anything fundamental about how syn-cookies work.

In the end, the only thing I can see is the extra CPU caused by having to do all those cryptographic operations.


Traditionally, SYN DOS are performed by sending SYN... SYN... SYN... SYN...
The common TCP usage pattern is to send SYN, wait for SYN/ACK and then send ACK. So when the server receives SYN, it sends SYN/ACK and waits for ACK. But the attacked throws away the SYN/ACK and just sends more SYNs. The server dutifully replies with SYN/ACKs, but its buffer is gradually filling up with open waiting connections. Finally, the buffer is full and no more connections are accepted. The server becomes unavailable.

Even better, the attacker fakes it's source address, so that every SYN appears to be coming from different address. The SYN/ACKs are being also sent away to that random address (where the server discards unauthorized SYN/ACK packets).

  • OK if there is another way to use SYN packets to perform a DoS attack, I will be happy to be enlightened.
    – Jakub Zaverka
    Mar 14, 2012 at 2:58
  • so...the question is to use SYNcookies to perform DOS. Usually they are user to avoid them. If you could share ur opinion regarding that.
    – chungtinhlakho
    Mar 14, 2012 at 3:24

With a bit of a wider search, I found this: https://www.rfc-editor.org/rfc/rfc4987 - a description of SYN Floods, which seem to be what you are being asked about.

You must log in to answer this question.