HTTP/2 Rapid Reset：网络安全的新挑战与应对(图文)

惊！新型 DDoS 攻击打破记录

最近，网络安全领域被一种名为 “HTTP/2 Rapid Reset” 的 DDoS 攻击技术搅得不得安宁。自 8 月以来，它作为零日漏洞被恶意利用，成为了黑客手中的 “新型武器”，打破了以往的 DDoS 攻击记录，让整个互联网都为之震惊。
亚马逊网络服务（Amazon Web Services）、Cloudflare 和谷歌等互联网巨头纷纷站出来发声，他们成功抵御了规模空前的攻击请求。其中，亚马逊阻止了每秒 1.55 亿次的攻击，Cloudflare 则拦下了每秒 2.01 亿次的攻击，而谷歌更是创下纪录，成功应对了每秒高达 3.98 亿次的攻击请求。这些数字听起来就令人咋舌，要知道，以往的 DDoS 攻击规模与之相比，简直是小巫见大巫。
Cloudflare 的工程师对此深感震惊，他们抵御的攻击规模是 2013 年 2 月那次创纪录攻击的三倍，而且令人难以置信的是，这次攻击仅仅是由一个由 2 万台机器组成的相对较小的僵尸网络发动的。自 8 月底以来，Cloudflare 已经检测并阻止了一千多次超过 1000 万次每秒的 “HTTP/2 Rapid Reset”DDoS 攻击，其中 184 次打破了之前每秒 7100 万次的记录。随着更多威胁行为者利用更大规模的僵尸网络和这种新的攻击方法，HTTP/2 Rapid Reset 攻击很可能会继续刷新记录。毕竟，现在的僵尸网络规模越来越大，有的甚至由几十万乃至数百万台机器组成。想象一下，整个网络通常每秒只处理 10 亿到 30 亿次请求，而利用这种攻击方法，将整个网络的请求集中在少数几个目标上，并非天方夜谭。

认识 HTTP/2 协议

 

（一）HTTP/2 与 HTTP/1 的区别

HTTP 协议发展至今，已经历了多个版本的更迭，其中 HTTP/2 和 HTTP/1 有着显著的区别。HTTP/1.x 在传输数据时，请求和响应报文是面向文本的，这就导致首部中很多字段重复出现，增加了不必要的开销。而且，在 HTTP/1.x 中，每个请求都需要一个独立的 TCP 连接，在高并发场景下，频繁地建立和关闭 TCP 连接会消耗大量的时间和资源。即使采用了流水线方式，服务器发回响应时也必须按先后顺序排队，逐个发给客户，一旦遇到某个响应迟迟不能返回，那么排在后面的响应就必须一直等待，这就是所谓的 “队头阻塞” 问题，极大地影响了传输效率。
而 HTTP/2 则是一次革命性的升级。它添加了一个二进制分帧层，采用二进制格式传输数据，将数据分成小帧，通过编号组装，解析起来更高效。在 HTTP/2 中，同一个 TCP 连接可以同时处理多个请求和响应，实现了多路复用。就好比你点外卖，HTTP/1.x 是 “每点一道菜打一次电话”，而 HTTP/2 是 “一个电话点所有菜”，节省了时间还不堵线。这一特性使得 HTTP/2 能够在一个连接上并发处理多个请求，避免了队头阻塞，大大提高了传输效率。同时，HTTP/2 还使用 HPACK 算法对头部信息进行压缩，减少了数据传输量，进一步提升了传输性能。

（二）HTTP/2 的流和帧

在 HTTP/2 中，流（Stream）是一个非常重要的概念。流是存在于连接中的一个虚拟通道，可以承载双向数据，每个流都有一个唯一的整数 ID。简单来说，一次请求 / 响应中，拥有同一流标识符的所有帧就可以抽象成一个流。在流的层面数据是有序的，但在 TCP 层面数据是无序的。多个流可以复用同一条 TCP 连接，从而实现并发传输。
帧（Frame）是 HTTP/2 数据通信的最小单位。HTTP/2 总共定义了 10 种类型的帧，一般分为数据帧和控制帧两类。其中，SETTINGS 帧用于初始化连接时，客户端和服务器之间交换一些设置参数，比如最大并发流数量、初始窗口大小等；HEADERS 帧用于传输 HTTP 请求或响应的头部信息；DATA 帧则用于传输实际的数据内容。
而我们今天重点要讲的 RST_STREAM 帧，它的作用是取消一个流。当服务器或客户端想要终止某个流的传输时，就可以发送 RST_STREAM 帧。比如，当客户端发现某个请求已经不再需要，或者服务器在处理请求时遇到错误，无法继续提供服务，就可以通过 RST_STREAM 帧来快速结束这个流，释放相关资源，而不需要关闭整个 TCP 连接 。这就好比在一场接力比赛中，如果某个选手因为受伤等原因无法继续比赛，就可以中途退出，而不会影响整个比赛的进行。RST_STREAM 帧的存在，使得 HTTP/2 在处理异常情况时更加灵活高效，也为 “HTTP/2 Rapid Reset” 攻击提供了可乘之机。

HTTP/2 Rapid Reset 攻击揭秘

（一）攻击原理剖析

HTTP/2 Rapid Reset 攻击的核心原理，是恶意利用 HTTP/2 的重置机制，绕过服务端对单个 TCP 连接的并发流数量限制（max_concurrent_streams），迫使服务端处理超量的请求，从而达到增强攻击效果的目的 。
首先，HTTP/2 出于安全考虑，支持对单个 TCP 连接的并发流数量进行限制，具体的限制数值可以在建立连接时通过 SETTINGS 帧中的 SETTINGS_MAX_CONCURRENT_STREAMS 参数来设置。比如，服务器可以将这个值设置为 100，意味着在这个 TCP 连接上，最多只能同时存在 100 个处于 “OPEN” 或 “Half-closed” 状态的流。
但这里存在一个关键的漏洞点，该限制策略只统计 “OPEN” 或 “Half-closed” 状态下的流，而 “Closed” 状态的流并不计入并发数。而 HTTP/2 中的 RST_STREAM 帧，恰恰可以让对应的 stream 快速进入 “Closed” 状态。攻击者正是利用了这一点，通过大规模发送应用层请求并快速重置。
简单来说，攻击者就像一个不讲武德的 “插队者”。正常情况下，服务端设置了一个 “队伍” 的最大人数（并发流数量限制），但这个 “队伍” 只统计正在排队（“OPEN” 或 “Half-closed” 状态）的人，而那些已经 “离开队伍”（“Closed” 状态）的人不算在人数限制内。于是攻击者就不停地 “进队 - 离开 - 进队 - 离开”，导致服务端需要不断处理这些 “进进出出” 的请求，资源被大量消耗 。

（二）攻击过程演示

为了更直观地理解 HTTP/2 Rapid Reset 攻击的过程，我们可以通过一个简单的示例来演示。假设我们有一个 Web 服务器，它使用 HTTP/2 协议，并且设置了单个 TCP 连接的最大并发流数量为 100。

1. 建立 TCP 连接：攻击者通过僵尸网络中的大量机器，与目标服务器建立 TCP 连接。这些连接就像是一条条 “通道”，后续的请求和响应都将在这些 “通道” 中传输。

2. 发起请求：攻击者的客户端像在标准的 HTTP/2 攻击中一样，一次性打开大量的请求流，比如同时打开 1000 个请求流。每个请求流都携带一个 HTTP 请求，这些请求就像一批批的 “货物”，被发送到服务器。

3. 快速重置：然而，攻击者并不等待服务器对每个请求流作出响应，而是立即发送 RST_STREAM 帧，取消每个请求。这就好比刚刚把 “货物” 送出去，马上又要求 “撤回”。

在这个过程中，由于服务端只统计 “OPEN” 或 “Half-closed” 状态的流，而攻击者快速重置的流会立即变为 “Closed” 状态，不计入并发数。所以，尽管服务器设置了最大并发流数量为 100，但攻击者却能通过这种快速重置的方式，不断地发送新的请求流，让服务器忙于处理这些超量的请求。随着攻击的持续，服务器的资源（如 CPU、内存等）会被大量消耗，最终导致无法正常为合法用户提供服务，出现拒绝服务的情况 。就像一个繁忙的客服中心，原本只能同时接待 100 个客户咨询，但却不断收到大量瞬间撤回的咨询请求，工作人员疲于应对，真正有需求的客户反而无法得到服务 。

攻击的威力与影响

（一）攻击效果测试

为了深入了解 HTTP/2 Rapid Reset DDoS 攻击的威力，火山引擎 Anit-DDoS 团队基于 NGINX 搭建了 HTTP/2 Server 和 HTTP2 Proxy 场景进行测试。在测试过程中，团队采用控制变量法，严格控制各种条件，以确保测试结果的准确性和可靠性。
从测试结果来看，在同等量级请求速率的前提下，H2 Rapid Reset DDoS 攻击在 H2 Server 和 H2 Proxy 场景下，对服务端 CPU 使用率的影响均略小于一般的 H2 应用层 DDoS 攻击 。这是因为在快速 Reset 后，NGINX 马上终止了对攻击请求的处理，在一定程度上 “节省” 了服务端资源 。比如，当面对每秒 10000 个请求的攻击时，一般 H2 应用层 DDoS 攻击可能会使服务端 CPU 使用率飙升至 80%，而 H2 Rapid Reset DDoS 攻击下，CPU 使用率可能仅达到 70% 。这表明，虽然 H2 Rapid Reset DDoS 攻击能绕过服务端的并发流限制，但在等量的请求频率下，对服务端的压力相对较弱。

（二）对不同业务架构的影响

在实际网络环境中，业务架构多种多样，HTTP/2 Rapid Reset DDoS 攻击对不同架构的影响也各不相同。对于反向代理架构来说，这种攻击带来的压力不容小觑。
当攻击发生时，大量的 RST_STREAM 帧会阻塞反向代理集群中 TLS decryption -> 上层应用的通道。就像一条繁忙的高速公路，突然出现了大量的 “障碍物”，导致交通堵塞。在这种情况下，反向代理无法及时将请求转发到上层应用，从而瘫痪代理对外服务能力。正常用户访问时，由于阻塞问题，Proxy 会返回 “502 Bad Gateway” 错误，导致正常业务受损。
更值得注意的是，H2 Rapid Reset DDoS 攻击经过反向代理后，还会转化为其他类型的 DDoS 攻击。它会转化成对源站的 SYN + RST 的四层 DDoS 攻击。在特定场景下，甚至可转换成 TCP connection Flood 攻击。这就好比一个 “变形金刚”，攻击形式不断变化，增加了防御的难度 。如果源站的防护措施不够完善，就很容易受到这些转化后的攻击影响，导致服务中断、数据丢失等严重后果 。

应对策略与防护措施

 

（一）厂商的应对方法

面对来势汹汹的 HTTP/2 Rapid Reset 攻击，各大厂商纷纷采取了积极有效的应对措施。Cloudflare 使用了一种名为 “IP Jail” 的系统来处理这些超大容量攻击 。这个系统就像是一个 “网络监狱”，一旦发现有问题的 IP 地址，就会将其 “监禁” 起来，并在一段时间内禁止其在任何 Cloudflare 域中使用 HTTP/2 。通过这种方式，Cloudflare 成功地抵御了大量的攻击，保障了其服务的稳定性。但这种方法也存在一定的副作用，那就是与被禁止 IP 地址共享的合法用户可能会受到轻微的性能下降影响 。
谷歌则通过在网络边缘增加容量来应对这些新型攻击。当攻击发生时，谷歌能够迅速调配更多的网络资源，确保服务器有足够的能力处理大量的请求，从而避免因攻击导致的服务中断。就像在高速公路上增加车道一样，即使车流量突然增大，也能保持交通的顺畅 。

（二）服务器配置调整

从服务器配置的角度来看，合理的参数设置可以有效地缓解 HTTP/2 Rapid Reset 攻击带来的影响。在 Nginx 服务器中，我们可以通过设置 keepalive_requests 参数来限制一个 HTTP/2 TCP 连接上的请求总数量。比如，将 keepalive_requests 保持在 1000 次请求的默认设置，这样可以防止攻击者通过单个连接发送过多的请求 。
同时，http2_max_concurrent_streams 参数也非常关键，它用于限制并发流的数量。将其保持在 128 个数据流的默认设置，能够在一定程度上防止攻击者绕过服务器的并发流限制 。
此外，还可以使用 limit_conn 和 limit_req 指令来进一步增强防护。limit_conn 用于限制单个客户端的连接数，比如设置 limit_conn_zone binary_remote_addr zone=two:10m rate=10r/s; 表示每个客户端每秒最多只能发送 10 个请求 。通过这些配置，可以有效地控制客户端的请求行为，减少攻击对服务器的影响 。

（三）安全工具的应用

在应对 HTTP/2 Rapid Reset 攻击时，各种 HTTP 洪水防护工具是我们的有力武器。Web 应用防火墙（WAF）可以检测并阻止恶意的 HTTP 请求，它就像一个智能的 “门卫”，能够识别出那些伪装成正常请求的攻击流量，并将其拒之门外 。例如，阿里云的 WAF 凭借在主动防御和基于机器学习的检测方面的优势，能够有效地抵御 HTTP 洪水攻击，过滤掉恶意机器人流量，保证网站源站的性能 。
入侵检测系统（IDS）和入侵防御系统（IPS）也不可或缺。IDS 可以实时监测网络流量，一旦发现异常流量，就会及时发出警报，提醒管理员采取相应的措施 。而 IPS 则更加主动，它不仅能够检测到攻击，还能直接对攻击进行拦截，阻止攻击流量到达目标服务器 。
我们还可以使用流量清洗服务。流量清洗服务会实时监测网络流量，当检测到 DDoS 攻击流量时，会将这些流量引流到专门的清洗设备进行处理，过滤掉恶意流量后，再将干净的流量返回给目标服务器 。这就好比在河流中设置了一个 “过滤器”，将污水过滤掉，只让干净的水流向目的地 。
面对 HTTP/2 Rapid Reset 攻击，我们需要从多个方面入手，综合运用各种应对策略和防护措施，才能有效地保障网络的安全和稳定 。无论是厂商还是普通用户，都应该时刻保持警惕，不断加强自身的安全防护能力，以应对日益复杂的网络安全威胁 。

总结与展望

HTTP/2 Rapid Reset 攻击作为一种新型的 DDoS 攻击手段，利用了 HTTP/2 协议的特性，展现出了强大的破坏力。它绕过了服务端的并发流限制，能在短时间内对服务器造成巨大的压力，导致服务中断，给企业和用户带来了严重的损失。从各大互联网巨头遭遇的攻击规模来看，这种攻击的威胁不容小觑，而且随着僵尸网络规模的不断扩大，未来它可能会引发更严重的网络安全事件 。
面对这一威胁，我们已经采取了一系列的应对策略。各大厂商如 Cloudflare、谷歌等都积极行动起来，通过技术手段来抵御攻击。服务器配置的调整也为防御提供了一定的保障，合理设置参数能够限制攻击者的行为。各类安全工具更是在防护过程中发挥了重要作用，它们就像一道道坚固的防线，守护着网络的安全 。
然而，网络安全是一场没有硝烟的持久战，HTTP/2 Rapid Reset 攻击只是众多网络威胁中的一个缩影。未来，安全厂商需要不断加强技术研发，提高对新型攻击的检测和防御能力。开发者在设计和实现网络协议及应用程序时，也应更加注重安全性，从源头上减少漏洞的出现。作为普通用户，我们也不能掉以轻心，要时刻关注网络安全动态，提高自身的安全意识，共同维护网络环境的安全与稳定 。只有各方齐心协力，才能在这场网络安全的较量中取得胜利，让互联网更好地为我们服务 。
 

墨者安全 防护盾

墨者安全作为专业级别安全防护专家，在应对 Webshell 风险隐患方面展现出了卓越的能力。其拥有全面的检测机制，能够精准识别 Webshell 的各种类型和变体，无论是复杂的大马，还是隐蔽的内存马，都难逃其敏锐的监测。
墨者安全防护盾具备强大的实时监控功能，对服务器的各项活动进行 7*24 小时不间断的监视。一旦发现任何可疑的 Webshell 活动迹象，立即发出警报，并迅速采取隔离和清除措施，将风险扼杀在萌芽状态。
在防护策略上，墨者安全防护盾采用了多层次的防御体系。不仅能够在网络层面阻挡外部的恶意访问和攻击，还能深入系统内部，对服务器的文件系统、进程等进行深度检查和保护，确保 Webshell 无法植入和运行。
同时，墨者安全防护盾拥有快速的应急响应能力。当 Webshell 攻击事件发生时，专业的安全团队能够迅速介入，进行深入的分析和处理，最大程度减少攻击带来的损失，并帮助用户快速恢复服务器的正常运行。
墨者安全防护盾还注重用户教育和培训，为用户提供关于 Webshell 防范的专业知识和最佳实践，帮助用户提升自身的安全意识和防范能力，共同构建坚实的网络安全防线。