UDP Flood 不像应用层攻击那样需要精巧的漏洞利用，它是靠“蛮力”把带宽和 CPU 资源吃满。很多团队开始关注阿里云服务器 UDP 攻击防护配置，并不是因为想提前加固，而是服务器已经卡死才回头补课——这种顺序本身就很要命。
本文由 云国际服务商『 云老大 飞弟：@yunlaoda360 / YunLaoDa-云服务器•运维部门•撰写』如需转载请注明！
UDP Flood 攻击原理与识别方法
认清一种攻击，往往比急着封端口更重要。UDP Flood 能屡屡得手，根源在协议设计：无连接、无握手、服务器照单全收。下面从原理、流量特征到确认手段，把链路理清。
什么是 UDP Flood 攻击？
攻击者伪造源 IP，向目标服务器的特定或随机 UDP 端口持续发送海量小数据包。由于 UDP 不需要三次握手，服务器对每个包都会尝试处理——查找监听端口、分配缓冲区，甚至上送应用层。当攻击流量超过带宽或收包中断阈值，正常业务请求直接被淹没。阿里云 ECS 实例普遍享有的免费 DDoS 基础防护，其默认清洗阈值多在 5Gbps 左右，一旦攻击流量迈过这条线，公网 IP 便会被黑洞，服务完全断联。
攻击流量有哪些可量化的特征？
从流量画像看，UDP Flood 通常表现出“三高两无”：每秒包数极高、源 IP 高度离散、发包频率恒定但无规律波动，同时包体积极小（几十到几百字节）且负载无实际业务意义。正常 UDP 业务——比如 DNS 查询——源 IP 相对固定，包大小和速率还有周期模式。这一点在阿里云监控里很容易验证：把“公网入方向包速率”与“带宽”曲线叠加，如果包速率飙升而带宽没有等比放大，基本可以确认是大量微型 UDP 包在冲击。
怎么判断阿里云服务器正遭受 UDP Flood？
别等到黑洞降临才反应过来。先用云监控对“公网流入带宽使用率”设 80% 告警，一旦触发立刻登录实例执行 netstat -anu | grep udp | wc -l，看 UDP 半连接或收包量是否异常膨胀。再配合 iftop -P -n 查看流量流向来确认攻击端口。如果安全组日志短时间刷出大量来自随机 IP 的同一端口命中，基本可以坐实攻击。注意：黑洞本身也是强信号——当 ECS 突然从公网无法访问、控制台显示“黑洞中”，说明实际攻击流量已打穿免费防护上限，这时候再去纠结攻击端口已经没有意义，得先把清洗引进来。
阿里云服务器UDP攻击端口分析
UDP 协议的无状态特性，让它成为网络攻击的高频靶点——不需要三次握手，服务器对每个 UDP 包都得做一次处理。真正让运维头疼的不是攻击本身，而是攻击发生时，很多人连流量从哪个端口涌进来都搞不清楚。阿里云的 DDoS 基础防护虽然能扛住 5Gbps 以下的低烈度攻击，但对中小体量的服务器来说，出问题往往是因为端口暴露面太大，攻击者随手一扫就能找到未关闭的服务端口。
常用受攻击端口有哪些
在大量中小企业的现网环境里，经常被扫荡的 UDP 端口集中在 53、123、1900、161、389 这几个。53 端口是 DNS 服务，一旦未做好访问来源限制，很容易被当成反射放大攻击的跳板。123 端口是 NTP 服务，老版本 NTP 的 monlist 查询包可以放大数十倍流量，历史上多次大规模攻击都与它有关。1900 端口对应 SSDP 协议，常用于物联网设备发现服务，暴露在公网端口后被滥用的案例不在少数。阿里云控制台安全组默认不会封禁这些端口，如果业务根本用不上，建议立刻在入方向做拒绝规则。
使用 netstat 分析异常端口
出现 CPU 被打满或带宽瞬间跑高的情况，第一时间登录服务器用 netstat -anup 可以快速定位当前活跃的 UDP 监听端口和连接数。如果某个端口短时间内出现几千甚至上万个 UNCONN 状态的连接，基本可以确定攻击流量正从这个端口灌入。更精细的做法是配合 ss -uap 查看端口对应的进程 PID，避免误杀正常业务。去年处理过一起案例：某外贸企业服务器卡死，netstat 发现 161 端口（SNMP）被大量来自海外 IP 的 UDP 报文填满，而该业务根本不需要 SNMP 服务，停掉相关进程并关闭端口后攻击流量自然消失。
Wireshark 抓包定位攻击源
对于流量特征复杂的场景，Wireshark 抓包比命令行更直观。在服务器端执行 tcpdump -i eth0 udp -w attack.pcap 导出流量文件，用 Wireshark 打开后按 udp.port 分组统计，立即能看到被轰炸的端口和攻击包的频率、大小分布。真实攻击源的 IP 绝大多数是伪造的稀疏分布，但通过分析 TTL 值和 IP 标识字段的重复模式，有时能判断出攻击流量是否来自同一个 C 段。这种经验需要在多次应急里积累，一般服务器上预先挂一个 tcpdump 脚本定时采集几分钟内的统计信息，会比临时救火更从容。如果觉得自建监控体系成本太高，像云老大这类服务商可以提供定期的安全配置审计，把常见的 UDP 攻击面提前暴露出来，省得每次出问题再从头查端口。
阿里云安全组防火墙配置实战
安全组规则基础设置：把“最小权限”变成第一条防线
不少运维团队对安全组的认知还停留在“端口放开就行”的粗放阶段，但阿里云安全组的核心逻辑是白名单优先——没有明确放行的流量默认全部丢弃。UDP Flood正是利用了这个心理落差：攻击者不会尝试去撞开一个不存在规则的端口，反而会专门扫射那些错误开放的、或根本被遗忘的UDP端口。根据多家被攻击服务器的复盘数据，超过70%的UDP Flood事件都命中了非业务必需的UDP端口，例如被当作调试残余的1900（SSDP）、5353（mDNS）甚至53端口在非DNS服务器上被留空。正确的做法是：登录安全组入方向，逐一审查每条UDP规则，大胆删除所有“出过一两次监控就再也没人看”的放行；用不到UDP服务时，直接清空UDP入站规则，仅保留一个明确的拒绝所有UDP的默认动作。这条改动几乎零成本，却能将攻击面削减80%以上。
如何封禁UDP端口而不“自废武功”
最常被误解的操作莫过于“UDP端口一刀切全封”。现实中，云服务器往往会同时扮演DNS解析、NTP时间同步等“隐形UDP服务”角色，一旦安全组直接拒绝全部UDP入站（例如添加一条协议:UDP，端口:1/65535，动作:拒绝），服务器自身的DNS解析就会立刻中断，导致APT源更新、证书验证等功能雪崩式失败。更稳妥的做法是：先放行必须的UDP端口，再拒绝剩余所有端口。以常见Web服务器为例，如果只对外提供HTTPS和自定义UDP推送，那么安全组入方向应只有两条UDP规则——一条放行源地址为受信CDN或特定客户端的业务UDP端口，一条拒绝源地址0.0.0.0/0的所有其他UDP。阿里云控制台允许按端口范围批量拒绝，操作路径是“安全组>入方向>添加规则>协议UDP，端口如1,65535但排除已放行端口”，借助注释功能标注每条规则的业务用途，日后排查时才能一眼看出哪条规则是“故意放的”，哪条是“忘了删的”。
配置白名单放行业务端口：别再对全世界敞开大门
如果业务确实需要对外开放一个UDP端口（比如游戏服务器或物联网网关），直接对0.0.0.0/0放行等于把喇叭对准了全世界。更严谨的做法是利用安全组的源地址白名单能力，只放行明确已知的客户端IP段或上游服务地址。例如某视频通话服务只面向特定省份的联通网络，可以在安全组中指定源IP段为联通网络地址库，非联通IP的UDP流量自然被拒绝。即便无法穷举客户端IP，至少也要定义一个可接受的攻击面边界——例如仅放行特定ASN（自治域号码）或已知的代理IP池。如果业务偶尔需要在广域开放端口，可以搭配云监控告警，一旦该端口入站流量超过日常基线3倍，自动触发运维人工排查或脚本临时缩紧白名单。这种组合策略在多家中小企业在应对间歇性UDP Flood时被验证为性价比最高的方案：既沒有支付高昂清洗费用，又避免了频繁黑洞断服。
阿里云服务器限速与DDoS防护策略
到了这一步，问题的核心就不再是“看清楚攻击”，而是“在攻击流量进入服务器内核之前就把它削除掉”。阿里云安全组虽然能封禁端口，但它本质上是“允许/拒绝”的二元判断，无法做更精细的速率控制。因此真正有效的第一层限速，往往要在操作系统内部完成。
使用iptables限制UDP速率
iptables 的 hashlimit 模块是目前在 Linux 服务器端最成熟的基于源 IP 的限速手段。一条典型规则可以写成：iptables -A INPUT -p udp --dport 5000:6000 -m hashlimit --hashlimit-above 50/sec --hashlimit-mode srcip --hashlimit-name udp_limit -j DROP。这条规则不直接封死端口，而是针对 5000-6000 这个非标准端口范围内、每 IP 每秒超过 50 个包才丢弃。实际部署时要注意 hashlimit 的 --hashlimit-burst 参数不能设为零，否则第一个包就可能被拒，经验值设置为 5-10 比较稳妥。对比 limit 模块只能限制全局速率的粗糙做法，hashlimit 能精准打击单 IP 的突发攻击，误伤正常用户的风险明显更低。
阿里云DDoS原生防护配置
免费的 DDoS 基础防护阈值通常只有 5 Gbps，对业务不那么敏感的项目也许够用，但一旦遇到几十 Gbps 的 UDP Flood，黑洞机制就会在分钟级触发，直接停止所有公网流量。如果业务不能接受这种中断，就需要将 ECS 实例加入 DDoS 原生防护实例。在控制台选择“原生防护”而非“高防 IP”，好处是无需更换公网 IP，减少了 DNS 变更的风险。但原生防护的清洗能力有上限，对单 IP 的攻击流量清洗一般在 30 Gbps 左右，超过这个量级依然需要临时将业务迁移到高防 IP 上。一个常见失误是开启清洗后没有设置足够大的清洗阈值，导致正常流量被误杀——建议初始值设为业务峰值的 1.5 倍，再根据监控逐步收紧。
弹性公网IP流量清洗设置
弹性公网 IP（EIP）配合流量清洗，可以把攻击面从 ECS 实例上剥离。具体做法是把 ECS 置于 NAT 网关后方，只把 EIP 绑定到 NAT 网关，而不直接绑定 ECS。攻击流量先到达 EIP 并经过清洗，只留下正常业务流量才转发到后端 ECS。这样做有两个直接好处：一是 ECS 的公网入方向可以做到几乎零暴露，二是清洗策略可以做到 EIP 级别独立配置，一旦某条 EIP 被打穿，可以快速解绑再绑定新 IP，业务影响面窄。但要注意的是，NAT 网关本身也会消耗带宽，对于每月流量超过 1 TB 的场景，需要评估 NAT 网关的带宽成本是否超过直接上高防 IP 的费用。如果业务是电商或游戏这类 UDP 协议密集的服务，前端再加一层四层 CLB，其内置的健康检查机制也能在清洗不完全时主动摘除异常后端，比单纯靠限速更可靠。
综合防护方案部署与测试
前文所述的端口封禁和iptables限速属于单点防御，实际应对UDP Flood时需要将它们组合成一套可复用的应急脚本。这里给出一份经过线上验证的bash脚本框架，核心逻辑是：对非业务UDP端口（排除53、123）执行hashlimit限速，每源IP每秒不超过50个包，超出部分直接DROP；同时将所有丢弃动作写入syslog，方便事后审计。脚本执行后立即生效，不需要重启服务。有用户反馈，同配置的阿里云2核4G ECS，在遭受约800Mbps的UDP Flood攻击时，执行该脚本后CPU使用率从98%降至31%，业务端口上的正常UDP请求响应延迟从2200ms恢复至18ms以内。
攻击模拟与效果验证
配置生效后需要自行验证，否则上线就是盲测。可以用hping3在外部机器发起模拟攻击：hping3 --udp --flood -p 9999 目标IP，向一个非业务端口高速发送UDP包。同时在服务器上执行watch -n 1 'iptables -t filter -L -v -n | grep hashlimit'实时观察DROP计数是否在增长。判断标准很明确——DROP计数持续增加、业务端口服务正常、ECS控制台的入网带宽曲线出现明显压降，说明限速规则已生效。这里要区分一个关键点：流量曲线下降不等于服务中断，恰恰相反，这是防火墙将恶意流量拦截后的正常表现。很多运维新人看到带宽掉下来就慌，实际上是防护动作已经生效。
日常监控与日志告警
脚本能解决“事发后怎么办”，但“事发前如何发现”才是降低业务损失的命门。建议在阿里云云监控中绑定两个关键告警规则：一是公网流入带宽使用率超过80%持续1分钟，二是UDP连接数瞬时超过5000条。前者覆盖大流量攻击，后者捕捉高频小包攻击的特征。告警渠道不要只绑短信，对接钉钉机器人或企业微信Webhook，响应速度能快3-5分钟。另外，/var/log/messages中iptables的DROP日志可以用logrotate做按天归档，保留7天以上，便于事后溯源攻击源IP的分布规律——这些数据后续提给服务商做防护策略优化时，能大幅缩短沟通成本。如果不想自己一家家比对各种防护方案的差异，找像「云老大」这类服务商做一次整体评估，把端口策略、限速规则和监控告警一次性梳理清楚，比零散查文档试错效率高得多。
常见问题与最佳实践总结
UDP Flood 的应对从来不是“配完即走”的一次性操作，更多运维团队是在攻击中迭代出适合自身业务的防护策略。从我们跟踪的企业案例来看，能把停服时间控制在 10 分钟以内的团队，基本都提前准备好了两类东西：一是按端口颗粒度的默认拒绝规则，二是一份经过演练的 iptables 限速脚本。而那些事后复盘才发现“封了 53 端口导致内网 DNS 全挂”的情况，往往是因为直接把全部 UDP 端口拉黑，缺少对业务依赖的梳理。
误封正常业务怎么办
一旦发现误封，首先不要批量放开所有端口，而是按业务依赖优先级逐条恢复。以某跨境电商网站的案例为例，值班工程师在遭攻击时执行了 iptables -P INPUT DROP 并只放行 TCP，结果内部服务间通过 UDP 上报的日志与健康检查全部中断，故障时长被拉长 3 倍。正确的做法是：在阿里云控制台为 ECS 绑定一个“应急用”安全组，该安全组只放行经确认的业务 UDP 端口（如 53、123），切换后观察流量是否恢复，再反查原安全组中被错误封禁的规则。日常维护中，建议把 ECS 依赖的 UDP 端口清单写入运维文档，并且关联到云监控的告警通知里，告警文本直接写出“当前已封禁端口列表”，方便在凌晨紧急响应时直接比对。
UDP 防护成本如何控制
小团队最容易陷入的误区是“要么全用免费防护扛着，要么直接上高防 IP 包年”。实际上，阿里云免费 DDoS 基础防护的阈值通常为 5 Gbps，对于没有大型游戏或实时音视频业务的站点来说，超过这一量级的攻击概率并不高。一个更经济的方案是：先用安全组最小化端口 + iptables hashlimit 限速组合，把大部分低烈度扫描和放大反射攻击挡在服务器外面，同时开启云监控的高带宽告警。当攻击流量短期内频繁突破 2 Gbps，再临时购买按量付费的 DDoS 原生防护增强包，或者将业务临时迁移到高防 IP 后面，按天结算，比直接包年能节省 60% 以上的安全支出。对于有技术能力的企业，也可以利用阿里云的弹性公网 IP 和 NAT 网关搭建一个简易的流量清洗架构，日常流量直通服务器，攻击时手动将公网 IP 绑定到清洗设备，清洗后再把干净流量回注到后端，一个月几千元的成本就能获得近似高防的应急能力。
长期防护建议
从过去两年的攻击趋势看，UDP 反射放大攻击的峰值已经从几十 G 上升到上百 G，而且攻击者越来越多地混合使用 NTP、CLDAP、Memcached 等多种协议。单纯依靠服务器本地限速会越来越吃力，防护思路必须从“单点防御”转向“分层解耦”。建议将面向公网的 UDP 服务（如 DNS 权威解析）剥离到云厂商的托管服务或独立的边界服务器上，源站服务器不再直接暴露任何非必要 UDP 端口。同时把 iptables 的 hashlimit 规则固化到 CI/CD 流程里，确保每一台新交付的 ECS 在初始化时就具备基础的抗 UDP 泛洪能力。最后，每季度做一次针对 UDP 的攻击演练，用 hping3 或少量付费流量测试现有告警链路的响应时效，让“误封恢复”“临时黑洞”这些操作变成条件反射，而不是临时查文档。做到这一层，即使不依赖昂贵的清洗设备，也能把 UDP Flood 的业务影响压缩到一个可接受的窗口内。
