UDP反射放大攻击已经成为DDoS攻击中最常见的流量型手段之一。攻击者利用UDP协议的无连接特性，伪造受害者的源IP地址，向大量开放UDP服务的服务器发送小型请求报文。由于UDP不进行三次握手，服务器无法验证源地址真实性，会将远大于请求的响应报文直接发往受害者，形成流量放大。CDN节点作为分布广泛的边缘服务器，常常拥有高带宽和优质网络资源，一旦这些节点上运行了可被利用的UDP服务，就会成为攻击者的理想反射器。因此限制CDN节点的UDP协议暴露面，是防御反射放大攻击的关键环节。
为什么CDN节点容易成为反射放大帮凶
UDP反射放大攻击的核心在于放大倍数。攻击者发送的请求往往只有几十字节，而响应却可能达到数百甚至数千字节。以常见的UDP服务为例：DNS查询的放大倍数约为54倍，NTP的monlist查询可达556倍，Memcached的UDP接口甚至能产生上万的放大倍数。CDN节点通常配备高性能CPU和大带宽接入，单台节点被利用时可能产生数十Gbps的攻击流量。如果攻击者同时控制多台暴露UDP服务的CDN节点，完全可以在短时间内打瘫大多数目标网络。
很多CDN平台为了提供DNS解析、负载均衡、健康检查、内部时间同步等功能，会在节点上运行UDP服务。但部分节点可能保留了默认安装的服务，或者防火墙规则过于宽松，导致UDP端口对公网开放。攻击者使用扫描工具可以快速发现暴露的UDP服务，并利用其特征报文触发放大响应。更棘手的是，CDN节点分布广泛，同一AS内可能有多台节点同时被利用，攻击流量来源分散，溯源和清洗难度极大。
CDN节点一旦被用于反射攻击，不仅自身带宽被大量消耗，节点IP还可能被安全机构列入黑名单，影响正常CDN业务的可用性。对于被攻击的受害者而言，入站流量被UDP响应占满，TCP业务基本无法建立连接。因此，限制CDN节点的UDP协议不是可选项，而是安全基线的一部分。
UDP协议限制的总体原则
第一条原则是最小化UDP开放面。只开放业务必需的UDP端口，其他一律关闭。对公网接口默认拒绝UDP入站流量，仅允许来自可信来源（如内部DNS服务器、监控系统）的UDP请求。如果CDN业务完全基于HTTP/HTTPS，那么公网UDP应全部关闭，内部通信使用单独的管理网卡或VLAN，与公网隔离。很多反射攻击之所以成功，就是因为节点上运行了并不需要的UDP服务。
第二条原则是对必需的UDP服务削弱放大能力。以DNS为例，应关闭递归查询，只应答权威域；启用响应速率限制（RRL），控制每客户端的响应速率；对NTP服务禁用monlist、mode 6等查询；对Memcached禁用UDP协议或限制访问来源IP；对SSDP和CLDAP直接关闭。如果无法关闭，使用防火墙限速和包过滤来降低可利用性。
第三条原则是启用源地址验证和出口过滤。在节点边界路由器或防火墙上启用反向路径过滤（rp_filter），可以丢弃源地址明显伪造的入站报文。同时出口方向应执行BCP38过滤，禁止源地址不属于本节点的报文发出。虽然反射攻击伪造的是受害者地址，但源地址验证能够减少其他类型的欺骗流量，间接提升整体防护水平。下表列出了常见UDP服务及其放大倍数和处置建议。
| UDP服务 | 端口 | 放大倍数 | 建议处置 |
|---|---|---|---|
| DNS | 53 | 约54倍 | 关闭递归，启用RRL，限制来源 |
| NTP | 123 | 约556倍 | 禁用monlist，限制内网同步 |
| Memcached | 11211 | 可达10000倍以上 | 禁用UDP，仅监听内网 |
| SSDP | 1900 | 约30倍 | 公网关闭，仅局域网使用 |
| CLDAP | 389 | 约56倍 | 公网阻断，仅内部ACL放行 |
防火墙与内核参数配置实践
使用iptables或nftables实现默认拒绝UDP和按需放行是最直接的协议限制手段。下面是一组iptables命令示例，其思路是默认丢弃所有入站UDP流量，只允许来自内网DNS服务器的UDP 53端口请求，并对该端口做速率限制，防止突发流量。
# 默认禁止所有入站UDP流量
iptables -A INPUT -p udp -j DROP
# 仅允许来自内网DNS服务器(例如10.10.10.53)的UDP 53端口
iptables -A INPUT -p udp --dport 53 -s 10.10.10.53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP
# 限制每源IP对UDP 53端口的请求速率，防止突发
iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name dnslimit --hashlimit-above 20/sec \
--hashlimit-burst 30 --hashlimit-mode srcip -j DROP如果使用nftables，可以编写更简洁的规则集。以下示例同样实现默认拒绝UDP，只放行内网DNS，并限制速率。
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
udp dport 53 ip saddr 10.10.10.53 accept
udp dport 53 limit rate over 20/second burst 30 packets drop
udp drop
}
}除了防火墙规则，内核参数的调整也能增强UDP协议限制效果。建议在/etc/sysctl.conf中设置反向路径过滤，丢弃源地址明显伪造的报文。同时可以忽略广播ICMP，减少其他类型的放大隐患。
net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.icmp_echo_ignore_broadcasts = 1
如果CDN节点部署在云平台上，还应在安全组或网络ACL层面配置入站规则，只允许TCP 80/443端口，UDP全部拒绝。对于确需开放的UDP端口，必须设置来源IP白名单，并记录流量日志，便于后续审计。
CDN业务层与DNS服务限制
如果CDN节点同时提供DNS解析服务，必须在DNS软件层做限制，否则仅仅靠防火墙可能无法阻断所有反射查询。以BIND为例，应关闭递归并启用响应速率限制（RRL）。以下配置片段展示了关键参数。
options {
recursion no;
allow-recursion { none; };
response-rate-limit {
responses-per-second 10;
window 5;
};
};对于使用NTP服务的节点，应配置restrict参数禁止外部查询某些模式。例如在ntp.conf中添加以下内容，只允许本机回环和内网网段访问，并禁止修改和查询敏感信息。
restrict default ignore restrict 127.0.0.1 restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap
如果CDN节点上安装了Memcached，启动时必须使用-U 0参数禁用UDP协议，或者通过防火墙阻断11211端口的UDP流量。从业务架构角度看，尽量使用TCP替代UDP：DNS可以支持TCP 53或DoT/DoH；流媒体如果用QUIC（基于UDP），则需要按业务需求评估，若必须保留，需在CDN边缘实施严格的连接追踪和速率限制。使用Anycast网络时，应在每个PoP点执行入口过滤，确保伪造源地址的流量不会进入网络。
验证限制效果与持续监控
完成UDP协议限制配置后，需要验证节点是否仍然存在不必要的UDP暴露。使用ss -lunp可以查看当前监听的UDP端口；使用nmap -sU -p- 节点IP可以扫描公网UDP端口，结果中应只包含预期开放的端口。如果扫描到未预期端口，需要立即检查对应服务配置和防火墙规则，确认是否为误配置或服务自动启动导致。
抓包分析是验证限制效果的有效手段。运行tcpdump -i eth0 udp -nn -c 100观察UDP流量中是否存在大量响应远大于请求的异常模式。如果发现某一UDP端口出现放大特征流量，可以结合iftop或NetFlow日志定位来源，并检查该端口对应的服务是否存在放大功能未关闭的情况。同时监控节点出站流量中UDP占比，正常CDN出站主要应为TCP，UDP占比异常升高需触发告警。
持续监控和自动化响应同样重要。结合SIEM或监控系统设置阈值：当单节点UDP出站流量超过总带宽的30%或出现大量同一源端口的响应时，触发告警并自动执行防火墙封禁或流量清洗。定期审计节点上开放的UDP服务列表，与基础设施清单比对，防止新增服务引入风险。只有将协议限制与监控审计结合，才能让CDN节点彻底摆脱成为反射放大攻击帮凶的可能。