BELNET 2021 年 DDoS 故障的问责测试：共享公共网络韧性

摘要

BELNET 的 2021 年年度报告称，该组织在 5 月 3 日和 4 日遭遇了一次大规模流量型分布式拒绝服务攻击。其实时状态记录记载了客户连接问题、连续攻击浪潮、替代流量路径、缓解规则、稳定化工作以及更长期防护规划。[1][2]
一份官方联邦议会记录显示，约 200 家连接机构（包括大学、公共机关和研究机构）在 5 月 4 日经历了不同程度的互联网接入中断。记录显示 BELNET 启动了危机程序，与比利时网络安全中心联系，并称当晚局势已受控。[7]
比利时公共广播公司 VRT 报道了政府网站、议会工作、远程接入和疫苗预约服务受到的实际影响。这些例子显示公共服务依赖关系，但并不证明每个连接机构都出现同样的故障或持续时间一致。[8]
BELNET 运营一个面向科研与公共服务的国家网络，具备 IP 与光纤基础设施、接入点、骨干连接和可选冗余通道。其使命声明称该网络是联邦数字服务的重要组成部分。[9][10][11]
公开来源未能确认具体攻击者、政治动机、精确流量体积、协议构成、僵尸网络规模、饱和链路、被利用漏洞或完整的按客户逐一时间线。问责分析必须保留这些未知因素。
后续 BELNET 记录提供了有价值的变更证据。该运营方在 2021 年后将点对点寻址控制与韧性建设关联起来，并在 2021 年 5 月实施外部云清洗中心以应对威胁上行链路的攻击流量。[3][6]
BELNET 的当前“高级 DDoS 安全”页面描述了路由器过滤、内部清洗中心和外部云层。这些是后续或当前控制措施的证据，而不是事件发生前完整架构的证明。[4][5]
IETF 关于拒绝服务、入口过滤和 DDoS Open Threat Signaling 的文档提供了减缓能力、上游协同和遥测的术语框架。它们并不证明 BELNET 在 2021 年使用了某一具体协议或配置。[12][13][14][15][16][17][18][19]
问责应按实际控制权界定。BELNET 控制骨干运行、缓解、重路由、危机升级和全网证据。连接机构控制本地故障转移、二次接入与应用连续性。上游与到户提供商控制已签约路径和容量。公共当局控制连续性要求与监督。
一次可信的结案应说明合法流量何时受限、何时生效了缓解与替代路径、发生了哪些附带过滤、客户恢复如何衡量，以及后续控制是否针对实际故障类型进行过测试。

这次故障把共享连接转变为共享公共服务风险

分布式拒绝服务攻击很容易被描述得不准确。简化版本是：攻击者发送了过量流量，网络不可用，工程师过滤流量，服务恢复。该序列在技术上可能成立，但会掩盖最关键的问责问题。

BELNET 不只是托管一个公共网站。它提供的是政府部门、大学、研究机构和其他公共机构使用的连接服务。BELNET 的使命陈述将该网络描述为国家科研网络及联邦数字服务的重要组成部分。其服务页面描述了一个混合 IP 与光纤网络，连接比利时国内及国际互联网与科研网络。[9][11]

这个角色改变了 2021 年 5 月事件的意义。

一次削弱共享网络容量的攻击可能影响到使用不相关应用、管理员与任务目标的机构。议会委员会不需要与大学共享应用数据库，两者也可能同时受影响。疫苗预约服务不需要与税务网站在同一台服务器上运行。共享的可达性足够了。

联邦议会记录显示，大约 200 家连接机构出现不同程度的互联网接入中断。[7] VRT 描述了政府网站变慢或不可用、议会工作取消或中断、远程接入问题，以及一段时间内疫苗预约服务无法正常运行。[8]

这些影响应被谨慎报告。证据并未显示所有机构在同一时段全部失去连通。并未显示所有比利时政府服务均失败，也未建立.be 域名本身不可达。各机构拥有不同的接入设计、应用依赖、地面网络和备用方案。

更窄且更重要的共性事实是：一次网络事件传播到了多个领域，因为这些领域依赖于同一共享连接控制面。

这样就能测量集中程度。

有多少关键服务依赖于单一 BELNET 接入路径？有多少机构通过不同接入点、光纤路由或供应商拥有第二条路径？哪些服务可在不更改 DNS、身份认证、防火墙或应用状态的情况下故障转移？哪些机构知道共享供应商事件会同时中断公共访问与员工远程接入？哪些连续性预案在国家科研与公共服务网络不可用时曾被测试？

答案决定的是：共享基础设施是否提高了韧性，还是放大了共模风险。

集中式网络保护可以有价值。国家科研网络可汇集专业能力、容量、监测和采购。它可比每个机构单独行动更有效地与上游供应商协同。它可提供冗余光纤和 IP 基础设施，并让组织获得本身难以独立运行的专门缓解能力。

同样的集中也提高了未充分配备缓解、升级缓慢或客户故障转移不完整的风险。若数百机构依赖共享上行链路和缓解系统，运营方的技术决策就会成为公共服务连续性的一部分。

这就是故障暴露的问责边界。攻击者控制恶意流量。BELNET 及其合作方控制共享基础设施如何检测、吸收、重定向和记录该流量。连接机构控制自身服务连续性依赖同一路径的程度。公共当局控制与社会后果相关服务的韧性要求。

因此责任不能被还原为攻击者身份。它必须追随实际控制权的分布。

公众记录能确认什么，不能确认什么

最可靠的分析要先把三类记录分开：BELNET 的运营状态更新、其后续年度报告，以及外部机构或新闻机构的公开报道。

BELNET 的年度报告将事件定于 5 月 3 日和 4 日，并称其为重大流量型 DDoS 攻击。报告称事件根本改变了组织对网络安全的应对方式。[2]

实时状态记录从 5 月 4 日开始。其一开始就写明部分客户因 DDoS 攻击出现连通问题。后续更新描述了连续攻击浪潮、持续的缓解工作、流量备用路径、已实施的缓解规则、稳定化、残留事件以及更长期防护和升级路径的工作。[1]

联邦议会记录提供一份官方政府说明。首相描述 5 月 4 日发生大规模 DDoS 攻击，称网络无法处理当前需求，并称受影响机构程度不同。记录还显示 BELNET 的危机程序启动及与比利时网络安全中心联络。内容称当晚局势已受控。[7]

VRT 提供了独立的同期影响报告。其指出受影响功能包括政府网站、议会议程、远程接入或学生接入以及疫苗预约。[8]

这些来源共同支持几项结论。

第一，事件是对共享网络基础设施的拒绝服务事件，不是单一应用遭到入侵。

第二，影响存在差异。官方说明明确写有不同程度的中断。

第三，响应是迭代式的。BELNET 并未对一类固定不变洪峰应用单一静态规则。其状态更新描述了浪潮、备用路径、缓解规则、稳定化和残留问题。

第四，运行终点不是单一时间戳。所谓“当晚局势受控”并不证明每位客户、每个站点、每个应用和每条远程接入路径在当时都完全恢复。

公众记录仍留下重要空白。

它未给出经过验证的峰值速率（比特每秒或包每秒）、协议分布、源伪造是否关键、是否有精确入口路径、饱和链路、受限路由器或缓解能力，也未完整公开检测、升级、重路由、过滤和客户恢复的时间线。

它同样未建立具体攻击者或动机。政府说明在总体层面提到 botnet 驱动流量，但冻结记录未识别 botnet 控制方、设备规模或归因链。进行政治推测都不负责任。

这些空白不是为了填补，而是为了区分发现与证据需求。

例如，入口过滤是重要网络控制，但源集合未证明伪造源地址导致了 BELNET 洪峰。主张“若普遍采用一种过滤实践就能阻止该事件”是不正确的。

同样，外部清洗中心能吸收大量洪峰，但公共来源未披露事件前可用的确切容量，也未公开调用该能力的合同条件。后续 BELNET 材料称 2021 年 5 月引入外部云服务。[6] 这是变化证据，不是对事件前完整架构的重建。

严谨报道应将未知可见化，因为这些定义了剩余问责问题：

是什么流量特征形成了约束？
哪些共享链路或设备成了瓶颈？
哪些缓解是自动的，哪些需要人工批准？
每次升级用了多长时间？
哪些客户获得了单独保护？
哪些机构具备独立路径？
哪些合法流量被过滤或延迟？
BELNET 与客户如何判定服务恢复？

这些问题比对攻击者的单一猜测更有价值。

BELNET 是网络控制面，而非泛化的云依赖

本文目标是网络基础设施。没有这一区分，事件会被扁平化为一则泛化的网络安全或政府 IT 故事。

BELNET 的公共服务说明称其网络结合 IP 与光纤连接，向机构提供商业互联网和科研网络接入。[9] 其技术 FAQ 还描述了 BELNET 接入点的直接连接、第三方到户选项、骨干接口，以及关键场景下通过另一接入点和独立光纤路径获得第二连接。[10]

这些细节显示了多个不同的控制域。

BELNET 控制骨干和在接入点交付的服务。它可观察进入网络的流量、配置路由器、建立缓解规则、重定向流量并协调全网响应。

当机构不在 BELNET 接入点直接驻留时，最后一公里供应商控制机构与 BELNET 之间的链路。该链路或容量限制不自动完全属于 BELNET 的单方控制。

连接机构控制其本地网络、边界防火墙、DNS 依赖、应用暴露范围以及二次接入使用情况。BELNET 可提供冗余接入，但机构仍需采购、配置并测试。

上游转运和缓解提供商控制 BELNET 管理域外的容量与过滤。其成效依赖预先约定的权限、路由和运行联系人。

这些边界在 DDoS 响应中很关键，因为需要过滤的环节常不在应用所有者的直接控制范围。

若攻击流量在到达本地防火墙前即使接入链路饱和，机构侧过滤往往太迟。若洪峰威胁供应商上行链路，供应商可能需要将流量重定向到清洗服务或请求上游网络协助。若缓解需要路由变更或客户前缀控制，参与方必须在通信拥塞前就有权力和已测试流程。

BELNET 的当前“高级 DDoS 安全”页面正描述了这类分层网络响应。其提到基于路由器的过滤、内部清洗中心以及外部云清洗中心。技术 FAQ 说明流量通常保持在清洗路径之外，并在检测到攻击时重定向。它也说明在网络可能饱和时将流量手动转到外部服务。[4][5]

当前设计不能在缺乏证据时向前外推。它能澄清运营方必须治理的实际决策：

什么异常触发路由器过滤？
目标重定向到何处？
哪些合法流量仍可达？
内部容量何时不足？
谁授权外部重定向？
使用了哪些路由与社区属性？
动作如何回滚？
何种证据显示缓解有效？

这些都是网络运营问题。它们涉及流量路径、控制权、共享容量与可观察服务。该事件属于网络基础设施问责，因为公共伤害取决于这些控制的实际运行。

容量型攻击是竞争性拥塞问题，解决方案常不完整

RFC 4732 指出一个严峻的架构事实：只要攻击者能组织足够流量或足够状态，就能让几乎任何互联网服务无法访问。[12] 这并不意味着韧性不可能。它意味着任何预防主张都必须具体。

容量型攻击旨在消耗受限资源。该资源可能是网络链路、路由转发能力、防火墙状态表、负载均衡服务、DNS 服务或应用本身。正确的缓解取决于约束发生在哪一处，以及可区分的流量类型。

如果瓶颈在上行链路，即使加本地防火墙规则也未必恢复服务，因为攻击报文已耗尽链路。若瓶颈在有状态处理，那么迁移到无状态路由策略可能有帮助。若流量来自多个真实源且与正常需求类似，简单封禁源可能无效或有害。

公共 BELNET 记录将事件归为“流量型”并称攻击浪潮威胁连通性。[1][2] 但并未披露最先失效的具体资源。

这层不确定性改变了控制评估方式。

容量是一项控制。运营方可配置冗余和多样化上游路径。容量本身无法保证对所有可能洪峰生存，但可抬高阈值并争取缓解窗口。

检测是另一项控制。流量遥测、路由器计数器和服务探测可识别异常流量、受影响目标与拥塞状态。检测必须在网络受压下仍持续运行。

过滤是另一项控制。访问控制列表、流定义、黑洞路由、速率限制和清洗系统都可移除恶意流量，但匹配范围或范围设定错误会误伤合法流量。

重定向是另一项控制。流量可经内部或外部清洗容量转发。这需要路由授权、前缀接受、回程路径设计和足够的清洁容量。

客户分段是另一项控制。若对单一目标的洪峰会威胁共享上行链路，提供方必须判断何时如何保护其他网络，即使该目标未购买单独缓解。

通信是另一项控制。运营团队在生产连通性受损时仍需与客户、上游和政府沟通。BELNET 的状态页面与危机程序是这一控制平面的组成部分。[1][7]

这些控制并非孤立。RFC 4948 讨论了过滤、访问列表、黑洞路由、容量和外部效益驱动的部署激励。[14] 因而问责问题不在于运营方是否拥有所谓“DDoS 防护”产品，而在于技术、合同与人员控制是否形成可测试序列。

有用的韧性说明应识别：

被监测以防枯竭的资源；
触发动作的阈值；
缓解授权；
内部与外部可用容量；
重定向所用路径；
合法流量处理方式；
主缓解路径失效时的兜底；
复核保留的证据。

缺少该序列时，“我们有 DDoS 防护”只是一种产品描述，不是韧性结果。

当应用不同，集中仍可放大损害

BELNET 影响的机构并非单一主体。它们包括治理、技术与公共职责各异的实体。[7][11]

共享连接使这些差异连接在一起。

政府部门可能在某环境中托管公共网站，同时依赖 BELNET 承担员工接入。大学可能将网络用于科研流量、身份联合、远程教学和外部服务。医院或研究中心可能有专用数据流。议会机构可能依赖视频、文档、身份认证和公共通信。

应用不必共享代码，网络故障就能让其失败同步。

这就是为什么依赖登记应包括外部网络控制，而不只是软件供应商。

传统服务地图可能列出应用、数据库、身份提供方和云主机，但仍遗漏用户和员工到这些组件的路径。若主备应用共享同一接入电路、DNS 解析器、供应商前缀或上游路由，表面冗余在供应商事件下可能消失。

BELNET 的技术 FAQ 说明关键接入需求的机构可通过另一接入点获得第二连接，并在可用时走独立光纤路径。[10] 这是一项重要选项，但并不证明所有受影响机构都具备这种多样性，也不证明每条备用路径不依赖同一 DDoS 控制平面。

真正的路径多样性不只是两条电缆。

路径应尽量避免共同沟槽、接入设备与电力源。它们应在不同接入点终止。路由策略应允许主路径受损时转移。防火墙和身份服务应认可备用路径。公共 DNS 与远程接入配置不应依赖在故障期间无法执行的手工改动。

这还涉及采购问题。

冗余连接有成本。公共机构可能在常规可用性目标下进行优化，而假设国家网络运营商吸收极端流量。运营方可提供基础连接和可选个体缓解，同时保留共享骨干稳定性的责任。客户可能不知道其服务是被主动防护还是仅在事件中获得被动支持。

BELNET 的 2022 监测文章明确了这种区别。它称部分机构购买了带监测的缓解服务，其它机构可以获得反应式帮助。它还称当针对某客户的攻击威胁网络上行链路时可启动外部云清洗。[6]

这形成至少三层问责：

目标客户的个体保护；
共享供应商基础设施保护；
每个机构关键服务的连续性安排。

这些层次不应混淆。供应商可通过黑洞保护骨干，但该目标仍可能不可达。客户可购买清洗服务，但其他依赖方仍可能失败。机构可保留第二回路，但两条回路可能共享同一上游缓解决策。

公共利益问题在于关键服务是否清楚自己购买的结果。

响应序列揭示了授权何时关键

BELNET 的实时状态更新很有价值，因为它把响应展示为序列，而非单次声明。[1]

早期消息指出连接问题与主动缓解。后续更新称攻击仍按浪潮持续。工程师稳定了局面并构建备用路径，实施缓解规则并监测网络。形势变得更稳，但残留事件仍在。随后又描述长期防护机制和升级路径。

每一步都需要不同授权。

监测需要访问网络遥测和客户报送。

备用路径需要对路由和可用接入有控制。

缓解规则需要有权更改转发或过滤行为，并判断附带影响。

外部支持需要既定联系人和交换路由或缓解信息的许可。

客户修复需要与 BELNET 未完全控制的客户流量和应用协调。

长期改进需要事件团队以外的采购、架构与治理决策。

联邦记录补充了与比利时网络安全中心的危机协调。[7] 这一步很关键，因为网络运营方不能独立判断每个客户中断的公共后果。政府协同可优先关键依赖并支持信息沟通。

问责应检验这些授权是否在攻击前就清晰。

谁可宣布网络级事件？谁可重定向流量？谁可调用外部容量？单一工程师可否做高影响路由改动，还是要双重批准？速度如何与变更风险平衡？应急联系人是否具备离线通道？当汇总指标改善后，客户是否知道残留故障从何处上报？

这些问题并不代表响应迟缓或不当。公开证据不足以支撑这种结论。它们定义了发生此规模事件后应可复核的运营控制。

“受控”这一表述同样需要可量化定义。

它可能表示攻击流量不再增长。可能表示共享上行链路不再饱和。可能表示多数客户已恢复连通。可能表示关键机构可达。可能表示没有新的攻击浪潮产生实质影响。

这些是不同条件。

可问责的状态流程应将公众表述与内部证据对应，并将网络稳定与客户完全恢复区分开。BELNET 的状态记录在报告稳定后仍持续讨论残留问题和长期工作。[1] 这一序列支持更精确模型：

遏制；
网络稳定化；
客户恢复；
残留事件关闭；
修复；
验证。

将这些混成一个时间点，会隐藏运营真相。

后续控制是学习证据，而非先前设计的直接证明

事件后的证据通常不如事件记录完整。组织会公布投入，但未说明对应失败类别。BELNET 后续材料更具体，但仍需严格时间对齐。

点对点寻址 FAQ 说明 BELNET 在重大 2021 DDoS 攻击后希望加强网络韧性。其解释点对点地址应仅用于互连与路由，在必要时要求客户配置合规。[3]

这是一项明确控制边界。地址纪律可简化保护，因为基础设施地址不作为普通客户地址处理。它可减少路由与过滤歧义，使互联功能与应接收普通流量的目的地区分更清楚。

该 FAQ 并未证明地址误用导致 2021 事件。正确的说法是 BELNET 将该变更与事件后防护改进关联。

BELNET 2022 监测文章称，2021 年 5 月建立了外部云清洗中心。其描述当针对一个客户的强攻击威胁网络其余部分饱和时采用该层处理。[6]

这也是具体说明。它指出受保护对象是网络上行链路，并区分个体客户保护与网络级保护。

BELNET 当前“高级 DDoS 安全”页面描述三层结构：路由器自动过滤、内部清洗中心和外部云清洗中心。[4][5]

技术 FAQ 说明检测器分析进入网络的流量，可将其重定向到内部清洗。为在发送外部流量时保持控制，外部重定向由人工确认。其还描述了内部清洗设备冗余。[5]

这些细节显示韧性涉及权衡。

自动化可加快响应，但在误检或错误路由时可放大问题。

人工审批可保留人工控制，但当链路接近饱和时会延迟缓解。

链路外清洗避免持续增加固定跳数，可能降低正常业务风险，但依赖在攻击期内稳定的检测与重定向。

外部清洗增加了容量和地域分布，但引入了新的供应商、路由关系和数据路径。

内部冗余可防止设备失效，但不能自动防住超过能力阈值的外部上行洪峰。

问责检验是这些权衡是否针对真实故障类别测试过。

采购凭证不是测试。产品仪表盘不是测试。低负载演示也不是测试。

证据应覆盖现实场景下的检测、重路由授权、路由传播、回程清洁路径、合法流量保留、客户专项策略、饱和期遥测、缓解供应商不可用时的兜底，以及攻击结束后的安全退出。

BELNET 的公共页面描述了机制。完整问责记录应将这些机制与实测演练和事故结果连接。

跨域缓解必须在链路满载前预先安排

DDoS Open Threat Signaling 文档提供了有价值的对照框架，因为它们处理一个结构性问题：受攻击网络可能需要另一管理域协助。

RFC 8612 规定了 DDoS 缓解信令要求。[15] RFC 8811 描述了客户端如何请求缓解提供方帮助并获取状态的架构。[16] RFC 8782 定义了面向恶劣条件的信令通道。[17] RFC 8903 提供了使用场景。[18] RFC 9244 处理遥测，包括共享连接链路。[19]

这些标准不应被理解为 BELNET 已部署 DOTS，它们的价值是分析框架。

它们说明运营方不应在事件中临时建立服务关系。

各方需要身份、认证、授权、作用范围和联系人路径。缓解供应方需要知道请求方可控制的前缀或服务。路由变更要被接受。遥测需要共同含义。信号路径本身也要在降级条件下可用。

BELNET 的状态记录提到升级路径，其后续材料提及外部云清洗。[1][6] 这些标准让概念转为审查问题。

外部关系在攻击前是否已生效？客户前缀和路由策略是否预授权？BELNET 能否在不等待各客户确认的情况下调用网络级保护？客户可否自行请求保护？什么条件触发外部升级？信号与管理路径是否依赖受损生产网络？缓解方返回了哪些状态？哪些遥测证明干净流量回流？

共享链路遥测尤为关键。

若多个客户共享同一物理或逻辑容量约束，攻击某一目标可影响其余客户。运营方需要识别受攻击目标、共享资源、可达的合法流量，以及客户级缓解何时转为网络级保护。

该决策有后果。

对目标进行黑洞处理可恢复共享网络但完全拒绝该目标。清洗可保留服务但增加时延或误检。限速可把压力在合法用户之间分摊。重定向可改变路径长度与容量。等待则让洪峰进一步影响无关客户。

不存在可解决全部情形的统一阈值，阈值是基于网络设计、客户关键性、容量和合同授权的治理决策。

问责意味着运营方能在事后用证据解释该决策。

入口过滤重要，但并非事件的普适解释

RFC 2827 描述了源地址过滤用于减少使用伪造源地址的攻击。[13] RFC 4948 讨论了该控制的价值与部署难点。[14]

这些标准适用于 DDoS 问责，因为攻击流量可利用许多网络中的弱源地址校验。允许伪造报文的网络会把治理成本外部化给受害者与缓解方。广泛部署可减少某类攻击。该机制在全球层面有效。

BELNET 的证据并未显示 2021 年 5 月洪峰中是否以伪源地址为核心。

这层边界应明确保留。

若攻击来自被攻陷设备且源地址真实，入口过滤可能无效；若为反射放大并伪造受害地址，源校验可降低源侧流量；若是多类组合攻击，则需要不同控制。

公共来源未在这些路径中作出选择。

正确的问责分析需区分控制政策与因果结论。

网络应实施适当源验证，因为它减少已知攻击类型并服务整个互联网。这是标准支持的一般责任。

BELNET 与合作方还应保留足够事件遥测，以判断洪峰是由伪造源、反射放大、真实 bot 流量还是应用请求驱动。这是事件级证据责任。

这一区别很重要，因为泛化建议会产生错误结论。

若运营方对直接 botnet 洪峰只提出入口过滤，可能未处理饱和资源问题；若对反射攻击只加容量，可能错过上游过滤和源验证；若部署激进过滤却未测量合法流量，会形成新的可用性问题。

控制选择应依据证据。

这也涉及经济问责。RFC 4948 指出某些过滤收益对其他网络更明显，导致部署延迟的激励问题。[14] 公共网络和监管机构可通过采购要求、对等预期、透明度与共享服务纠正该激励。

BELNET 作为公共网络运营方，这一问题更显著。它可集中供应机构难以单独购买的保护，也可要求客户和连接供应商保持地址与路由纪律。点对点寻址变化是运营方用服务规则改进共享控制面的例子。[3]

重点不在于某个 BC 预案能否“单独”阻止事故，而在于跨组织边界部署的控制必须由证据支持，并与故障类型匹配。

连接机构也有连续性职责

BELNET 控制共享网络。并不意味着所有连续性职责都在 BELNET。

连接机构控制了连通性下降后发生的应对。

它们可识别关键应用，维持备用接入，分离公共与行政路径，保留带外通信，测试远程办公兜底，并决定哪些服务需要独立提供方。

实际可选项不同。小型科研机构无法建设全国清洗网络。某部委不能重构 BELNET 骨干。大学不能单独调用 BELNET 路由上的外部缓解提供方。

责任应与现实边界一致。

不应因无法操作某控制而追责；机构应对其权限内选择承担责任。

对疫苗预约服务而言，可能包括第二公共访问路径、DNS 故障转移、缓存信息页、电话兜底和清晰的状态通道。

对议会而言，可能包括替代会议与文档通道，并确保关键议程在主网络失效时继续推进。

对大学而言，可能包括独立应急通信、关键系统本地访问，以及对远程学习或科研服务受限的明确上限。

对政府部门而言，可能包括显示依赖 BELNET 的功能地图：公众接入、员工接入、身份联动、跨机构交换与事件通信。

这些控制都需要与网络运营方协作。

第二回路仅在机构明确其是否共享同一接入点、光纤路径、上游或缓解依赖时才有价值。DNS 故障转移仅在权威 DNS 与管理入口在故障期可达时才有效。备用远程接入仅在身份与终端可达时才有效。

BELNET 的技术 FAQ 描述了第二接入点和独立光纤路径可选项。[10] 机构应能把它转为服务级风险决策。

公共采购可通过以下问题加以约束：

哪些物理与行政故障域是独立的？
防护是主动还是反应式？
预留多少容量？
谁可触发缓解？
共享网络和单个客户的恢复目标分别是什么？
会提供哪些遥测和事后证据？
应急变更如何授权并复核？

这些问题可防止将韧性降为无法反映相关攻击关联性的可用率数字。

公共状态沟通是恢复控制平面的一部分

在网络故障期间，通信并非独立于运营之外。它会影响客户决策、升级和证据形成。

BELNET 的状态页面在攻击演化中持续发布更新。[1] 消息识别了连接问题、持续浪潮、缓解动作、备用路径、稳定化和残留问题。

这种节奏对机构决定是否触发本地连续性预案十分重要。

含糊的“调查中”可使客户等待，错过本地兜底窗口。过早“已恢复”可导致机构提前移除临时控制。过于技术化的详细信息也可能给非专业人员带来风险或混淆。

合格的公开记录应回答运营问题，同时不公开敏感配置：

问题是否在共享网络中？
受影响的服务类别是什么？
攻击流量是否仍在持续？
缓解是否已生效？
客户是否以不同速度恢复？
机构是否应保持本地兜底？
残留事件应向何处报告？
下一次更新何时发布？

状态记录也会成为证据。

它可与路由遥测、缓解日志、客户工单和危机决策对照。差异可揭示检测延迟、影响评估不完整或恢复缺口。

这也是为何要保留结构化时间戳。后续叙述可总结事件，但响应者和监督者需要原始顺序。

联邦议会记录展示了另一层沟通：公共监督。[7] 官员需要解释规模、机构影响、协同和预防。有效监督应请求控制与证明，而不要求披露可被滥用的细节。

问题应聚焦于：

受约束的共享资源是什么？
当时可用的缓解容量是多少？
响应中有哪些变化？
哪些机构缺乏独立路径？
后续控制对应解决了哪些观测到的故障？
修复是否有独立验证？

只问攻击者会使基础设施经验未被完整总结。

恢复主张应按服务可验证且可独立复测

网络运营方常报告主网稳定后再发布整体恢复，这并非必然误导。骨干可稳定，而本地会话、路由或应用仍可能受损。

问题在于阶段没有明确。

BELNET 的状态序列从持续浪潮和备用路径，转向缓解规则、稳定化、残留事件和长期工作。[1] 这支持多阶段恢复模型。

遏制

攻击增长受限，危险流量被过滤或重定向，运营方恢复共享资源控制。

网络稳定化

骨干和上行资源维持在安全范围。路由与缓解不再振荡，核心监测可靠。

客户连通恢复

连接机构可通过预期路径交换流量。异常被逐项识别，而非被平均值掩盖。

服务恢复

从机构外部验证公共网站、远程访问、身份、视频、科研和其他功能。

残留事件关闭

解决客户特定路由、过滤、状态或到户问题。

修复验证

针对原始故障类别进行重演或模拟，记录回滚和证据。

每阶段应有退出条件。

对遏制而言，条件可包括丢包下降、干净容量可用和路由器资源稳定。

对网络稳定化，条件可包括持续期利用率、路由收敛、缓解一致性和健康遥测。

对客户恢复，条件可包括不同接入点与客户类别的代表性探测。

对服务恢复，机构需要进行应用层校验。接口可达不等于认证、交易或远程办公恢复。

独立测试很重要，因为受损或过载的控制平面可能仍显示自检健康。

外部探测、客户测量和独立管理路径可对运营方内部视图提出挑战。它们不能替代运营遥测，却可降低因单一系统修复而产生的假阳性。

CISA 的后续 DDoS 指南强调规划、供应商协调与分层响应。[20] 该指南用于对照，不是 BELNET 2021 程序的直接证据。

一般原则是：恢复应从合法用户和共享基础设施角度验证，而非只从单一仪表盘判定。

可问责的公共网络应保留的证据包

事后报告不需要公布敏感路由配置，但应保留足够证据，让客户、监管机构和独立评审理解发生了什么。

证据包应以当前字节完整性开始。

遥测提取、配置快照、缓解规则、路由变更和报告应带有时间戳、归属和哈希。若有修订版本，应标出被替代版本及原因。

应包括依赖图。

图中应识别骨干链路、接入点、上游、缓解供应商、管理路径、状态通道和客户类别，展示共享容量，不暴露不必要的设备细节。

应包括事件时间线。

时间线应区分有害流量首次出现、检测、客户受影响、事件声明、危机升级、备用路径、过滤、内部清洗、外部清洗、稳定化、客户恢复和结案。

应包括资源证据。

哪些链路、转发资源或服务接近上限？正常基线流量是多少？观察到哪类攻击？哪些遥测在负载下仍可靠？

应包括行动证据。

哪些规则变更？谁批准？哪些路由移动？有哪些附带影响？变更如何回退或保留？

应包括客户证据。

有多少机构受到实质影响？哪些服务类别失败？哪些机构有独立接入？残留问题如何收集并关闭？

应包括沟通证据。

状态更新何时发布？每个时刻可见哪些信息？关键机构是否有离线联系人？

应包括修复证据。

哪些后续控制对应了观测故障？点对点地址变更如何验证？外部清洗何时可调用？当前分层保护能否同时保护目标与共享网络？

应包括不确定性。

未归因、缺少分组细节、客户数据不全与假设应当列明，而非静默消失。

这一证据包将问责从口号变为可复核流程。

也能保护运营方。证据可显示团队是否快速行动，是否遭遇超出合理设计假设的攻击，客户是否未提前购买，或上游行动是否限制了响应。问责不预设运营方错误，而按证据和控制归责。

监督应将修复与观测到的故障类型连接

联邦议会讨论聚焦预防、技术演进、投资与评估。[7] 这些问题适当，但若不与故障机制绑定，容易产生泛化回答。

“我们增加了网络安全投入”不足以构成结论。

监督记录应将每项支出连接到控制项：

增加内部清洗提高某一网络节点容量；
外部清洗保护在本地能力之外的上行链路；
路由器检测缩短识别目标所需时间；
点对点地址纪律简化过滤与路由；
独立管理路径保留响应授权；
第二接入点降低接入路径集中；
演练验证调用与恢复流程。

BELNET 的点对点 FAQ 与后续 DDoS 服务说明使上述映射可实现。[3][4][5][6]

监督也应追问服务覆盖问题。

若只有部分客户购买主动缓解，若未受保护客户遭攻击并威胁公共骨干时，是否有保障？BELNET 是否可在不逐客户确认下启动网络级保护？该操作下目标服务会有何影响？关键公共服务是否有更高基线要求？

这是技术与政策共同的问题。

公共网络可以选择社会化部分缓解成本，因为单一目标会对数百机构产生外溢；可对高风险客户提供增强保护；可要求作为服务条件的配置纪律；可在重大事故后发布标准化证据。

设计必须明确。

否则责任常常只有在故障时才浮出水面，届时运营方、客户与政府会发现对洪峰成本分摊有不同假设。

真正的问责测试是下一次浪潮前的准备

BELNET 的 2021 事件是动态的。状态页面记录了持续浪潮和不断变化的缓解。[1]

这是韧性演练中的有效模型。

测试不应只向单一受保护服务发送可预测流量并在仪表盘变绿后结束。

应在安全范围内变化目标、协议和负载；测试有保护客户与无保护客户，后者的流量可能威胁共享容量；测试内部与外部清洗；测试路由传播、回程路径、撤销机制；测试误检和高峰合法流量场景。

还要测试人员流程。

运营方是否可在夜间调用外部缓解？联系人是否持续更新？网络受损时可否完成认证？客户是否理解状态信息？政府协调人是否能识别关键服务？工程师能否在时间压力下在同行评审下修改过滤？

还要测试证据。

遥测和时间戳是否在压力下可恢复？能否追溯某条规则影响的流量？客户探测能否确认恢复？独立审阅者能否复现结论？

还要测试缓解系统自身失效。

若内部清洗不可用怎么办？若云服务提供方控制平面故障怎么办？若路由重定向延迟怎么办？若过滤误伤关键合法流量怎么办？若状态平台依赖受损路径怎么办？

这就是当前架构说明成为可问责控制的关键。[4][5]

三层结构价值不在于“有三层”，而在于每层是否有明确角色、边界、触发点和回退。若三层仍依赖同一探测器、同一管理身份或同一路由路径，表面多样性依然会有共模风险。

测试因此要问的不只是能否吸收流量，还要问组织在条件变化下是否仍保有控制与证据。

结论：共享网络意味着共享证明韧性的共同责任

BELNET 2021 事件并未让公共服务连续性变成网络问题，而是揭示其本来就是网络问题。

政府、教育、科研和其他机构依赖共享网络。一次大规模流量型攻击在这些机构间形成了连通性问题。BELNET 后续把地址纪律与外部云清洗关联到事件后，当前页面还描述了分层路由、内部清洗和外部清洗控制。[1][2][3][4][5][6][7]

公开来源并未支持具体攻击者、精确流量、完整向量分析，或“某个缺失控制导致了故障”这样的结论。

但它支持一套清晰的问责框架。

BELNET 对骨干运营、网络级缓解、重路由、危机升级和解释恢复所需证据具有实际控制。

连接机构对二次接入、应用连续性、关键依赖图和本地兜底具有实际控制。

上游、到户与缓解供应商控制受合同约束的路径、容量和跨域动作。

公共当局控制连续性要求、采购、协调与监督。

攻击者对恶意流量的责任并不消除这些职责。基础设施问责也不表示每次故障都构成过失。

正确测试是：每一方是否能证明其控制能力与可防可控或可放大风险的程度相匹配。

对共享公共网络而言，这种证明应覆盖容量、检测、备用路径、清洗、升级授权、合法流量保留、客户恢复和经过测试的修复。

服务恢复是一次运行成绩。能够说明网络为何更具韧性、哪些风险仍存以及结论如何被验证才是问责成果。

BELNET 2021 年 DDoS 故障使共享公共网络韧性成为问责测试

为何重要

摘要