SYN cookies

SYN cookies

应对SYN Flood攻击
Syn-Flood攻击成立的关键在于服务器资源是有限的，而服务器收到请求会分配资源。通常来说，服务器用这些资源保存此次请求的关键信息，包括请求的来源和目(五元组)，以及TCP选项，如最大报文段长度MSS、时间戳timestamp、选择应答使能Sack、窗口缩放因子Wscale等等。当后续的ACK报文到达，三次握手完成，新的连接创建，这些信息可以会被复制到连接结构中，用来指导后续的报文收发。

那么现在的问题就是服务器如何在不分配资源的情况下

1. 验证之后可能到达的ACK的有效性，保证这是一次完整的握手
2. 获得SYN报文中携带的TCP选项信息

SYN cookies 算法

SYN Cookies算法wiki可以解决上面的第1个问题以及第2个问题的一部分

我们知道，TCP连接建立时，双方的起始报文序号是可以任意的。SYN cookies利用这一点，按照以下规则构造初始序列号：

• 设t为一个缓慢增长的时间戳(典型实现是每64s递增一次)
• 设m为客户端发送的SYN报文中的MSS选项值
• 设s是连接的元组信息(源IP,目的IP,源端口，目的端口)和t经过密码学运算后的Hash值，即s = hash(sip,dip,sport,dport,t)，s的结果取低 24 位

则初始序列号n为：

• 高 5 位为t mod 32
• 接下来3位为m的编码值
• 低 24 位为s

当客户端收到此SYN+ACK报文后，根据TCP标准，它会回复ACK报文，且报文中ack = n + 1，那么在服务器收到它时，将ack - 1就可以拿回当初发送的SYN+ACK报文中的序号了！服务器巧妙地通过这种方式间接保存了一部分SYN报文的信息。

接下来，服务器需要对ack - 1这个序号进行检查：

• 将高 5 位表示的t与当前之间比较，看其到达地时间是否能接受。
• 根据t和连接元组重新计算s，看是否和低 24 一致，若不一致，说明这个报文是被伪造的。
• 解码序号中隐藏的mss信息

到此，连接就可以顺利建立了。

SYN Cookies 缺点

既然SYN Cookies可以减小资源分配环节，那为什么没有被纳入TCP标准呢？原因是SYN Cookies也是有代价的：

1. MSS的编码只有3位，因此最多只能使用 8 种MSS值
2. 服务器必须拒绝客户端SYN报文中的其他只在SYN和SYN+ACK中协商的选项，原因是服务器没有地方可以保存这些选项，比如Wscale和SACK
3. 增加了密码学运算