前言
2023年10月Cloudflare、Google、AWS等厂商公布了一种利用HTTP/2快速重置进行应用层DDoS攻击的0day漏洞 (CVE-2023-44487)[1][2]，即H2 Rapid Reset DDoS。Google宣传其监控到此种攻击峰值超过每秒3.98亿个请求 ，打破互联网历史最大应用层DDoS攻击记录[3]。而本文中火山引擎网络安全团队将对H2 Rapid Reset DDoS进行深入的研究分析，并介绍火山引擎对这种新型攻击手法的防护效果。
关键信息速读
【关键点一】 H2 Rapid Reset DDoS漏洞可绕过HTTP/2协议的并发流限制，迫使服务端处理超量请求，但无法绕过NGINX的keepalive_requests，故攻击威力视服务端配置而定
【关键点二】 H2 Rapid Reset DDoS对服务端CPU的压力实际略小于一般的应用层DDoS，但仍具有一定威力
【关键点三】 H2 Rapid Reset DDoS可阻塞反向代理集群中TLS decryption->上层应用的通道，从而瘫痪代理对外服务能力
【关键点四】 H2 Rapid Reset DDoS经过反向代理后会转化成对源站的SYN + RST的四层DDoS，在特定场景甚至可转换成TCP connection Flood
【关键点五】 H2 Rapid Reset DDoS相比一般的应用层DDoS能够节省攻击端的下行带宽，为攻击者带来"降本增效"
【关键点六】 火山引擎已上线H2 Rapid Reset DDoS的优化补丁，对这种新型攻击攻击有显著的防护效果，如需更强的防护能力，推荐接入高防产品
一、背景知识：HTTP/2与多路复用
HTTP/2是超文本传输协议的最新版本，与HTTP/1对同一个TCP连接的每个请求需串行处理不同，HTTP/2通过引入二进制分帧层(Binary Framing Layer)的方式实现了多个请求和响应在同一个TCP连接上用不同流进行并发传输，实现多路复用，大大提升互联网访问效率。如图1所示：
图1 HTTP/1和HTTP/2访问流程对比
所谓的二进制分帧层即HTTP/2将HTTP协议通信分解为二进制编码帧，然后将其映射到特定的流(stream)中，具体流程见图2。
图2 HTTP/2将HTTP信息分解为二进制编码帧
在同一个TCP连接上，不同stream的帧并交错传输，并在对端重新组合，还原完整HTTP消息，最终实现在单个TCP连接上的多路复用。
此外HTTP/2还支持客户端发送RST_STREAM帧来让服务端终止处理和应答对应stream的请求，以节省服务端资源和客户端下行带宽，类似IM软件的"消息撤回功能" 。如图3中ID为3的流被客户端重置，服务端停止处理不作应答。
图3 HTTP/2传输过程和流重置
但正所谓"福祸相依"，HTTP/2以其强大的功能为用户提供更高效、快速服务的同时也不可避免地增加了被黑客恶意利用，实现更高效DDoS的风险，而H2 ****Rapid Reset DDoS就是其中一个典型的例子。
二、什么是H2 Rapid Reset DDoS
H2 Rapid Reset DDoS(CVE-2023-44487)的核心原理就是：恶意利用HTTP/2的重置机制绕过服务端对单个TCP连接的并发流数量限制(max_concurrent_streams)，迫使服务端处理超量的请求，增强攻击效果。
具体漏洞利用过程如下：
（1）首先HTTP/2出于安全考虑，支持对单个TCP连接的并发流数量进行限制(详情见RFC9113)[4]
（2）但该限制策略只统计"OPEN"或"Half-closed"状态下的流，而"Closed"状态的流并不计入并发数[1]，这也是整个漏洞的关键所在。
（3）而HTTP/2 RST_STREAM帧可让对应stream快速进入"Closed"状态
（4）攻击者通过大规模发送应用层请求并快速重置，让服务端接收到请求后对应的stream快速进入"Closed"状态，最终并发流数量限制被绕过，服务端无法忽略超量的stream，造成资源被大量消耗。
图4 HTTP/2 Rapid Reset attack攻击过程
备注：这种快速重置的方式无法绕过NGINX对单TCP连接上的HTTP/2请求总数限制策略，故开启了此项功能的NGINX服务端对此类手法有一点抵御能力
由此可见整个漏洞利用的过程本身并不复杂，并且给人一种似曾相识的感觉...
但是，大家可能会不禁疑惑：
（1）这种攻击手法有DDoS效果吗？
（2）跟一般的H2的应用层DDoS有什么差别？
（3）攻击过程中会有哪些异常迹象？
为此，火山引擎Anit-DDoS团队进行了HTTP/2快速重置攻击进行了深入的研究和测试。
三、H2 Rapid Reset DDoS威力如何
为了全面、客观、量化地分析H2 Rapid Reset DDoS的实际效果，火山引擎Anit-DDoS团队基于NGINX搭建了HTTP/2 Server和HTTP2 Proxy(反向代理)两种常见的业务场景进行测试(见图5)。
图5 H2 Server和H2 Proxy业务场景
3.1 CPU使用率指标分析
应用层DDoS攻击的效果主要依赖耗尽服务端CPU资源，故在同等量级请求速率的前提下，对服务端的CPU消耗量是量化攻击威力的重要指标。火山引擎网络安全团队通过控制变量法测试了各种场景：
图6 各类被攻击场景下的NGINX的CPU使用率
由测试结果可见：
（1）H2 Rapid Reset DDoS不管在H2 Server还是H2 Proxy场景下威力均略弱于一般的H2应用层DDoS，这是因为快速Reset后NGINX马上终止了对攻击请求的处理，"节省"了服务端资源；
（2）H2 Proxy对一般的H2应用层DDoS的抗压能力最差，这是由于H2 Proxy既要处理客户端请求，又要处理源站应答。而H2 Rapid Reset DDoS的快速"撤回"请求，无需Proxy过多处理，反而降低了H2 Rapid Reset DDoS对H2 Proxy的压力；
（3）H2 Proxy的回源协议版本对应用层攻击的抗压能力影响不大。
综上所述：H2 Rapid Reset DDoS虽然能绕过服务端的并发流限制，但对在等量的请求频率下对服务端压力弱于一般的H2应用层DDoS，特别是在H2 Proxy场景下，反而为Proxy"减负"。而且H2 Rapid Reset DDoS无法绕过绕过NGINX对单TCP连接上的HTTP/2请求总数限制[5]，所以其攻击效果的"增益"并没有想象中大.
3.2 对反向代理架构的压力分析
前面只是在协议层面的分析，而实际现网的攻击效果中还需结合业务架构综合评估。当前业界常见的HTTP服务架构通常是在Web服务段前部署HTTP/2反向代理集群，且为了实现高性能、高可靠，代理集群会对请求作异步处理：例如处理HTTPS流量时，要先经过TLS解密模块进行解密，再将解密后的明文数据上报至上层服务，这使得H2 Rapid Reset DDoS有更大发挥空间：(如图7)
（1）攻击者对目标域名发起H2 Rapid Reset DDoS；
（2）TLS解密模块至上层服务间的通道被大规模攻击数据阻塞；
（3）正常用户访问由于阻塞问题，Proxy返回"502 Bad Gateway"，正常业务受损。
图7 H2 Rapid Reset DDoS对HTTP服务架构的威胁
当然事实上所有经过TLS加密的应用层DDoS都有此类风险，而并非H2 Rapid Reset DDoS所独有的特性。
3.3 H2 Proxy场景下源站性能分析
H2 Proxy场景中除了要评估反向代理自身的压力以外，还需考虑源站的受影响情况。在一般的H2应用层DDoS中，如果反向代理上层的安全策略被绕过，那么攻击请求将到达源站，也就是源站自身也遭受应用层DDoS攻击。而H2 Rapid Reset DDoS由于会在发送请求后会马上重置，所以应用层攻击请求并不会透传到源站，那是否意味着在Rapid Reset DDoS源站完全无压力？--事实并非如此。
火山引擎网络安全团队测试确认：当H2 Proxy遭受H2 Rapid Reset DDoS时，攻击请求的QPS会被转化针对源站的SYN Flood + RST Flood，具体过程：
（1）H2 Proxy收到应用层请求后马上给源站发syn报文，准备回源；
（2）而后H2 Proxy收到对应流的"RST_STREAM"帧，H2 Proxy停止后续处理并清空对应回源的SYN_SENT节点；
（3）此时源站收到syn后应答synack，但由于H2 Proxy的SYN_SENT节点被回收，直接返回rst；
（4）最终大量的Rapid Reset经过H2 Proxy后被转化成对源站的大规模SYN+ RST的四层DDoS(当然实际现网回源会有复用已有连接的情况，故这个转化率不一定能达到1:1)
图8 H2 Proxy场景下H2 Rapid Reset DDoS会转化成对源站的四层DDoS
当然从源站来说，处理SYN Flood + RST Flood的性能消耗比等量的应用层DDoS要小，故也从侧面说明H2 Rapid Reset DDoS相比一般的H2应用层DDoS对源站的威力更小
值得注意的是，火山网络安全团队测试中发现当H2 Rapid Reset DDoS攻击满足一定条件时，可以转换成对源站的TCP connection Flood(即完成TCP握手后，马上fin断连)，这种情况下会耗尽源站的连接池，消耗更多的CPU资源/内存，对源站压力更大。
综上所述：在H2 Proxy场景中Rapid Reset DDoS会转化成对源站的四层DDoS攻击，对源站也有压力和威胁。
3.3 流量指标分析
虽然应用层DDoS攻击重点在于应用层请求的QPS，但实际四层的流量大小也会影响服务端的带宽成本、肉鸡自身的带宽瓶颈，故也具备一定的分析和评估意义。
经过对比测试，在发起相同QPS的情况下：
（1）H2 Rapid Reset DDoS和General H2 DDoS在上行带宽维度(客户端->服务端)差别不大；
（2）但下行带宽维度(客户端->服务端)差别很大：H2 Rapid Reset DDoS的下行带宽远小于General H2 DDoS(见图9)。这其实也很好理解，毕竟快速重置后，服务端不会进行应用层应答。
图9 攻击带宽对比
这就意味着H2 Rapid Reset DDoS可为肉鸡节省大量的下行带宽成本，为攻击者"降本增效"。当然也有些攻击场景专门请求服务端大文件，通过大规模下行流量来阻塞服务端带宽资源，所以H2 Rapid Reset DDoS这个特性并非在所有场合下都能称为优点。
最后需要补充说明的是：上述分析数据是在实验环境控制变量下的测试结果，以客观、准确地量化攻击威力，而实际现网的攻防情况由业务架构、防护策略、肉鸡规模等多种因素共同决定，故实际攻防结果需具体情况具体分析。
四、火山的应对和防护效果
面对H2 Rapid Reset DDoS的威胁，火山网络安全团队联WAF、LB、CDN等相关团队进行了紧急分析和评估，并在火山相关产品(包括但不限于高防IP、高防WAF、CDN、LB等)上线了优化补丁，经过测试确认：火山引擎可在不影响正常业务的基础上对Rapid Reset DDoS攻击的识别和拦截，如图10所示
图10 火山引擎优化补丁对H2 Rapid Reset DDoS的防护效果
然而所谓"大力出奇迹"，假设攻击者发起的攻击量足够大，还是有可能耗尽HTTP/2反向代理集群的资源，最终影响业务整体稳定性。为此对于有严重DDoS威胁的业务，建议接入火山DDoS高防产品(DDoS高防IP/高防WAF)进行应对。
火山引擎高防在精确识别各类应用层DDoS的同时，还基于四七层防御系统联动，对超大规模应用层DDoS攻击分层治之，为客户提供专业、可靠的防护服务。
图11 火山引擎高防四七层联动防御
五、关于团队
火山引擎网络安全团队由业界资深安全专家组成，专注DDoS/CC防护、入侵检测与防护、边界安全、访问控制等领域，具有多年超大规模业务如今日头条、抖音、西瓜等的防护经验，并为企业客户客户提供专业的DDoS、CC、入侵检测与防护等网络安全服务。
DDoS 高防 : www.volcengine.com/product/Ant...
Web应用防火墙 : www.volcengine.com/product/waf
高级网络威胁检测系统 : www.volcengine.com/product/nta
云防火墙 : www.volcengine.com/product/clo...
参考文献1\] [blog.cloudflare.com/technical-b...](https://link.juejin.cn?target=https%3A%2F%2Fblog.cloudflare.com%2Ftechnical-breakdown-http2-rapid-reset-ddos-attack%2F "https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/") \[2\] [aws.amazon.com/cn/blogs/se...](https://link.juejin.cn?target=https%3A%2F%2Faws.amazon.com%2Fcn%2Fblogs%2Fsecurity%2Fhow-aws-protects-customers-from-ddos-events%2F "https://aws.amazon.com/cn/blogs/security/how-aws-protects-customers-from-ddos-events/") \[3\] [cloud.google.com/blog/produc...](https://link.juejin.cn?target=https%3A%2F%2Fcloud.google.com%2Fblog%2Fproducts%2Fidentity-security%2Fhow-it-works-the-novel-http2-rapid-reset-ddos-attack "https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack") \[4\] [www.rfc-editor.org/rfc/rfc9113...](https://link.juejin.cn?target=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9113%23SETTINGS_MAX_CONCURRENT_STREAMS "https://www.rfc-editor.org/rfc/rfc9113#SETTINGS_MAX_CONCURRENT_STREAMS") \[5\] [nginx.org/en/docs/htt...](https://link.juejin.cn?target=https%3A%2F%2Fnginx.org%2Fen%2Fdocs%2Fhttp%2Fngx_http_core_module.html%23keepalive_requests "https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests")