iptables string模块可匹配HTTP等明文协议载荷中的固定SQL注入特征字符串，但无法解析语法、不支持正则、不能处理HTTPS加密流量，仅作辅助阻断或审计，需限定搜索范围、注意规则顺序并清楚其易被绕过等局限性。
iptables 的 string 模块可以匹配应用层明文载荷中的固定字符串，适用于 HTTP 等未加密协议中识别典型 SQL 注入特征（如 union select、1=1、sleep(、information_schema 等）。但它不能解析语法、不支持正则、也无法处理 HTTPS 加密流量。实际使用需严格限定范围、注意规则顺序，并清楚其局限性。
明确适用前提和限制
– 仅对明文协议有效：HTTP（80端口）、MySQL 协议（3306端口，但需注意 MySQL 包结构复杂，string 匹配易误判）；HTTPS（443）中除 Client Hello 的 SNI 域名外，正文完全不可见。
– 不是 SQL 注入的“防护主力”：无法替代参数化查询或 WAF，仅作辅助阻断或日志审计用途。
– 性能敏感：全包扫描耗 CPU，必须用 --from/--to 限定偏移范围，避免扫描整个 TCP payload。
– 大小写问题：SQL 关键字常大小写混用，建议统一加 --icase。
常用 SQL 特征字符串及推荐规则写法
以下规则均作用于 INPUT 链，假设 Web 服务监听在 80 端口：
iptables -A INPUT -p tcp --dport 80 -m string --algo bm --from 0 --to 512 --string "union select" --icase -j DROPiptables -A INPUT -p tcp --dport 80 -m string --algo bm --from 0 --to 512 --string "order by" --icase -j DROPiptables -A INPUT -p tcp --dport 80 -m string --algo bm --from 0 --to 512 --string "sleep(" --icase -j DROPiptables -A INPUT -p tcp --dport 80 -m string --algo bm --from 0 --to 512 --string "information_schema" --icase -j DROP-
iptables -A INPUT -p tcp --dport 80 -m string --algo bm --from 0 --to 512 --string "select.*from" --icase -j DROP（⚠️注意：string不支持.*，此写法无效；若需模糊匹配，应拆为多条，如"select"+"from"，或改用xt_string配合其他模块，但不推荐）
关键操作细节
– 规则位置很重要：必须插入在默认 ACCEPT 规则之前，否则会被跳过。可用 iptables -I INPUT 1 ... 插入最前。
– 端口要核对准确：若 Web 服务跑在 8080 或 8000，需同步修改 --dport。
– 建议先 -j LOG 再 -j DROP：例如 -j LOG --log-prefix "SQLi-ATTEMPT: "，便于观察误报再决定是否拦截。
– 若同时部署了 Nginx/Apache，建议优先在 Web 层用 ModSecurity 拦截，iptables 仅作兜底。
为什么不能靠它防住真实攻击
– 攻击者可轻松绕过：URL 编码（%75%6e%69%6f%6e）、双写（ununionion）、注释符（/**/select/**/from）、大小写混搭、空格替换为 %09 或 + 等。
– MySQL 协议本身有长度头、分包机制，单次匹配难以覆盖完整语句。
– 无上下文判断能力：匹配到 1=1 就丢包，可能误杀正常业务参数（如 ?status=1=1）。
– 无法识别逻辑型、盲注、二次注入等无显式关键字的变种。
