iptables可通过--hex-string匹配单包TCP载荷中固定十六进制特征，适用于明文、未加密且不跨包的攻击载荷（如HTTP漏洞利用、shellcode片段），但无法处理TLS加密、分片跨越或编码绕过，性能开销大，生产环境宜结合代理或DPI工具。
iptables 可以通过 --hex-string 匹配 TCP 数据包载荷中固定的十六进制特征，适用于已知明文攻击载荷（如 HTTP 漏洞利用、shellcode 片段、命令注入），但仅限单包内、未加密、不跨分片的场景。它不是万能防御手段，而是轻量级辅助过滤方式。
确认系统支持 string 和 hex-string 模块
执行以下命令验证模块是否可用：
-
iptables -m string --help—— 查看是否显示--hex-string和--algo选项 -
lsmod | grep xt_string—— 确认内核已加载xt_string模块 - 若无输出，需加载：
modprobe xt_string - 要求内核 ≥ 2.6.14，iptables ≥ 1.3.5；生产环境建议使用较新稳定版（如 iptables 1.8.x）
用 --hex-string 匹配典型攻击特征
适用于已知二进制模式的攻击载荷，例如某漏洞利用中固定开头的 shellcode 或混淆指令序列：
- 匹配 x64 清零指令
0x48 0x31 0xc0：iptables -A INPUT -p tcp --dport 80 -m string --algo bm --hex-string "|48 31 c0|" -j DROP - 匹配常见 WebShell 特征
0x70 0x68 0x70 0x20 0x65 0x76 0x61 0x6c（即 "php eval"）：iptables -A INPUT -p tcp --dport 80 -m string --algo bm --from 0 --to 512 --hex-string "|70 68 70 20 65 76 61 6c|" --icase -j DROP -
--algo bm更适合短模式，--algo kmp对长或含重复字节的模式更稳健 -
--from和--to必须设置，避免全包扫描拖慢性能；HTTP 请求头通常在前 512 字节内
用 -m u32 精确匹配固定偏移处的字节
当攻击特征位于 payload 固定位置（如协议头后第 4 字节恒为 0xff），u32 比字符串匹配更高效、更确定：
- 匹配 TCP payload 第一个字节为
0xff（跳过 IP 头 20 字节 + TCP 头最小 20 字节）：iptables -A INPUT -p tcp --dport 23 -m u32 --u32 "40 & 0xFF = 0xFF" -j DROP - 匹配 payload 偏移 20 处的双字节值
0x1234，且偏移 24 处字节为0x56：iptables -A INPUT -p tcp --dport 80 -m u32 --u32 "20 & 0xFFFF = 0x1234 && 24 & 0xFF = 0x56" -j DROP - TCP 头长度可变（含选项时 >20 字节），实际部署需估算最大头长（如设为 40 或 60），或配合
--tcp-option判断
关键限制与实用提醒
直接靠十六进制匹配防御攻击存在明显盲区，不可高估其能力：
- HTTPS 流量中所有应用层内容被 TLS 加密 → payload 是密文 →
--hex-string无法识别正文，仅可能碰巧匹配 ClientHello 中的 SNI（不稳定且易绕过） - HTTP 请求被 TCP 分片时，特征可能跨两个包 → iptables 单包匹配失效
- Base64、URL 编码、大小写混用、空格插入等简单混淆即可绕过
--string或--hex-string - 规则顺序很重要：必须放在通用 ACCEPT 规则之前，否则会被跳过
- 生产环境建议仅作临时缓解或日志审计（如
-j LOG），核心防护应交由反向代理、WAF 或 DPI 设备处理
