DDoS反射放大攻击怎么防？服务器别当帮凶

反射放大攻击（Reflection Amplification）最反直觉的地方在于：攻击者往往只发出很小的流量，真正把带宽打满的是被利用的第三方服务器——可能是别人家的，也可能就是你自己家的。本文用 9 个问答讲清反射放大的原理、怎么自查服务器有没有被当成反射器、常见开放服务怎么加固，以及源 IP 伪造为什么在本地很难拦。

Q：反射放大攻击的原理是什么？为什么说它「防不住」？

它靠三个条件同时成立：可伪造源 IP + 存在应答比请求大得多的 UDP 服务 + 攻击者不需要看到回包。

源 IP 伪造：UDP 是无连接的，攻击者可以把源 IP 伪造成受害者的地址，不需要完成握手，因此可以随意写出任何源地址。
放大倍数：查询请求很小（几十字节），应答可能上千甚至上万字节。攻击者用 1 份流量，就能换来几十到几万份流量打向受害者。
单次交互：攻击者根本不需要接收应答，只要把请求发出去就够了。所以他可以用极小的上行带宽放大出巨大的下行流量。

致命点在于：受害者看到的所有攻击流量，来源都是无辜的第三方服务器。你没法封锁这些 IP——它们是正常提供服务的 DNS、NTP 或缓存服务器；封了它们，你自己的用户也受影响。这就是反射放大比普通 DDoS 难处理的根本原因。

Q：哪些服务最容易被拿来当反射器？

放大倍数越高、越常见，就越容易被写进攻击工具的字典里。

DNS（53/udp）：开放递归解析器最经典。ANY 查询、DNSSEC 记录、大 TXT 记录都能放大几十倍；用 EDNS0 还能把请求做小、应答做大。
NTP（123/udp）：早期版本支持 monlist 命令，一条小请求能返回上百台客户端列表，放大倍数可达 500 倍以上。虽然新版本默认关闭，但互联网上仍有大量老设备。
memcached（11211/udp）：这是放大倍数最夸张的一类，单键 get 请求可放大数万倍。2018 年 GitHub 遭遇的 1.35 Tbps 攻击就是这类。
SSDP（1900/udp）：家用路由器、智能设备的 UPnP 服务，放大倍数约 30 倍。
CLDAP（389/udp）：Windows AD 环境常见，放大倍数约 50 到 70 倍。
其他还包括开放 SNMP（161）、CharGen（19）、游戏服务器查询端口等。

规律很清楚：凡是「UDP 单向请求、应答体积可控放大、无需鉴权」的服务，都是潜在的反射器。

Q：怎么判断自己的服务器已经被当成反射器了？

被利用的机器通常不会卡，最典型的信号是出向流量异常而不是入向。

出向远大于入向：反射放大是「小进大出」。如果你的服务器平时入向 10M、出向 2M，突然变成入向 5M、出向 200M，先怀疑被当反射器。
收到 ISP 或机房投诉：这是最常见的第一通知渠道，通常直接告诉你「你的 IP 在攻击某目标」。
自己列出对外暴露的 UDP 服务：

# 查看本机监听的 UDP 端口（重点关注 0.0.0.0 监听）
ss -lunp

# 只看对外开放的 UDP 服务
ss -lunp | grep -v "127.0.0.1\|::1"

# 本地自查是否开放递归解析（返回状态 OK 表示可递归）
dig +short test.openresolver.com TXT @127.0.0.1

# 自查 NTP monlist 是否还开着（有输出即为开放，需关闭）
ntpdc -n -c monlist 127.0.0.1 2>/dev/null | head

# 自查 memcached UDP 是否监听（有 STAT 输出说明对外开放）
echo -e "stats\r" | timeout 2 nc -u -w 2 127.0.0.1 11211

把这几条做成定时任务，每天跑一次并把结果写进日报。被当成反射器往往自己毫无感知，等 ISP 找上门时攻击可能已经持续了几天。

Q：DNS 开放递归怎么关闭？

原则只有一句：递归解析只对内网开放，对外只做权威解析。

# ---- BIND 9 ----
# 只对内网网段开放递归，其余一律拒绝
acl "internal" { 127.0.0.1; 10.0.0.0/8; 192.168.0.0/16; };
options {
    recursion yes;
    allow-recursion { internal; };
    allow-query     { internal; };
    allow-transfer  { none; };
    rate-limit {
        responses-per-second 10;
        window 5;
    };
};

# ---- Unbound ----
server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow
    access-control: 10.0.0.0/8 allow
    access-control: 0.0.0.0/0 refuse   # 其余全部拒绝
    do-not-query-localhost: no

如果这台机器本来就不该对外提供 DNS，最省事的做法是直接在内核层丢掉 UDP 53：

# 仅允许可信来源访问 UDP 53，其余丢弃（注意保留你的运维出口 IP）
iptables -A INPUT -p udp --dport 53 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP

改完务必用外部视角复验：从公网机器上执行 dig @你的IP example.com，如果还能拿到递归结果，说明没关干净。

Q：NTP monlist 和 memcached 这类服务怎么收敛？

同样是「关掉、限制、别对外」三步，不要指望换端口能解决问题——扫描器会扫全端口。

# ---- NTP：关闭 monlist ----
# /etc/ntp.conf 追加
disable monitor
# 重启后复验（应无输出）
ntpdc -n -c monlist 127.0.0.1

# 限制 NTP 只服务内网 + 速率限制
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict 10.0.0.0 mask 255.0.0.0 nomodify notrap

# ---- memcached：只监听回环 ----
memcached -d -m 512 -l 127.0.0.1 -U 0 -p 11211 -u memcache
#                         ↑ 只绑本地   ↑ 关闭 UDP（0 = 禁用）

# ---- 通用：如果确实不需要，直接在内核层封掉可疑 UDP 端口 ----
iptables -A INPUT -p udp -m multiport --dports 11211,1900,19,161 -j DROP
ip6tables -A INPUT -p udp -m multiport --dports 11211,1900,19,161 -j DROP

云服务器还要额外检查两处：安全组入方向规则和控制台的默认开放端口。很多「已经封了 iptables」的机器，实际是安全组里的 UDP 规则还开着——两条链路都要看。

另外别忘了出方向：如果业务不需要这些 UDP 协议出网，直接在安全组出方向禁止 UDP 123、53、11211，即使服务被利用也发不出去。

Q：源 IP 伪造能在本地拦住吗？

不能，这一点必须说清楚，否则容易在错误的方向上花时间。源 IP 是伪造的，出站的包在你机器上打出来时源地址就是受害者的地址——你的服务器只是在正常应答一个「看起来来自受害者」的请求，本地策略无从判断对错。

uRPF（反向路径校验）：能拦一部分伪造包，但前提是在你上游的路由器上启用，且网络拓扑支持。你本地防火墙开了没有效果，因为包根本没经过你。
BCP38 / 反欺骗部署：这是根治方向，指运营商在接入层丢弃源地址不属于该网段的包。但这需要 ISP 配合，站长层面只能呼吁和等。
本地能做的只有两件事：一是把自己的服务关掉，不参与放大；二是如果自己被攻击，靠上游清洗。

所以遇到反射放大，正确的心态是：先确认自己不是反射源（这是你能控的），再谈怎么扛住流量（这需要上游配合）。

Q：被反射放大打了，高防和 CDN 能做什么？

分工不同，别指望单一环节解决全部问题。

高防 IP / 清洗中心：流量牵引到清洗节点后，按包特征与行为模型丢弃攻击流量，只把干净流量回源。对 UDP 反射放大这类特征明显的流量，清洗效率通常较高；但要注意清洗带宽上限，攻击量超过套餐带宽就会触发封禁或黑洞。
CDN：能隐藏源站 IP、把静态请求吸到边缘。但反射放大是打向解析到的地址的体积攻击，如果攻击目标就是 CDN 节点，CDN 只能靠自身带宽硬扛；如果 CDN 供应商没有 UDP 清洗能力，反而可能把节点打瘫。
运营商 / ISP：只有他们能在源侧做 BCP38，也只有在上游做流量调度才能拦住持续的超大流量。遇到几百 G 级别攻击，说到底是要 ISP 介入。
止损动作：确认受影响业务后，先切到备用 IP 或备用域名，把攻击面从核心业务上剥开，再慢慢处理。

Q：还有什么补充建议？

把每月一次的「反射源自查」固定下来，逐条打勾：① 列出所有监听 0.0.0.0 的 UDP 服务 → ② 逐个判断是否必须对外 → ③ 能回环绑定的绑定回环，能关 UDP 的关 UDP → ④ 必须对外的加源 IP ACL 与速率限制 → ⑤ 安全组入/出方向双向收紧 → ⑥ 检查备用 IP、IPv6 地址是否漏配了同样的规则（IPv6 常被忽略）→ ⑦ 出向流量基线监控与告警。

核心认知一句话：反射放大攻击里，你的服务器有两种身份——受害者，或者帮凶。躲开第二种身份不需要多少钱，只需要一次认真的端口与 ACL 梳理；而一旦变成第二种身份，除了给攻击者递刀，还会收到 ISP 投诉、被列入开放解析器黑名单，甚至影响整台服务器所在网段的信誉。

所以这件事的性价比极高：花半天时间梳理 UDP 暴露面，等于替整个互联网减掉一个潜在的放大器，也替自己排掉一颗随时会炸的雷。