TG咨询很多人第一次做UDP攻击防护时，只想到关闭几个端口，或把防火墙策略设为“全部拒绝”。这两种做法都可能留下问题：业务需要的DNS、语音、在线游戏或QUIC流量被误伤，而真正暴露在公网的管理接口、测试服务仍然可以接收大量报文。
一、先确认哪些UDP服务真的对外开放
UDP没有像TCP那样的连接建立过程，端口一旦开放，服务端通常会直接处理收到的数据。初学者最容易忽略的是“服务器有监听端口”和“公网应该访问这个端口”并不是一回事。
- 在Linux主机上查看监听情况，重点检查DNS、NTP、WireGuard、游戏服务或自定义程序使用的端口。可通过系统的端口查看工具确认监听地址，是仅绑定内网地址，还是绑定了所有网卡。
- 在云平台安全组、边界防火墙和主机防火墙分别核对入站规则。三层策略中只要有一层放行，公网流量就可能到达服务。
- 删除临时测试规则，尤其是允许任意来源访问高位UDP端口的规则。若业务只服务固定客户，应优先使用来源地址段或VPN进行限制。
例如，BIND DNS若只是为内网解析服务，就没有必要对整个互联网开放递归查询；WireGuard则应限制到实际使用的端口和客户端地址范围。明确业务边界，是UDP攻击防护的第一步。
二、不要把“限速”设置成一个固定数字
速率限制是常见的UDP攻击防护措施，但限速值不能脱离业务类型。DNS查询通常是短报文、高频请求；视频会议和实时游戏更关注连续性与延迟；QUIC流量则可能在高峰期出现较大的并发变化。
| 场景 | 更适合的限制方式 | 常见风险 |
|---|---|---|
| 公共DNS | 按源地址、请求类型和异常频率综合限制 | 过严会让移动网络或NAT用户集中受影响 |
| WireGuard | 仅允许已登记的客户端地址或上游网段 | 把公网端口误认为必须对所有来源开放 |
| QUIC服务 | 按连接建立速率、单源流量和总带宽动态调整 | 只限制包数，未观察实际带宽 |
实际配置时，可以先以正常高峰流量为基线，再留出约20%至50%的弹性空间，具体仍取决于链路容量、报文大小、用户是否集中在运营商NAT之后。不要只限制单个IP，因为多个用户可能共享一个公网地址；也不要只限制总流量，否则攻击者仍可能耗尽连接处理能力。
三、被忽略的入站规则与出站规则
入站规则要写清来源、端口和协议
“允许UDP”这种宽泛规则几乎没有可审计性。较好的写法是明确协议、端口、来源地址、接口和用途。例如，BIND DNS的公网递归功能应关闭，权威解析与递归解析应按不同来源划分；管理服务则不应依赖隐藏端口来获得安全性。
出站规则也能减少被利用的影响
某些恶意程序会把主机变成反射或放大流量的参与者。对不需要主动访问外部UDP服务的主机，可以限制出站UDP目的端口和地址范围。需要时间同步的服务器可只允许访问指定的NTP服务，其他出站请求记录并告警。出站限制不会替代UDP攻击防护，但能降低账号泄露或程序被入侵后的扩散风险。
四、日志、告警和状态监测不能省略
只看防火墙“允许或拒绝”的总数，往往无法判断是正常高峰还是攻击。至少应记录五类信息：时间、源地址或源网段、目的端口、报文数量、总字节数。还应区分小报文高频请求与大报文突发流量，因为两者对网络设备和应用的压力不同。
- 先记录正常工作日和业务高峰的基线，观察约数小时到数天，避免把一次短时活动误判为攻击。
- 设置分层告警：单源异常、单端口异常、总入口流量异常分别处理，不要只设一个总阈值。
- 确认告警送达值班人员，并定期演练静默、升级和恢复流程。
如果采用状态监测，要注意UDP本身无连接，设备通常依赖超时、会话表和应用响应来判断状态。超时时间过长可能占用表项，过短又可能误删正常的实时业务，因此应根据报文间隔和客户端网络情况调整。
五、MTU、分片和回程路径容易造成误判
UDP报文较大时可能出现IP分片。部分防火墙会丢弃非首片，部分网络则对分片重组不稳定，结果看起来像攻击防护策略生效，实际是正常业务无法通信。启用QUIC、语音或自定义协议时，应检查应用是否会产生大报文，并确认链路MTU、隧道封装和防火墙对分片的处理方式。
同时检查回程路径是否经过同一组安全设备。请求从一条线路进入、响应从另一条线路返回时，依赖会话状态的设备可能把响应判定为异常。发生问题时，可分别在入口、主机网卡和应用日志中对照时间戳，而不是只看应用端的“超时”提示。
六、初学者可执行的检查清单
- 列出所有公网UDP监听端口，并为每个端口写明业务负责人、用途和允许来源。
- 在云安全组、边界设备和主机防火墙逐层核对规则，删除任意来源的临时放行。
- 为DNS、VPN、QUIC或其他实时服务分别制定限速，不使用一套阈值覆盖全部业务。
- 启用日志和告警，记录包数、字节数、源网段、目的端口及丢弃原因。
- 准备降级方案，例如暂停非必要UDP服务、缩小来源范围，并保留恢复原配置的记录。
真正有效的UDP攻击防护，不是单独依赖某项设备功能，而是把暴露面、规则、限速、监测和恢复流程连起来。完成以上检查后，再根据实际流量调整策略，通常比直接套用网上的固定参数更稳妥。
常见问题
1. 是否应该直接封禁所有UDP？
不建议。DNS、VPN、实时通信和部分HTTP/3业务依赖UDP。应先识别业务，再按端口和来源收敛规则。
2. 只限制单个IP的请求数够不够？
不够。攻击流量可能来自大量地址，也可能通过NAT让多个正常用户共享一个地址。应同时观察单源、网段、端口和总入口流量。
3. 主机防火墙和云安全组选一个即可吗？
不建议只依赖一层。云安全组负责边界收敛，主机防火墙负责细分端口和来源，两者还应保持规则记录一致。
4. 为什么限速后业务仍然延迟很高？
可能是链路已被占满、设备会话表压力过大、分片被丢弃，或限速只按包数而没有考虑报文字节数。应结合链路、设备和应用日志排查。
