UDP Flood和UDP放大攻击有什么区别？防护不一样

作者

UDP Flood 是纯洪水硬砸带宽和包速率，UDP 放大攻击是伪造源 IP 借第三方服务反射几十倍流量。两者都走 UDP，但一个靠量、一个靠倍率，防护动作完全不同。本文讲清怎么分辨、各自怎么处置。

Q：UDP Flood 和 UDP 放大攻击，本质区别是什么？

  • 共同点是协议基础：UDP 无连接、不握手、源 IP 可以随便伪造，所以这两种攻击都不需要真的能收到你的回包。
  • 纯 UDP Flood 是攻击者（或肉鸡）自己发大量 UDP 包到你的 IP 和端口，流量从哪里来就是哪里，不依赖任何第三方。目的是占满你的出口带宽和设备的包处理能力。
  • UDP 放大是攻击者伪造你的源 IP，向互联网上开放的 DNS、NTP、memcached 等服务发一个很小的请求，让那些服务把几十倍大的响应发给你。流量来自无辜的第三方服务器。
  • 所以一个问题是「量」：多少 Gbps、多少 Mpps；另一个问题是「倍率」：攻击者花 1Mbps 能换来多少 Mbps 打到你身上。
  • 这个区别直接决定处置顺序：洪水只能靠清洗和限速硬扛，放大则有一半功夫在「别让自己成为反射源」和「让上游把伪造包丢掉」。

Q：纯 UDP Flood 有什么特征？抓包能看出什么？

  • 包很小：常见 64 到 128 字节，很多是空载荷，就是为了让包速率（PPS）最大化。
  • 源端口随机。目标端口固定，通常是你的业务端口，或者 53、123、161、1900 这类常见 UDP 服务端口。
  • 源 IP 高度分散，甚至完全不重复。因为伪造没有成本，攻击工具会直接随机生成。
  • 光看带宽可能不吓人：100Mbps 的 64 字节小包就是约 148 Kpps，很多老设备的转发能力先撑不住，而不是链路先满。

Q：UDP 放大为什么要靠第三方？常见的有哪几种？

  • 因为放大需要「小请求换大响应」，这个转换只有开放服务能提供。攻击者自己做不到，只能借别人的服务器。
  • 常见几类，倍率差别很大：memcached 能到几万倍，NTP monlist 约 500 倍，DNS 的 ANY 查询和根区查询约 30 到 50 倍，CLDAP 约 70 倍，SSDP 约 30 倍，SNMP 个位数到十几倍。
  • 条件都一样：服务对外开放、允许匿名查询、响应比请求大得多。2018 年 GitHub 那场 1.35Tbps 就是 memcached 反射。
  • 反过来说，你自己服务器上任何对外开放的 UDP 服务，都可能是别人的弹药。一旦被利用方关掉服务或加了响应速率限制，攻击面就消失了。

Q：怎么用一条命令分辨是洪水还是放大？

  • 抓 1 万个包就够判断了，先看源端口和包长，这两个字段最有辨识度。
# 1) 采 1 万个 UDP 包（注意 -s 0 抓完整包，否则看不到载荷）
tcpdump -nn -i eth0 -s 0 'udp' -c 10000 -w /tmp/udp.pcap

# 2) 看源端口分布：放大攻击的源端口会高度集中在 53/123/11211/389/1900
tcpdump -nn -r /tmp/udp.pcap 2>/dev/null | awk '{print $5}' \
  | awk -F. '{print $NF}' | sort | uniq -c | sort -rn | head

# 3) 看包长分布：洪水集中在 60-128，放大常见 200-1400
tcpdump -nn -r /tmp/udp.pcap 2>/dev/null | awk '{print $NF}' \
  | sort -n | uniq -c | sort -rn | head

# 4) 看源 IP 是否真实可解析（放大攻击的源是真实服务器，洪水多为随机段）
tcpdump -nn -r /tmp/udp.pcap 2>/dev/null | awk '{print $3}' \
  | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20
  • 判读要点：源端口固定且包长大 = 放大；源端口随机且包长小 = 纯洪水；两者混合出现说明攻击者多手法并用，按最耗资源的那种先处置。
  • 顺便看一眼 nstat -az | grep -i udp 和 ss -uan，确认是本机在收包还是在回包——如果出向包异常大，说明你的服务正在被当成放大器。

Q：为什么「关掉开放服务」对纯 UDP Flood 没用？

  • 关 53、123、11211 这些端口，只对被别人利用来打你的场景有用，前提是你自己是被反射的那一方。
  • 纯洪水打的是你的业务端口。如果你的业务本身就是 UDP（游戏、VoIP、直播推流、DNS 服务），关端口等于关业务。
  • 所以处置逻辑要分开：放大 → 先堵源头和伪造；洪水 → 先保带宽和包速率。
  • 把这两件事搞混，最容易出现的场面是：被打了一整夜，运维一直在查「我们是不是开了什么反射服务」，实际对方只是拿肉鸡在硬灌。

Q：源站侧能做的限速和 ACL 怎么写？

  • 原则只有一条：业务不需要的 UDP 端口，一个都别开。这是零成本、零误伤的操作。
  • 留下的业务端口，用 hashlimit 按源 IP 限包速率，比直接 DROP 全部更可控。
# 1) 默认丢弃入向 UDP（先把口子收窄，再按需放行）
iptables -A INPUT -p udp -j DROP
iptables -A INPUT -p udp --dport 53  -m hashlimit \
  --hashlimit-name dns --hashlimit-mode srcip \
  --hashlimit-above 50/sec --hashlimit-burst 100 \
  --hashlimit-htable-expire 30000 -j DROP

# 2) 业务 UDP 端口限速（示例：游戏/语音端口 27015）
iptables -A INPUT -p udp --dport 27015 -m hashlimit \
  --hashlimit-name game --hashlimit-mode srcip \
  --hashlimit-above 100/sec -j DROP

# 3) 防 conntrack 表被打满（UDP 会话超时要调短，否则表瞬间满）
sysctl -w net.netfilter.nf_conntrack_max=262144
sysctl -w net.netfilter.nf_conntrack_udp_timeout=10
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=30

# 4) 内核侧抗洪水：队列与软中断
sysctl -w net.core.netdev_max_backlog=250000
sysctl -w net.core.rmem_max=16777216
  • hashlimit 只能挡住「单 IP 高频」的那一类，对完全随机的伪造源基本无效——它挡的是量级，不是伪造。真正的伪造包要在上游丢。
  • 如果 dmesg 里出现 nf_conntrack: table full, dropping packet，说明限速规则本身已经成了瓶颈，先调表再谈防护。

Q：uRPF 和 BCP38 是干什么的？

  • 两者都针对「伪造源 IP」这一件事。BCP38 是出方向过滤：你的网络不许发出源地址不属于你的包，等于不让自己当帮凶。
  • uRPF 是入方向校验：收到一个包，反查源地址的回程路由是否从同一接口来，不是就丢。能过滤掉大部分伪造包。
  • Linux 上对应 rp_filter：1 是严格模式（要求回程接口一致），2 是松散模式（只要求路由表里有这个源段）。
# 单出口服务器用严格模式；多出口、策略路由、负载均衡环境用松散模式，否则会误丢
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1
# 多线路场景：
# sysctl -w net.ipv4.conf.all.rp_filter=2
  • 提醒一句：开了 uRPF 之后一定要回归测试多线路访问。非对称路由被打断的故障，排查起来比攻击本身还费时间。

Q：买高防该看 Gbps 还是 Mpps？

  • 两个都要看，但UDP 洪水拼的是 Mpps。以 64 字节小包算，1Gbps 约等于 1.49 Mpps，10Gbps 线速约 14.88 Mpps。
  • 很多清洗设备标称 500Gbps，实际包处理能力只有几 Mpps。对方用 200Kpps 的小包就能把设备打满，你的 500G 一点没用到。
  • 问清三个数：清洗带宽（Gbps）、包处理能力（Mpps）、保底额度。再问一句「小包攻击时按哪个口径计费」，这句最能试出对方的真实水平。
  • 还要问清超规格之后的行为：是继续清洗但降级，还是直接黑洞。前者会慢，后者会全站失联，完全是两种事故。

Q：真被打的时候，处置顺序是什么？

  • 0 到 5 分钟：定性。抓包看是洪水还是放大，看目标端口是不是业务端口。这一步决定后面所有动作，别省。
  • 5 到 15 分钟：切清洗。把域名或 IP 切到高防/清洗节点，DNS 改 TTL 要提前压到 60 秒，否则切换本身就要等半小时。
  • 15 到 30 分钟：收口。关掉所有非业务 UDP 端口，给业务端口加限速，把开放递归服务停掉，同步让上游做源地址过滤。
  • 之后：留证据。pcap 至少留 30 分钟窗口，配合 NetFlow/sFlow 采样，这是后续找运营商协同和索赔的唯一凭据。
  • 整个过程里，不要一边被打一边在源站上调参数。源站此刻连 SSH 都可能连不上，所有变更都应该在清洗侧或控制台做。

Q：还有什么补充建议？

  • 先自查一遍「我是不是帮凶」。对外开放的 DNS 递归、NTP monlist、memcached、SNMP、SSDP 全部关掉或加响应速率限制，这既是自保，也是行业义务。
  • 监控别只看带宽，PPS 和 conntrack 使用率要单独告警。UDP 洪水最典型的形态就是带宽曲线平平、PPS 垂直起飞。
  • 业务是 UDP 的（游戏、音视频、DNS），提前和上游确认「能不能按目的端口做限速」，很多机房默认只按 IP 限，帮不上忙。
  • 最后，别指望源站自己能扛 DDoS。源站的价值是「不被打死」，不是「打赢」，把清洗放在上游才是正解。