过往可能低估了反射放大 DDoS 的风险

工作来源

Usenix Security 2021

工作背景

最近在 DDoS 攻击中攻击者正更多地利用反射放大攻击，先前认为通过网空搜索引擎就可以扫描/查找不同协议的开放服务，例如 Censys/openresolver 会扫描开放 DNS 服务、Shadowserver 会扫描开放的 CharGen、LDAP、QOTD 和 SNMP 服务等，但实际上这是有问题的。即使是相同版本的服务也会存在放大因子不同、查询模式不同的不可预测性，因此使用统一方法进行估量并不准确。

任何响应大于查询的无状态协议都可能被滥用于反射放大攻击，先前的研究都集中在：什么样的查询会导致反射放大？会产生多大的反射放大？反射放大基本原理如下所示：

攻击者伪造受害者的IP为源IP，向反射放大源服务器发送小查询请求，而服务器回复受害者的响应很大。反射放大因子（AF，也称 BAF）即为响应和查询的比值，用于衡量反射放大的“杠杆“比例。

由于设备和协议之间存在显著差异，依赖服务器进行普查的方式可能会错误估计风险。故而需要进行普查测量，设计 AmpMap 针对 6 种基于 UDP 协议的服务进行了扫描普查，不仅发现此前限制特定查询的防护方式仍然会留下风险，也有很多服务器并不使用最佳实践进行缓解（如限制速率、限制访问等），还有许多其他反射放大的查询方式会被漏掉。

以 DNS 协议为例，利用已知 DNS 会影响反射放大的三个字段（record type、EDNS、recursion desired），构建 172 个查询模式，在 Censys 中随机抽取 1000 个 DNS 服务器，向其发送这些查询模式，记录每个查询的反射放大因子。另外，也使用 Nmap 对服务器的服务版本进行扫描。

使用 28 作为 DNS 的反射放大因子时，已知的几种测量评估方式都会低估实际的风险。

使用相同查询模式时，实际上不同服务器之间的反射放大因子也是在变化的。限定 TOP 10 的查询模式的情况下，标准差为 3.9 到 17 之间。而扩展到所有查询模式时，标准差为 16.7。

分析可知，是不能用一个服务器和一个软件版本类似推断反射放大的风险的。

工作设计

最朴素的想法是将符合协议的查询枚举出来发送到每个服务进行查询，这样做搜索空间太大不可行。分析可知不同的查询模式在协议字段值上存在重叠，而且长字段要么不影响反射放大（NTP 协议的时间戳）要么一定是连续的（DNS 协议的 Payload），这样就可以采用智能采样策略对大规模的搜索空间进行检索。

简化协议

构建一个简化协议，由 5 个字段及其可接受的值组成，例如准备了几十个字符串用于填充字符串类型的字段，如 DNS 协议的 Domain 字段。

例如单个服务器反射方法测试，反映在简化协议中如下所示：

其挑战在于：

• 协议复杂，如 DNS 和 NTP，想枚举探索整个查询空间不可能。

• 参数设置还可能互相依赖、互相作用才能触发反射放大。

• 由于服务器配置不同、协议实现方式不同导致反射放大因子是可变的。

如下所示的三台服务器，各自触发反射放大的查询模式各不相同，且反射放大因子也不相同。

查询模式

可以证明随机 Fuzzing 和启发式优化都不适合该场景，也不再赘述。通过测试，设计的启发式方法与模拟退火和随机搜索相比较具有明显优势，如下所示：

给定一个查询模式，可以通过每次改变一个字段来发现临近的查询模式，逻辑如下所示：

如果观察到有连续范围（例如 4000 到 65535）都表现出类似的行为，就进行对数采样测试而非逐个测试。

单个服务器测试与多服务器的测试流程如下所示：

想要查看完整伪代码，可以进一步阅读技术报告（Accurately measuring global risk of amplification attacks using ampmap. Technical Report CMU-CyLab-19-004.）。

启发式方法

对放大因子 AF 高于阈值 δ 的所有查询模式上进行数据挖掘，例如层次聚类、K-means 聚类、决策树。但效果都不好，所以设计启发式方法如下所示：

协议中跨字段依赖关系如下所示：

工作评估

通过 Shodan、Censys 获取给定协议的开放服务器列表，从中删除不存活的服务器或者政府军方拥有的服务器。检查也只专注于无状态协议和单播协议（例如 UDP）以及无状态放大策略。

对 6 种基于 UDP 的协议（DNS、NTP、SNMP、Memcached、Chargen、SSDP）和 3 种协议（QOTD、Quake、RPCbind）进行测量。

使用 CloudLab 的服务器，1个节点用于控制，30 个节点用于测量。从 Censys 和 Shodan 上为每个协议尽量抽样选取了 1 万个服务器，。

为避免对正常服务产生影响，对总查询测试次数限定在 1200-1500 间。

Brand一般在限定次数的 10% 到 45% 就可以了，Bprobe一般限定在 5% 到 30% 之间就可以。

最终，查询速率限制为每 5 秒一次，超时时间为 2 秒。超过 10 个字段的协议（DNS、NTP、RPCbind）为每台服务器分配 1500 个查询总额，简单协议为每台服务器分配 400 个查询总额。RandomSample Stage 设置 45%，为 Probing Stage 设置 10%。

整体结果

每个服务器针对每个协议的放大因子分布如下所示，分布是个长尾分布（NTP AND 中位数为 5.11，最大值为1300）。

随着时间变化，放大因子也会变化。例如，只有 7% 的 NTP AND 服务器在 2019 年 AF ≥ 100，而 2020 年为 14%。

AmpMap 与此前的工作进行比较，发现以前的工作高估了 NTP 427 倍、高估 Chargen 2.9 倍、低估 SNMPv2 3.5 倍。

被遗漏的查询模式带来的风险比已知查询模式的风险大 21.9 倍。

全球风险如下所示，蓝色是已知风险，红色是未知风险：

97% 的服务器的放大因子大于 10：

DNS 协议

以 DNS 协议为例，在 DNS 协议中，查询的记录类型与放大因子的统计关系如下所示。TXT 和 ANY 是之前研究已经揭露的，其他类型的查询实际上也能用于反射放大攻击。而且，DNSSEC 的一些记录类型（例如 RRSIG、DNSKEY）可以产生高 AF。

其箱线图如下所示：

所有放大因子大于 10 的供应商（拥有 20 台以上服务器）如下所示：

其他协议

• Memcached 实测放大因子最大为 35 可能是由于基本修复完成。
  SNMP 发现了新模式且已知查询模式低估了风险，受影响的、拥有超过 200 台服务器的供应商如下所示：

• SSDP 有多个查询模式，都可产生大于 10 的放大因子

• Chargen 确认了已知查询模式的风险，但未发现新查询方式

• Quake、QOTD、RPCbind 也会产生放大因子为 10

工作思考

本次工作有三大发现：① 发现反射放大查询新方式与新变种 ② 发现反射放大因子的可变性 ③ 发现过往低估了反射放大风险。

过往利用网空搜索引擎基于服务器数量针对全球风险进行衡量和评估的方式会误判整体风险，可能会低估或者高估反射放大的风险。针对此类风险进行披露时，更加精细地测量可能可以更好的反映面临的风险情况。

在研究过程中遵守道德原则是很重要的，需要限制扫描速率、扫描总量、扫描范围。向受到影响的组织发送了数千封邮件进行告知和提醒，也收到了不少感谢：

文由微信公众号威胁棱镜