计算机网络自顶向下方法26——运输层 SYN洪泛攻击 SYNCookie
TCP安全专题：SYN洪泛攻击与SYN Cookie防御机制
一、SYN洪泛攻击
要理解这种攻击，我们必须先回顾TCP三次握手的一个关键细节。
1. 攻击原理：利用TCP设计的资源承诺
在标准的三次握手中：
客户端发送SYN。
服务器收到SYN后，需要为这个“即将建立”的连接分配核心资源，包括：
分配接收缓冲区。
分配发送缓冲区。
初始化连接状态变量（如序列号）。
并将这个“半连接”放入半连接队列。
服务器发送SYN-ACK，并等待客户端的ACK。
SYN洪泛攻击正是利用了第二步中的“资源分配”机制。 攻击者会向目标服务器发送大量的TCP SYN报文段，并且伪造源IP地址。
2. 攻击流程与影响
下图直观地展示了SYN洪泛攻击如何耗尽服务器资源：
3. 攻击的严重后果
资源耗尽：服务器的内存被大量半连接占用，最终耗尽。
服务拒绝：当半连接队列被填满后，服务器无法再接受任何新的合法连接请求，对正常用户表现为服务不可用。
难以追踪：由于源IP是伪造的，很难直接追溯到攻击者。
二、SYN Cookie：一种优雅的防御机制
SYN Cookie是一种由D. J. Bernstein提出的、无需状态记录的防御方案，它从根本上解决了服务器需要预先分配资源的问题。
1. 核心思想：无状态握手
服务器在收到SYN后，不立即分配存储资源。而是将连接信息编码成一个“Cookie”，并将其作为初始序列号发送给客户端。只有当客户端返回这个Cookie（在第三次握手的ACK中）时，服务器才分配资源，正式建立连接。
2. SYN Cookie的编码与验证
Cookie的生成需要是一个不可逆的、可验证的函数，通常包含一个加密哈希。
Cookie生成公式（概念性）：
text
cookie = Hash(客户端IP、端口、服务器IP、端口、秘密值、序列号...)
服务器在发送SYN-ACK时，其序列号
server_isn就是这个计算出的Cookie。Cookie验证过程：
服务器收到ACK后，提取其中的确认号
ack = server_isn + 1。服务器根据收到的ACK报文，重新计算一次Cookie值（使用相同的哈希函数和输入）。
将计算出的Cookie值与
ack - 1进行比较。如果匹配：说明这是一个合法的连接请求，服务器为其分配资源，连接建立。
如果不匹配：说明ACK是伪造的或无效的，服务器直接丢弃。
3. SYN Cookie的工作流程
4. SYN Cookie的优缺点
优点：
从根本上免疫SYN洪泛攻击：攻击者发送的SYN包不会消耗服务器资源。
向后兼容：对合法的TCP客户端完全透明，无需修改客户端。
缺点/限制：
Cookie编码限制：由于序列号字段只有32位，能编码进Cookie的连接信息有限（如无法编码TCP选项，如大窗口缩放因子）。
密码学开销：每个连接都需要进行哈希计算，带来一定的CPU开销。
通常作为备用方案：现代操作系统（如Linux）通常在检测到半连接队列快满时，才自动开启SYN Cookie机制，平时仍使用传统的高效方式。
总结
| SYN洪泛攻击 | SYN Cookie防御 | |
|---|---|---|
| 核心问题 | 利用TCP三次握手的资源预先分配机制。 | 将资源分配从第二次握手推迟到第三次握手之后。 |
| 关键手段 | 发送大量伪造IP的SYN包。 | 通过加密哈希将连接状态编码进序列号，实现无状态握手。 |
| 结果 | 耗尽服务器资源，导致拒绝服务。 | 服务器在验证合法前不消耗资源，保障服务可用性。 |
SYN Cookie是一种非常巧妙的设计，它体现了在协议栈中通过一些计算开销来换取巨大安全性和鲁棒性的经典权衡，是网络安全领域一个里程碑式的创新。