iptables --string模块无法可靠过滤恶意HTTP请求，因其仅做单包载荷字节匹配，不重组TCP流、不解析协议结构、不处理编码压缩、无法定位HTTP字段，仅适用于极简明文内网环境；生产环境应使用透明代理、WAF或eBPF等应用层检测方案。
iptables 的 --string 模块不能可靠过滤包含恶意脚本特征的 HTTP 请求。这不是配置技巧问题，而是底层能力限制——它压根不理解 HTTP 协议结构。
iptables --string 为什么匹配不了真实的 HTTP 请求
- 它只扫描单个 IP 数据包的原始载荷（payload），不重组 TCP 流：一个典型的 HTTP GET 或 POST 请求经常被拆成多个 TCP 分段，关键词（如
"<script>"</script>、"eval("）可能横跨两个包，--string对后者完全不可见 - 它不跳过 TCP/IP 头部或 TLS 记录头：HTTP 明文在 TCP 载荷偏移处开始，但
--string默认从载荷起始位置硬扫，无法动态定位 HTTP body 或 header 区域 - 它不识别 URL 编码、gzip 压缩、分块传输（chunked encoding）：比如
"%3Cscript%3E"或压缩后的二进制流，--string扫不到原文本 - 它不区分 HTTP 方法、Header、Body：无法限定只在
POST body中匹配，也无法跳过User-Agent等干扰字段
常见失效写法示例：
iptables -A INPUT -p tcp --dport 80 -m string --string "<script>" --algo bm -j DROP这条规则在真实流量中几乎必然漏掉攻击——只要请求被分片、用了 gzip、或路径含编码，就匹配失败。
如果坚持用 iptables，哪些场景下 --string 可能“凑合用”
仅适用于极简、可控、无优化的明文 HTTP 环境（例如内网测试服务，无压缩、无分块、无代理、短请求）：
请求体极小（< 1500 字节），确保整个 payload 落在单个以太网帧内
Web 服务禁用所有压缩（
gzip、br）、禁用Transfer-Encoding: chunked-
使用
--from和--to手动指定偏移（需预估 HTTP header 长度），例如：iptables -A INPUT -p tcp --dport 80 -m string --from 200 --to 1000 --string "javascript:" --algo bm -j DROP
但 header 长度随Cookie、Referer动态变化，该偏移极易错位 -
必须搭配连接状态模块，否则会误杀响应包：
-m state --state ESTABLISHED,RELATED
或更现代的-m conntrack --ctstate ESTABLISHED,RELATED
真正能拦截恶意脚本特征的替代路径
-
透明代理层检测：用
Squid或nginx（开启http_sub_module或配合 Lua）解析完整 HTTP 请求，检查Content-Type、body、query string，再通过return 403或重定向丢弃 -
应用网关前置：部署
HAProxy+PCRE规则，支持正则、大小写忽略、UTF-8 解码后匹配 -
eBPF 深度检测：用
libpcap或bpfilter在内核态做 TCP 流重组 + 应用层解析，但开发成本高，非通用方案 -
WAF 专用工具：如
ModSecurity（Apache/Nginx 模块）或开源OpenResty + lua-resty-waf，这才是为 HTTP 攻击特征设计的
关键点在于：协议解析和特征匹配必须发生在应用层上下文里，而不是靠 netfilter 对裸包做字节扫描。
实际生产环境里，看到有人在公网服务器上靠 iptables --string 拦 XSS 或 JS 注入，基本等于没拦。真正要防，得把流量先引到能读懂 HTTP 的地方。
