OpenResty 源站被扫描的排查与防御实战：Cloudflare + DOCKER-USER + Fail2Ban 最全方案解析

面对自动化扫描器绕过 Cloudflare 直接攻击源站 IP 的挑战，这篇文章从真实日志入手，拆解扫描特征，讲清为何单靠 Cloudflare 不够安全。全文给出可复用的三层防御方案，包含 DOCKER-USER 限制源站访问、Cloudflare WAF 规则精简及 Fail2Ban 动态封禁。适合后端运维、安全与运维团队阅读，掌握实战方案和排查清单，提升防御能力。

遇到自动化扫描怎么办

最近我在一套线上 OpenResty 容器里，发现日志里突然刷出大量奇怪请求。除了正常 HTTP 访问，扫到很多看起来像是非 HTTP 协议探测，敏感文件扫描，甚至伪装浏览器的 User-Agent。更烦的是攻击者绕过 Cloudflare，直接访问我们源站 IP。也就是说，Cloudflare WAF 再厉害，源站一旦暴露，还是难免被各种扫描扫到。

这种问题麻烦在哪里？自动化扫描会触发未知漏洞爆破，甚至暴露云配置文件和数据库凭证，代价可能是一键全量泄露。更麻烦的是，没有按层拦截，扫描请求会频繁写日志，增加硬盘 IO 和分析成本。

本文基于真实日志案例，演示如何用 DOCKER-USER 结合 ipset 限制源站只允许 Cloudflare 回源，配合 Cloudflare WAF 和 Fail2Ban 动态封禁，打造三重防线。如果你最近也在做公网源站安全，这篇建议先收藏，后面有经典排查清单和脚本模板，真正能现场用得上。

核心结论：单靠 Cloudflare 不够

先说结论，为什么会出现这种大量扫描日志？问题核心是：

> 攻击者绕过 Cloudflare，直接访问了源站 IP，Cloudflare WAF 无法生效。

举个生活中的例子，这就好比你家门装了门卫，面向街道拦截坏人，但家门后院有个后门开着没有防护，坏人直接从后门进来你也没辙。

大部分团队只盯着 Cloudflare 配置，却忽略源站 IP 信息泄露带来的风险。源站口，要严格限制只允许 Cloudflare IP 访问，其他全部拒绝才保险。否则日志里永远刷屏，硬盘和分析成本飙升无止境。

日志现象拆解

现象一：非 HTTP 协议探测日志密集出现。比如：

CODE

复制代码

"\x16\x03\x01..."   // TLS 握手探测
"JDWP-Handshake"      // Java Debug 协议
"MQTT"               // 物联网协议探测
"SMB"                // Windows 文件分享
"postgres"           // 数据库协议探测

这说明扫描器没把我们 80/443 端口当 Web 服务，仅仅是用来试探各种常见服务。

现象二：日志出现大量返回码 444，代表 Nginx 主动断开连接，拦截了明显异常请求，比如空 Host、伪造 UA。

现象三：频繁扫描敏感路径，如 docker-compose.yml、.aws/credentials、config/parameters.yml 等配置文件，若泄漏相当危险。

这三个现象合起来，说明攻击者不仅扫 Web 层，还针对云配置和后端服务做探测。你是不是线上的日志也出现类似情况？记得先确认是不是都直接进了源站 IP。

理解防护原理

Docker 容器暴露端口后，流量默认经过宿主机上的 `DOCKER-USER` iptables 链。这个链是 Docker 官方推荐用来做端口流量过滤的入口。在这里，我们可以加规则：

允许 Cloudflare 官方 IP 段流量通过
拒绝非 Cloudflare IP 访问 80/443

这里的重点是自动同步 Cloudflare 最新的 IP 列表，保证防护不落伍。

类似于给家门口装卡口，只允许有门禁卡的人进去，禁止所有无关流量。由于是4层规则，所以只判断源 IP，不依赖 HTTP 层协议，这样才是真正阻断绕过 Cloudflare 的直接访问。

而 Cloudflare 免费版 WAF 可以更细致分辨异常 UA、敏感路径，起到应用层的安全防御。

反面教材：没锁源站直接暴露的坑

不少团队的第一反应是"反正 Cloudflare 有 WAF，没必要锁源站 IP"，结果导致：

扫描流量直接打到源站，消耗带宽与日志资源
源站端口暴露各种非 HTTP 协议探测，增加安全隐患
监控告警泛滥，排查困难

另一个误区是只用 Nginx 层的 `return 444` 规则拦截，但由于 Nginx 被动响应，浪费资源，无法彻底过滤底层 TCP 请求。

还有团队直接封杀来源 IP，忘记放行 Docker 内网和健康检查 IP，导致站点偶现 504，服务自伤。

这类坑踩过的读者，文章中后段的排查清单一定能帮你理清思路。

正确做法：三层防御体系

DOCKER-USER + ipset限流

写脚本自动同步 Cloudflare IP 到 ipset，配合 iptables DOCKER-USER 链，拦截未通过 Cloudflare 的所有 80/443 TCP 流量。
Cloudflare 免费版 WAF 规则

精简恶意 UA 和敏感路径匹配规则，屏蔽已知扫库探测脚本、Masscan 探测和常见敏感路径。结合业务特例（健康检查例外）调整。
Fail2Ban 日志动态封禁

监控 Nginx 日志中的 400、444 以及敏感文件扫描请求，启动封禁策略，自动拉黑重复恶意 IP。

配合放行 Docker 内网和健康检查 IP，避免误伤同时保障服务可用。

这套方案几乎覆盖了绝大多数自动化扫描的攻击链条。你们线上有没有类似防护？如果遇到过莫名 504 或日志异常，可以对照这套流程对症下药。

边界与取舍：不是每个场景都适用

这套方案不可盲目照搬：

适合公网暴露且流量经过 Cloudflare 代理的大中型站点
不适合完全自研或无 Cloudflare 代理的内网服务
一定要同步维护 Cloudflare IP，未更新可能导致误封
DOCKER-USER 规则写错可能导致容器内通信受阻，必须严格放行 Docker 内网段
Fail2Ban 触发规则门限不要设太低，避免误封正常爬虫和运维脚本

简单说，如果你没用 Cloudflare 或业务不在容器中，请先评估网络层实际路径再做方案调整。

这部分原则和细节是我实战中踩过的坑，推荐收藏备用。

排查清单与上线检查

实战中建议的排查与上线步骤：

日志分析：定期扫描 Nginx/OpenResty 访问日志，识别非 HTTP 协议探测和敏感文件请求
验证端口暴露：`ss -lntup`、`docker ps` 等确认 80/443 是否同时暴露 IPv4 和 IPv6
同步 Cloudflare IP，确认 ipset 规则是否加入且命中
用 `iptables -S DOCKER-USER` 检查规则顺序，确保先放行白名单，最后 DROP 非白名单
配置 Fail2Ban 策略，测试是否自动拉黑高频异常 IP
制定监控报警策略，如日志异常量激增触发告警

这份排查清单既适合新上线演练，也适合老系统常规安全复检。建议团队互转，尤其是后端、安全和运维同学都应理解整体防御方案，避免沟通断层。

总结与行动指南

这次 OpenResty 源站被扫描事件，揭示了自动扫描器绕过 Cloudflare 的真实威胁，也暴露出不少团队对源站网络层防护的盲区。总结下来，最关键的三点是：

源站入口必须只能被 Cloudflare IP 访问 ，彻底阻断直连
Cloudflare WAF 负责拦截经过代理的恶意请求 ，重要但不足够
Fail2Ban 动态封禁可补足日志内异常的兜底机制 ，防止重复扫描无休止

如果你看到这里，不妨对照自己的架构和日志，确认一下自己的防护有没有这三层。对这篇的价值认可，可以先收藏备用，平时少踩坑多省心。团队里负责安全和运维的同学，建议一起看，毕竟防护是团队活。遇到更复杂的攻击场景，也欢迎评论区交流你的实战经验。