iptables可通过--hex-string匹配单包tcp载荷中的十六进制特征，适用于明文、未加密且不跨包的攻击载荷，但无法处理tls加密、分片跨越或编码绕过，性能开销大，生产环境宜结合代理或dpi工具。

iptables 可以对 TCP 报文载荷中的十六进制字符串做简单匹配，但必须明确：它只在单个数据包的原始 payload 层进行线性扫描，不解析协议、不解密 TLS、不重组 TCP 流。因此，它适合过滤已知明文特征、未加密、且能落在单包内的攻击载荷（如某些 HTTP 漏洞利用、恶意 shellcode 片段、明文命令注入），但不能替代专业 DPI 或代理网关。

确认系统支持并加载必要模块

确保内核和 iptables 满足最低要求：

• 内核 ≥ 2.6.14，且编译时启用 CONFIG_NETFILTER_XT_MATCH_STRING=m（或 =y）
• iptables ≥ 1.3.5，并安装了 string 和 u32 模块（可通过 iptables -m string --help 验证）
• 若需 hex-string 匹配，确认帮助中显示 --hex-string 选项可用

使用 --hex-string 匹配固定十六进制模式

适用于已知二进制特征的攻击载荷，例如某漏洞利用中固定的 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| 表示字节 0x48 0x31 0x c0（常见 x64 清零指令）
• --algo bm 推荐用于短模式，性能较好；--algo kmp 更适合长模式或需避免误判场景
• 注意：该匹配从 payload 起始（默认 offset=0）开始搜索，若特征不在前段，可加 --from 20 --to 1500 限定范围，减少开销

用 -m u32 精确匹配报文偏移处的字节值

当攻击特征位于 TCP payload 固定偏移（如某协议头后第 4 字节恒为 0xff），比字符串匹配更轻量、更确定：

• 语法：iptables -A INPUT -p tcp --dport 23 -m u32 --u32 "20 & 0xFF = 0xFF"
• "20 & 0xFF = 0xFF" 表示跳过 IP 头（通常20字节）+ TCP 头（最小20字节），即 payload 第 0 字节，检查其是否等于 0xFF
• 若 TCP 头含选项，长度可能 >20，此时需估算最大头长（如 "40 & 0xFF = 0xFF"），或结合 --tcp-option 判断
• 支持组合条件，如 "20 & 0xFFFF = 0x1234 && 24 & 0xFF = 0x56"，匹配连续多字节

关键限制与规避建议

直接依赖十六进制匹配防御攻击存在明显盲区，部署前必须评估：

• HTTP 请求被分片时，特征字符串可能跨两个 TCP 包 → iptables 无法匹配 → 规则失效
• TLS 流量中所有应用层内容加密 → payload 是密文 → 十六进制匹配仅能针对 ClientHello 中的 SNI（需定位到特定偏移，且易受 ALPN/ESNI 干扰）
• 攻击者可编码绕过：URL 编码、Base64、大小写混用、插入空字节等 → 简单 hex-string 无效
• 开启 -m string 会禁用 conntrack 快速路径，高并发下显著降低吞吐 → 生产环境慎用
• 更可靠做法：用 -j REDIRECT 将流量导入透明代理（如 Squid、Nginx）或专用 DPI 工具（如 Suricata），由其完成协议解析与深度检测