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.