iptables --string 模块仅支持单包明文固定字符串匹配，适用于HTTP头、未加密协议命令等简单场景，无法处理HTTPS、压缩、分片或URL编码流量，真正应用层防护需用WAF、DPI或透明代理。
iptables 的 --string 模块只能在单个数据包的原始载荷中做字节级匹配，不能解析协议、不解密 TLS、不重组 TCP 流，因此它无法可靠拦截“恶意应用层 payload”。所谓“教程”若承诺精准过滤 HTTP 参数、SQL 注入语句、FTP 凭据或 JSON 中的敏感字段，基本是误导——实际中极易漏判或误杀。
真正能起效的适用场景
仅限明文、结构简单、且完整落在单个 TCP 包前几百字节内的固定字符串：
- HTTP 明文请求头中的特征串（如
User-Agent: sqlmap、GET /phpmyadmin/） - 未加密的 SMTP/FTP 控制命令开头（如
USER admin、HELO evil.com，需确保未分片） - 自定义协议中位置固定的明文指令（如设备通信协议含
cmd=reset且始终出现在前 128 字节）
基础写法与关键参数说明
以拦截 HTTP 明文请求中含 passwd= 的 POST 请求为例（仅限端口 80）：
-
--algo bm：Boyer-Moore 算法，对 ASCII 固定串效率高；若关键词含重复字符（如aaaa），可换--algo kmp -
--from 0 --to 512：强制限定扫描范围，避免匹配到 TCP/IP 头部或后续加密数据，也降低性能损耗 -
--icase：忽略大小写，但依赖内核支持（≥ 4.10 推荐，旧版可能无效） - 规则必须放在
ACCEPT规则之前，否则被提前放行
为什么 HTTPS、压缩、分片会让它失效
以下情况该规则完全不工作：
- HTTPS 流量：TLS 加密后载荷是密文，
--string "admin"扫不到明文 - Gzip 压缩的 HTTP body：关键词被编码打散，不再以原始字节序列存在
- TCP 分段：一个 HTTP 请求被拆成两个包，
pass在包1末尾，wd=123在包2开头 → 单包内无完整匹配 - URL 编码：
password%3D123≠password=123，字符串不一致即不触发
比 iptables 更靠谱的替代方案
要真正识别和拦截恶意应用层内容，应交给专业工具分层处理：
- 透明代理：如 Squid + ICAP 或 Nginx + Lua，可解密 HTTP/HTTPS（需中间人证书）、解析 URI/body、执行逻辑判断
- DPI（深度包检测）：用 Suricata 或 Zeek（Bro），支持协议解析、正则匹配、会话重建、多包上下文分析
- eBPF/XDP 层检测：如 Cilium 或基于 eBPF 的自定义过滤器，可在内核高效提取并解析应用层字段
- Web 应用防火墙（WAF）：部署在反向代理层（如 ModSecurity），专为 HTTP 流量设计，规则成熟、维护方便
