UDP反射放大攻击的最终放大倍数，本质上由开放服务的响应体积除以攻击者伪造请求的体积决定；响应越大、请求越小，打向受害者的流量就被放得越狠。
你可以把反射放大想成一面“回声墙”：攻击者伪造受害者IP，向开放服务递过去一张小纸条，服务却回敬一块砖，砖有多大，不看攻击者多用力，而看这面墙本身有多“慷慨”，UDP没有三次握手，源IP可以伪造，响应报文就会径直飞向受害者，这就是整条攻击链的底层逻辑。
UDP反射放大攻击的底层账本：响应体积就是“回礼”大小
伪造源IP之后，响应为什么直接砸向受害者
UDP协议不建立连接,服务收到查询后只认源IP，不验证对方是否真的发起过请求，攻击者把源IP改成受害者地址，开放服务处理完查询，响应包自然发往受害者，请求包由攻击者控制，可以压得很小；响应包由服务决定，往往远大于请求，放大倍数就在这一小一大之间被拉开。
放大倍数按带宽算还是按包数算
实际攻击里有两种口径：
- 带宽放大倍数：响应字节数 ÷ 请求字节数，决定链路被打满的速度。
- 包数放大倍数：一个请求触发多少个响应包，决定设备每秒处理包的能力是否先被拖垮。
DNS的响应可能被EDNS0缓冲区撑大,也可能因分片变成多个包；memcached则可能用一个十几字节的请求换回接近单条UDP报文上限的大块数据，带宽和pps要分开看，只盯其中一个，防护选型容易跑偏。
UDP反射放大攻击放大倍数怎么计算
请求包能压到多小
以DNS为例,一个普通查询可以只有几十字节；NTP的monlist命令、memcached的get命令同样很短，攻击者不需要大上行，一台普通主机就能发出大量伪造请求，请求越小，分母越小，理论放大倍数越高。
响应包能撑到多大
响应体积受协议类型、服务配置、查询内容共同影响，DNS递归解析器如果允许ANY查询、开启DNSSEC、支持较大EDNS0缓冲区，响应体积会明显上升；NTP的monlist会返回客户端列表；memcached的value越大，单包响应越夸张，服务端配置越“大方”，攻击者越省力。
MTU与分片：响应体积的隐形天花板
UDP响应超过路径MTU就会分片,分片带来两个效果：单次请求产生的总字节数可能更大，但中途丢一片就会导致重组失败，攻击者往往偏好“不需要重组也能造成压力”的响应体积，或者利用大量小包拉高pps，响应体积不是越大越一定有效，链路和中间设备的分片策略会参与最终结果。
哪些开放服务的响应体积最“慷慨”
DNS与NTP反射放大攻击哪个放大倍数更高
行业共识认为,单看典型配置，NTP monlist的放大能力通常高于普通DNS查询；但DNS的可怕之处在于开放递归解析器数量多、查询构造灵活，配合DNSSEC和较大缓冲区时，响应体积也能被显著推高，memcached则属于另一个量级，曾被公开披露的案例显示其可产生极高的带宽放大，业内专家指出，比较放大倍数不能只看协议理论值，还要看互联网上实际开放且可被利用的实例数量。
| 服务 | 默认端口 | 请求特征 | 响应体积特征 | 放大能力量级 |
|---|---|---|---|---|
| DNS递归解析 | 53/UDP | 几十字节查询 | 可返回较大记录集 | 数十倍 |
| NTP monlist | 123/UDP | 单条小命令 | 返回多包客户端列表 | 数百倍量级 |
| memcached | 11211/UDP | 十几字节get | 可返回大value | 数千倍以上 |
| CLDAP | 389/UDP | 小查询 | 目录信息较大 | 数十至数百倍 |
| SSDP | 1900/UDP | 小搜索请求 | 设备描述较大 | 数十倍 |
memcached、CLDAP、SSDP的极端响应体积
memcached的UDP支持本为局域网缓存设计,暴露到公网后，一个短请求可能换回大块缓存值，响应体积直接决定攻击烈度，CLDAP常见于目录服务，响应中携带的目录信息较多；SSDP则常被家用路由器、摄像头等设备默认开启，搜索请求小、设备描述响应大，三者共同点是：服务本身不是为公网对抗设计的，响应体积没有按“最小必要”收紧。
开放DNS解析器被利用做反射攻击怎么办
攻击者验证开放服务的三条命令
授权环境下,可用以下方式验证自身资产是否存在开放递归或可被反射利用的服务：
dig @203.0.113.10 example.com ANY +bufsize=4096 +dnssec nmap -sU -p 53,123,1900,11211 --script dns-recursion,ntp-monlist 203.0.113.10 ntpdc -n -c monlist 203.0.113.10
三条命令分别检查DNS递归与响应体积、常见UDP反射端口、NTP monlist是否开放，若返回结果明显大于请求，且服务对任意源IP都响应，就应进入整改清单。
防御侧的三道闸门
第一道是关闭不必要服务：DNS只对可信网段开放递归，NTP关闭monitor，memcached用-U 0禁用UDP，SSDP在不需要时关闭UPnP，第二道是限制响应体积与速率：DNS启用Response Rate Limiting，NTP配置disable monitor和restrict，第三道是源地址校验：网络侧部署BCP38/RFC 2827，接入层启用uRPF，减少伪造源IP包流出。
BIND开启RRL的配置路径
在BIND的options中加入速率限制，按业务调整阈值，避免误伤正常递归用户：
rate-limit {
responses-per-second 20;
window 5;
slip 2;
};
RRL不能替代关闭开放递归,它只是把“每个请求都回大包”改成“超限后少回或截断”，降低响应体积被利用的效率。
网络层uRPF与BCP38
Linux可启用反向路径过滤：
sysctl -w net.ipv4.conf.all.rp_filter=1 sysctl -w net.ipv4.conf.default.rp_filter=1
Cisco设备可在接口下配置：
interface GigabitEthernet0/1 ip verify unicast source reachable-via rx
这类配置不能挡住已经进入运营商网络的伪造包,但能显著减少本地网络成为反射源或跳板的机会。
高防IP清洗UDP反射流量价格与选型逻辑
计费口径决定账单
高防IP清洗UDP反射流量价格通常不是单一数字,常见计费口径包括保底 bandwidth、弹性带宽95计费、按清洗次数、按pps能力包，只看“多少G防护”容易忽略清洗设备的包处理能力，UDP反射攻击常用小请求触发大响应，攻击流量中包数可能很高，清洗设备若pps不足，带宽没满也可能先丢包。
带宽之外必须看pps
选型时至少确认三项：清洗中心能处理的每秒包数、单IP清洗阈值、回源线路质量，对DNS、NTP这类反射流量，建议要求服务商提供按协议识别和限速的能力，而不是只做静态流量清洗，价格低但只按带宽计费的方案，遇到高pps攻击时容易暴露出短板。
北京地区UDP反射攻击防护方案的地域落地差异
北京地区的业务选防护时,除了清洗能力，还要看本地清洗节点与运营商互联质量，金融、政企类业务通常更关注低延迟回源和等保合规，清洗节点离业务近，反射流量在近源被丢弃，正常用户感知更小，跨地域清洗虽然价格可能更低，但回源路径变长，实时业务要谨慎评估，近年来，多地运营商推进近源清洗，北京地区可优先询问是否支持运营商侧联动封堵。
关于UDP反射放大攻击与响应体积的常见问答
同样开放DNS，为什么放大倍数差很多？
差异来自递归权限、响应策略和查询内容，允许ANY查询、开启DNSSEC、支持大EDNS0缓冲区的解析器，单次响应体积更大；启用了RRL或只返回最小记录的解析器，响应被压缩，放大空间就小，响应体积不是协议固定值，而是配置结果。
关闭递归后还会被反射吗？
关闭开放递归能消除“替任意源IP递归查询”的能力，但权威DNS、缓存残留、其他UDP服务仍可能被利用，防护要按资产梳理，逐项关闭NTP monlist、memcached UDP、SSDP等非必要响应面，不能只改一项就收工。
响应体积越大一定越危险吗？
不一定,响应体积大但触发条件苛刻、需要重组、被中间设备限速时，实际到达受害者的流量会打折，真正决定危害的是“可被利用的响应体积 × 可触发的反射源数量 × 请求速率”，单看响应体积只是第一步。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787867.html
