TCP SYN-cookies解析
问题背景
SYN-cookie（DoS攻击方式的防范手段）
SYN-Cookie是对TCP服务器端的三次握手协议作一些修改，专门用来防范SYN Flood攻击的一种手段。它的原理是，在TCP服务器收到TCP SYN包并返回TCP
SYN+ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。在收到TCP ACK包时，TCP服务器再根据那个cookie值检查这个TCP ACK包的合法性。如果合法，再分配专门的数据区进行处理未来的TCP连接。
SYN Flooding攻击原理
当客户端发起TCP连接时，它发送一个SYN报文给服务器。服务器收到这个SYN报文后，将分配一定资源给这个连接，并回复一个SYN+ACK报文。此时，服务器认为这个连接处于半连接（Half-Open）状态。只有在服务器收到客户端回复的ACK报文后，连接才算建立完成。如果服务器一直没有收到ACK报文，服务器会在超时后重传SYN+ACK。 如果经过多次超时重传后仍然没有收到ACK报文，服务器会释放之前为这个连接分配的资源，并关闭半连接。实际上，服务器会将这个连接的状态恢复到初始状态，就好像最初的SYN报文从来没有到达过一样。
连接请求的关键信息
Syn-Flood攻击之所以有效是因为服务器资源有限，每次接收请求都需要分配资源。
服务器在应对这种攻击时需要解决的问题是：
1、如何在不消耗过多资源的情况下验证后续ACK的有效性；
2、提取SYN报文中的TCP选项信息，以确保建立的连接是完整的且安全可靠的。
下面让我们来介绍一下SYN Cookies算法的实现过程：
1、构造初始序列号：
服务器收到客户端的SYN请求后，按照以下规则构造初始序列号n：
·使用一个缓慢增长的时间戳t（典型实现是每64秒递增一次），取其模32的高5位作为初始序列号的高5位。
·获取客户端发送的SYN报文中的MSS选项值m，并对其进行编码，取其编码值的3位作为初始序列号的接下来3位。
·对连接的元组信息(源IP，目的IP，源端口，目的端口)和时间戳t经过密码学运算后的Hash值s进行计算，取其低24位作为初始序列号的低24位。
2、发送SYN+ACK响应：
服务器将构造的初始序列号n编码在SYN+ACK响应中发送给客户端作为确认。这个SYN+ACK报文中的ack字段指向n+1。
3、恢复初始序列号：
客户端在接收到服务器的SYN+ACK响应后，会回复一个ACK报文，其中包含ack=n+1。服务器收到这个ACK报文后，通过ack-1来恢复之前发送的SYN+ACK报文中的初始序列号n。
4、检查序号有效性：
服务器需要对ack-1这个序号进行检查，包括：
·比较高5位表示的t与当前时间，看其到达的时间是否在合理范围内。
·根据t和连接元组重新计算Hash值s，看是否和低24位一致，若不一致，则说明这个报文可能被伪造。
·解码序号中隐藏的MSS信息，以确保其正确性。
通过这些步骤，服务器可以巧妙地保存了一部分SYN报文的信息，确保了连接的建立安全可靠。
SYN Cookies缺点
SYN Cookies的确在实现上存在一些限制和代价，这也是为什么它没有被纳入TCP标准的原因：
1、有限的MSS编码：由于MSS的编码只有3位，因此最多只能使用8种MSS值，这限制了服务器与客户端在连接中协商的最大数据包大小;
2、无法保存其他选项：服务器必须拒绝客户端SYN报文中的其他只在SYN和SYN+ACK中协商的选项，因为服务器没有足够的空间来保存这些选项;
3、增加了密码学运算：为了构造初始序列号，服务器需要进行密码学运算来计算Hash值，这会增加一定的计算成本。
这些限制和代价使得SYN Cookies并不适用于所有网络环境，特别是对于需要支持更复杂TCP选项、更大MSS值或更高安全性要求的场景。因此，虽然SYN Cookies在解决Syn-Flood攻击方面具有优势，但它并不适合成为TCP标准的一部分。
原创文章，作者：速盾高防cdn，如若转载，请注明出处：https://www.sudun.com/ask/76540.html
