一、前言

QUIC作为新生代的网络协议，其在设计之初就充分考虑了防止反射放大在内的安全风险。然而火山引擎Anti-DDoS团队经过研究发现：现网实际存在大量可被利用作反射放大的QUIC server，而且反射器数量和放大系数均非常可观，放大系数最高可达250倍，QUIC反射攻击或许会在不远的将来登上舞台。

二、什么是QUIC

QUIC是一种基于UDP开发的加密且面向连接的协议，在实现可靠传输、拥塞控制、数据加密的同时还能更好地支持多路复用、连接迁移等特性，可提供比TCP+TLS更快速、更高效、更简单的加密流量通信。QUIC最早由2012年Google工程师开发，目标是改善用户体验，后在2021年5由IETF标准化(RFC 9000)[1]。目前现网有8.5%的网站使用QUIC，这个占比还在不断上升。此外谷歌、Youtube、Facebook大牌企业均广泛使用QUIC，Facebook甚至宣称其超过75%的流量来自QUIC[2]。

图1 QUIC 在网站的使用率

数据来源：​https://w3techs.com/technologies/details/ce-quic

在OSI五层模型上看(图2)：与传统的加密通信建立在TCP+TLS上不同，QUIC放弃已被广泛使用几十年的TCP协议，转而基于UDP协议进行开发。UDP本身为QUIC暴露IP和端口，类似一种"垫片"的功能，而上层的QUIC则实现类似TCP的可靠传输、拥塞控制等功能，以及基于TLS实现数据加密，并在增加了比TCP更灵活的多路复用、连接迁移等功能，提升网络访问体验，更兼容当前移动互联网的业务场景。

图2 QUIC协议与TCP+TLS对比

QUIC建立一个加密信道的过程图3，可以看出QUIC可以比TCP+TLS至少减少1个RTT，这是因为QUIC在设计之初就把TLS(TLS.1.3)考虑在内，将传输和加密握手合并在一起，即QUIC只需一个RTT即可建立安全的加密信道，而TCP+TLS在最优的情况下需要2个RTT，而如果业务使用TLS1.2则甚至需要3个RTT。

图3 QUIC握手过程与TCP+TLS握手过程对比

虽然QUIC具有巨大的发展潜力，但随着QUIC协议发展和普及，其安全问题必然越来越突出，而反射放大攻击就是其中之一。

三、基于QUIC的反射放大攻击

3.1 QUIC的防反射放大攻击机制

所谓的反射放大攻击是指：攻击者利用特定协议对访问源缺乏身份验证且应答数据大于请求数据的特点，伪造靶机IP向公网开放此类协议的服务器发起请求，导致靶机收到大量应答数据，从而实现攻击流量放大的DDoS手法。

而实际上QUIC协议在设计之初就充分考虑到被利用作反射攻击的风险，具备防放大攻击的机制，具体有：

1. 在握手阶段QUIC要求客户端发送的Initial报文(携带Client hello)必须填充至1200字节以上

这是因为TLS协议决定了Server hello携带的数据可能远大于Client Hello，为了避免该机制被利用，QUIC要求Initial报文填充至1200字节以上，这样就可以增加攻击者带宽成本，减少放大倍数。

2. QUIC服务器不会应答没有会话记录的QUIC报文

QUIC与TCP协议一样，必须完成握手协商建立点对点会话后才会传输数据，QUIC服务端不会应答没有会话记录的QUIC请求，从而避免被利用作反射攻击。

3. 在握手阶段或连接迁移阶段，客户端地址通过验证前，服务器发送的字节数不得超过其已接收字节数的三倍

不管在握手阶段，还是在连接迁移阶段[3]，QUIC服务器在验证客户端地址前，发生给客户端的字节数不得超过其从客户端收到字节数的3倍，从而限制此类场景的放大系数不超过3倍。

备注：所谓的连接迁移是指QUIC利用CID机制标识会话，所以支持客户端源IP或者端口变化的情况下将连接迁移到新的五元组中，避免客户端重新建连的功能，详情见参考文献[3]

4. 在连接迁移阶段，验证客户端地址之前 ，服务器将限制向该客户端的发包速率

为了进一步限制攻击者恶意利用连接迁移特性发起攻击，QUIC服务器在验证客户端地址前，QUIC服务器每个RTT给该客户端发送的数据不得超过最小拥塞窗口值。

5. QUIC限制了同一个Token不会在短时间多次接受

QUIC协议允许服务端在一次连接期间通过NEW_TOKEN 帧为客户端下发Token，该Token可用于后续其他QUIC连接，这是QUIC 0-RTT的重要基础。但也因为如此，服务端可能会向客户端发送大量数据来应答0-RTT请求。为了避免攻击者侦听和收集Token后，通过重放Token的方式，从而使服务端作为 DDoS 攻击的放大器，QUIC对Token存在安全限制。例如Token存在过期时间，超过时间的Token不会被接受，此外服务端不会在短时间多次接受同一个Token，从而将该攻击风险降低。

由此可见，似乎QUIC被用作反射放大的风险似乎很小。然而现实可能并非如此...

3.2 基于QUIC的反射放大效果研究

火山引擎Anti-DDoS团队通过研究和测试发现：由于QUIC的部分特性和网络配置等因素，攻击者可以通过伪造特定QUIC Initial请求获得放大系数超过3倍甚至接近250倍的放大效果(具体见图4)：

图4 QUIC发射放大器分布

从扫描结果来看，当前全网有20万+QUIC服务端具有反射放大效果，其中放大系数3倍以内的放大器数量有14.6万左右，3~30倍的7万左右。此外还有1500+个放大器的放大系数竟有30~250倍，这些放大系数其实已经相当可观。

为便于理解，火山引擎Anti-DDoS团队整理了现网常见的UDP反射攻击的放大系数情况(图5)，可以看到横行互联网多年的SSDP反射放大系数不过30倍，DNS放大系数也就54倍，250倍的放大系数已经排名前列。

图5 常见UDP反射放大系数分布

既然QUIC协议在设计之初已经充分考虑其防反射放大的安全性，为何最终现网还能发现那么多可用且放大系数比较客观的反射放大器呢？

QUIC反射器按放大系数大小，主要分三类：

3.2.1 放大系数：3倍及以内 --- (TLS协议机制决定放大效果不可避免)

由于TLS协议决定了Server Hello将携带证书等信息，使其数据远大于Client Hello，虽然QUIC要求Initial报文(Client Hello)填充至1200字节以上，但不可避免地出现应答数据大于请求数据的情况，故现网会有大量存在放大系数3倍以内的反射放大器。

图6 放大系数3倍的QUIC反射

3.2.2 放大系数：3至30倍 --- (服务端重传加剧反射放大)

部分QUIC服务端会设置一定次数的重传(取决于QUIC库和软件的具体实现)，最终导致Server Hello的内容在较短时间内多次重传，放大倍数提升至3~30倍不等。此类QUIC服务端已经有不错的反向攻击利用价值。

图7 放大系数21倍的QUIC反射

3.2.3 放大系数：30~250倍 --- (特定的网络架构和配置让反射放大系数超百倍)

测试过程中团队惊奇地发现部分服务器IP收到一个QUIC Initial请求后会同时应答多个Server Hello，而且从Server Hello的source CID判断这些报文实际是由多个不同QUIC server返回，这就导致放大系数大增，达到数十倍甚至达到250倍的放大，这个倍数已经超过DNS、SSDP、CharGEN等常见的UDP反射攻击。

图8 放大系数200+倍的QUIC反射

那为何出现这么大的放大倍数呢？其实主要由特定的网络架构和QUIC特定的设置导致的，具体流程如下：

图9 特定的网络架构和QUIC特定的设置

• 攻击者伪造靶机IP向某公网IP发送伪造的Initial请求报文

• 而该公网IP实际是某个子网的NAT出口IP

• NAT收到请求后将其转换成内网请求，由于转换规则设置问题，dstip被转换成其子网的直接广播地址

• Initial请求在内网中被广播到所有server上

• 由于内网的QUIC server开启了广播功能(如下图为Node.js实现的QUIC广播)，将应答Server Hello

图10 QUIC(Node.js实现)设置广播

• 从而多个不同QUIC server应答的Server Hello再通过NAT应答给靶机，最终靶机收到大量应答报文，实现数十倍甚至上百倍的流量放大

上述反射放大场景较为特殊，故此类反射器往往集聚在某些大型CDN或云厂商(初步判断此为其通用配置方案)，这也使得这种反射放大器的数量较为可观，根据团队粗略扫描：共计发现1000+个QUIC服务端放大倍数超过30倍，其中500+个放大系数超过100倍，最大的放大倍数250倍左右。而且随着QUIC的进一步普及和互联网的发展，此类放大器可能会不断增多。

3.2 将QUIC反射放大用作实战的门槛

根据上文分析可以看到QUIC协议实际存在被用作反射攻击的风险，但由于QUIC协议本身存在一些安全机制，攻击者要将QUIC反射用于实战的门槛实际远高于其他反射协议，这是因为：

• 伪造的QUIC请求需要随机变化CID

QUIC规定同一台QUIC server并不会多次应答同一个DCID的Initial请求，这就意味如果需要持续稳定的攻击效果，攻击者必须在伪造Initial请求的同时动态变化其DCID。而其他UDP反射协议如DNS、SSDP、NTP只需要重放固定的请求报文即可获得稳定的放大效果。

• 攻击端需完全实现Initial报文的加密逻辑

QUIC对报文的加密可以说是"武装到了牙齿"，虽然CID明文传输，但Initial报文的Payload实际结合使用了Version、DCID等关联数据并通过AES-128-GCM算法加密，也就是说如果只是存粹修改报文中的CID会导致服务端无法解密和识别Initial报文的Payload而将其忽略。故攻击端必须完全实现Initial报文的加密流程，每次变化DCID时都按加密逻辑生成Encrypted Payload，才能获得QUIC server端应答。

图11 Initial报文组成和加密流程

由此可见，由于QUIC本身具有较多安全机制，所以要将QUIC反射用于实战对攻击者来说有更高的门槛。但这些门槛实际并不能消除QUIC被利用作反射放大攻击的风险。因为QUIC反射不但具有可观的放射放大系数，而且在有使用QUIC的业务场景下，因QUIC反射流量与正常QUIC流量完全一致，难以区分，故其防护难度其实远超其他UDP反射。

四、防护方案

正所谓"抛开业务场景谈DDoS防护都是耍流氓"，QUIC反射放大攻击在不同业务场景下的应对措施和防护难度差异很大。一般攻防场景主要有3种：

不需要QUIC协议的业务场景

这种场景下防护相对简单，只需要在上游的安全设备上封禁UDP 443端口流量即可，当然如果攻击流量过大则有需要购买各大云厂商的DDoS高防服务或者需求运营商协助。火山引擎为用户提供Tb级别DDoS防护带宽，可帮助客户从容应对各类大型DDoS攻击，详情见https://www.volcengine.com/docs/6352/196721

存在对外发起QUIC访问业务场景

部分业务场景如NAT网关、服务器间的数据同步等，需要服务器对外发起QUIC访问，即正常业务就需要QUIC应答流量，所以这种场景下毫无疑问无法直接封禁UDP 443端口。更要命的是反射流量本身就是外部QUIC server返回合法的Server Hello，与正常业务访问的并无差异，这使得该场景下防护难度很大，建议业务联系火山引擎Anti-DDoS团队支持，团队具有多年海量流量攻防对抗经验，自主研发多种业界先进的防护算法能够有效抵御此类攻击。

QUIC服务端场景

对公网提供QUIC访问服务的QUIC server主要的威胁是被利用作做QUIC反射放大器，一旦被利用，QUIC server将频繁遭受大量恶意QUIC initial请求，对QUIC server的资源和带宽造成巨大消耗，甚至会因请求量过大出现拒绝服务的风险，对于此类场景可通过请求来源区域、请求域名等维度进行一定的缓解，但如果需要彻底解决，同样建议寻求火山引擎Anti-DDoS团队协助。

参考文献

[1] https://www.rfc-editor.org/rfc/rfc9000

[2] https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-is-bringing-quic-to-billions/

[3] https://www.rfc-editor.org/rfc/rfc9000#name-connection-migration