iptables能拦截明文木马流量，前提是未加密、特征完整落于单包内；它不解析协议、不解密tls、不重组tcp流，仅是网络层初筛工具。需先验证string和u32模块支持，再结合--hex-string与--u32按偏移精准匹配，并避开tls、分片、编码等失效场景。
iptables 能拦截二进制木马流量，但前提是流量明文、未加密、特征完整落在单个数据包内。它不解析协议、不解密 TLS、不重组 TCP 流，本质是网络层轻量级初筛工具，不是 WAF 或 IDS。
确认系统支持再写规则
执行以下命令验证基础能力是否就绪：
- 运行 iptables -m string --help，确认输出中含 --hex-string 和 --algo 选项
- 运行 iptables -m u32 --help，检查是否支持 u32 模块
- 若提示“Unknown arg”，加载内核模块：modprobe xt_string && modprobe xt_u32
- 精简系统（如某些容器或嵌入式环境）可能默认未编译这些模块，需检查内核配置：zcat /proc/config.gz | grep -E "(STRING|U32)"
用 --hex-string 匹配明文载荷中的木马特征
适用于 HTTP、DNS 查询、Telnet 等未加密协议中嵌入的固定二进制指纹，例如 Cobalt Strike 的 User-Agent、Webshell 的 shellcode 片段、或 DNS 域名编码格式。
- 语法示例：iptables -A INPUT -p tcp --dport 80 -m string --algo bm --hex-string "|436F62616C74|" -j DROP（匹配 "Cobalt" ASCII 十六进制）
- |436F62616C74| 必须小写、无空格、用竖线包裹；DNS 域名要按协议编码写，如 "baidu.com" 写成 |05|baidu|03|com|00|，不能写明文
- 加 --from 40 --to 1024 限定扫描范围，跳过 IP/TCP 头部和响应体噪声，降低误匹配与性能损耗
- 短模式（≤32 字节）用 --algo bm（Boyer-Moore），速度快；长模式或需抗干扰时改用 --algo kmp
用 -m u32 精确定位协议结构中的恶意字节
比字符串匹配更高效、更稳定，适合识别位置固定的二进制特征，比如 DNS 污染响应中的伪造 IP、TCP 载荷起始处的 NOP 指令（0x90）、或自定义 C2 协议魔数。
- 偏移从 IP 头起算：TCP 最小头长 = 20（IP）+ 20（TCP）= 40 字节 → payload 第 0 字节对应偏移 40
- 匹配 payload 第 5 字节是否为 0x90：iptables -A INPUT -p tcp -m u32 --u32 "40 & 0xFF = 0x90" -j DROP
- DNS 污染常用：iptables -A INPUT -p udp --dport 53 -m u32 --u32 "40 & 0xFFFFFFFF = 0xc0000101" -j DROP（拦截返回 192.0.1.1 的响应）
- 支持组合条件，例如“SYN+ACK 标志且 payload 第 12 字节是 0x41”："20 & 0x3FFF0000 = 0x12000000 && 64 & 0xFF = 0x41"
绕过常见、必须规避的失效场景
很多规则上线后“看似生效却拦不住”，往往因为踩中了这几类典型陷阱：
- TLS/HTTPS 流量完全无效：所有应用层内容加密，--hex-string 只能偶然匹配 ClientHello 中的 SNI（位置浮动、易被 ESNI/ALPN 绕过），正文无法识别
- HTTP 分片或分块传输导致特征跨包：如 "<script>" 被拆在两个 TCP 段里，iptables 单包扫描必然漏掉</script>
- 编码与混淆使原始字节变形：URL 编码（%65%76%61%6C）、Base64、gzip 压缩、大小写混用都会让预设 hex 特征失效
- TCP 头含选项时长度 >20 字节：u32 固定偏移会错位，建议保守估算最大头长（如 60），或配合 --tcp-option 判断
