DDoS攻击中UDP反射的端口封禁策略

处理UDP反射放大攻击时，最让运维人员头疼的往往不是带宽被占满，而是如何在封禁恶意流量时不误伤正常业务。直接无差别封禁UDP端口，等于自断手脚，攻击者还没打垮你，自己先把服务停了。真正的难点在于，绝大多数反射攻击利用的都是业务必须开放的端口，比如DNS的53端口、NTP的123端口。这就决定了端口封禁策略不能是简单的“关”或“不关”，而必须是一套基于流量特征、地理位置和协议行为的精细化过滤体系。

UDP反射攻击之所以难防，根源在于协议设计本身。攻击者发送一个很小的请求包，伪造源IP为受害者地址，服务器就会向受害者返回一个体积大几十倍甚至上百倍的响应包。目前被高频利用的端口主要集中在几类服务：DNS（53端口）的ANY查询或DNSSEC响应放大、NTP（123端口）的monlist命令、Memcached（11211端口）的stats命令、CLDAP（389端口）的查询、WS-Discovery（3702端口）的多播响应、SSDP（1900端口）的M-SEARCH应答，还有CharGen（19端口）、QOTD（17端口）、RIP（520端口）等老旧协议。做端口封禁前，必须先在流量清洗设备或NetFlow分析器中拉出当前入向UDP流量的目的端口排名，看攻击流量主要集中在哪几个端口。很多时候攻击者会混合利用多种反射源，你需要同时应对多个端口的洪流。

DNS是互联网的根基，直接封禁53端口意味着所有域名解析失败，业务瞬间瘫痪。针对DNS反射攻击，正确的做法是在网络边界部署具备DNS深度包检测能力的设备，对入向UDP 53端口的响应包做合法性校验。具体策略包括：只放行来自你实际配置的上游DNS递归解析器IP的响应流量，其余源IP发来的UDP 53响应一律丢弃；对入向DNS响应包的大小设置阈值，正常DNS响应通常不超过512字节，即便启用EDNS0也很少超过4096字节，超过这个尺寸的包直接判定为异常；限制单源IP的DNS响应速率，一个合法的DNS服务器在短时间内不可能向你发送海量响应包。如果你的业务不需要对外提供DNS服务，那么入向UDP 53只应该存在你主动发起查询后返回的响应，任何未经请求的入向DNS流量都是可疑的，可以直接在状态防火墙或ACL上丢弃所有非established状态的UDP 53入向包。

NTP反射放大倍数极高，但好消息是，现代NTP服务已经默认关闭monlist功能，攻击者利用的是大量老旧或配置不当的NTP服务器。对于防守方来说，你的服务器如果不需要对外提供NTP服务，入向UDP 123端口应该完全封禁，只允许出向的NTP时间同步请求及其响应回程。如果必须对外提供NTP服务，务必在NTP配置中禁用monlist、version查询等危险命令，同时在上游路由器或防火墙上对入向UDP 123端口做速率限制，单IP每秒几个请求包就足够正常时间同步使用。很多网络设备本身也会开启NTP服务，检查你的路由器、交换机、摄像头等物联网设备，确保它们的NTP服务没有暴露在公网上。

Memcached反射攻击的放大倍数可以达到五万倍以上，是迄今为止最恐怖的UDP放大手段。但解决这个问题异常简单：Memcached服务根本不应该监听在公网IP上。它的设计场景是内网缓存，默认绑定127.0.0.1或内网地址。如果你发现自己的公网IP开放了11211端口，这本身就是一起严重的安全配置事故。立即检查所有云主机、物理服务器的Memcached配置，将监听地址改为内网IP或127.0.0.1，同时在安全组或iptables中显式封禁入向UDP 11211。对于上游运营商来说，在骨干网上对目的端口11211的UDP流量做整体限速或丢弃，是遏制此类攻击的有效手段，很多ISP已经在这样做。

这三个端口有一个共同特点：它们都属于内网服务发现或目录访问协议，正常情况下根本不应该出现在公网流量中。CLDAP是微软活动目录的轻量目录访问协议的无连接版本，SSDP是UPnP设备发现协议，WS-Discovery是Web服务动态发现协议。如果你的网络边界收到了大量以这些端口为目的的入向UDP流量，说明攻击者在利用互联网上大量暴露这些端口的设备进行反射。防守策略很明确：在边界防火墙上直接丢弃所有目的端口为389（UDP）、1900（UDP）、3702（UDP）的入向流量，这不会影响任何正常公网业务。同时，如果你内部网络中有设备向外发送这些协议的请求，检查是否存在被入侵后作为反射源的肉鸡。

当攻击流量超过你的接入带宽时，在本地设备上封禁端口已经没有意义，因为链路已经被塞满。这时候需要借助上游运营商或云服务商的清洗能力。BGP FlowSpec是一种有效的信令协议，你可以向上游宣告针对特定UDP端口、包长度、源IP段的丢弃规则，让清洗中心在流量进入你的链路之前就完成过滤。具体操作时，FlowSpec规则可以精确匹配UDP目的端口等于11211且包长度大于特定值的流量，然后执行丢弃或限速动作。如果没有部署FlowSpec，退而求其次的方案是RTBH（远程触发黑洞路由），将攻击目标IP的流量在上游全部丢弃，但这会连正常流量一起牺牲，属于断臂求生。更精细的做法是结合sFlow或NetFlow采样数据，动态识别出攻击流量的特征后，自动生成临时ACL或FlowSpec规则推送到边界设备，实现自动化清洗闭环。

UDP是无状态协议，但现代状态防火墙可以通过伪状态机制跟踪UDP会话。防火墙会记录内网主机发出的UDP请求的五元组信息，并只允许对应的响应包通过，超时未收到响应的会话条目会被清除。这个机制天然防御了绝大部分UDP反射攻击，因为反射攻击的响应包是“未经请求”的，在防火墙的状态表中找不到对应的会话，直接就会被丢弃。问题在于，当攻击流量巨大时，防火墙的状态表可能被撑满，导致正常会话也无法建立。因此需要配合速率限制：对入向UDP流量按目的IP和端口进行限速，超出阈值的包直接丢弃而不进行状态检查。例如，对目的端口53的入向UDP，限制单目的IP每秒不超过一定数量的包，这个阈值根据业务实际DNS查询量来设定，一般几千到几万pps对于单一服务器已经足够。

如果你的业务只面向特定国家或地区的用户，那么基于GeoIP的端口封禁是非常有效的降噪手段。大量的UDP反射攻击源分布在特定的网络环境中，通过分析攻击流量的源IP地理位置，你会发现某些地区的源IP占比异常高。在边界ACL或防火墙策略中，对这些地区的入向UDP流量做整体限制或丢弃，可以瞬间砍掉大部分攻击流量。这个策略的关键在于GeoIP数据库的准确性和更新频率，以及你对业务覆盖范围的清晰认知。误封一个地区的正常用户可能带来商业损失，所以这个策略更适合作为辅助手段，在攻击发生时临时启用，而不是作为常驻规则。

网络边界的防护可能因为各种原因被绕过或失效，服务器自身的iptables规则是最后兜底。对于Linux服务器，可以使用raw表的PREROUTING链在连接跟踪之前就丢弃明显的攻击流量，减少状态表的消耗。具体的规则示例：

# 丢弃所有入向UDP 11211端口的包
iptables -t raw -A PREROUTING -p udp --dport 11211 -j DROP

# 限制入向UDP 53端口的速率，每秒最多1000个包，突发2000个
iptables -A INPUT -p udp --dport 53 -m limit --limit 1000/sec --limit-burst 2000 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j DROP

# 只允许来自指定上游DNS服务器的53端口响应
iptables -A INPUT -p udp --sport 53 -s 8.8.8.8 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -s 1.1.1.1 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j DROP

这些规则的精妙之处在于分层处理：raw表在连接跟踪前直接拦截已知的恶意端口，limit模块对DNS等必要端口做速率控制，源IP白名单确保只有可信的上游服务器响应能被接收。需要注意的是，iptables规则顺序至关重要，要把命中率最高、开销最小的规则放在前面。

在云平台上，安全组是有状态防火墙，网络ACL是无状态防火墙，两者配合使用效果更好。安全组默认拒绝所有入向流量，只放行必要的端口，这是最基本的配置。但针对UDP反射攻击，安全组的问题在于它是有状态的，如果攻击流量命中了安全组允许的端口，流量还是会进入实例，消耗带宽和CPU。网络ACL作为子网级别的无状态过滤，可以在流量到达安全组之前就拦截掉。建议在网络ACL中显式拒绝那些绝对不应该出现在业务中的UDP端口，比如11211、389、1900、3702、17、19、520等。对于53端口，如果子网内没有DNS服务器，同样应该在网络ACL中拒绝入向UDP 53。这种分层过滤能大幅减少到达实例的恶意流量。

任何静态的端口封禁策略都会随着时间推移而失效，因为攻击者会不断寻找新的反射源和利用方式。必须建立持续的流量监控机制，通过NetFlow、sFlow或IPFIX采集网络流量数据，分析UDP流量的端口分布、包大小分布、源IP集中度等指标。当发现某个之前不常见的UDP端口突然出现流量激增时，要能快速识别并生成封禁策略。建议将常见的反射攻击端口维护成一个动态更新的威胁情报列表，通过自动化脚本定期同步到边界设备的ACL或防火墙规则中。同时，定期对公网IP进行端口扫描，检查是否有意外的UDP服务暴露，很多安全事件都源于运维人员临时开放端口后忘记关闭。

UDP反射攻击的端口封禁，本质上是一场不对称对抗。攻击者只需要找到几个反射源就能发起攻击，而防守方必须堵住所有可能的漏洞。但正因为反射攻击依赖特定的协议和端口，只要把这些关键节点掐住，攻击效果就会大打折扣。核心思路始终是：区分哪些端口必须开放、哪些可以完全关闭、哪些需要限速和校验，然后分层部署策略，从上游FlowSpec到边界ACL再到服务器iptables，形成纵深防御。