iptables不能过滤Web扫描器HTTP头，因其仅工作在L3/L4层，无法解析应用层Header；应使用WAF、反向代理限速或IP行为分析等L7方案。
iptables 本身无法直接解析 HTTP 请求头（如 User-Agent、Referer 或自定义扫描特征字段），因为它工作在 OSI 模型的网络层和传输层（L3/L4），不处理应用层（L7）内容。因此，**不能用 iptables 原生匹配或拦截 “sqlmap”、“nuclei”、“dirsearch” 等扫描器发出的 HTTP 头部特征**。
为什么 iptables 不适合过滤 Web 扫描器头
HTTP 头属于 TCP 数据载荷的一部分，需完整重组 TCP 流并解析应用层协议——这超出了 iptables 的设计能力。尝试用 -m string 模块粗略匹配载荷虽有极少数实验性用法，但存在严重问题：
- 无法保证 TCP 分片完整性，易漏匹配或误匹配
- 性能开销大，尤其在高并发 Web 流量下显著拖慢内核包处理
- 规则极易被绕过（如大小写混淆、空格填充、编码变形、分段发送）
- 缺乏上下文判断（比如无法区分真实爬虫与恶意扫描）
真正有效的替代方案（推荐组合使用）
拦截 Web 扫描器应下沉到应用层或准应用层，以下方案成熟、稳定、可落地：
-
Web 应用防火墙（WAF）：部署 Nginx + ModSecurity 或 OpenResty + lua-resty-waf，可精准识别并阻断含
User-Agent: sqlmap、X-Scan: nuclei、异常路径（/wp-admin/admin-ajax.php批量探测）、高频目录爆破等行为 -
反向代理层日志联动限速：用 Nginx 的
limit_req结合map指令，对匹配特定 UA 或 URI 的 IP 动态启用严格限流（如 10 秒内仅允许 2 次请求） - 基于 IP 行为的 iptables 辅助防护：虽然不能看 Header，但可结合 recent/connlimit 模块识别扫描器的“行为指纹”——例如 60 秒内对 >20 个不同 URL 路径发起 GET 请求的源 IP，通过应用层日志（如 Nginx access.log）触发脚本自动加入 ipset 黑名单，再由 iptables 引用该 set 进行 DROP
- 云 WAF 或 CDN 防护：Cloudflare、阿里云 WAF、腾讯云 Web 应用防火墙已内置数百条扫描器指纹规则（含 Burp、Acunetix、Arachni 特征库），无需自行维护，且支持自动学习模式
若坚持在 iptables 层做初步过滤（仅限特定场景）
仅适用于极简架构、无反代、且明确知道攻击流量具备 L4 可识别特征的情况，例如：
- 扫描器使用非标准端口（如 8080、8888）发起 HTTP 探测 → 可用
-p tcp --dport 8080 -j REJECT关闭非常规 Web 端口 - 大量短连接直连后端服务（绕过 Nginx）→ 用
connlimit限制单 IP 到 80/443 的并发新建连接数（如--connlimit-above 5） - 扫描器混用 TCP 异常标志（如 SYN+FIN）试探 → 启用
--tcp-flags ALL SYN,FIN -j DROP规则（见知识库中非标准标志防御部分）
不复杂但容易忽略：Web 扫描防护是分层任务，iptables 是守门人，不是解码员。把该它干的事（封 IP、限连接、拦畸形包）干扎实，把该应用层干的事（看 Header、析行为、做语义判断）交给 WAF 或业务逻辑，才是稳健路线。
