--hashlimit-upto在UDP反射攻击中失效，因其默认按conntrack连接限速，而CLDAP/Memcached攻击为伪造源IP的无连接单包UDP流量，不进入conntrack表；须改用--hashlimit-mode srcip、--hashlimit-srcmask 32/128，并禁用conntrack依赖。
为什么 --hashlimit-upto 在 UDP 反射攻击中经常失效
因为 --hashlimit-upto 默认按「连接」（conntrack 状态）限速，而 CLDAP（端口 389）和 Memcached（端口 11211）反射攻击全是伪造源 IP 的单包 UDP 请求，不建连接、不进 conntrack 表——规则根本匹配不到流量。
实操建议：
- 必须显式指定
--hashlimit-mode srcip，强制按源 IP 哈希（否则默认可能用 dstip 或更不可控的 key） - 加上
--hashlimit-srcmask 32（IPv4）或--hashlimit-srcmask 128（IPv6），避免 CIDR 合并导致漏限 - 禁用 conntrack 依赖：
--hashlimit-htable-expire 60000（毫秒），防止哈希表项长期滞留
针对 CLDAP 放大攻击的最小有效 iptables 规则
CLDAP 查询包极小（~100B），响应可达数 MB，攻击者常发 LDAPSearchRequest 到开放的 389/udp 服务。重点不是拦住所有请求，而是压住单 IP 每秒请求数。
推荐规则：
iptables -A INPUT -p udp --dport 389 -m hashlimit \ --hashlimit-above 5/sec \ --hashlimit-burst 10 \ --hashlimit-mode srcip \ --hashlimit-srcmask 32 \ --hashlimit-name cldap-flood \ -j DROP
说明：
-
--hashlimit-above 5/sec：单 IP 超过 5 包/秒即触发限速（实际生产可调至 1–2/sec） -
--hashlimit-burst 10：允许短时突发，避免误伤合法扫描或重试 -
--hashlimit-name cldap-flood：命名哈希表，便于排查（cat /proc/net/ipt_hashlimit/cldap-flood）
Memcached 攻击需额外处理 UDP 分片和短连接特征
Memcached UDP 协议本身无会话概念，且攻击包常被分片（尤其 >1500B 的 get 请求），而 iptables 默认在 NF_INET_PRE_ROUTING 钩子点处理，此时分片尚未重组——--hashlimit 可能对同一攻击流的不同分片重复计数或漏计。
应对方式：
- 优先在
raw表中早于分片重组处限速：iptables -t raw -A PREROUTING -p udp --dport 11211 ... - 若已启用
nf_conntrack_ipv4(fragment)，确认内核参数net.ipv4.ipfrag_high_thresh不过低，否则碎片队列丢包会导致哈希统计失真 - 避免用
--hashlimit-htable-size设过大值（如 65536），UDP 源 IP 随机性强，哈希冲突高，反而降低限速精度
验证规则是否生效的关键检查点
光加规则不等于防御到位，以下三点漏掉任一都可能让规则形同虚设：
- 确认
xt_hashlimit模块已加载：lsmod | grep hashlimit，未加载则modprobe xt_hashlimit - 检查规则插入位置：必须在
ACCEPT相关规则之前（如-A INPUT -p udp --dport 389 -j ACCEPT若在限速规则后，攻击包直接放行） - 监控哈希表水位：
watch -n1 'cat /proc/net/ipt_hashlimit/cldap-flood 2>/dev/null | wc -l'，持续 >1000 行说明攻击源过多或--hashlimit-htable-size设置不足
真实环境中，源 IP 伪造程度高，单一哈希限速只能缓解，不能根除；配合关闭公网 UDP 端口、禁用 Memcached 的 UDP 接口、或用 DDoS 清洗设备做首层过滤，才构成完整防线。
