存在缺陷的路由器导致威斯康星大学互联网时间服务器流量激增（2003年）

# 有缺陷的路由器洪泛威斯康星大学互联网时间服务器 来源：https://pages.cs.wisc.edu/~plonka/netgear-sntp/ ***摘要*** 2003年5月，威斯康星大学麦迪逊分校发现其校园内一个公共网络时间协议（NTP）服务器持续遭受大规模互联网入站流量的洪泛攻击。洪泛流量速率高达数十万包/秒，带宽达数百兆比特/秒。随后我们确认，这些洪泛流量实际上来自全球数十万台真实的互联网主机。然而，此次事件并非源于恶意的分布式拒绝服务（DDoS）攻击，其根本原因实际上是某厂商数百万台面向家庭用户的低价互联网产品设计中存在严重缺陷。这些产品的意外行为将在未来数年内对威斯康星大学麦迪逊分校造成重大的运营问题。本文首次公开披露了这些产品设计缺陷的详细信息，并阐述了我们正在采取的多方解决方案，涉及大学、产品制造商、相关互联网标准（RFC）以及公共互联网服务与用户社区。 **目录** ``` 有缺陷的路由器洪泛威斯康星大学互联网时间服务器 网件公司与大学合作解决方案 初始洪泛攻击 图1. 初始洪泛攻击 阻断洪泛攻击 背景：简单网络时间协议（SNTP） 图2. SNTP请求数据包 图3. 单播SNTP应答数据包 洪泛持续 图4. 洪泛持续：一个月后 调查过程 联系源头网络 图5. 向同行机构发送的电子邮件通知 收集背景信息 审查网件代码 联系网件公司 图6. 发送至网件支持部门的邮件 图7. 网件支持部门的回复邮件 审查流程 有缺陷的SNTP客户端 对网件客户的影响 受影响网件产品的代码升级 图8. 受影响的网件产品 有缺陷产品统计 图8a. 网件SNTP客户端每日请求量 建议修复方案 初步修复："即时"代码 网络运营方案：提供服务还是切断连接？ 终局方案A：威斯康星大学麦迪逊分校网件任播时间服务 图10. 基于WiscNet BGP的任播时间服务 终局方案B：尝试抑制请求 图11. 利用全球BGP路由表抑制请求 终局方案B：所需的IP资源 图12. 基于BGP抑制所需的IP资源 通报互联网社区 明确互联网最佳实践与协议标准 状态更新，2003年8月21日 图13. 最新洪泛情况 回顾与反思 致谢 分析工具 参考文献/延伸阅读 常见问题解答 网件公司对导致贵网络遭受此次（无论是否无意）拒绝服务攻击应承担何种责任？ 是否考虑过设立一个向网件客户端返回虚假应答的服务器，以促使用户升级？ 这些产品的预期使用寿命是多久？ 在图13中，那个"鲨鱼鳍"状峰值是否与上周的电网故障（2003年大停电）及随后的"滚动式"恢复有关？ 除了文中提及的设备，是否还有其他设备也存在导致无意中洪泛贵网络的缺陷？ 本文被Slashdot报道后产生了什么影响？ 为何不采用传统的厂商召回/缺陷解决方案方案？ 我来自[某IT媒体]，是否有时间接受我的采访？ 媒体报道情况如何？ ``` --- ## 初始洪泛攻击 图1展示了2003年5月13日至15日（周二至周四）48小时内校园入站流量曲线图。图表前半段显示校园典型的流量水平，峰值入站包速率约为40,000包/秒。然而如图所示，从当地时间5月14日上午8点左右开始，入站包速率急剧上升，流量主要来自商业互联网服务提供商WiscNet。约9:40，这些额外流量开始影响我们的测量基础设施和部分旧式校园内部路由器。至11点，我们已通过协议和端口号识别出洪泛流量：它们均指向我们的公共时间服务器。随即我们在上游WiscNet边界路由器处阻断了该入站流量，暂时缓解了问题。这是网络运营商应对恶意拒绝服务洪泛攻击的典型操作——我们当时假设这属于此类攻击。 --- ### 阻断洪泛攻击 相关流量看似为网络时间协议（NTP）查询，因为它们是由76字节的IP数据包构成，目标为UDP端口123（NTP端口）。但这些数据包具有一个异常特征：尽管来源看似多样，但所有数据包均使用相同的源端口号：23457。因此，我们能够配置路由器仅阻断针对NTP服务器的部分查询请求，同时继续正常处理其他合法请求。具体而言，我们阻断了所有源端口为23457、目标端口为123（NTP）的UDP流量。（注：数字23457似乎是精心选择的，刚好是23456的下一个数。） 此时我们仅将其归咎于"攻击者"的幼稚——我们推测其伪造了大量随机源地址——因此暂未深入处理，预计洪泛会在数小时内自行消退，类似"脚本小子"发起的攻击通常如此。 --- ## 背景：简单网络时间协议（SNTP） 根据Dave Mills的RFC2030文档摘要： > 简单网络时间协议（SNTP）是网络时间协议（NTP）的简化版本，用于同步互联网中的计算机时钟。它是一个简单的无状态远程过程调用（RPC）系统，其精度和可靠性预期与RFC-868中描述的UDP/TIME协议相似。当不需要完整NTP实现的终极性能时，可使用SNTP。 > 需注意SNTP使用与NTP相同的数据包格式。因此SNTP客户端能够利用NTP服务器，即使它们未实现完整的对等NTP协议复杂性。SNTP会话通常遵循以下步骤： 1. 需要获取时间的客户端向NTP服务器的知名端口123发送包含SNTP请求的UDP数据包，并等待应答。 #### 图2. SNTP请求数据包 ``` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |LI | VN |Mode | Stratum | Poll | Precision | |=0|=1-4|= 3 |= 0 |= 0 |= 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Delay | |= 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Dispersion | |= 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Identifier | |= 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Timestamp (64 bits) | |= 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originate Timestamp (64 bits) | |= 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp (64 bits) | |= 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmit Timestamp (64 bits) | |= n | | (某个数值：零，或客户端发送请求时的时间) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` 2. 服务器从知名NTP端口123向SNTP客户端发送包含SNTP应答的UDP数据包进行响应。 #### 图3. 单播SNTP应答数据包 ``` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |LI=| VN |Mode | Stratum | Poll | Precision | |0-2|=req.|= 4 |= 1-14 |= (忽略) |= (忽略) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Delay | |= (忽略) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Root Dispersion | |= (忽略) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Identifier | |= (忽略) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reference Timestamp (64 bits) | |= (忽略) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originate Timestamp (64 bits) | |= (从请求数据包的发送时间戳复制) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp (64 bits) | |= (服务器收到请求的时间) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmit Timestamp (64 bits) | |= (服务器发送应答的时间) | |= n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` 3. 客户端收到应答后，可选择性地使用应答中的原始时间戳（Originate Timestamp）验证响应，试图确认这确实是对应其请求的响应。（若应答来自其他伪造源，则不太可能包含正确的原始时间戳值。）随后提取"发送时间戳"（Transmit Timestamp）的值，可能进行微调以估计单程端到端延迟，并将结果作为当前时间设置本地时钟。 *现在，回到我们的故事……* --- ## 洪泛持续 一个月后，我们发现NTP入站洪泛流量以更高的速率持续，图4显示了2003年6月初以来相关流量的路由器丢包率。图4显示： （1）速率存在轻微的日间波动（可能源于用户昼夜行为） （2）整体速率维持在250,000包/秒以上（超过150兆比特/秒） （3）流量速率在所示时间内持续增长 图中的急剧下降并非洪泛减退，而是由于网络维护和上游临时阻断。发现洪泛持续且速率仍在增长后，我们展开深入调查。通过谨慎地部分解除入站接口的阻断，允许少量流量通过至服务器并捕获包含载荷的数据包，我们确认这些数据包看似合法且格式规范的简单网络时间协议（SNTP）第一版查询，尽管每个客户端的发送速率异常偏高。例如在某次追踪中，许多客户端产生了约每秒一次的查询。这对正常构建的SNTP客户端而言极其异常，因为使用SNTP的应用程序仅需相对准确地设置自身时钟，使主机获得合理的当前时间感知。每秒一次的查询频率极为离谱，远非NTP客户端最佳实践。此外我们发现，许多IP地址可解析为DNS名称，且这些IP地址对于解除阻断的入站接口而言均是有效源地址。这表明源地址很可能并非伪造，而是运行着异常SNTP客户端的真实互联网主机。遗憾的是，这些客户端源主机均不在本地校园网络内，这意味着我们需要远程站点的工作人员协助调查。 --- ## 调查过程 ### 联系源头网络 从上述数据包追踪的顶级通信源IP地址中，我选择了来自其他大学的两个客户端主机——这些机构拥有擅长应对此类事件的技术人员。以下是我发送给其中一所机构（某客户端主机所属）事件响应团队的邮件（为适度匿名，已将真实SNTP客户端IP地址替换为10.42.69.10，并移除邮件域名）。 #### 图5. 向同行机构发送的电子邮件通知 ``` 日期：2003年6月14日 周六 04:34:11 -0500 发件人：Dave Plonka 收件人：abuse@[remotedomain] 主题：来自10.42.69.10至ntp1.cs.wisc.edu的sntp/ntp查询洪泛 [机构名称]网络滥用处理团队： 自2003年5月14日约0800（中部时间）起，我校的NTP服务器"ntp1.cs.wisc.edu"（128.105.39.11）持续遭受大规模简单网络时间协议（SNTP）请求洪泛——远超其处理能力。这种入站SNTP请求的异常增长至今仍在持续。为缓解洪泛，我们目前阻断了超过25万包/秒（超过150兆比特/秒）的流量，且已持续数周。我们正在尝试确定此洪泛是否具有恶意性，或是SNTP客户端配置错误或程序缺陷所致。 该流量主要包含76字节的UDP数据包，是大量源主机地址发往ntp1.cs.wisc.edu端口123（NTP）的SNTP第一版查询。异常的是，这些请求的UDP源端口均为23457。我们已识别出主机地址10.42.69.10仅为其中一个来源（实际源主机地址至少有数万个）。我附上了2003年6月13日（周五）下午的数据包捕获时间戳日志，证实来自主机10.42.69.10的SNTP查询包以约每秒一次的异常高频发送。日志中包含最后一个数据包（帧998）的数据包解析（由tethereal工具生成）和十六进制转储，显示其为符合RFC 1361（http://www.ietf.org/rfc/rfc1361.txt）描述的有效SNTP v1查询。 能否尽快协助我们调查，识别该主机的操作系统及其运行的SNTP客户端代码？若能获知10.42.69.10上当前是否有进程绑定了UDP端口23457，以及该进程运行的代码将极具价值。 谢谢， Dave 附注：我们的调查目前显示，Windows系统（如2000和XP）具有"Internet Time"功能，通常配置为向微软服务器"time.windows.com"发送SNTP请求，但此服务器可更改。我尚未发现任何SNTP客户端定期使用UDP端口23457作为源端口。（注：该端口号似乎是精心选择的，刚好是23456的下一个数。） ---------------------------------------------------------------------- 1 2003-06-13 16:32:24.8808 10.42.69.10 -> 128.105.39.11 NTP NTP 7 2003-06-13 16:32:25.9611 10.42.69.10 -> 128.105.39.11 NTP NTP 14 2003-06-13 16:32:27.0412 10.42.69.10 -> 128.105.39.11 NTP NTP 21 2003-06-13 16:32:28.1215 10.42.69.10 -> 128.105.39.11 NTP NTP 27 2003-06-13 16:32:29.2020 10.42.69.10 -> 128.105.39.11 NTP NTP 33 2003-06-13 16:32:30.2821 10.42.69.10 -> 128.105.39.11 NTP NTP 39 2003-06-13 16:32:31.3624 10.42.69.10 -> 128.105.39.11 NTP NTP 45 2003-06-13 16:32:32.4427 10.42.69.10 -> 128.105.39.11 NTP NTP 51 2003-06-13 16:32:33.5232 10.42.69.10 -> 128.105.39.11 NTP NTP 56 2003-06-13 16:32:34.6049 10.42.69.10 -> 128.105.39.11 NTP NTP 68 2003-06-13 16:32:36.7638 10.42.69.10 -> 128.105.39.11 NTP NTP 74 2003-06-13 16:32:37.8441 10.42.69.10 -> 128.105.39.11 NTP NTP 78 2003-06-13 16:32:38.9242 10.42.69.10 -> 128.105.39.11 NTP NTP 84 2003-06-13 16:32:40.0050 10.42.69.10 -> 128.105.39.11 NTP NTP 90 2003-06-13 16:32:41.0846 10.42.69.10 -> 128.105.39.11 NTP NTP 96 2003-06-13 16:32:42.1647 10.42.69.10 -> 128.105.39.11 NTP NTP 998 2003-06-13 16:35:13.3789 10.42.69.10 -> 128.105.39.11 NTP NTP 帧998（线路上90字节，捕获90字节） 到达时间：2003年6月13日 16:35:13.378978000 与前一数据包的时间差：0.524605000秒 相对首包时间：168.498125000秒 帧编号... ```