摘要

  • Microsoft 早在 2002 年 7 月发布 SQL Server 2000 解析服务修复，但到 2003 年 1 月，Slammer 仍找到大量可达的未修复主机；CAIDA 估计，十分钟内超过九成可达易受攻击主机已经感染。
  • 事件把“发布修复”和“撤销旧代码权力”彻底分开：厂商能提供补丁，发行者能揭示嵌入式 MSDE，应用所有者能改变运行实例，网络运营者则必须在人工审批来不及之前，预先限定自动隔离的权限。

2002 年 7 月已经有答案

Microsoft 于 2002 年 7 月 24 日发布安全公告 MS02-039。问题位于 SQL Server 2000 Resolution Service：为了让客户端找到命名数据库实例，这项服务监听 UDP 1434。精心构造的请求可以越过未检查的栈缓冲区，以 SQL Server 服务账户的权限执行代码。受影响对象既包括 SQL Server 2000，也包括 Microsoft Desktop Engine 2000，也就是 MSDE 2000。

公告不只描述风险。它给出补丁、可核对的文件版本，也建议在不需要该服务时用防火墙阻断 UDP 1434。10 月 16 日发布的 MS02-061 累积补丁同样包含该修复。从日历看，网络拥有半年准备时间。

但公告日期只能证明发布者完成了什么，不能证明安装现场已经改变。Microsoft 可以制作正确的二进制文件和安装说明，却不能知道每个第三方产品把 MSDE 带到了哪台机器，不能替应用所有者选择停机窗口，也不能让独立管理的进程自动加载新代码。旧实现只要仍在运行且可达，就继续拥有真实权力。

“运行代码优先”在这里不是修辞。文档规定期望状态，内存中的服务决定现实状态。

一个数据报取消了等待

SQL Slammer 也被称为 Sapphire。CAIDA 的测量显示，它在 2003 年 1 月 25 日星期六 05:30 UTC 前不久开始传播。蠕虫本体为 376 字节；加入 UDP/IP 头后，CAIDA 将线上数据包记为 404 字节。它抵达易受攻击的解析服务后触发溢出，并让新感染主机向伪随机互联网地址的 UDP 1434 发送同一段代码。

这条内循环没有连接建立，也不用等目标回复。传统 TCP 扫描会耗时等待握手或超时，Slammer 则发完一个包马上发下一个。限制传播速度的不再是往返时延，而是感染主机能够把多少数据塞进出口。

CAIDA 直接观测到单台主机每秒约 26,000 次探测，估算早期每个感染实例平均每秒约 4,000 次。爆发约三分钟后，全网扫描率超过每秒 5,500 万包。十分钟内，超过九成可达的易受攻击主机已经感染。

数字必须带着测量边界。CAIDA 在前 30 分钟记录到 74,856 个不同感染地址，但明确称其为下限。Slammer 的伪随机数生成器存在缺陷，监测点可能漏掉整组地址循环；一份关键早期数据也在约两分四十秒时中断。因此，文章不能把 74,856 写成完整全球总数。可以确定的是，决定性的传播阶段先于普通人工升级流程结束。

拖垮网络的是内部发送者

Slammer 不是 memcached 反射攻击。它不伪造受害者地址，不诱使第三方返回更大的响应，也不需要指挥服务器。感染的 SQL Server 以自己的网络身份主动扫描。公开分析认为所见变种没有额外破坏载荷，但传播行为本身已经足以制造中断。

在许多站点，一台或少数几台感染主机会用尽可用发送能力。最先被塞满的是本地共享瓶颈，于是同一出口后的其他系统一并失联。CAIDA 还指出，网络设备同时面对高字节量、高包速率与快速变化的大量目的地址；CPU、内存或队列都可能成为失败点。感染实例彼此争抢稀缺带宽，甚至压低了蠕虫自己的后续增长。

这改变了控制位置。只考虑“把攻击挡在外面”的边界防火墙并不充分，因为一项被忽略的内部运行时可以消耗整个组织的出口。最先有效的控制可能是内部隔离、出口异常检测、公平排队、速率限制，或一条能只隔离问题主机而不关闭整个站点的应急规则。

MSDE 让资产清单失去直觉

MSDE 2000 的特殊风险，在于它可以作为其他产品的数据库引擎被安装。一个认为自己“没有运行 SQL Server”的管理员，仍可能因业务应用依赖而拥有解析服务。CERT/CC 特别指出，包含 MSDE 2000 的产品同样受影响。

这不是简单的漏打补丁，而是名称体系断裂。Microsoft 知道组件，软件发行者知道捆绑关系，应用负责人知道业务依赖，网络团队看见 UDP 1434；任何单一视角都不是可靠清单。

所以修复对象必须是可执行身份，而不是产品标签。哪个进程正在监听？加载的是哪个文件版本？谁安装了它？哪项业务承担维护风险？哪些客户端真的需要发现服务？从外部和内部路径能否抵达？这些答案合在一起，才构成采用证据。

MS02-061 的后续历史也说明“直接安装”为什么不是完整治理。原补丁组合在某些情况下会干扰 SQL Server 运行，Microsoft 后来把额外的非安全修复与新安装器整合进重发版本。这不构成继续暴露漏洞的理由，却解释了为何承担业务后果的一方必须测试和安排真实变更，而不能把“可下载”误当成“已部署”。

人工过滤赶上了恢复，没有赶上感染

CAIDA 记录到，爆发后一小时内许多站点开始过滤目的端口为 UDP 1434 的数据包。Slammer 恰好属于最容易实施网络过滤的情形：特征清楚、端口狭窄，通常又不承载关键公网通信。即使如此，最早的人工过滤开始时，几乎所有可感染主机已经中招。

过滤仍然有价值。它压低后续扫描量，帮助网络恢复，却无法把已经发生的感染撤销。只在互联网边界阻断，也可能漏过内部网段之间的传播。Cisco 的运行建议因此区分路由器 ACL 与可作用于 VLAN 内部的控制，并提醒某些组织确实需要 UDP 1434，规则范围必须跟随真实依赖。

正确结论不是“把一切交给自动化”，而是预先授权范围很窄、条件可观察的行动。如果一台主机突然以极高频率向不断变化的目的地址发送同尺寸 UDP 包，本地规则可以限速、隔离或把它移入受限路径。阈值、网段、例外、证据保存与回滚都应由网络所有者掌握。

这就是机器时间里的“最小初始规范”：共同要求只是识别易受攻击的运行时、消除无正当理由的可达性，并阻止一台节点垄断共享网络。工具和拓扑选择继续留在本地。

采用必须留下四类证据

对软件发布者，证据是明确的修复版本与可用安装路径。对产品发行者，证据是组件清单，以及能抵达那些根本不知道自己拥有 MSDE 的客户的通知链。对应用所有者，证据是运行版本、暴露测试和明确依赖。对网络运营者，证据是流量显示单个端点无法夺走整条链路，以及隔离演练不会伤及无关服务。

这些证据不能互相抵账。防火墙能暂时隐藏易受攻击服务，却没有修正代码；打过补丁的服务仍可能不必要地暴露公网；清单可能过期；隔离规则也可能因为范围过宽而在事故中无人敢用。

多方协调不需要产生一个常设中央管理员。Microsoft 无须管理每个客户网络即可发布修复，网络运营者也无须改写 SQL Server 才能保护共享容量。最佳边界是：每一方公开足够状态让下一方作决定，承担后果的一方保留执行权。

证据边界

公开记录支持这些事实：补丁在爆发前已经发布；蠕虫能装入一个 UDP 数据报；CAIDA 至少观测到 74,856 个感染地址；决定性传播以分钟计。记录不能证明所有 SQL Server 或 MSDE 都暴露在公网，不能把下限变成全球总数，也不能证明每个流传甚广的公共服务故障都有相同因果链。

资料同样不支持源地址伪造、反射放大、数据盗窃或额外破坏载荷。更可靠的结论很窄：补丁可以存在数月，旧实现仍在运行系统里掌权。传播快于人工授权时，领导层必须事先划定有限自动权力，并要求二进制、套接字、流量与演练共同证明采用。发布开启修复，运行改变才撤销旧代码。

来源