文章总结： 1996年首现SYNFlood攻击，攻击者伪造IP发送SYN包耗尽服务器半开连接队列，以极低成本瘫痪系统。因IP欺骗导致难以防御，Bernstein提出SYNCookies方案，利用序列号编码连接信息实现无状态握手，成功缓解了危机，暴露了早期互联网架构缺乏自我保护的缺陷。 综合评分： 83 文章分类： 网络安全,漏洞分析,解决方案

【第五空间简史】第17节 SYN Flood 拒绝服务攻击初现（1996）

原创

千里

东方隐侠安全团队

2025年12月31日 13:04 江苏

1996年9月6日下午，纽约商业ISP Panix的运维室里， Alexis Rosen面对着一次前所未有的系统崩溃。

当时的服务器大多运行的是SunOS 4.1.3或者BSD派生的系统。Rosen发现，尽管网络带宽（T1线路）还有巨大的盈余，CPU负载也十分平稳，但内核的Mbuf（Memory Buffer）和PCB（Process Control Block）链路却频繁告警。

这就是历史上第一次SYN Flood事件，也叫SYN泛洪攻击。

01.

为何100字节就能锁死内核？

要拆解SYN Flood攻击，我们需要着重关注内核里的一个数据结构：TCB（Transmission Control Block，传输控制块）。

早在1994年，Bill Cheswick和Steve Bellovin就发现了TCP SYN泛洪弱点[B96]。他们在《防火墙和互联网安全：击退威利黑客》（CB94）一书中加入并删除了一段关于攻击的内容。不幸的是，在接下来的两年内没有制定任何对策。

当内核收到一个带有 SYN 标志位的TCP报文时，它必须进入SYN_RECV状态。

在BSD体系的实现中，这意味着内核需要立即从有限的系统池中分配出一块内存来维护这个连接的状态信息——包括源/目的IP、端口、序列号、窗口大小以及相关的缓冲区指针。

这块内存就是TCB。

问题的核心在于“半开连接队列”（Half-open Connection Queue）的长度限制。

在1996年的操作系统内核里，这个队列（通常由 listen() 系统调用的 backlog 参数控制）非常狭小。当时许多Unix变种的默认 somaxconn 甚至只有5到24。这意味着服务器同时只能维持极少数处于“握手一半”状态的连接。

攻击者利用当时盛传的 synk4.c 等工具通过构造原始套接字（Raw Socket），伪造随机的源IP地址，向目标80端口发送 SYN 包。

内核收到 SY N后，随机分配TCB，将TCB挂载到半开队列，接着发送 SYN-ACK ，最后启动重传定时器（Retransmission Timer）。

由于源IP是伪造的， SYN-ACK 永远得不到 ACK 。

根据当时的TCP指数退避重传算法，内核会坚持重试5次（初始间隔1s，随后翻倍），这意味着这个TCB会在半开队列里占据长达 75 秒 甚至更久。

攻击者只需要每秒发出几十个报文，就能轻而易举地将这个极其微小的 backlog 队列塞满。此时，内核会直接丢弃（Drop）后续所有的 SYN 请求，包括合法用户的请求。

这种情况下，攻击者消耗几百字节的流量，就能换取服务器内核资源长达一分多钟的彻底锁定，成本低，收益高。

02.

攻击溯源的艰难

Panix的工程师当时尝试追踪攻击源，但很快就陷入了绝望。

SYN Flood能够成功的技术基石是IP Spoofing。在那个年代，绝大多数路由器只负责根据路由表转发数据包（Forwarding），根本不会去校验一个从下属网段发出来的包的源IP是否真的属于该网段。

这就是BCP 38（Best Current Practice 38）标准出现前的情况。攻击者利用原始套接字直接填充 ip_src 字段，伪造出遍布全球的虚假访问者。对于当时的防火墙（大多是简单的包过滤型，Stateless Packet Filter）来说，这些 SYN 包看起来和正常的业务请求毫无区别。

这就让反击变得毫无目标，毕竟你不可能封掉全世界的IP，而攻击包的指纹又极其干净。

03.

SYN Cookies：一种数学级延迟分配艺术

直到1996年底，Daniel J.Bernstein提出了SYN Cookies，这场危机才真正得到解决。

他的思路非常硬核且具有颠覆性：既然TCB队列容易溢出，那我就干脆在收到ACK之前，不分配TCB。

但这违反了TCP协议的设计理念，如果不记录状态，当客户端发回第三次握手的 ACK 时，服务器怎么知道这个连接是合法的？

Daniel J.Bernstein巧妙地利用了TCP报文头里的Sequence Number（序列号）字段。他将连接的核心信息进行编码：

$ ：一个缓慢增长的时间戳（用于防止重放）。

$ ：客户端在 SYN 中声明的最大报文段大小（MSS）。

$ ：服务器端的一个私钥。

服务器计算一个哈希值：$Hash(source*ip, dest*ip, source*port, dest*port, t, K)$。

最终发送给客户端的 SYN-ACK 序列号（Initial Sequence Number）就等于这个哈希值加上时间戳和编码后的MSS。

当合法的 ACK 回来时，其确认号（Acknowledgment Number）就是刚才那个ISN+1。服务器收到后，反向减1，再利用同样的参数算一遍哈希，对比通过后，才正式分配内存建立TCB。

这本质上是一种“无状态”的挑战应答机制。它让服务器在面对海量攻击时，依然稳如老狗，因为它不再为每个请求预留资源，而是让请求者自己携带凭证回来。

04.

历史的深层反思：协议实现的工程代价

站在技术史的高度看，1996年SYN Flood事件暴露了早期互联网架构的一个设计漏洞：过分追求端到端的透明性，而忽视了中间层的自我保护。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：东方隐侠安全团队 千里《【第五空间简史】第17节 SYN Flood 拒绝服务攻击初现（1996）》