iptables 的 -m string 和 -m u32 仅适用于明文、单包、未分片、无加密流量中的固定字节模式识别，无法处理 tls 加密、分片、压缩或编码流量，不能替代专业 dpi 或应用层网关。

iptables 可以通过 -m string 和 -m u32 两类模块匹配报文载荷中的十六进制特征码，但适用场景和能力边界必须明确：它仅适用于明文、单包、未分片、无加密的流量中固定字节模式的粗粒度识别，不能替代专业 DPI 或应用层网关。

用 --hex-string 匹配明文十六进制特征

当恶意 payload 以明文形式出现在 TCP/UDP 载荷头部（如 HTTP GET 参数、DNS 查询名、FTP 命令）且未被分片时，可用 --hex-string 直接定位十六进制字节序列：

• 语法格式：iptables -A INPUT -p tcp --dport 80 -m string --algo bm --hex-string "|DE AD BE EF|" -j DROP
• | 是十六进制分隔符，支持空格或连续书写（如 |deadbeef|）
• --algo bm 表示使用 Boyer-Moore 算法，性能优于默认的 KMP；部分内核也支持 --icase 忽略大小写
• 注意：该规则对每个数据包独立扫描载荷，若特征码跨两个 TCP 分段（如 DEAD 在第一个包末尾、BEEF 在第二个包开头），则完全无法匹配

用 -m u32 精确定位协议字段中的十六进制值

当需匹配 IP/TCP 头部或固定偏移处的原始字节（如 DNS 响应中的污染 IP、TCP 选项字段中的异常标志），-m u32 更可靠：

• 语法示例：iptables -A INPUT -p udp --dport 53 -m u32 --u32 "20 & 0xFFFFFFFF = 0xC0A80101" -j DROP（匹配 DNS 响应中第 20 字节起的 4 字节等于 192.168.1.1）
• 20 表示从 IP 头起始向后偏移 20 字节（即 UDP 数据起始位置），需结合协议结构手动计算偏移
• 支持掩码运算（如 & 0xFF 提取单字节）、多条件组合（用 && 连接），适合识别 GFW DNS 污染包等格式固定的攻击特征
• 不依赖字符串算法，无跨包问题，但要求特征位于固定位置且未被加密或压缩

关键限制与避坑提醒

以下情况 iptables 无法生效，强行配置会导致策略失效：

• TLS/HTTPS 流量：应用层内容全程加密，--string 只能扫描密文随机字节，无法命中明文关键词（如 "admin"、"password"）
• 分片 IP 包或 TCP 重组流：iptables 工作在 netfilter 钩子，处理的是单个 IP 数据包；若恶意特征被拆到多个分片中，仅首片可能被匹配
• HTTP 压缩（gzip）、URL 编码（%3Cscript%3E）、Base64 编码等：原始字节已变形，预设的十六进制特征不再存在
• 非标准端口或动态端口协商（如 FTP 被动模式、SIP）：规则绑定固定端口（如 --dport 80）会漏掉真实攻击流量

更可行的替代路径

若目标是检测真实恶意 payload，建议分层部署：

• 前置透明代理：用 Squid 或 Nginx 拦截 HTTP 流量，解压、解码、解析 URI/Body 后再做关键词或正则匹配
• DNS 层过滤：用 dnsmasq 或 CoreDNS 基于域名黑名单拦截，比解析响应包更稳定
• eBPF/XDP 加速检测：在内核态实现轻量级协议解析（如 HTTP method + path 提取），避免用户态转发开销
• 专用 DPI 引擎：集成 nDPI 或 Zeek 规则，识别协议行为异常（如 HTTP User-Agent 非法字符、TLS SNI 与 ALPN 不匹配）