新颖的 HTTP/2快速重置DDoS 攻击

许多 Google 服务和云客户已成为基于 HTTP/2 的新型 DDoS 攻击的目标，该攻击在 8 月份达到顶峰。这些攻击的规模明显大于之前报告的任何第 7 层攻击，最大的攻击每秒超过 3.98 亿个请求。

这些攻击基本上被 Google 的全球负载平衡基础设施阻止在我们网络的边缘，并且没有导致任何中断。虽然影响很小，但 Google 的 DDoS 响应团队审查了这些攻击，并添加了额外的保护措施以进一步缓解类似的攻击。除了 Google 的内部响应之外，我们还帮助领导了与行业合作伙伴协调一致的披露流程，以解决整个生态系统中新的 HTTP/2 向量问题。

下面，我们解释了过去几年中第 7 层攻击的主要方法、这些新攻击中发生的变化导致其规模如此之大，以及我们认为针对这种攻击类型有效的缓解策略。本文是从反向代理架构的角度编写的，其中 HTTP 请求由反向代理终止，该反向代理将请求转发到其他服务。相同的概念适用于集成到应用程序服务器中的 HTTP 服务器，但考虑因素略有不同，这可能会导致不同的缓解策略。

DDoS 的 HTTP/2 入门

自 2021 年底以来，我们在受Cloud Armor保护的 Google 第一方服务和 Google Cloud 项目中观察到的大多数第 7 层 DDoS 攻击都基于 HTTP/2，无论是从攻击数量还是峰值请求率来看。

HTTP/2 的主要设计目标是效率，不幸的是，使 HTTP/2 对合法客户端更高效的功能也可用于使 DDoS 攻击更高效。

流复用

HTTP/2 使用“流”，即用于在端点之间传输各种消息或“帧”的双向抽象。“流复用”是 HTTP/2 的核心功能，它可以提高每个 TCP 连接的利用率。流以一种可以由连接双方跟踪的方式进行多路复用，同时仅使用一个第 4 层连接。流复用使客户端能够拥有多个正在进行的请求，而无需管理多个单独的连接。

发起第 7 层 DoS 攻击时的主要限制之一是并发传输连接的数量。每个连接都会产生成本，包括用于套接字记录和缓冲区的操作系统内存、用于 TLS 握手的 CPU 时间，以及每个连接需要唯一的四元组、连接每一端的 IP 地址和端口对，从而限制了两个 IP 地址之间的并发连接数。

在 HTTP/1.1 中，每个请求都是串行处理的。服务器将读取请求、处理它、写入响应，然后才读取并处理下一个请求。实际上，这意味着可以通过单个连接发送的请求的速率是每次往返一个请求，其中往返包括网络延迟、代理处理时间和后端请求处理时间。虽然 HTTP/1.1 管道在某些客户端和服务器中可用于增加连接的吞吐量，但它在合法客户端中并不普遍。

使用 HTTP/2，客户端可以在单个 TCP 连接上打开多个并发流，每个流对应一个 HTTP 请求。理论上，并发打开流的最大数量是由服务器控制的，但实际上，客户端每个请求可以打开 100 个流，并且服务器并行处理这些请求。需要注意的是，服务器限制不能单方面调整。

例如，客户端可以打开 100 个流，并在单次往返中对每个流发送一个请求；代理将串行读取和处理每个流，但对后端服务器的请求可以再次并行化。然后，客户端可以在收到对先前流的响应时打开新流。这为单个连接提供了每次往返 100 个请求的有效吞吐量，并且具有与 HTTP/1.1 请求类似的往返计时常数。这通常会导致每个连接的利用率提高近 100 倍。

HTTP/2 快速重置攻击

HTTP/2 协议允许客户端向服务器指示应通过发送 RST_STREAM 帧来取消先前的流。该协议不要求客户端和服务器以任何方式协调取消，客户端可以单方面这样做。客户端还可以假设，当服务器收到 RST_STREAM 帧时，在处理来自该 TCP 连接的任何其他数据之前，取消将立即生效。

这种攻击称为快速重置，因为它依赖于端点在发送请求帧后立即发送 RST_STREAM 帧的能力，这使得另一个端点开始工作，然后快速重置请求。请求被取消，但 HTTP/2 连接保持打开状态。

基于此功能的 HTTP/2 快速重置攻击很简单：客户端像标准 HTTP/2 攻击一样一次打开大量流，而不是等待服务器或代理对每个请求流的响应，客户端立即取消每个请求。

立即重置流的能力允许每个连接有无限数量的正在运行的请求。通过显式取消请求，攻击者永远不会超过并发打开流的数量限制。进行中请求的数量不再取决于往返时间 (RTT)，而仅取决于可用网络带宽。

在典型的 HTTP/2 服务器实现中，服务器仍然需要为取消的请求执行大量工作，例如分配新的流数据结构、解析查询并进行标头解压缩以及将 URL 映射到资源。对于反向代理实现，可以在处理 RST_STREAM 帧之前将请求代理到后端服务器。另一方面，客户几乎不支付发送请求的费用。这在服务器和客户端之间造成了可利用的成本不对称。

攻击者获得的另一个优势是，在创建请求后立即显式取消请求意味着反向代理服务器不会发送对任何请求的响应。在写入响应之前取消请求会减少下行链路（攻击者的服务器/代理）带宽。

HTTP/2 快速重置攻击变种

在最初的 DDoS 攻击发生后的几周内，我们发现了一些快速重置攻击变体。这些变体通常不如初始版本有效，但仍可能比标准 HTTP/2 DDoS 攻击更有效。

第一个变体不会立即取消流，而是立即打开一批流，等待一段时间，然后取消这些流，然后立即打开另一大批新流。此攻击可能会绕过仅基于入站 RST_STREAM 帧速率的缓解措施（例如在关闭连接之前允许每秒最多 100 个 RST_STREAM）。

这些攻击由于没有最大化连接利用率而失去了取消攻击的主要优势，但仍然比标准 HTTP/2 DDoS 攻击具有一定的实施效率。但这种变体确实意味着任何基于速率限制流取消的缓解措施都应该设置相当严格的限制才能有效。

第二种变体完全取消了流，而是乐观地尝试打开比服务器宣传的更多的并发流。与标准 HTTP/2 DDoS 攻击相比，这种方法的好处是客户端可以始终保持请求管道满载，并消除客户端代理 RTT 作为瓶颈。如果请求是针对 HTTP/2 服务器立即响应的资源，它还可以消除代理服务器 RTT 作为瓶颈。

RFC 9113（当前的 HTTP/2 RFC）建议，尝试打开过多的流应该仅使超出限制的流无效，而不是使整个连接无效。我们认为大多数 HTTP/2 服务器不会处理这些流，这正是通过在响应先前的流后几乎立即接受和处理新的流来实现非取消攻击变体的原因。

多方面的缓解方法

我们并不认为简单地阻止单个请求就能有效缓解此类攻击，而是在检测到滥用行为时需要关闭整个 TCP 连接。HTTP/2 使用 GOAWAY 帧类型提供对关闭连接的内置支持。RFC 定义了一个优雅地关闭连接的过程，该过程涉及首先发送一个不限制打开新流的信息性 GOAWAY，然后在一个往返中发送另一个禁止打开其他流的往返。

然而，这种优雅的 GOAWAY 过程通常不是以对恶意客户端具有鲁棒性的方式实现的。这种形式的缓解措施使连接在很长一段时间内容易受到快速重置攻击，因此不应用于构建缓解措施，因为它不会阻止入站请求。相反，应该设置 GOAWAY 以立即限制流创建。

这就留下了确定哪些连接是滥用的问题。客户端取消请求本质上并不是滥用行为，该功能存在于 HTTP/2 协议中以帮助更好地管理请求处理。典型情况是，由于用户离开页面，浏览器不再需要它所请求的资源，或者应用程序使用具有客户端超时的长轮询方法。

针对这种攻击媒介的缓解措施可以采取多种形式，但主要集中在跟踪连接统计数据并使用各种信号和业务逻辑来确定每个连接的有用程度。例如，如果某个连接有超过 100 个请求，其中超过 50% 的给定请求被取消，则它可能是缓解响应的候选者。响应的幅度和类型取决于每个平台的风险，但响应的范围可以从前面讨论的强制 GOAWAY 帧到立即关闭 TCP 连接。

为了缓解此攻击的非取消变体，我们建议 HTTP/2 服务器应关闭超出并发流限制的连接。这可以是立即发生的，也可以是在少量重复犯罪之后发生的。

对其他协议的适用性

由于协议差异，我们认为这些攻击方法不会直接转换为 HTTP/3 (QUIC)，并且 Google 目前并未看到 HTTP/3 大规模用作 DDoS 攻击媒介。尽管如此，我们建议 HTTP/3 服务器实现主动实施机制来限制单个传输连接完成的工作量，类似于上面讨论的 HTTP/2 缓解措施。

产业协调

在我们的 DDoS 响应团队调查的早期以及与行业合作伙伴的协调中，很明显，这种新的攻击类型可能会对为其服务提供 HTTP/2 协议的任何实体产生广泛的影响。谷歌利用先前存在的协调漏洞披露小组，帮助领导了协调的漏洞披露流程，该小组过去已用于许多其他工作。

在披露过程中，该团队重点通知了 HTTP/2 的大规模实施者，包括基础设施公司和服务器软件提供商。这些先前通知的目标是开发和准备协调发布的缓解措施。过去，这种方法为服务提供商提供了广泛的保护，或者通过许多软件包和解决方案的软件更新来提供保护。

在协调披露过程中，我们保留了CVE-2023-44487来跟踪对各种 HTTP/2 实现的修复。

下一步

本文讨论的新颖攻击可能会对任何规模的服务产生重大影响。所有拥有 HTTP/2 服务的提供商都应该评估他们是否面临此问题。现在或不久的将来可能可以应用常见网络服务器和编程语言的软件补丁和更新。我们建议尽快应用这些修复程序。

对于我们的客户，我们建议修补软件并启用应用程序负载均衡器和Google Cloud Armor，这一直在保护 Google 和现有的 Google Cloud 应用程序负载均衡用户。

想阅读原文可通过点击阅读原文