一、CPU 很闲，业务全死

这是运维最迷惑的一类故障现场：服务器 CPU 占用 5%、内存充足、进程都在，但业务就是打不开。

排到最后往往发现，是 UDP Flood（UDP 洪水攻击）。它的杀伤逻辑和"打垮主机"完全不同——它打的是链路带宽和中间设备的会话表。你盯错了地方（主机资源），就会得出"服务器没问题，那一定是运营商"的错误结论，白耗几个小时。

这篇讲清楚四件事：UDP Flood 到底打在哪、和 DNS 反射有什么关系、怎么在十分钟内判断、以及五层防御怎么搭。

二、先厘清：UDP Flood 与反射攻击不是一回事

很多资料把两者混着讲，但防御手段差别很大，必须先分开。

维度	UDP Flood（直接洪水）	UDP 反射放大（DRDoS）
流量路径	攻击者/僵尸网络直接打向目标	攻击者伪造目标 IP，让第三方服务器把响应发向目标
源地址	集中或分散的僵尸网络 IP	大量正常的第三方服务器（如开放 DNS、NTP）
放大效应	无，1:1 消耗攻击者带宽	有，可达数十倍
封源 IP 是否有效	部分有效	基本无效（封不完）
主要防御手段	端口策略、限速、清洗	清洗中心按反射特征过滤、关闭自身开放服务

判断要点：看入站 UDP 流量的源端口。大量流量的源端口是 53（DNS）、123（NTP）、11211（Memcached）、1900（SSDP），那是反射攻击；源端口杂乱、目标端口固定（打你的业务端口），那是直接 UDP Flood。

三、UDP Flood 为什么难防：三个天然弱点

1. UDP 无连接、无握手：发包成本极低，且源 IP 极易伪造——这让"按源 IP 封禁"天然失效；
2. 防火墙/NAT 的会话表是稀缺资源：大量 UDP 报文会在防火墙、负载均衡、NAT 网关上建立会话表项。表项被打满，正常用户的连接也建不进来——这是"带宽没满但业务全死"的常见原因；
3. 业务本身可能就依赖 UDP：DNS、VoIP、视频直播、游戏、QUIC（HTTP/3）都跑在 UDP 上，"一刀切封 UDP"等于自断业务。

四、四类常见变种与判断特征

4.1 纯 UDP 洪水（带宽型）

入站 UDP 流量陡增，链路打满，丢包严重。判断：流量监控中 UDP 占比从个位数飙升到 80% 以上，目标端口多为业务端口或随机端口。

4.2 小包高频洪水（PPS 型）

带宽占比不高，但每秒包数（PPS）极高。它打爆的是网络设备与会话处理能力，而非带宽。很多监控只看带宽，因此容易漏判——这是最容易被误诊的一类。判断：看 PPS 曲线而不是 Mbps 曲线；防火墙数据面 CPU 飙高、新建会话失败率上升。

4.3 UDP 分片攻击

大量分片报文，靠重组分片耗尽资源。判断：分片报文比例异常、重组失败计数上升。现代设备多有防护，老旧防火墙和嵌入式设备仍需关注。

4.4 会话表耗尽型（状态防火墙场景）

带宽与 PPS 都不夸张，但防火墙会话表利用率逼近 100%，新用户完全无法接入。判断：直接看会话表使用率与会话新建速率——排查"业务打不开但资源正常"的必查项。

五、五层防御：从本地规则到上游清洗

第一层

端口最小化——只放行业务必需的 UDP

这是性价比最高的一步。原则：默认拒绝所有入站 UDP，按业务白名单放行。

• 只开放业务真实需要的 UDP 端口（DNS 53、VoIP 的 RTP 段、游戏端口、QUIC 443 等）；
• 对非业务端口的高位随机端口直接拒绝；
• 特别注意：很多企业的安全组是"全端口入站"的粗放配置，这是 UDP Flood 能轻易打进来的前提。

第二层

限速与阈值——给每个来源设上限

• 按源 IP 限速：单源 UDP 包速率设阈值（结合业务合理值），超限丢弃；
• 按目标端口限速：对暴露在公网的高风险 UDP 服务单独设阈值；
• 总体带宽占比限制：为 UDP 设定不超过链路带宽的合理占比上限，超出部分优先丢弃低优先级流量；
• 关键：阈值要基于业务基线来定，拍脑袋的数字要么误伤要么无效。

第三层

保护会话表——别让中间设备先倒下

• 对 UDP 会话设置更短的存活时间（UDP 伪会话无需长时间保持）；
• 设置单源最大并发会话数、全局会话表水位告警（70% 即预警）；
• 会话表打满时优先清理"无响应、单向"的伪会话，而不是让新用户排队；
• 防火墙性能有限时，把清洗/限速前置到专用设备，避免业务网关直接承受攻击。

第四层

架构减负——让攻击打不到单点

• 带宽冗余：日常水位控制在 30% 以内，为突发留余量；
• Anycast / 多入口：把流量分摊到多个节点，避免单 IP 被打穿；
• 隐藏源站：全站走 CDN 或高防，源站只对回源 IP 开放——源站 IP 一旦暴露，前面几层都白设；
• 业务侧限速：游戏、VoIP 类业务在应用层做"每 IP 速率限制 + 合法性校验（如 token/challenge）"，让无效报文在业务层也被丢弃。

第五层

上游协同与应急——大流量只能在上游解

当攻击规模超过本地带宽时，本地任何配置都无效，必须靠上游：

1. 联系云厂商/托管商安全团队，申请上游流量清洗；
2. 切换到已备案的高防/清洗线路（前提是预案已备好、解析可快速切换）；
3. 极端情况下对非核心业务做黑洞路由，但要明确代价：黑洞期间该 IP 完全不可达；
4. 全程留存流量样本与时间线，用于后续评估与报案。

六、应急响应：被打的那 30 分钟该做什么

1. 先看三条曲线：带宽（Mbps）、包速率（PPS）、会话表利用率——判断是带宽型、PPS 型还是会话耗尽型；
2. 看源端口分布：判断是直接洪水还是反射攻击，这决定了要不要找上游按特征过滤；
3. 确认攻击目标：单一 IP 还是整个网段？单一业务端口还是全端口？范围决定处置粒度；
4. 按类型施策：带宽型走上游清洗；PPS 型加限速与前置设备；会话耗尽型先清伪会话 + 降 UDP 会话老化时间；
5. 同步业务侧：通知客服与业务方准备话术，避免"用户在投诉、运维在抓包"的信息真空；
6. 事后复盘：把本次攻击特征（端口、包长、速率、来源分布）沉淀成规则，加入监控基线。

七、自查清单

• 入站 UDP 是否为"默认拒绝 + 白名单放行"？有没有"全端口开放"的安全组？
• 是否为暴露在公网的 UDP 服务设置了单源限速阈值？阈值是否基于业务基线？
• 监控是否同时覆盖 带宽（Mbps）与包速率（PPS） 两条曲线？
• 防火墙/NAT 会话表利用率是否纳入告警（建议 70% 预警）？
• UDP 会话老化时间是否已调短？单源并发会话是否有限制？
• 源站 IP 是否已隐藏？是否只对 CDN/高防回源 IP 开放？
• 高防/清洗服务的开通流程与切换预案是否已演练过？
• 是否有运营商/云厂商安全团队的紧急联系通道？

八、常见问题（FAQ）

Q1：UDP Flood 和 DNS 反射攻击有什么区别？

UDP Flood 是攻击者直接向目标发 UDP 报文；DNS 反射是伪造目标 IP，让大量正常 DNS 服务器把响应发向目标。看源端口可区分：源端口 53/123/11211 多为反射，源端口杂乱、目标端口固定多为直接洪水。两者防御重心不同。

Q2：服务器 CPU 才 5%，为什么业务完全打不开？

因为攻击打的是链路带宽或中间设备的会话表，不是主机资源。优先看三条曲线：带宽、PPS、防火墙会话表利用率。会话表打满是"资源正常但业务全死"的典型原因。

Q3：能不能直接把 UDP 全封了？

不能。DNS、VoIP、直播、游戏、QUIC（HTTP/3）都依赖 UDP，全封等于自断业务。正确做法是"默认拒绝 + 按业务白名单放行 + 对放行的端口限速"。

Q4：为什么带宽看着没满，攻击却生效了？

说明是小包高频的 PPS 型攻击，或者是会话表耗尽型。这类攻击的瓶颈在"每秒包数"和"会话处理能力"，只看带宽监控会漏判。监控必须同时看 PPS。

Q5：云厂商的高防什么时候该买？

两个信号：一是业务完全依赖在线访问且有明确损失（电商、游戏、SaaS、金融），一次数小时中断的损失可能超过全年费用；二是自建带宽不足以吸收常见攻击量级。买之前先做好源站隐藏，否则高防形同虚设。

Q6：限速会不会误伤正常用户？

会，如果阈值拍脑袋定。正确做法：先采集 1–2 周业务基线（正常单用户 PPS、峰值并发），阈值设在基线的数倍以上；同时给监控探测源、合作方 IP 加白名单，并在上线前做灰度验证。

Q7：黑洞路由是不是"投降"？

是一种有代价的止损。黑洞期间该 IP 完全不可达，适合"先用它保住同网段其他业务"的极端场景。正确用法是：先切高防/清洗，黑洞只作为最后的兜底，且必须明确告知业务方影响范围。

Q8：游戏/直播类业务被 UDP Flood 打，有什么特殊手段？

除了通用手段，业务层要做三件事：每 IP 速率限制、连接前 token/challenge 校验（让伪造源 IP 的报文无法通过校验）、以及把不活跃会话快速老化。这三条能把大部分无状态洪水挡在业务逻辑之外。

关于墨者安全
墨者安全致力于安全防护、服务器高防、网络高防、ddos防护、cc防护、dns防护、防劫持、高防服务器、高防dns、网站防护等方面的服务，全网第一款指纹识别技术防火墙，自研的WAF指纹识别架构，提供任意CC和DDoS攻击防御