QUIC 存在 UDP 反射 DDoS 攻击漏洞吗？

今年年初，360信息安全部发布了一篇关于利用 UDP 反射 DDoS 的分析报告： Memcache UDP反射放大攻击技术分析 。报告一出，引起了业界的普遍关注。根据文中所述，光是Qrator Labs 在 medium.com 上 批露的 一次DDoS攻击 看，其攻击流量峰值达到 480Gbps。而360信息安全团队本身也监测和确认有更大的攻击已经实际发生，只是未被公开报道。

而就在这个这个事件纰漏没多久，我把博客升级为支持基于 UDP 的 QUIC 协议来改善小站的访问体验： 本站开启支持 QUIC 的方法与配置 。本着小站没几人访问的蜜汁自信，当时也没太纠结 QUIC 是否也存在 UDP 反射漏洞。前几天，看到著名博主， 阮一峰同学网站被 DDoS 攻击 ，心里咯噔一下：出来混迟早是要还的，还是填坑为安吧。

什么是 UDP 反射 DDoS 攻击

简单讲，就是攻击者利用IP网络不做真实源地址检查的“设计缺陷“，向提供基于 UDP 服务的服务器发送伪造源地址（一般为被攻击者的主机IP）的 UDP 报文请求，使得这些 UDP 报文的响应数据都会发送给被攻击者主机，这种攻击我们称之为 UDP 反射 DDoS 攻击。

之所以要通过被利用的服务器反射流量到被攻击的服务器，是因为被利用的服务器一般存在流量放大效应。即一个伪造IP的 UDP 请求发送到到被利用服务器后，被利用服务器会发送比请求更多的数据到被攻击者服务器。

被利用服务器输出流量与输入流量的比值我们称之为放大系数。这个系数与被利用服务器所提供的 UDP 服务有关。之前提到的利用 Memcache 漏洞的 DRDoS 攻击，可以获得稳定的 60000 倍放大系数。而我们日常使用的 DNS 则可以轻松的获得 50 倍的放大系数。

由放大系数反推，我们可以知道，如果一个 UDP 服务被利用以后，放大系数小于等于1的话，则不存在利用价值，因为这个时候，只从带宽流量方面考虑的话，还不如直接利用攻击主机对被攻击服务器进行攻击效率高。

QUIC 存在 UDP 反射攻击漏洞吗

按照蛤乎惯例，照顾猴急的同学，先给结论：可以。

QUIC 主要通过以下机制来解决该问题：

1. 对于首次发起建立 QUIC 连接的客户端，服务端要求其初始化的 hello 数据包必须完全填充。这个包在 IPv4 下一般是 1370 字节，在 IPv6 下是 1350 字节。在 QUIC 协议中，服务器和客户端数据交互的基本单位是就是 UDP 数据包，而一个全填充的数据包已经达到了数据包大小的上限，因此服务器的响应数据包一定是小于等于这个 hello 数据包的。显然，放大系数小于等于1. 因此，新连接的建立没有反射利用的价值。
2. 建立 QUIC 连接后，客户端发出的数据包就不会全填充了。这个时候，如果被 UDP 反射利用，放大系数是大于1的。因此, QUIC 引入了源地址token (source address token)：在成功建立 QUIC 连接后，服务器会用发放一个源地址token给客户端，并要求客户端在后续的数据包中带上这个token；服务器只对源地址token有效的数据包进行处理。源地址token中一般包含客户端的源地址和服务器的时间。因此这是一个客户端证明其IP所有权的凭证。
3. 由于源地址token可能会被网络中的攻击者嗅探收集，因此 QUIC 设计了一套源地址token的过期和刷新机制。另一方面，每次客户端发送的数据包如果都带上源地址token的话，不仅客户端流量大，服务器验证token也是额外的开销，使得协议延迟变高。因此 QUIC 协议允许客户端按照一个动态策略选择是否在数据包中夹带源地址token：服务器端收集和统计源地址的数据包，当统计到源地址数据包交互响应异常的数量超过阈值时，要求该源地址的客户端必须夹带源地址token, 对于无法提供合法源地址的token的请求进行 reject 处理。

扩展阅读

• QUIC Wire Layout Specification
• On DDoS & QUIC