如何在Linux系统中通过Iptables-T-Raw命令巧妙绕过连接跟踪机制以应对超大规模网络攻击？

本文共计809个文字，预计阅读时间需要4分钟。

conntrack在数据包进入协议栈后、路由决策前触发展开，而raw的PREROUTING和OUTPUT链是唯一能在conntrack初始化前介入的位置。其他表（如filter/INPUT）生效时，conntrack已完成状态创建，NOTRACK失效。

• filter 表的 INPUT 链：conntrack 状态已建立，-m conntrack --ctstate INVALID 只能丢弃，无法跳过跟踪
• nat 表的 PREROUTING：DNAT 会强制触发 conntrack，哪怕你之前在 filter 里写了 ACCEPT
• 只有 raw 表的 PREROUTING 链 + -j NOTRACK 才真正“早于”连接跟踪逻辑

-j NOTRACK 的匹配条件和典型用法

它不改变数据包内容，只打上 UNTRACKED 标记，后续所有表（包括 filter）都会跳过该连接的状态检查。常用于以下三类流量：

• ICMP 扫描包（如 ping 洪水）：iptables -t raw -A PREROUTING -p icmp -j NOTRACK
• UDP 短连接洪泛（如 DNS 反射攻击源）：iptables -t raw -A PREROUTING -p udp --dport 53 -j NOTRACK
• 已知恶意 IP 段的全部入向流量：iptables -t raw -A PREROUTING -s 192.0.2.0/24 -j NOTRACK

注意：NOTRACK 后仍需在 filter 表中显式 DROP 或 ACCEPT，否则默认策略会接管——它只是跳过状态跟踪，不等于放行。

容易踩的坑：NOTRACK 不等于 DROP，也不兼容 DNAT/SNAT

一旦标记为 UNTRACKED，该数据包将彻底脱离 netfilter 的状态机，带来几个硬性限制：

• nat 表规则对 NOTRACK 流量完全无效：不能做 DNAT、SNAT、端口转发
• filter 表中依赖 -m conntrack 的规则（如 --ctstate ESTABLISHED）对其不生效
• 若你同时用了 NOTRACK 和 iptables -t nat -A PREROUTING -d $VIP -j DNAT，后者会被静默忽略
• NOTRACK 无法撤销：标记后不可恢复为 tracked，只能靠规则顺序控制作用范围

性能影响与部署建议

raw 表规则本身开销极低，但滥用会导致运维盲区：比如你对整个 /24 段 NOTRACK，后续就无法用 conntrack -L | grep 查看其连接状态，监控和排障变困难。

• 优先按协议+端口窄匹配，避免 -p tcp -j NOTRACK 这种宽泛写法
• 配合 -m limit 控制日志量：iptables -t raw -A PREROUTING -p icmp -m limit --limit 1/sec -j LOG --log-prefix "RAW-ICMP: "
• 生产环境上线前，务必用 conntrack -S 观察 entries 和 max 值变化，确认 conntrack 表压力下降
• NOTRACK 规则必须放在 raw 表最前面（-I PREROUTING 1），否则可能被其他规则提前处理掉

真正关键的不是加多少条 NOTRACK，而是确保它只覆盖你明确不想进 conntrack 的那部分流量——漏掉会压垮连接表，多加会失去状态可见性。