SYN cookies HOWTO

说起SYN cookies，就不得不先说SYN flood，而说起SYN flood就不得不先说 TCP 三次握手。

Alice  -->-- SYN     -->-- Server
Server -->-- SYN-ACK -->-- Alice
Alice  -->-- ACK     -->-- Server

这个是正常的三次握手，最后Alice向Server回复 ACK ，三次握手完成。

Hack   -->-- SYN     -->-- Server
Hack   -->-- SYN     -->-- Server
Hack   -->-- SYN     -->-- Server
Server -->-- SYN-ACK -->-- Hack
Server -->-- SYN-ACK -->-- Hack
Server -->-- SYN-ACK -->-- Hack

上面Hack向Server发送了 SYN ，但是或者Hack故意不回复 ACK ，或者Hack向Server发送 SYN 时伪造了源IP地址。Server收不到最后的 ACK ，最终处于半连接状态。

当Hack发送大量的 SYN 时，Server端保留了大量的半连接，占用了大量的资源，此时Alice发送正常的 SYN ，Server却无法响应了。这种情况，就是Hack利用 SYN flood 发起了 DOS 攻击。

SYN cookie 正是为了解决 SYN flood 才出现的。 SYN flood 造成 DOS 的关键是半连接，占用了Server的资源，如果能消除半连接占的资源，那么就可以防止 SYN flood 。

TCP 规定，每次 ACK 都要把收到的包的 sequence number 加1发送回去。 SYN cookie 的解决思路是，把半连接保存的资源放到 sequence number 中，收到 ACK 时把 sequence number 减1，从中恢复需要的资源。 sequence number 只有32位，能保存的资源有限，5位保存时间，3位保存TCP选项 MSS ，剩下24位保存一个加密串，具体实现参考wiki。

SYN cookie 有2个缺陷。首先，如果Alice发送的ACK 丢失 ，因为服务器没有保留半连接信息，所以它无法通过重发 SYN ACK 来让Alice重发 ACK ，当Alice的 ACK 丢失时，Alice认为连接建立，Server则根本没有这个连接。如果建立连接后是Server先发数据，Alice则只能通过超时发现问题。其次，因为 sequence number 只有32位，只保留了 MSS 这个TCP选项，这在早期不是问题，随着TCP选择逐渐增多，而这些选项也非常重要，它们无法保存在 sequence number 中。

在改进SYN cookie 中，通过在TCP timestamp中保存更多的TCP选项，解决了缺陷2。在此文中提到，SYN cookie的最初作者认为SYN cookie可能已经没有必要了，因为现在Server性能强劲，内存常有富裕，半连接占用的资源已经可以忽略了。但是测试似乎表明 SYN cookie 提升了响应时间，虽然略有CPU的提升，另外在有SYN flood的情况下，SYN cookie开启要优于不开启。