iptables仅能对明文、单包、未加密且特征位置固定的恶意载荷做轻量级拦截，非补丁替代品；需验证string/u32模块支持，合理使用--hex-string与--u32匹配，并规避TLS、分片、编码等失效场景。
iptables 可以在未打补丁的服务前加一道轻量级网络层防线，但只对明文、单包、未加密且特征位置固定的恶意载荷有效。它不是补丁替代品，而是争取响应时间的临时兜底手段。
确认系统支持再写规则
运行以下命令验证关键能力是否就绪：
-
iptables -m string --help：必须显示
--hex-string和--algo选项 - iptables -m u32 --help：应输出帮助信息，说明支持 32 位偏移匹配
-
lsmod | grep xt_string：若无输出，执行
modprobe xt_string
缺失模块常见于容器、精简云镜像或旧内核，需提前补全，否则规则直接不生效。
用 --hex-string 匹配明文载荷中的已知特征
适用于 HTTP、DNS、Telnet、未加密 MySQL/Redis 等协议中暴露的恶意字节序列：
- 匹配 Webshell 常见函数：
iptables -A INPUT -p tcp --dport 80 -m string --hex-string "|73797374656d|" --algo bm --from 40 --to 1024 -j DROP（对应 "system"） - DNS 域名必须按协议编码写：
|03|www|05|baidu|03|com|00|，不能写成明文 "www.baidu.com" - 短特征（≤32 字节）优先用
--algo bm；长特征或需抗误判时选--algo kmp
务必限定 --from 和 --to 范围（如 40–1024），避开 IP/TCP 头部和响应体噪声，否则性能下降且易误杀。
用 -m u32 精确定位固定偏移处的恶意指纹
比字符串匹配更高效、更稳定，适合结构化攻击流量：
- TCP 载荷首字节通常从 IP 头起算偏移 40 字节（IP 头 20 + TCP 头最小 20）
- 匹配 shellcode 常见 NOP 指令：
iptables -A INPUT -p tcp -m u32 --u32 "40 & 0xFF = 0x90" -j DROP - DNS 污染响应中伪造 IP 若固定出现在第 8 字节起：
"8 & 0xFFFFFFFF = 0x76053106"（对应 118.5.49.6）
TCP 头含选项时长度可能超 20 字节，保守起见可将偏移设为 60 或结合实际抓包校准。
必须绕开的失效场景
这些情况会让规则完全失效，部署前必须排除：
-
TLS/HTTPS 流量：所有应用层内容加密，
--hex-string只能偶然匹配 ClientHello 中的 SNI，正文无法识别 - 跨包载荷：HTTP POST 或大请求被 TCP 分片，“<script>”可能拆在两个包里，iptables 单包扫描必然漏掉</script>
- 编码与混淆：URL 编码（%3Cscript%3E）、Base64、gzip 压缩都会让原始特征不可见
-
头部长度浮动：TCP 选项导致头部 >20 字节，
--from 40可能错位，需估算最大头长或改用--u32组合判断
不复杂但容易忽略。真正有效的防护，仍需尽快打补丁、启用 WAF 或部署反向代理做应用层解析。
