2015 年 GitHub“Great Cannon”DDoS：路径代码注入如何成为网络问责的试金石

摘要

GitHub 表示，针对其网站的分布式拒绝服务攻击约于 2015 年 3 月 26 日 02:00 UTC 开始，并称其为当时公司历史上规模最大的 DDoS 事件；攻击中的新手法会让不知情用户的浏览器向特定 GitHub 页面持续发出请求。[1]
GreatFire 记录了更早开始的受攻击阶段，并声称与百度统计资源有关的内容在传输途中被替换为恶意 JavaScript。GreatFire 将事件归因于中国当局；百度则否认其产品遭到入侵。两者都属于应当明确注明来源的当事方陈述，而不是已经裁定的事实。[7][8]
Citizen Lab、国际计算机科学研究所、加州大学伯克利分校、普林斯顿大学及合作研究者通过测量和旁路特征分析，描述了一个能够选择性拦截明文 HTTP 请求、注入替代响应并借用境外浏览器发起请求的系统，并将其命名为“Great Cannon”。[2][3][4][5]
研究者根据可观察的网络位置、代码相似性和系统行为，提出了“很可能由中国政府运营”的判断；这不是司法裁决，也不能证明某名个人下达了指令或掌握完整命令链。
这一机制不是伪造源地址的反射放大，也不同于预先攻陷设备组成的传统僵尸网络。浏览器执行被注入的代码后，会从自身真实地址建立正常形式的应用层连接。[6]
BCP 38、可行路径反向转发及其他源地址验证措施仍是重要的 DDoS 防线，但它们主要约束源地址伪造，无法单独阻断由真实浏览器地址发出的请求。[12][13][14]
经过正确认证的加密传输能够显著提高路径响应替换的难度，但 HTTPS 不能消除所有阻断、流量分析、端点失陷、路由操纵或 DDoS 风险。[15][16]
GitHub、路径运营者、第三方资源发布者、浏览器厂商、传输网络和缓解服务商承担不同的控制责任。问责应依据各方能够观察、改变和证明什么，而不能把全部责任压给攻击目标或终端用户。
Heng.lu 的“运行代码优先”原则为此提供了现实层判断：域名、路由、注册记录、托管合同和状态页描述的是预期关系；真正需要核验的，是不同路径上实际送达的内容、浏览器实际执行的代码以及服务实际呈现的连续性。

这场事件首先是网络交付完整性事件

2015 年 3 月的 GitHub 攻击经常被概括为一次超大规模 DDoS。但仅仅用“流量很大”描述它，会遗漏最具问责意义的部分。公开研究所重建的攻击链，并不是攻击者直接控制大量终端，然后命令这些终端向 GitHub 发起连接；也不是利用开放服务，把伪造了 GitHub 地址的请求放大后反射回平台。它利用的是普通网页、第三方明文资源、共享传输路径和浏览器执行能力之间的信任缝隙。

一个用户可能只是打开了与 GitHub 无关的网页。网页加载某项通过明文 HTTP 提供的第三方资源。请求经过特定跨境路径时，一个处于路径上的系统识别出符合条件的请求，并向浏览器送入替代响应。浏览器把响应当作原资源接受并执行，其中的 JavaScript 随后驱动浏览器反复访问 GreatFire 内容或 GitHub 托管的指定页面。

在这条链上，浏览器发出的连接可以是真实的，源地址可以是真实的，HTTP 请求也可以具有正常应用流量的外观。缺失的是用户意图，以及浏览器对所执行代码来源的可靠确认。真正被利用的不是用户主动参加攻击的意愿，而是网络能够在缺少认证保护的资源交付过程中改变内容。

因此，事件的核心问题不是抽象地追问“谁应为网络攻击负责”，而是更具体地追问：谁控制了资源发布，谁控制了内容经过的路径，谁有能力改变响应，谁能验证浏览器收到的字节，谁能限制脚本造成的网络行为，谁能在目标端吸收或过滤请求，又是谁保存了足以支持这些判断的证据。

把对等互联、传输路径、认证交付、浏览器执行边界和 GitHub 边缘缓解从事件中拿掉，问责论点便无法成立。它不是一篇可以随意替换对象的泛安全事故故事，而是一场由网络控制面和真实交付面之间的落差直接塑造的基础设施事件。

公开记录能够确认什么

GitHub 的第一方说明是划定事件边界的稳妥起点。公司表示，攻击约于 2015 年 3 月 26 日星期四 02:00 UTC 开始，并称其为当时 GitHub 历史上规模最大的 DDoS 攻击。GitHub 还表示，攻击混合了常见向量和更复杂的新手法，其中包括利用无辜用户的浏览器向网站大量发送请求。根据公司当时掌握的报告，GitHub 判断攻击目的在于迫使平台删除某一类内容。[1]

这份说明可以支持几个有限但重要的结论：GitHub 确实观察到一次重大可用性事件；浏览器借用是攻击的重要特征；受压目标与平台托管的特定内容有关；GitHub 将这种压力理解为试图改变其内容托管决定。

它不能单独回答另外一些问题。公开说明没有给出可据以重建全程的完整流量规模，没有确认参与浏览器的总数，没有列明每一项缓解调整，没有披露完整的客户影响、经济损失或精确恢复时刻，也没有证明攻击基础设施由谁具体启动。GitHub 对攻击意图的理解具有直接参考价值，却不能取代独立的技术归因。

GreatFire 提供了另一条受害方时间线。该组织表示，其服务自 3 月 17 日起承受大量请求，并在后续说明中称，恶意 JavaScript 替换了与百度统计资源有关的正常内容，把浏览器导向 GreatFire 材料及两个托管在 GitHub 上的页面。GreatFire 将活动归因于中国当局。[7][8]

这里必须同时保留百度的否认。百度否认其产品遭到入侵，而“源站被攻陷”“资源发布者知情参与”“第三方资源被滥用”与“网络路径上发生响应替换”是四种不同的事实命题。路径注入之所以值得单独研究，正是因为一个合法资源发布者可能并未从自己的服务器发送恶意内容，用户却仍可能在途中收到带有其资源身份外观的替代代码。没有证据就把这种结果表述成百度主动发送恶意脚本，会抹去攻击机制中最关键的控制位置，也会越过百度公开否认所形成的事实边界。

Citizen Lab 与合作研究者的技术工作为事件提供了最强的公开重建。他们把所观察到的系统与“防火长城”区分开来，同时指出二者在代码与网络位置上存在相似性。研究显示，该系统能够选择性处理未加密请求，注入替代内容，使中国境外的浏览器向目标持续发出请求；研究者还利用侧信道和多种测量结果缩小了系统可能部署的位置。[2][3][4][5]

这些结果支持研究者对运营者作出“很可能”的判断，但不能被改写成已经由法院确认的国家责任，更不能被延伸为某位具体官员、工程师或指挥者的个人命令链。技术位置推断、代码相似性、目标选择与政治背景可以共同提高归因置信度，却仍然不同于取得内部授权文件、完整访问日志或可公开核验的指令记录。

最可靠的表达应当同时保留观察和不确定性：公开测量支持存在一个具有选择性明文响应注入能力的网络系统；研究者将其命名为 Great Cannon，并判断其很可能具有政府运营背景；GreatFire 提出了更直接的中国当局归因；百度否认其产品被攻陷；公开证据没有裁定某名个人的具体指挥责任。

浏览器为什么会成为攻击流量来源

理解浏览器借用，需要把“浏览器遭到持久入侵”与“浏览器暂时执行了被替换的网页代码”区分开来。

传统僵尸网络通常意味着设备已经被恶意软件控制，攻击者能够在一段时间内向设备下达任务。Great Cannon 的公开重建并不要求每一台参与设备都预先安装恶意程序，也不要求攻击者取得设备的长期管理权限。用户浏览器只要在一次普通资源请求中接受了被注入的 JavaScript，就可能在脚本生命周期内向目标发出请求。

这也不是典型的源地址伪造反射。反射攻击通常由攻击者伪造受害者地址，向能够返回更大响应的第三方服务发送请求，使这些服务把流量反射给受害者。Great Cannon 机制中的浏览器则会直接建立连接，网络看到的客户端地址与实际发起连接的设备相符。流量的恶意目的来自上游注入的执行指令，而不是网络层地址字段被伪造。

由此出现了三个容易混淆的身份。

第一个身份是网页中写明的资源。URL、域名解析和页面引用说明浏览器打算从哪里取得内容，但它们并不能在明文传输中证明实际抵达的字节没有被修改。

第二个身份是浏览器实际接受的响应。若传输没有经过正确认证，路径上的系统可能争先送达替代内容。浏览器看到的表面资源名称没有变化，真正执行的代码却可能已经不同。

第三个身份是随后访问 GitHub 的浏览器。它的源地址可以准确表示连接从哪里建立，却不能说明用户是否知情，也不能说明触发请求的指令来自哪里。

若把第三个身份直接等同于攻击者，缓解系统可能惩罚不知情用户。若把第一个身份直接等同于恶意代码来源，则可能错误指控资源服务器。若把一个看起来合理的路由或域名记录当作内容完整性的证明，又会把可达性与真实性混为一谈。

这就是为什么该事件必须在网络基础设施层面讨论。攻击者利用的不是单一软件漏洞，而是从资源标识、路径交付、浏览器信任到目标端处理之间的一整段控制链。

运行代码优先：记录不是现实的替代品

Heng.lu 的运行代码优先原则，在这里不是一句抽象口号，而是一种严格的取证方法。

DNS 记录说明某个域名应解析到哪里。IP 与 ASN 注册信息说明号码资源由谁管理或联系。路由观测说明外部网络在某一时刻看到了怎样的可达路径。证书链说明客户端试图认证哪个身份。托管合同说明谁承诺提供服务。GitHub 的状态说明则记录平台对自身运行情况的公开描述。

这些记录都有价值，但没有一项能够独自证明某个浏览器实际收到了哪些内容。2015 年事件的关键就在于：管理记录可能保持正常，域名也可能仍然解析到预期位置，而浏览器执行的代码却在途中发生了变化。

“运行代码优先”并不是否定注册体系、路由记录或合同，而是要求这些账本与现实互证。一个域名登记得再准确，也不能替代响应内容的哈希；一个 ASN 归属再清晰，也不能单独证明注入发生在哪台设备；一条外部可见的 BGP 路径，也无法穷尽运营商内部的接口、隧道和策略系统；一份服务状态公告，更不能代替边缘错误率和实际可达性测量。

现实层要求把预期身份与真实结果放到同一条证据链上：浏览器请求了什么，解析得到什么，路径如何变化，传输是否认证，多个地点收到了哪些字节，哪个响应先到，浏览器执行了什么，随后建立了哪些连接，GitHub 的边缘系统又观察到什么。

这也是“注册机构是账本保管者，而不是主权裁判者”在网络事件中的具体含义。注册与路由资料可以帮助定位责任边界，却不能凭行政记录直接宣布技术事实。号码资源的唯一性、转移记录、安全元数据和持续运行都必须准确，但最终仍要接受运行网络的检验。

在 Great Cannon 案例里，现实层比立场表达更重要。分析无需替任何政府、平台、资源发布者或反审查组织背书。它只需要坚持：凡是声称自己没有控制某项行为、采取了某项缓解、交付了某份内容或维持了某种连续性的参与方，都应让陈述尽可能接受可重复的技术验证。

归因必须与响应分开

平台在遭受 DDoS 时，不能等到政治与法律归因完全确定以后才采取行动。GitHub 必须根据实时可见的流量特征保护服务：哪些路径被频繁请求，连接行为如何变化，哪些资源最消耗后端能力，边缘容量是否逼近限制，过滤后误伤了多少正常访问，缓解服务商接管后是否改善了可用性。

这些判断不依赖于先确定攻击由谁发起。即使运营者归属仍存在争议，目标平台也可以根据可观察行为进行分类、限速、缓存、流量清洗和容量调度。

反过来，某项缓解措施有效，也不能证明关于运营者的归因。过滤某类请求后服务恢复，只能说明该请求特征与服务压力有关；它不能自动证明注入系统的位置、所属机构或命令来源。

可靠的归因分析需要组合多类证据：基础设施位置、代码特征、网络时序、目标选择、部署方式、历史行为与排除其他解释的能力。每一类证据都有局限。代码可能被复制，网络位置可能被借用，目标选择可能用于误导，路由观测可能看不到内部路径，事件时间也可能受到时钟误差影响。

Citizen Lab 等研究者的重要贡献，正是没有只给出政治标签，而是展示机制、测量位置、系统差异和推断过程。[2][3][4][5] 但越是有说服力的研究，越不应被二次表述夸大。将“研究结果支持很可能由某方运营”改写成“已经证明某方下令”，不是更有力，而是更不准确。

为什么源地址验证挡不住这类请求

源地址验证是互联网 DDoS 防御的重要基础。RFC 2827 所对应的 BCP 38 倡导在网络边界过滤不应从该接口后方出现的源地址；后续文档讨论了多宿主和非对称路径环境下的部署难点，以及增强型可行路径反向转发等更具适应性的方式。[12][13][14]

这些措施主要改变的是“攻击者能否谎报自己从哪里发包”。它们可以显著压缩伪造源地址的空间，降低许多反射与放大攻击的可行性，也能让源地址在取证时更具参考价值。

但 Great Cannon 重建中的浏览器连接并不依赖这种谎报。浏览器确实从自己的网络发出请求，访问 GitHub 的连接在拓扑上完全可能成立。网络边界设备看到真实客户端地址时，即使严格执行源地址验证，也可能判定流量合法通过。

这不是对 BCP 38 的否定。大型攻击往往混合多种流量，减少伪造流量可以为缓解系统保留容量，也可以降低其他攻击面的噪声。问题在于不能把不同控制层的目标混在一起。

源地址验证约束地址真实性；认证加密约束传输内容被悄悄替换；浏览器策略约束收到的代码能做什么；GitHub 边缘系统约束请求消耗多少服务资源；上游清洗和流量工程约束平台在高压下能否保持可达。它们彼此补充，却没有任何一项可以独自覆盖整条攻击链。

RFC 4732 对拒绝服务风险、资源耗尽和协议设计的讨论，以及 NIST 将源地址验证、路由安全与 DDoS 缓解纳入更广泛韧性框架的做法，适合用来说明这种分层关系。[11][17] 它们不能被当作对 2015 年具体实现细节的事后证明。

认证加密改变了什么，又没有改变什么

明文 HTTP 无法为浏览器提供端到端的内容完整性保证。浏览器知道自己请求了某个资源，却没有密码学证据证明收到的响应完整来自预期服务，也没有证据证明响应在途中未被替换。

经过正确认证的 TLS 连接改变了这一条件。它使浏览器可以验证对端身份，并保护传输内容免受窃听、篡改和伪造。若验证正常，一个仅仅位于路径上的系统不能像处理明文响应那样随意改写内容，同时仍让浏览器把改写结果视为有效的原始资源。RFC 7258 将大规模监控及传输破坏视为协议设计应对的攻击；TLS 1.3 则清晰表达了认证加密信道的安全目标。[15][16]

因此，正确使用认证加密会显著提高直接响应注入的成本。它也能产生更明确的失败信号：路径上的干预更可能表现为证书错误、握手失败、连接中断或显式阻断，而不是悄无声息地把替代代码伪装成正常资源。

不过，不能从这里推导出“只要 HTTPS 就解决一切”。攻击者仍可能阻断连接、发送重置、操纵路由、压迫上游链路、攻击端点、利用合法但恶意的第三方脚本，或者选择完全不同的 DDoS 方法。认证加密也不能自动修复错误的证书验证、被攻陷的源站、脆弱的密钥管理或不安全的浏览器扩展。

负责任的结论应当限定为：认证加密直接加强了资源交付的身份与完整性，使简单路径替换更困难；它不是针对所有审查、端点攻击和拒绝服务手法的万能屏障。

对于运营者，真正的问题不是是否在政策文件中写了“采用 HTTPS”，而是事件发生时哪些可执行资源实际受到保护，是否仍存在明文依赖，浏览器是否允许混合内容，证书验证失败如何呈现，以及不同网络上的用户是否得到一致结果。

多观测点为何不可替代

路径注入系统可以选择性工作。它可能只识别特定主机名、资源路径、查询参数、源网络、目标地址或时间窗口；也可能只在某些路由上可见，在另一些路径上保持沉默。单一地点看到异常内容，并不足以判断问题位于源站、传输路径、本地设备还是递归解析环境。

多观测点测量的价值，是把“某处看到异常”推进为“异常随哪些路径和条件变化”。研究人员可以从不同网络和地区请求同一资源，比较响应内容、哈希、头部、时序、证书状态和解析结果。在合法且必要的范围内，还可以保存能够说明响应竞争与连接行为的底层记录。

若某一网络收到替代代码，而另一网络收到预期内容，可能的控制位置便得到缩小。若异常响应总是更早抵达，而稍后的正常响应来自预期源站，则时间关系可以支持竞争式注入解释。若源站日志和可验证内容中没有出现替代代码，源站主动发送的可能性会下降，但仍不能仅凭日志缺失排除所有源站问题。

多点证据应把观察与推断分开。观察包括时间戳、请求条件、内容哈希、证书结果、解析记录、响应顺序、网络路径和浏览器行为；推断则包括注入可能发生在哪一段、系统与已知基础设施有何联系、哪一运营者最可能具有相应控制能力。

时间完整性尤其重要。资源请求、替代代码执行与后续 GitHub 访问之间存在因果顺序。若各系统时钟误差不明、时区换算不一致或采集延迟未记录，再漂亮的事件图也可能制造虚假的先后关系。

隐私边界同样不能忽略。浏览器和网络记录可能包含用户访问行为。问责所需的证据应遵循最小化原则：只保存证明机制、时间和影响所必需的信息，控制访问权限，记录脱敏与转换过程，并用哈希维护证据完整性。隐私不是放弃技术证据的理由，技术调查也不是无限收集用户活动的许可。

GitHub 控制了什么

GitHub 是可见的受害平台，也是目标侧网络与应用基础设施的运营者。它不能直接阻止远端路径上的系统替换第三方响应，却能决定自己的服务如何承受随后到来的请求。

平台的控制面包括流量分类、边缘容量、连接管理、缓存策略、限速、过滤、负载均衡、外部缓解协调、目标页面保护和状态沟通。GitHub 较早发布的 DDoS 防御文章提到过网络栈调优、负载均衡器限制、过滤设备及外部缓解伙伴等分层措施。[9] 这份历史材料只能说明 GitHub 公开讨论过哪些设计，不能证明所有措施在 2015 年 3 月以相同配置运行，也不能证明每项措施在该事件中有效。

浏览器借用给目标平台制造了特别困难的分类问题。请求从真实客户端地址发出，可能使用正常协议行为。若仅凭来源地址快速封禁，平台可能误伤共享网络、代理出口或不知情用户；若每次都返回计算成本较高的内容，又可能放大后端压力；若为降低攻击而删除被针对内容，则可能让流量压力变成影响托管决定的工具。

因此，GitHub 的问责不应被简化成“为什么没有买更多容量”。容量只能改变部分可用性结果，不能修复远端路径上的内容完整性失效。更有意义的问题是：

平台如何区分浏览器借用流量与普通访问？哪些目标路径承受了异常负载？边缘、缓存、应用与数据库分别出现了什么压力？何时调整过滤或限速？外部缓解服务何时介入？每一项措施如何改变错误率、延迟、资源消耗与正常用户访问？哪些控制在事件后撤销，哪些成为长期配置？

公开资料没有给出这些问题的完整答案。缺失的细节应当继续被标注为未知，而不能用想象补成一段英雄式或失职式叙事。

路径运营者承担的是可检查控制责任

据公开重建，注入机会来自网络路径上的技术位置。能观察特定明文请求并尝试替换响应，意味着某个系统对传输过程拥有特殊权力。拥有这种能力的运营者，应当承担与能力相匹配的证据责任。

这类责任至少包括：哪些政策授权了流量检查或改写功能，哪些系统实现这些功能，哪些角色可以修改配置，部署变更如何批准，运行日志记录了什么，如何防止越权使用，以及出现争议时能否提供独立可验证的材料。

这不意味着凡是转发过流量的运营商都要为注入负责。互联网路径会跨越多个管理域，路由也可能在事件期间变化。一些运营者既没有查看应用内容的能力，也无法控制上游系统。责任应依据实际控制、可见性与证据，而不能依据地理邻近或政治猜测分配。

BGP 数据可以说明哪些自治系统宣布或传播了可达性，也可以为外部观察到的路径提供背景，却通常不能单独证明应用内容在哪个设备上遭到替换。运营商内部链路、隧道、流量工程和策略设备可能不出现在公共控制面中。地理定位和地址注册也只能说明分配与管理关系，不能直接证明某台设备在某一时刻执行了注入。

在 Heng.lu 的现实层框架下，注册信息是必要账本，却不是判决书。ASN、IP 地址和联系记录应保持唯一、准确、可追踪并包含安全元数据；但从“这个地址登记给谁”跳到“这个机构一定实施了某项行为”，中间仍缺少运行证据。

商业合同和拓扑保密可能限制公开披露，但不能成为内部无记录的理由。运营者即使不公开完整网络结构，也可以保留接口标识、路由快照、部署版本、变更批准、访问记录和不可篡改的事件摘要，在需要时接受受控核验。

第三方资源发布者不是自动责任人

公开分析指向了一条依赖第三方资源的路径。只要网页调用能够执行代码的外部资源，资源发布者、嵌入该资源的网站以及浏览器都会进入责任图谱。

资源发布者可以控制资源是否通过认证加密提供、是否强制安全传输、更新方式如何管理、缓存策略是否清晰，以及收到内容不一致报告时如何调查。嵌入资源的网站则能决定是否把明文依赖引入页面，是否对可执行依赖建立清单和完整性约束。

但这些控制责任不能被偷换成未经证实的共谋指控。百度否认其产品遭到入侵。[8] 如果替代内容是在路径上插入的，那么源站可能从未保存、发送或认可那段代码。仅凭浏览器请求了一个带有百度资源身份的地址，无法证明百度服务器实际交付了用户收到的字节。

调查需要比较源站记录、不同地点收到的响应、传输是否认证、内容哈希、缓存行为和时间特征。只有这些证据组合起来，才能区分源站入侵、路径替换、本地恶意软件与正常第三方脚本行为。

子资源完整性和内容安全策略在某些场景中可以增加保护，但它们也有部署边界。浏览器必须先取得可信的完整性值，页面必须正确执行策略，动态资源的更新方式也必须兼容。把某项控制列在清单上，并不等于运行时已经有效。

更基本的要求是建立可执行依赖清册：资源的协议、主机名、所有者、预期行为、更新方式、失败模式和替代方案都应明确。一个能在浏览器中运行代码的外部依赖，风险等级显然高于普通静态图片。

浏览器的责任边界

浏览器位于“收到内容”与“发出下一批网络请求”之间。它决定是否执行脚本，如何处理混合内容，如何验证证书，如何应用同源与跨域规则，以及如何限制后台活动。

浏览器无法仅凭“重复请求”判断恶意意图。现代网页本来就可能产生大量异步访问、遥测和资源加载。限制过严会破坏正常应用，限制过松又可能让页面无限消耗带宽并把用户变成流量来源。

有价值的改进方向包括：默认使用认证传输，更严格地处理明文可执行资源，对异常后台请求提供隔离或资源预算，向用户和开发者展示可疑跨域行为，并提供能够保存必要技术证据、同时减少隐私暴露的诊断能力。

浏览器的责任也不是无限的。它不能阻止路径直接丢弃连接，不能保证所有通过认证的源站都诚实，也不能替 GitHub 吸收攻击流量。但它可以降低一段临时注入代码悄无声息地借用用户连接的能力。

事件分析还应记录不同浏览器版本的行为差异。若某些版本执行了替代脚本而另一些没有，这种差异本身就是攻击面证据。后续版本改变了安全策略，也不能反向假定 2015 年事件发生时已经具备相同保护。

缓解不能建立在错误等同上

目标端看到的是大量请求，但“请求具有真实地址”不等于“用户有攻击意图”。这是 GitHub 和缓解服务商必须面对的伦理与工程双重问题。

过于激进的封禁可能影响共享出口后的大量普通用户；交互挑战可能带来可访问性和隐私代价；严格限速可能破坏合法自动化；把流量迁移到其他链路可能把压力转移给新的网络；直接撤下被攻击内容则可能奖励以可用性成本强迫平台改变决定的策略。

可信的缓解记录不应只写“攻击已缓解”，而应说明采取了什么动作、针对哪种可观察特征、预期改变什么、实际效果如何、误报和附带影响有多大、何时回滚。它还应区分网络容量、连接处理、应用成本和内容政策四个层面，避免用一项指标概括全部效果。

外部缓解服务商同样掌握关键证据。它们可能看到清洗前后的流量差异，负责分类请求、调整路由宣布或提供清洗能力。合同应明确客户对事件数据、路由变更记录、时间同步信息、留存期限和事后分析材料的访问权。把缓解外包，不等于把问责外包。

桌面推演可以验证联系人和决策权限，却不能证明真实流量下过滤器、缓存、路由和应用会按预期协同。受控演练更应测量识别时间、可用容量、误伤率、应用饱和、切换效果与回滚条件。

按实际控制划分责任

参与方	可实际控制的边界	应保存或提供的证据	不应被夸大的责任
路径与传输运营者	接口、路由策略、流量检查或改写系统、变更权限	路由快照、接口记录、配置版本、授权和访问日志	不能仅凭流量经过某网络便认定该网络实施注入
第三方资源发布者与嵌入网站	资源协议、认证传输、依赖清单、完整性与缓存策略	源站记录、资源哈希、传输配置、异常响应调查	路径替换不能自动等同于源站失陷或知情参与
浏览器与平台厂商	证书验证、混合内容、脚本执行与请求资源限制	版本行为、策略结果、异常执行与网络活动记录	浏览器不能阻止所有网络阻断或替目标承担容量
GitHub 与缓解伙伴	边缘容量、分类、过滤、限速、缓存、流量工程和状态沟通	请求特征、服务健康、缓解动作、误报与影响时间线	GitHub 无法直接控制远端第三方明文响应的路径
用户	终端设置和有限的访问选择	在自愿、必要条件下提供局部诊断信息	不知情用户不应因浏览器被临时借用而被视为自愿攻击者

这张责任图的意义在于避免“最显眼的公司承担全部责任”。GitHub 是可见受害者，百度是被点名的资源关联方，用户的地址出现在请求中，但真正的控制可能分布在路径、资源、浏览器和目标边缘多个层次。

问责不是平均分摊，也不是按品牌知名度分摊。它应当跟随可操作的权力：谁能改变配置，谁能中止行为，谁能保存记录，谁能验证交付，谁能恢复连续性。

一份最低限度的可核验证据体系

面对类似事件，运营者需要一套能把观察、行动和结论连接起来的证据体系。这套体系不要求把所有敏感信息公开，却必须让具备权限的独立核验者能够判断结论是否来自真实运行状态。

一、事件身份与时间完整性

为事件建立稳定标识，统一记录 UTC 时间、采集时间、时钟来源、已知偏差和传输延迟。区分首次异常、确认事件、启动缓解、服务稳定和结束记录。所有导出材料都应计算完整性摘要，并记录后续转换。

时间不能只是展示字段。资源请求、替代响应、脚本执行、浏览器访问目标和平台压力之间的因果关系，都依赖可信的先后顺序。

二、资源与传输身份

记录请求的协议、主机名、解析结果、预期源站、认证状态、响应头、内容摘要和浏览器处理结果。在合法条件下同时保存异常响应与正常响应，不能因为 URL 看起来正确就假定内容正确。

三、多路径环境

记录观测网络、解析环境、可见路由背景、响应时序和区域差异。公共 BGP 数据与运营者内部路由快照都可以参与重建，但必须明确：控制面路径只能缩小范围，不能独自证明应用内容在哪里遭到替换。

四、浏览器执行行为

记录脚本做了什么、访问了哪些目标、请求如何重复、浏览器版本及相关安全策略、是否需要用户操作，并区分临时执行与持续控制。除非有额外证据，不应把用户或设备标记为恶意参与者。

五、目标端运行事实

保存目标路径、请求特征、边缘与应用健康、过滤动作、缓解服务交接、错误率、延迟和用户影响。每项操作都应连接到可测量结果，而不是只留下“采取措施”的叙述。

六、运营者控制记录

对于具备检查或改变流量能力的系统，保存政策授权、配置变更、部署标识、访问权限和完整性日志。对于不在可疑控制点上的运营者，也应提供足以说明实际边界的证据，而不是只给出无法核验的概括性否认。

七、归因置信度

将直接观察、技术推断、外部陈述和未知事项分栏。说明哪些证据支持“很可能”，哪些替代解释仍然存在，什么新信息会改变当前判断。后续资料应以版本化方式更新，不应悄悄改写当时记录。

八、披露、隐私与留存

明确哪些结论可以公开、哪些材料只能受限访问、个人数据如何脱敏、底层证据保留多久。脱敏不应破坏技术链，技术留存也不应无限扩大到与事件无关的用户行为。

这样的证据体系把“信任我们”转换成“检查我们能够证明什么”。它适用于平台、传输运营者、资源发布者、浏览器厂商、缓解服务商和公共机构。

经济激励为何会留下责任缺口

网络安全控制往往具有成本与损失分离的特征。能够部署保护的一方，未必承担未部署时造成的主要损失。

第三方资源发布者保留一个旧的明文入口，可能降低兼容与运维成本；但路径替换风险由访问者和攻击目标承担。传输运营者保存更细的事件记录需要成本，却未必直接增加收入。GitHub 必须为大量由外部浏览器生成的请求购买容量和缓解服务，但它不控制那些浏览器收到代码的远端路径。用户消耗带宽并可能遭到封禁，却没有选择参与。

合同可以缩小部分缺口。托管和缓解协议可以要求事件数据访问、路由变更记录、时间同步、留存期限、测试支持和披露协作。外部资源采购可以要求认证交付、依赖清单和失败替代方案。浏览器政策可以让不安全依赖更难被忽略。

不过，合同仍是预期记录。供应商在合同里承诺了日志，不等于事故发生时日志完整；服务声称支持加密，不等于所有实际资源都经过认证；缓解商承诺容量，也不等于切换过程没有误伤。运行证据始终要回到现实层。

事件报告制度也可能扭曲机制描述。为了统计方便，把所有来源分散的请求统一写成“僵尸网络攻击”，会掩盖浏览器临时借用与传统终端失陷的差别。分类可以简化，但不能覆盖真正的控制点。

公共监管同样不应要求运营团队在响应阶段给出不可能达到的归因确定性。更可执行的要求是：什么服务受影响，哪项控制失效或被绕过，保存了什么证据，通知了哪些参与方，用户数据是否受到影响，恢复如何验证，以及哪些事实仍然未知。

内容压力与运营连续性

GitHub 表示，它根据当时报告判断攻击意在迫使平台删除某类内容。[1] 这让服务连续性与托管决定发生联系，但仍不能把攻击的网络原因归咎于 GitHub 选择托管内容。

如果平台一遭遇针对特定页面的流量压力就立即删除内容，攻击者便可能把容量成本转化为事实上的内容控制权。反过来，这也不意味着任何托管决定都不应接受质疑。技术问责只要求区分：内容争议属于政策问题，路径注入与流量攻击属于运行问题，二者不能通过“平台本来可以删掉内容”被混成同一责任。

运营连续性的真正标准，是平台能否在保护整体服务的同时维持目标资源的完整性，能否避免对普通用户造成不成比例的误伤，并能否用记录说明每项缓解决定的依据和效果。

这里也不存在“一项控制解决全部问题”的答案。更多边缘容量可以延缓饱和，却不能修复远端明文注入；更严格的浏览器限制可以减少请求，却无法保证网络不直接阻断连接；认证加密可以保护内容完整性，却不能消除流量洪峰；源地址验证可以减少伪造攻击，却无法拒绝真实浏览器连接；RPKI 可以提高路由起源验证能力，却不能直接证明应用响应未遭路径替换。

网络韧性来自这些控制之间的组合、证据连接和明确边界，而不是寻找一个可以替代全部责任的技术名词。

后续再现不能改写 2015 年事件

后续技术文章曾报告 Great Cannon 或相似工具再次出现。[10][18] 这些材料说明，路径级内容干预与浏览器借用并非只值得作为一次历史异常保存，也支持持续建设加密交付、多点探测和跨运营者证据交换。

但后续观察必须与 2015 年 3 月的 GreatFire—GitHub 事件分开。相同名称、相似代码或相近行为，并不能自动证明后续事件使用了完全相同的基础设施、目标清单、运营团队或命令来源。

事件记录应保持独立身份：发生日期、受影响对象、观测地点、代码行为、网络位置和公开陈述分别保存。后续证据可以提高某些技术假设的可信度，也可以显示某类能力仍在使用，却不能把多个年份的活动合并成一条未经证明的连续指挥链。

安全叙事常在多年后变得过度整齐：复杂观察被一个著名名称取代，置信度被省略，技术差异被当作无关细节。网络问责需要反其道而行之——保留事件边界、版本化更新结论，并明确说明新证据究竟改变了什么、没有改变什么。

如何讨论反事实而不制造确定性

事故分析需要问“如果当时采用另一项控制，结果是否会不同”，但反事实必须说明改变的是哪一项技术属性，而不能假装知道未发生的历史。

如果相关第三方资源通过正确认证的加密连接交付，直接路径替换会更加困难，浏览器也更可能显式拒绝无效响应。但这不能证明攻击者会放弃目标；其仍可能阻断连接、寻找端点弱点或改用其他 DDoS 向量。

如果浏览器对异常的后台重复请求设有更严格资源预算，目标流量或许会减少，但限制必须兼顾正常应用，也不能排除脚本通过变化时序、目标和请求形式绕开简单阈值。

如果 GitHub 拥有更多边缘与清洗容量，平台或许能够承受更多流量，但公开资料没有给出可据以计算所需额外容量的数据。更多容量也不能修正远端内容被替换的问题。

如果网络运营者与研究机构具有更丰富的多点监测，注入位置或许能更快缩小，归因证据也可能更强。监测本身不能阻止改写，而且必须受到隐私和比例原则约束。

如果全球更广泛部署源地址验证，许多伪造反射攻击会更难实施；但本事件中由浏览器真实地址建立的连接仍可能通过验证。

有价值的反事实应包含三个元素：它改变哪项属性，需要什么证据判断效果，还有哪些攻击路径依然开放。其用途是改进控制设计，而不是进行轻率的事后归罪。

面向路径注入的网络问责标准

2015 年 GitHub 事件可以提炼出一套适用于网络运营者、平台和资源发布者的最低标准。

第一，所有能够在浏览器中执行代码的资源，都应优先采用认证交付。组织需要知道页面加载了哪些第三方依赖，并消除不必要的明文执行路径。

第二，不能只从源站观察服务。源站日志最多证明服务器记录了什么，不能证明每个用户在沿途实际收到什么。多网络、多地区和多解析环境的外部观测，应成为关键资源完整性监测的一部分。

第三，按照控制层分配责任。资源发布、域名解析、路由与传输、浏览器执行、目标边缘、缓解服务和状态沟通分别由谁掌握，必须清楚列出。

第四，所有关键操作都要与结果相连。过滤、限速、路由变更、容量迁移和内容保护决定，都应有所有者、时间、理由、预期效果、观察结果和回滚条件。

第五，公开语言必须保留归因置信度。技术位置和代码相似性可以支持强判断，却不能替代个人命令链证据或司法裁定。

第六，缓解设计应保护不知情用户。浏览器生成的请求并不等于用户主动攻击，封禁策略需要考虑共享地址、代理网络和误伤。

第七，连续性不应以交出内容控制权为默认代价。平台必须预先设计在内容定向压力下维护服务和合法托管材料的方式。

第八，把行政记录连接到运行证据。DNS、证书、ASN、路由记录和合同之所以重要，是因为它们定义了预期身份和责任；只有当这些记录能与真实交付、服务状态和控制行为相互核验时，它们才构成有效问责。

第九，后续事件要独立归档。技术能力可能再现，但每次事件的运营者、基础设施和目标都需要单独证明。

第十，任何“万能控制”主张都应被拒绝。HTTPS、BCP 38、RPKI、浏览器策略、清洗容量或某一家缓解服务商，都不能单独覆盖从路径改写到目标可用性的全部风险。

管理者与网络运营者应追问的问题

页面中哪些资源能够执行代码，它们在事件发生时是否全部经过认证传输？
有什么证据能够区分源站入侵、路径响应替换、本地恶意软件与资源发布者的正常行为？
哪些网络和路径收到异常内容，哪些收到预期内容？
时间戳、内容摘要、证书结果、解析结果和路由观测是否能放进同一条可信时间线？
哪一方实际拥有改变疑似注入系统的权限，哪些可检查记录能够证明这种控制？
GitHub 如何识别浏览器借用流量，同时避免假定所有来源用户都有攻击意图？
过滤、限速、缓存、扩容和外部缓解分别改变了什么运行指标？
缓解措施对普通用户、共享网络和其他服务产生了哪些附带影响？
哪些事实支持研究者的运营者判断，哪些替代解释仍未排除？
GreatFire 的归因、GitHub 的内容压力判断、百度的否认与独立测量是否保持清晰分离？
哪些控制针对源地址伪造，哪些针对内容完整性，哪些针对目标可用性？
不依靠对任何机构的先验信任，具备条件的核验者能否从证据重建同样的事件边界？

结论

2015 年 GitHub DDoS 之所以成为网络问责的试金石，不是因为它可以被列入“重大网络攻击”清单，而是因为它把网络身份与内容真实性之间的裂缝变成了攻击能力。

浏览器请求的是一个看似普通的第三方资源，路径上的系统却据称能够把另一段代码送入浏览器。浏览器随后用真实地址建立连接，GitHub 面对的于是既不是纯粹的伪造流量，也不是一支由预先感染设备组成的传统僵尸网络。攻击借用了互联网正常运行所依赖的资源引用、路径转发和浏览器执行机制。

公开记录支持一个审慎结论：GitHub 遭受了重大且具有内容压力特征的 DDoS；GreatFire 记录了更早阶段并将活动归因于中国当局；研究者测量并描述了一个具有选择性明文响应注入能力的系统，对其运营者作出了“很可能”的评估；百度否认其产品遭到入侵。完整流量规模、参与用户数量、经济损失、精确恢复时刻和个人命令链仍未由公开资料确定。

责任必须沿实际控制分配。路径运营者应为能够观察或改变内容的系统保留可检查记录；资源发布者和嵌入网站应管理可执行依赖与认证交付；浏览器应减少代码对用户连接的静默借用；GitHub 和缓解伙伴应把边缘行动与真实效果连接起来；研究者和公共机构则必须保持观察、推断与归因之间的边界。

事件留下的长期规则很明确：网络不能只凭地址、合同、注册记录和状态页接受判断。那些材料描述预期权力，真正的问责来自运行现实——用户实际收到什么，浏览器实际执行什么，路径实际如何变化，服务实际能否持续，以及每个拥有控制权的运营者能够证明什么。