iptables可对TCP/UDP载荷做单包十六进制匹配，仅适用于明文、未加密且特征完整落于单包内的场景；它不解密TLS、不重组TCP流、不解析协议，需结合端口、偏移和模块支持（xt_string）使用，生产环境应由WAF或DPI替代。
iptables 可以对 TCP 或 UDP 数据包的载荷做简单十六进制匹配，但仅限于明文、未加密、且特征完整落在单个数据包内的场景。它不是入侵检测系统，不能解密 TLS、不重组 TCP 流、也不理解应用层协议。真正有效的过滤需结合上下文判断，比如端口、协议类型和偏移位置。
确认环境支持 hex-string 和 string 模块
执行以下命令检查是否可用：
- iptables -m string --help | grep hex-string —— 若输出含 --hex-string，说明模块就绪
- lsmod | grep xt_string —— 应显示 xt_string（内核模块已加载）
- 若无输出，需加载：modprobe xt_string
用 --hex-string 匹配明文攻击载荷
适用于 HTTP 请求、DNS 查询、Telnet 命令等未加密流量中固定出现的二进制特征。例如某 WebShell 利用中常见 shellcode 开头：
- iptables -A INPUT -p tcp --dport 80 -m string --algo bm --hex-string "|48 31 c0 48 89 c7|" -j DROP
-
|48 31 c0| 对应 x86_64 中
xor rax,rax指令，常出现在漏洞利用起始处 - --algo bm 适合短模式；若模式较长或需避免误判，改用 --algo kmp
- 如特征不在包开头，加 --from 40 --to 1400 限定 payload 扫描范围，减少性能损耗
用 -m u32 精准定位固定偏移字节
比字符串匹配更轻量、更可靠，适合协议字段级控制。例如 DNS 响应中伪造 IP 出现在固定位置：
- DNS 响应中，Answer Section 的第一个 IP 地址通常从 payload 第 40 字节起（IP 头20 + TCP 头最小20）
- iptables -A INPUT -p udp --dport 53 -m u32 --u32 "40 & 0xFFFFFFFF = 0xc0000101" -j DROP —— 匹配返回 192.0.1.1 的污染响应
- 支持多条件组合："40 & 0xFF = 0xc0 && 41 & 0xFF = 0x00" 表示连续两个字节为
c0 00 - TCP 头可能含选项（>20 字节），此时可估算最大头长（如 60 字节），改用 "60 & 0xFF = 0xff"
关键限制与实用建议
直接靠十六进制匹配防御漏洞利用，存在明显盲区，部署前必须清楚：
- HTTP 分块传输或大请求体易导致特征跨包 → iptables 单包扫描无法捕获
- TLS/HTTPS 流量 payload 全加密 → hex-string 只能匹配 ClientHello 中 SNI（需精确定位偏移，且受 ESNI/ALPN 干扰）
- Base64 编码、URL 编码、大小写混用等绕过手段会使明文特征失效
- 生产环境建议：将此类规则作为临时缓解措施，长期应交由反向代理（Nginx/Envoy）、WAF 或 DPI 设备处理
