有效，但需正确配置hashlimit：按srcip限速、禁用conntrack、增大htable-size至8192，并将规则置于INPUT链靠前位置；否则易因哈希碰撞或状态干扰而失效。
UDP 53/123/1900 放大攻击的 iptables 防御是否还有效？
在当前主流反射放大攻击（如 DNS、NTP、SSDP）场景下，单纯靠 iptables -m limit 做速率限制基本无效——它不区分源 IP，容易被多个伪造源绕过；而 hashlimit 是唯一可行的轻量级内核级方案，但必须配对使用 --hashlimit-mode srcip 和合理桶宽，否则规则形同虚设。
针对 UDP 53/123/1900 的 hashlimit 规则怎么写才不被绕过？
关键不是“限多少”，而是“按什么维度限”和“桶怎么建”。DNS（53）、NTP（123）、SSDP（1900）都依赖 UDP 请求触发响应，攻击者常伪造海量不同源 IP 发送单包请求。因此必须按源 IP 哈希限速，并禁用连接跟踪（ctstate INVALID,NEW 不适用 UDP），直接匹配四层特征：
-A INPUT -p udp --dport 53 -m hashlimit --hashlimit-above 10/sec --hashlimit-burst 20 --hashlimit-mode srcip --hashlimit-name dns_limit -j DROP-A INPUT -p udp --dport 123 -m hashlimit --hashlimit-above 5/sec --hashlimit-burst 10 --hashlimit-mode srcip --hashlimit-name ntp_limit -j DROP-A INPUT -p udp --dport 1900 -m hashlimit --hashlimit-above 3/sec --hashlimit-burst 6 --hashlimit-mode srcip --hashlimit-name ssdp_limit -j DROP
注意：--hashlimit-burst 必须略高于 --hashlimit-above，否则首包即丢；--hashlimit-name 必须全局唯一，否则规则冲突；所有规则应插入 INPUT 链靠前位置（建议在 ESTABLISHED,RELATED 规则之后、其他服务规则之前）。
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
为什么加了 hashlimit 还是被打爆？常见配置陷阱
现象：规则生效，iptables -L -v 显示 DROP 计数上涨，但服务器负载仍飙升、网卡收包率超限。根本原因往往不在规则本身，而在内核哈希表容量或匹配粒度：
- 默认
hashlimit的哈希桶大小太小（通常仅 1024），高并发源 IP 下哈希碰撞严重，多个 IP 被映射到同一桶，导致误放行或误限流；需显式加大：--hashlimit-htable-size 8192 - 未禁用 conntrack 对 UDP 的干扰：某些内核版本中，若
nf_conntrack_udp_timeout过长，会导致伪造包被错误归入 “ESTABLISHED” 状态而绕过INPUT链；建议临时关闭：echo 0 > /proc/sys/net/netfilter/nf_conntrack_udp_be_liberal - 规则放在
FORWARD链而非INPUT链——这些端口是本机监听的，攻击流量终点是本机，必须在INPUT处理
要不要加 state 检查？UDP 场景下完全没必要
iptables -m state --state NEW 或 -m conntrack --ctstate NEW 对纯 UDP 反射攻击无效，因为攻击包本身是“无状态”的单向请求，且 conntrack 在高洪流下自身就是性能瓶颈。强行启用只会增加 CPU 开销、降低吞吐、甚至引发哈希表锁争用。所有规则应直击 -p udp --dport X，跳过任何 connection tracking 判断。
真正要盯住的是 /proc/net/nf_conntrack 行数（别让它超 65536）和 hashlimit 的 htable-expire 行为——默认 60 秒不活跃条目自动清理，这个时间足够覆盖正常扫描间隙，也避免哈希表无限膨胀。
