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