OVH 2016年Mirai攻击：DDoS清洗能力为何成为问责试金石

摘要

OVHcloud公开表示，在2016年9月首轮Mirai攻击浪潮中，其基础设施遭遇了超过每秒1太比特的流量。这个峰值来自运营商披露，不等于对每个数据包、受攻击目标、持续时间或客户影响的独立审计。[1][2]
USENIX Security的独立研究从多个测量视角重建了Mirai的发展和攻击历史。研究记录显示，针对OVH基础设施的攻击于2016年9月18日开始；其观察到的Mirai感染规模一度约为60万台设备，并分析了超过1.5万次攻击。[3][4]
OVH事件必须与针对KrebsOnSecurity和Dyn的攻击分开。即使它们涉及同一恶意软件家族，也不能把不同日期、目标、依赖关系、服务影响和缓解行动拼接成一个事件。
Mirai的核心攻击能力可以由受感染设备直接发送流量，源地址可能是设备实际使用的可路由地址。这与依赖伪造源地址的反射放大攻击不同。BCP 38、BCP 84和其他反欺骗措施仍然重要，但不足以单独阻止这种直接洪泛。[15][16][19][20]
DDoS能力不是一个孤立的带宽数字。真正的运营能力包括同时观察比特率和包速率，识别受限资源，控制路由或过滤变更，避免转发面与控制面失稳，并为合法流量保留可用路径。
清洗系统的成绩不能只用“丢弃了多少攻击流量”衡量。客户关心的是合法连接、应用事务和区域访问能否继续完成，以及恢复结论能否由内部遥测、外部探测和客户观察相互印证。
责任分布在多类参与者之间：设备厂商影响默认凭据、开放服务和更新支持；设备所有者负责部署与维护；接入网络能够观察异常外发行为；转接和托管运营商掌握容量、过滤、流量工程与恢复；执法机关处理僵尸网络运营者的刑事责任。[5][9]-[12]
公开资料没有揭示OVH完整的清洗拓扑、启动阈值、过滤规则、容量余量、受影响客户数量、合同责任或损失金额。这些未知项不能被攻击规模或事后叙述填补。
最终的问责标准应落在可运行的服务上：缓解路径是否承受了真实的数据包组合，合法流量是否持续送达，附带损害是否得到约束，恢复记录是否足以由客户、运营商或审查者核对。

一、每秒1太比特是问题的起点，不是韧性的结论

2016年9月，OVHcloud公开报告称，在首轮Mirai浪潮期间，其基础设施承受了超过每秒1太比特的攻击。OVHcloud现有的DDoS说明把这次事件列入大规模攻击的发展脉络，后来的工程文章也把Mirai描述为首个产生超过1 Tbps流量的僵尸网络。[1][2] 这个数字之所以重要，是因为它显示，大量安全薄弱的联网设备已经能够汇聚成足以冲击大型托管网络的流量源。

但峰值本身只回答了“观测到多大流量”，没有自动回答“服务是否得到保护”。公开数字通常不能说明测量点位于上游、网络边缘、清洗入口还是内部链路；不能说明峰值持续了多久；也不能说明流量集中在一个目标还是多个目标。它还没有告诉读者，统计发生在过滤之前还是之后，是单个站点的瞬时值还是多个位置的汇总值。

同一个比特率也可能对应截然不同的工程压力。大量接近最大传输单元的数据包容易耗尽链路带宽；数量庞大的小数据包则可能先触及路由器转发速率、访问控制表、队列、缓冲区或遥测系统的上限。连接型攻击还可能耗尽状态表，合法但高并发的请求则可能越过网络层，把压力推向应用。

因此，“超过1 Tbps”不能独立证明OVH准备充分，也不能证明其准备不足。它更不能直接推出疏忽、合同违约或法律责任。要作出这些判断，至少还需要知道：哪个资源首先接近上限，缓解何时启动，路径如何变化，合法流量保留了多少，服务在哪些区域受到影响，以及系统以什么证据确认恢复。

OVH后来的包速率工程讨论有助于说明为什么核心路由器可能在高包速率下承压。[2] 然而，这类后续材料只能作为理解控制面的技术背景，不能倒推成OVH在2016年部署了哪些具体设备、阈值或过滤策略。有关接口计数器、线路卡限制、私有路由策略和容量储备的细节，公开记录并不完整。

真正有意义的容量陈述应同时回答六个问题：测量了什么资源；在哪里测量；峰值是否持续；当时处于何种缓解状态；合法流量是否继续完成有用事务；流量转移后哪个组件成为新的瓶颈。只有把攻击数字与这些问题连接起来，容量才从宣传性指标变成可审查的运营事实。

二、独立研究证明了僵尸网络及其时间线，却没有揭开OVH的私有网络

关于Mirai的最强独立技术记录来自USENIX Security发表的研究。研究人员结合多个数据源和测量位置，重建了Mirai的扫描、感染、控制基础设施和攻击活动。论文记载，Mirai于2016年9月18日开始攻击OVH基础设施；研究观察到的感染规模一度约为60万台设备，并分析了观察期内超过1.5万次攻击。[3][4]

这项研究的重要性在于，它没有只依赖受攻击企业的一张流量图。多个观测角度共同显示，摄像机、录像设备和其他联网产品可以因为弱凭据或暴露服务而被大规模控制，随后从地理上分散的普通网络连接直接发出攻击流量。它为Mirai的增长机制和攻击能力提供了独立基础。

然而，僵尸网络侧的重建并不等于受害网络侧的完整事故报告。USENIX研究没有披露OVH每个客户的可用性，也没有公开其全部边缘结构、清洗位置、内部链路、过滤阈值或商业义务。研究所观察到的约60万台感染设备也不表示所有设备参加了每一次攻击，更不能用来推算某一时刻向OVH发包的精确设备数量。

不同证据持有者掌握的是不同切面。研究人员能够观察Mirai的传播和攻击基础设施；OVH掌握内部网络状态、客户遥测和缓解决策；接入运营商可能掌握订户连接和异常外发数据；设备所有者则可能掌握本地配置。没有一个公开来源天然拥有整条证据链。

这也是为什么事件边界必须保持清晰。Mirai曾被用于攻击KrebsOnSecurity、OVH以及后来的Dyn，但相同恶意软件并不会把不同目标变成同一次事故。针对Dyn的事件涉及权威DNS连续性；OVH事件的核心是托管网络、流量吸收和清洗能力。混为一谈会放大叙事，却削弱事实精度。

美国司法部后来公布了涉及Mirai相关案件的认罪情况。[5] 该资料可以支持一个有边界的法律事实：被点名的被告对特定Mirai相关行为承担了刑事责任。它不能证明每一波发往OVH的流量由谁下令，也不能把每一个受感染设备、设备所有者或沿途网络都归为共犯。

负责任的分析必须分层使用证据：运营商资料支持有明确归属的测量和运营陈述；独立研究支持僵尸网络时间线与技术机制；司法记录支持有限的法律事实；标准和政策文件用于说明适用控制。任何一层都不应被拉伸去填补另一层才可能掌握的空白。

三、直接僵尸网络洪泛与反射放大不是同一种控制问题

反射放大攻击通常先把受害者地址伪装成请求源地址，再向第三方服务发送小请求。第三方服务器把响应发给被冒充的受害者，某些协议还会产生明显大于请求的响应。阻止伪造源地址、关闭开放反射服务和限制放大协议，因而是这类攻击的重要治理手段。

Mirai的核心攻击能力并不依赖这种结构。受感染设备可以直接向目标发送流量，使用其连接实际分配的可路由源地址。攻击的分布性来自大量被控制设备同时参与，而不是每个数据包都必须借道一台反射服务器。[3][4]

这种机制差异直接决定了控制手段。RFC 2827所述的BCP 38旨在通过入口过滤限制伪造源地址；RFC 3704讨论了多宿主网络中的过滤问题，提醒运营商注意合法的非对称路由，避免机械的反向路径判断误伤正常流量。[15][16] RFC 7039和MANRS指南进一步提供了源地址验证与反欺骗的实施思路。[19][20]

这些措施能够削弱依赖源地址伪造的攻击，也有助于提高网络证据质量。然而，如果一台被感染摄像机正使用其真实分配地址直接发包，单纯验证源地址并不会阻止它。反欺骗不会修补默认凭据，不会关闭暴露的管理接口，也不会自动增加受害网络的转发和清洗能力。

对于直接洪泛，运营商需要分析源分布、协议行为、目的地址集中度和重复攻击特征；需要与源网络协调；也需要在不过度封锁整个地区或自治系统的前提下约束恶意流量。对于反射放大，还应增加反射协议识别、放大节点治理和源地址验证。混合型攻击则可能同时要求两套控制。

NIST关于跨域流量韧性的指导把DDoS缓解置于分层体系中，涵盖路由安全、源地址验证、过滤、远程触发黑洞、FlowSpec、速率限制、检测和跨运营商协调。[13][14] RFC 4732也把拒绝服务视为广泛的系统工程问题，并提醒防御措施本身可能产生附带影响。[17]

这些后续指导不能证明OVH在2016年具体启用了哪些功能。它们所支持的是一个更稳健的判断：任何控制都必须与攻击机制匹配。把BCP 38描述成阻止Mirai的唯一缺失开关，不仅技术上不准确，还会把责任错误地从设备安全、直接流量检测和受害侧容量转移出去。

四、DDoS容量至少包含六种不同资源

托管网络所说的“容量”，至少应拆成以下维度：

容量维度	它回答的问题	典型失效表现	所需证据
链路容量	入口、骨干或回程链路能承载多少比特	接口饱和、排队和丢包	接口计数器、队列数据、路径利用率
转发容量	路由器每秒能处理多少数据包	高包速率下转发下降或设备异常	包速率、包长分布、线路卡与转发面遥测
清洗容量	过滤平台能分类和处理多少攻击流量	规则处理不足、误判或清洗入口拥塞	清洗计数、分类结果、规则命中及资源使用
控制面稳定性	路由、管理和自动化在压力下能否继续工作	会话抖动、路由收敛异常、管理失联	BGP状态、控制面负载、变更记录
干净流量交付能力	过滤后的合法流量能否返回托管网络	攻击被丢弃但客户仍不可达	清洗出口、回程链路、端到端服务探测
应用承载能力	网络缓解后业务是否仍能完成事务	连接建立但应用超时或后端过载	应用成功率、延迟、错误率和客户观察

这六种资源互相关联，却不能相互替代。一个平台可以拥有足够的总带宽，但在小包洪泛下先触及转发上限；清洗设施可以成功丢弃攻击包，却因为返回链路不足而无法把合法流量送回；路由变化也可能把压力从一个站点转移到另一个共享瓶颈。

包速率尤其容易被非技术性叙述忽略。相同比特率下，小包意味着更多报头解析、查表、排队、过滤和遥测操作。路由器的线路卡、转发芯片、交换结构、缓冲区、访问控制表和路由处理器各有不同边界。只用总吞吐量测试，可能完全错过真实攻击会触发的失败路径。

容量测试还必须包含进入缓解状态的过渡期。系统在稳定清洗状态下能够工作，不代表它在安装过滤规则、改变路由、放大遥测量或切换回程路径时同样稳定。一次未经演练的路径变化可能制造第二次中断。

测试条件应被完整记录。若平台被宣称可处理某个包速率，就应说明数据包大小、协议组合、规则数量、前缀数量、日志配置和合法流量比例。若容量跨多个站点共享，还需要说明怎样防止一个地区的攻击耗尽其他地区的备用资源。

供应商实验室数字、设计容量和生产实测也必须分开。实验室环境往往有理想化的包型、规则和故障条件；生产网络则存在不均匀流量、多个客户、路由依赖和同时发生的故障。董事会和客户未必需要查看私有配置，但需要知道测试覆盖了哪种资源、何种失效域以及何种真实服务结果。

五、托管连续性始于网络边缘，却不能止于过滤入口

托管运营商面对分布式直接洪泛时，首先要在硬故障发生之前识别异常。随后，它必须决定是否启动缓解、把哪些前缀或服务纳入动作范围、在哪里过滤，以及如何确保流量变化不会使路由和客户连接进一步失稳。

检测不能只依赖一个图表。接口计数器提供比特率、包速率、错误和丢弃数据；流记录揭示协议、端口、源分布和目的集中度；路由器遥测显示队列与控制面压力；清洗平台记录分类与动作；应用和客户侧探测则显示有用事务能否完成。BGP及内部路由数据说明流量实际走过了哪条路径。

每一种观测都有局限。流量突增可能是攻击，也可能是产品发布、直播活动或测量错误。源地址高度分散可能来自僵尸网络，也可能来自全球用户。过滤平台显示丢弃了数百万个数据包，不代表客户已经可用；一个地区探测成功，也不能证明另一个地区没有丢包。

问责的关键在于关联。攻击入口的包速率应该能与清洗系统记录相互解释；路由变化应能与外部路径观测对照；过滤动作应能与应用成功率和客户报告对应。若不同视角互相矛盾，运营商需要调查测量边界，而不是挑选最有利的一张图。

启动方式同样影响风险。按需清洗可以减少常态依赖，但会引入检测、决策和切换间隔；常开清洗消除了这一特定切换，却仍可能存在分类、容量、共享故障域或回程限制。混合模式也不是天然最优，其效果取决于威胁历史、网络结构和演练结果。

公开资料没有披露OVH在2016年的完整私有设计。因此，本文不推测其清洗站点、路由策略或内部阈值，而是检验运营商应保留何种证据。核心标准是：攻击期间继续工作的路径有没有运送合法流量，以及运营商能否证明这一结果。

六、缓解启动本身也是高风险变更

重大攻击发生时，网络团队往往必须在极短时间内改变流量处理方式。新的过滤规则可能误封合法协议；错误的前缀操作可能扩大中断范围；预定清洗路径可能没有如期接受路由；不同响应人员还可能同时执行冲突动作。

因此，启动政策必须明确行动权限、对象范围、触发信号、成功标准和退出条件。自动化能够缩短响应时间，但动作对象应被限制在经过批准的前缀、服务和路径内。人工判断能够处理陌生攻击，却需要清楚的事件负责人和经过演练的操作步骤。

攻击前的验证应覆盖路由授权、会话、社区属性、前缀列表、清洗入口和干净回程。运营商还应知道能否只转移部分目标，以及非对称路径对有状态服务会造成什么影响。只演练“所有组件正常”的理想场景，无法证明一个清洗站点或一个转接路径失效时仍有连续性。

攻击期间，每一次实质性变更都应留下统一、带时间的记录：改了什么、由谁执行、影响哪些资源、以什么信号判断成功，以及何时撤销。这并不是要求团队在服务中断时进行冗长审批，而是确保所有响应者知道当前状态，并避免遗留规则长期伤害客户。

回退与启动同样重要。过早撤销清洗可能暴露在第二波攻击下；过晚撤销可能让不必要的过滤继续限制客户。运营商应设置稳定观察期、分阶段恢复和重新进入缓解的明确触发条件。

RFC 4732提醒，拒绝服务防御可能产生自身的有害后果；RFC 4948则讨论了互联网安全中责任分散和激励不足等挑战。[17][18] 这些文件没有规定OVH的私有操作手册，却支持一个基本原则：任何缓解措施都必须以运行后果评估，而不是以配置已下发为完成标志。

七、清洗系统必须证明合法流量送达，而不只是攻击流量被丢弃

DDoS清洗同时追求两个结果：拒绝不需要的流量，并交付需要的流量。运营商往往更容易展示前者，因为攻击峰值、规则命中和丢弃数量便于统计；客户实际体验的却是后者。

攻击分类可能依据协议有效性、源行为、信誉、包型、目的上下文、速率和应用知识。每种方法都有误报和漏报风险。全面阻断UDP可能压制攻击，却也可能破坏DNS、语音、游戏或监控业务；按单一源地址限速可能伤害共享地址后的大量用户；适用于浏览器的挑战机制则未必适合API或机器通信。

多租户托管商尤其难以预先掌握所有客户的正常流量模式。它需要客户级策略、紧急联系人和安全的规则调整方式。客户也有责任向运营商提供关键协议、区域需求和可接受降级边界，否则运营商只能在不完整的业务信息下取舍。

干净路径还必须真正可用。在上游清洗掉攻击流量没有意义，如果过滤后的回程连接过小、路由不稳或指向错误位置；在本地进行精确过滤也无济于事，如果攻击在抵达过滤设备前已经塞满接入链路。分布式运营商还必须判断清洗容量、站点间传输和客户连接是否共享同一瓶颈。

恢复证据应覆盖不同层次。路由可见不等于源站可达；TCP握手成功不等于应用事务完成；全球平均值正常也可能掩盖特定区域的严重丢包。运营商需要从不同网络和地区执行探测，并把结果与清洗、路由、服务器和应用遥测进行核对。

附带影响也应进入事故记录，而不能被最终的“已恢复”状态抹去。哪些协议、地区或网络受到限制？哪些客户需要例外？过滤是否保护了一个目标，却把负载转移到另一个目标？攻击流量下降后，合法服务是否仍有一段时间处于降级状态？这些数据既用于改进下一次响应，也用于向客户提供可信解释。

公开报告不必披露所有过滤签名和内部阈值。过度详细的信息可能帮助攻击者。运营商仍可在安全边界内说明攻击类型、测量规模、主要缓解动作、影响时段、恢复信号和尚未解决的问题；更敏感的拓扑、样本和合同材料则可向有权限的客户或审查者提供。

OVH的公开材料证明了攻击规模及缓解问题的重要性，却没有提供逐客户的干净流量结果。这个缺口只能被列为已知未知，不能反向解释成“所有客户都保持在线”，也不能解释成“所有客户都发生中断”。

八、比特率和包速率必须在同一证据框架中解释

带宽以每秒比特数表达，直观地对应链路标称容量。但路由器面对的是一个个数据包。即使总比特率相同，较小数据包也会带来更高包速率，要求设备执行更多解析、查表、排队、转发、丢弃和统计操作。

路由设备没有单一容量上限。线路卡、转发芯片、交换结构、缓冲区、过滤表、路由处理器和遥测导出模块可能以不同方式失效。某条规则对一种协议处理代价很低，对另一种流量却可能消耗更多资源。攻击期间大量导出细粒度流记录，甚至可能反过来加重系统压力。

这意味着压力测试必须采用容量矩阵，而不是单一峰值。矩阵应包含不同包长、协议、源分布、目的数量、过滤规则、路由状态和合法流量比例。还应包含部分故障，例如一个清洗站点不可用、一个上游拥塞或一个遥测组件退化。

测试也应关注容量之间的转移。过滤入口承受住攻击后，清洗出口可能成为瓶颈；核心路由器成功转发后，客户侧连接可能饱和；网络层过滤正确时，应用层仍可能因连接或请求压力崩溃。宣称“平台可处理某个太比特数”无法说明这些后继边界。

OVH后来的包速率文章对这一控制问题具有参考价值。[2] 但它不能证明2016年事件中究竟是哪台设备、哪条链路或哪种规则接近上限。本文能够得出的结论仅是：可信的事后证据必须同时包含比特率、包速率、包长和测量位置。

对客户和董事会而言，重点不在于公开每个硬件型号，而在于确认测试是否覆盖实际受限资源、缓解切换是否经过演练、备用能力是否处于独立故障域，以及服务层证据是否被保留。任何一个攻击峰值都不能代替这些答案。

九、责任从攻击流量到达OVH之前就已经开始

Mirai把受感染设备变成了攻击者可调用的分布式网络资源。因此，责任链条在流量抵达托管网络之前就已形成，但它不能被简化为单一责任人。

设备制造商和软件供应商决定默认凭据、暴露服务、更新方式、认证机制以及产品终止支持后的处置。唯一凭据、受限管理接口、可靠的安全更新和清晰的支持期限能够降低设备被接管的概率。ENISA曾警告，日常联网设备可能成为僵尸网络组成部分。[9]

美国商务部和国土安全部后来的僵尸网络报告强调，需要技术生态中的多方协同，而不能仅要求攻击受害者无限扩容。[10][11] NIST关于物联网DDoS的工作也把设备安全与网络韧性视为相互连接的问题。[12] 这些资料支持系统性控制框架，但不能证明某一家制造商明知会造成OVH事件，也不能证明所有感染设备具有完全相同的弱点。

设备所有者负责其可控制范围内的部署与维护，包括更改凭据、限制外部访问、安装更新以及隔离无法修复的设备。不过，有些用户缺乏专业知识，或者厂商并未提供可用更新。这个现实影响治理方式和激励设计，却不会使持续对外发起扫描或攻击的设备变得无害。

接入网络能够看到用户侧流量离开本网络。异常扫描、极高的目的地址分散度或持续攻击行为可能形成检测信号。运营商可以维护有效的滥用联系方式、通知用户并采取适度限制。但公开记录不足以支持点名某一家接入网络“明知故犯”。

转接运营商和缓解服务商能够在流量抵达受害者接入链路之前提供容量、黑洞路由、FlowSpec或协同过滤。不过，这些动作也有授权和附带损害问题：范围错误的黑洞操作可能直接移除本应保护的服务。

OVH掌握其托管边缘、内部容量、缓解启动、客户沟通和恢复证明，因此是本案网络问责的中心运营商。它并不控制每台设备的固件，也不控制所有源网络。执法机关负责调查和追诉僵尸网络运营者，却不负责实时转发和过滤数据包。[5]

合理问责应遵循实际控制能力：每个参与者当时能够观察什么、能够改变什么、保留了什么证据，以及其行动如何影响下一环节。责任不能仅根据品牌知名度、地址归属或流量经过某个网络就自动推定。

十、源网络证据必须足以采取行动，又不能变成未经证实的指控

直接僵尸网络流量带来一种特殊证据问题。源地址可能是真实的，但它指向的可能是普通订户连接、运营商级NAT出口、企业网关或受感染设备，而不是实际操纵攻击的人。地址真实性提高了网络定位能力，却没有直接完成行为人归属。

一份可操作的滥用报告至少应包含带时区的时间戳、源和目的地址、协议、端口、包数量、字节数量、采样方法、判断置信度、采取的缓解动作，以及是否检查过源地址欺骗。在合法且必要的范围内，短数据包样本或行为特征可以帮助源网络区分恶意流量和正常使用。

ASN和IP地址登记记录有助于确定地址资源被委派给哪个网络，以及公开了哪些运营联系人。这些记录是资源分配和运营元数据的线索，不是攻击者身份的判决书。某自治系统在特定时刻宣告了一条路由，并不证明它知道某台设备正在攻击，也不证明宣告该路由的网络就是攻击发起者。

BGP证据同样需要边界。路由起源可以说明哪个自治系统向互联网宣布了某个前缀，但看不到所有私有路径、订户身份和设备状态。地址还可能在时间上重新分配，或者由多个用户共享。因此，源网络协调必须依赖精确时间和足够细的测量信息。

滥用报告应当可验证且措辞克制。接收方需要足以定位客户或设备的信息；发送方则应明确采样和归属局限，避免推定故意行为。双方最好保留工单、响应动作和后续观察。重复出现的证据可能显示结构性问题，一次观察则可能来自短暂感染或测量误差。

MANRS等行业规范可以把反欺骗和协同责任转化为具体实践。[20] 但遵循规范的声明不能代替当前运行证据。真正有用的问题是：过滤是否生效，滥用联系人是否可达，源网络是否能找到异常设备，重复流量是否下降。

OVH可以使用这类证据进行针对性缓解和通知。现有公开记录没有披露每次攻击的完整源自治系统集合，也没有说明各源网络采取了什么动作。对这些事项作进一步判断，需要由证据持有者提供材料。

十一、对等互联、转接与清洗路径决定攻击在哪里被约束

大型托管网络的DDoS响应并不是只在本地防火墙上完成。流量可能经过多个转接商、对等互联点、骨干链路和清洗位置。若攻击在抵达本地过滤设备之前已经使接入链路饱和，最精确的本地规则也无法恢复服务。

上游缓解能够更早减少流量，但需要明确的路由授权、稳定的会话和足够的跨域协调。远程触发黑洞可以迅速保护更大范围的基础设施，却以牺牲目标可达性为代价。FlowSpec能够下发更细粒度规则，但规则权限、设备支持和错误范围都必须受到控制。[13][14]

对等互联和转接容量还涉及故障域。如果多个站点共享同一骨干或同一清洗出口，表面分布式的设计可能仍有共同瓶颈。攻击者无需压垮所有设施，只需找到连接它们的有限资源。

外部路由观察可以帮助确认流量是否按计划进入缓解路径，但公共路由收集器无法看到每一条私有对等和内部路径。运营商应把外部观测与自身BGP、接口和清洗数据结合，避免把“外界看到了路由”误当作“客户流量已经恢复”。

跨运营商协同还需要清晰的联系人、前缀范围、动作期限和撤销机制。只在事故发生后临时寻找上游联系人，会浪费最关键的响应时间。事前演练应确认对方能接受正确前缀、识别授权请求，并把合法流量送回预定位置。

NSTAC关于互联网和通信韧性的报告以及NIST的跨域指导，都支持把路由、DDoS缓解和运营协调作为连续性的一部分。[6][13][14] 这些资料提供的是通用控制依据，而不是OVH在2016年已经部署某项具体能力的证明。

十二、时代背景可以解释风险上升，却不能替代事件级证据

2016年前后，大规模DDoS和物联网僵尸网络进入公共安全讨论的中心。Akamai当年的安全报告及其公告记录了当时更广泛的攻击环境。[7][8] ENISA、美国政府部门和NIST随后从设备安全、生态激励和网络韧性角度提出了进一步建议。[9]-[14]

这些资料有助于说明，OVH事件并非孤立的技术奇观，而是互联网设备安全、源网络治理和受害侧容量共同作用的结果。但宏观趋势不能被当作OVH事件的详细事故记录。全球攻击量上升不等于某一客户发生了特定时长的中断；行业常见攻击手法也不等于某一波流量使用了相同协议组合。

同样，2016年之后形成的成熟指导不能倒推成当时已经执行的控制。它可以用来评价运营商今天应该保留什么证据，也可以帮助识别历史记录中的空白，却不能证明OVH当时使用了远程黑洞、FlowSpec、某类路由安全措施或某个清洗拓扑。

时代背景的正确用途，是帮助建立控制分类和责任边界。它不应填补目标、客户、接口、阈值、损失和合同方面的事实空缺。

十三、一套可辩护的事故证据包应把记录与结果分开

最可信的事后说明不是保证同类攻击永不再发生，而是提供一个边界清楚的证据包：发生了什么，哪些控制被改变，如何验证，产生了何种附带影响，以及哪些问题仍然未知。

控制面	应保留的证据	运行检验	重要局限
流量检测	时间同步的接口、流量、包速率和服务遥测	多个信号在硬故障前共同识别洪泛	采样和聚合可能掩盖短时或局部影响
容量边界	链路、转发、过滤和干净路径在特定包型下的上限	代表性负载保持在已测试资源范围内	实验室和供应商数字未必等同生产表现
缓解权限	获批前缀、负责人、供应商会话和启动政策	只有预定路由和规则发生变化	内部批准不能证明外部网络已经收敛
流量改道	变更前后公告、外部观测和上游接受记录	预定流量进入缓解路径	公共收集器看不到全部私有路径
攻击分类	协议、源分布、包样本和置信度	规则压制了已观察到的攻击向量	攻击者可换向量，规则也可能过度封锁
干净流量交付	多区域探测、应用成功率、延迟和源站健康	合法事务在缓解期间能够完成	合成探测可能遗漏客户特有业务
附带影响	被误丢弃的合法类别、例外和客户报告	损害保持在明确边界内	部分用户可能不会报告失败
源网络协调	有时间边界的滥用报告、联系人和后续动作	源网络能够定位并约束异常设备	地址证据不能证明人的身份或故意
回退	变更记录、负责人、退出条件和分阶段恢复	正常路由恢复且未立即复发	新一波攻击可能要求重新启动缓解
长期改进	演练、例外、容量复核和现行操作记录	控制在后续测试中持续通过	一次成功不能构成永久证明

这张表区分了“拥有记录”和“取得结果”。工单能够证明有人提出过动作；容量计划能够说明设计假设；ASN记录能够定位资源所属网络；过滤配置能够显示规则内容。它们都不能单独证明攻击期间用户完成了请求。

证据包还应区分公开材料和受保护材料。公开说明可以包含时间、规模、向量、主要动作、恢复信号和未知项。客户、审计方或监管方可在适当保密条件下查看更详细的拓扑、阈值、包样本、合同和内部决策。敏感材料不必完全公开，但应当被保留并可供授权核验。

最重要的原则是相互核对。接口计数器应与清洗遥测大致一致；路由变化应与外部观察对应；过滤动作应与源站和应用健康相符；客户报告应能与区域探测解释。数据不一致并不意味着应丢弃某个视角，而是提示测量范围或时间边界需要继续调查。

十四、公开记录明确支持什么，又没有证明什么

公开资料支持以下判断：

2016年9月，OVH基础设施遭遇了与Mirai相关的重要攻击，OVHcloud报告峰值超过每秒1太比特。[1][2]
独立研究记录了自9月18日起针对OVH基础设施的攻击，并证明Mirai能够形成规模庞大的分布式僵尸网络。[3][4]
Mirai的核心能力包括由受感染设备直接发送流量，不能把它完全解释成源地址伪造或反射放大。
DDoS韧性需要设备安全、源网络响应、转接协调、路由控制、过滤、容量和恢复证据共同支持。[6][9]-[20]
司法记录能够支持特定Mirai相关案件中的有限刑事责任事实。[5]

公开资料没有证明：

OVH每个具体目标、受影响客户数量及各自影响时长；
OVH私有清洗拓扑、启动阈值、过滤规则和容量余量；
超过1 Tbps峰值的独立逐包审计；
每次OVH攻击所涉及的全部感染设备和源自治系统；
客户损失金额、服务补偿、合同违约或法律注意义务；
任一被点名接入网络明知并允许攻击发生；
后续标准所描述的每项控制已经在2016年由OVH部署；
司法记录中的被告下令实施了OVH观察到的每一次攻击。

这些限制并不会让事件失去研究价值。相反，它们决定了结论可以走多远。本文能够评价托管运营商及其合作方应展示的控制和证据，却不能利用公开摘要虚构一份私有事故复盘。

十五、运营商、客户和审查者应追问什么

托管和转接运营商

流量基线是否同时包含比特率、包速率、协议、源分布和服务成功率？
面对小包、大包及混合流量时，哪个组件首先成为瓶颈？
哪些前缀、站点和客户可以独立改道或过滤？
缓解会话、路由授权和干净回程是否经过真实演练？
事件期间，响应人员能否看到上游容量、过滤状态和外部可达性？
哪些合法流量类别容易被宽泛规则误伤？
启动、例外和回退是否由一个明确负责人统筹？
是否能够生成精确、限时且尊重隐私边界的源网络报告？
恢复验证是否依赖同一组可能已被攻击压垮的系统？
客户探测、外部探测和内部仪表是否得到相互核对？

设备制造商和设备所有者

设备是否默认使用唯一凭据，并限制管理服务的暴露？
产品在有效寿命内能否接收经过认证的安全更新？
停止支持状态是否清晰，用户是否有可行的替换或隔离方案？
所有者能否观察异常扫描、连接扩散或持续外发攻击？
无法修复的设备是否可以被安全下线，而不会破坏关键业务？

托管客户

服务商在现实条件下测试过哪些攻击规模、包型和协议组合？
缓解是常开、按需还是混合模式，切换条件是什么？
紧急过滤可能限制哪些客户协议、地区或用户群？
服务商如何证明干净流量和区域访问已恢复？
事故后客户能够获得哪些测量、时间线和解释？
备用供应商、路由和源站是否真正独立并接受过测试？

审计方和监管方

容量陈述是否绑定到具体接口、包型、规则集和测试日期？
证据是否显示合法服务完成，而不只是攻击流量被丢弃？
路由和过滤权限是否被限制在获批资源范围内？
敏感的包样本和拓扑能否在不公开安全细节的情况下接受核验？
改进措施是否有近期演练、例外记录和失败结果支撑？
IP、ASN和滥用联系信息是否与真实运营响应相连接？

这些问题并不要求无限容量，也不要求网络永不失败。它们检验的是：运营商是否能够识别已知威胁，在受控权限内采取行动，维持关键服务，并对结果作出有证据的解释。

结论：当干净流量真正存活，容量才具有问责意义

OVHcloud所报告的超过每秒1太比特Mirai攻击，是DDoS规模史上的重要节点。独立研究显示，大量受感染设备能够从分散的普通网络连接直接形成洪泛。政府、标准和行业资料则说明，响应必须横跨设备安全、源网络、转接、托管、过滤和执法。[1]-[20]

核心教训不是要求某一家运营商购买无限带宽。没有可信网络能够承诺吸收所有可能的攻击。真正的要求，是让容量声明与正在运行的基础设施证据绑定。

这种证据应包括明确测量边界上的比特率与包速率、可解释的缓解触发条件、受控的路由和过滤权限、足够的干净回程、端到端服务探测、附带影响记录、源网络协调以及经过演练的回退。它还必须正确区分直接僵尸网络洪泛和反射放大，只在机制适用时使用反欺骗控制，而不是把一个标准口号当作万能答案。

责任仍然是分布式的。设备制造商能够减少不安全默认设置；所有者能够修补或隔离设备；接入网络能够检测异常外发行为；转接和缓解服务商能够提供上游容量与过滤；OVH负责运营托管路径并证明恢复；执法机关负责追究僵尸网络运营者。每一方都应按其实际掌握的控制和证据接受评价。

IP登记、自治系统编号、流量图、容量计划和事故工单都很重要，但它们不是服务本身。真正的结果是：承载合法工作的数据包能否抵达目的地，攻击流量是否被约束，受限资源是否保持稳定，以及恢复记录能否由另一方核验。

对于承受DDoS压力的托管网络，最有说服力的证据从来不是事后报告中最大的数字，而是攻击期间仍然送达的干净流量、没有越过边界的关键资源，以及一份能够解释成功、失败和未知项的恢复记录。

资料来源

OVHcloud，“什么是DDoS攻击？”：https://www.ovhcloud.com/en-gb/security/anti-ddos/ddos-definition/
OVHcloud，“包速率攻击的兴起：当核心路由器成为风险点”：https://blog.ovhcloud.com/en/posts/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/
USENIX Security 2017，“理解Mirai僵尸网络”演讲页面：https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis
Antonakakis等，“理解Mirai僵尸网络”：https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf
美国司法部，涉及Mirai的指控与认罪公告：https://www.justice.gov/archives/opa/pr/justice-department-announces-charges-and-guilty-pleas-three-computer-crime-cases-involving
美国国家安全电信咨询委员会，互联网与通信韧性报告：https://www.cisa.gov/sites/default/files/publications/NSTAC%20Report%20to%20the%20President%20on%20ICR%20FINAL%20%2810-12-17%29%20%281%29-%20508%20compliant_0.pdf
Akamai，2016年第三季度互联网安全状况执行摘要：https://www.akamai.com/site/en/documents/state-of-the-internet/q3-2016-state-of-the-internet-security-executive-summary.pdf
Akamai，2016年第三季度互联网安全状况报告公告：https://www.akamai.com/content/akamai/it/newsroom/press-release/akamai-releases-third-quarter-2016-state-of-the-internet-security-report1
ENISA，“物联网：当洗衣机和血压监测仪成为网络攻击目标”：https://www.enisa.europa.eu/news/enisa-news/the-internet-of-things-when-your-washing-machine-and-blood-pressure-monitor-become-a-target-for-cyberattacks
NTIA，美国商务部与国土安全部僵尸网络报告公告：https://www.ntia.gov/press-release/2018/us-departments-commerce-homeland-security-release-report-president-promoting-action-against-botnets
美国商务部与国土安全部，僵尸网络报告：https://www.ntia.gov/sites/default/files/publications/eo_13800_botnet_report_for_public_comment_0.pdf
NIST，“缓解基于物联网的DDoS”：https://csrc.nist.gov/pubs/pd/2017/12/14/mitigating-iotbased-ddos/final
NIST，“具有韧性的跨域流量交换：BGP安全与DDoS缓解”：https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation
NIST特别出版物800-189：https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
IETF，RFC 2827 / BCP 38，网络入口过滤：https://datatracker.ietf.org/doc/rfc2827/
IETF，RFC 3704 / BCP 84，多宿主网络入口过滤：https://datatracker.ietf.org/doc/rfc3704/
IETF，RFC 4732，互联网拒绝服务问题：https://datatracker.ietf.org/doc/rfc4732/
IETF，RFC 4948，互联网安全挑战：https://datatracker.ietf.org/doc/rfc4948/
IETF，RFC 7039，源地址验证改进：https://datatracker.ietf.org/doc/html/rfc7039
MANRS，网络指南：反欺骗：https://docs.manrs.org/docs/network-guide/anti-spoofing/