iptables 的 string 模块仅能对明文协议单包载荷做简单字符串匹配，无法可靠防止敏感数据泄露；它受限于未加密、不分片、小包等严苛条件，且不适用于 https 等加密流量。
iptables 可以通过 string 模块对报文载荷中的明文字符串做简单匹配，从而在特定条件下拦截含敏感词的流量，但**它不是内容审计工具，不能可靠防止敏感数据泄露**。它的作用非常有限，仅适用于未加密、未分片、结构简单的 HTTP/FTP 等明文协议，且必须满足严格前提。
前提条件：确认系统支持并适用场景
使用前必须验证两点：
- 内核已启用
CONFIG_NETFILTER_XT_MATCH_STRING：运行iptables -m string --help，不报错才表示可用；精简系统（如某些容器镜像、嵌入式设备）常缺失该模块 - 目标流量必须是明文且完整落在单个 IP 包内：仅限 HTTP（80）、FTP（21）、SMTP（25）等未加密协议；HTTPS（443）、TLS 加密流量正文完全不可见，SNI 域名匹配也不稳定，不推荐依赖
基本用法：构建一条有效规则
以拦截 HTTP 请求中出现 credit_card= 为例（假设服务监听 80 端口）：
iptables -A INPUT -p tcp --dport 80 -m string --algo bm --from 0 --to 512 --string "credit_card=" --icase -j DROP-
--algo bm：选用 Boyer-Moore 算法，效率高，适合固定 ASCII 字符串 -
--from 0 --to 512：限定只扫描前 512 字节，覆盖 HTTP 请求行和头部，避免误匹配和性能损耗 -
--icase：忽略大小写，提升覆盖度（注意旧内核可能不支持） - 规则必须放在通用 ACCEPT 规则之前，否则会被跳过
关键限制与常见失效原因
以下情况会让规则完全失效，需特别警惕：
- TCP 分片或大请求被拆成多个包：关键词被截断在两个包之间，
string模块无法跨包重组 - 内容经过 URL 编码（如
password%3D123）或 gzip 压缩：原始关键词不存在于明文载荷中 - 使用非标准端口（如 8000、8080）却未同步修改
--dport - 规则加在 OUTPUT 链试图拦截本机发出的敏感数据：需确保应用未缓冲或延迟发送，且数据确实以明文形式发出
- 开启连接跟踪后性能下降明显，高并发下影响吞吐量
真正可行的替代方案
若目标是防止敏感数据泄露，应放弃 iptables 单点过滤思路，改用分层专业手段：
- 应用层：在 Web 应用中做参数校验与脱敏（如 Spring 拦截器、Django 中间件），从源头控制输出
- 代理层：部署透明代理（如 Squid、Nginx + Lua）或 WAF（ModSecurity），可解析 HTTP 结构、解压、URL 解码后再匹配
- 网络层：引入 DPI（深度包检测）设备或 eBPF 工具（如 Cilium、bpftrace），支持流级上下文分析和 TLS 解密（需配合证书）
- 终端侧：对数据库客户端、日志采集器等工具配置字段级脱敏策略，而非依赖网络层拦截
