Posts

在 2025 年如何有效阻止恶意爬虫与扫描器

2 min read

引言：给网站加把“智能锁”，挡住不速之客

2025 年了，如果你也感觉服务器日志里的爬虫和扫描越来越猖狂，那我们面临的是同一个问题。AI 大发展需要海量数据，导致内容抓取猛增；同时，自动化的安全扫描也从没停过。这对我们站长来说，意味着服务器压力增大、用户访问变慢，安全风险也实实在在摆在眼前。光靠传统的防火墙或者单一 WAF，感觉越来越力不从心了。

因此，我折腾出了一套多层防御的办法。思路很简单：层层过滤，各有侧重。这篇文章，我就想跟你聊聊我是怎么把 Caddy、Anubis 和雷池 WAF 这三个工具组合起来，给我的网站加上多道防线的。希望能给你一些实用的启发。

核心策略：纵深防御 (Defense in Depth)

面对复杂多变的自动化威胁，单一的防御点很容易被绕过。所以，核心思路是纵深防御——像建城堡一样，设置多道防线，每一层负责不同的拦截任务，增加攻击者的难度。

我的防御架构概览：

下面是我目前采用的架构流程：

[互联网流量] -> [Caddy (HTTPS 终止)] -> [WAF 层 1: Anubis (工作量证明)] -> [WAF 层 2: 雷池 WAF (语义分析)] -> [业务 Caddy (应用代理)] -> [后端应用]

接下来，我们一层层看它们都干了什么：

第一层：HTTPS 终结点与流量入口 - Caddy

  • 角色: 作为整个服务架构的最前端，负责接收所有外部流量并处理 HTTPS。

  • 工具: Caddy Web 服务器。

  • 选择 Caddy 的理由: Caddy 最突出的优势在于其全自动化的 HTTPS 功能。它能够自动申请和续订 SSL/TLS 证书，尤其是通过 DNS 验证方式可以便捷地实现通配符证书的自动化管理，这极大地简化了以往相对繁琐的证书维护工作。作为入口，Caddy 确保了所有面向公网的通信都经过 TLS 加密。完成 TLS 握手和解密后，它将 HTTP 流量反向代理给下一层服务（这里是 Anubis WAF）。在内部服务间使用 HTTP 通信可以简化后续服务的配置，因为它们无需再处理 TLS。

  • 资源: 关于 Caddy 的更多细节请参阅：Caddy 官网文档。

  • 配置示例 (Caddyfile):

    下面是一个 Caddyfile 配置示例，展示了如何为 inetech.fun 及其所有子域名（通配符）自动申请 ZeroSSL 的通配符证书（使用腾讯云 DNSPod 进行 DNS 验证），并反向代理到运行在 10.0.8.11:8923 的 Anubis 服务：

    # 全局选项: 关闭管理 API
{
        admin off
}

# 站点配置: 监听 inetech.fun 和 *.inetech.fun 
inetech.fun, *.inetech.fun  {
        # TLS 配置
        tls {
                # 使用 DNS 挑战，提供商为 tencentcloud (DNSPod)
                # API 密钥从环境变量读取，增强安全性
                dns tencentcloud {
                        secret_id {$TENCENT_SECRET_ID}
                        secret_key {$TENCENT_SECRET_KEY}
                }
                # 强制使用 TLS 1.3 协议
                protocols tls1.3
                # 指定 ACME CA 为 ZeroSSL
                ca https://acme.zerossl.com/v2/DV90
                # ZeroSSL 可能需要的 EAB 凭据，也从环境变量读取
                eab {$ACME_EAB_ID} {$ACME_EAB_KEY}
        }

        # 启用响应压缩，优化传输效率
        encode zstd gzip

        # 自定义响应头，增强安全性
        header {
                # 移除默认的 Server 和 X-Powered-By 头，减少信息泄露
                -Server
                -X-Powered-By
                # 可选：添加 HSTS 头，强制浏览器后续使用 HTTPS 访问，有效期一年
                Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        }

        # 处理请求: 将所有请求反向代理到内部 Anubis 服务
        # 注意：这里是 http://，表示 Caddy 将 HTTPS 流量解密后，以 HTTP 协议转发给 Anubis
        handle {
                reverse_proxy http://10.0.8.11:8923
        }
}

    说明:

    • 请记得将示例中的 inetech.fun 和 reverse_proxy 的目标地址替换为你自己的配置。
    • 该配置通过环境变量（如 {$TENCENT_SECRET_ID}）读取敏感凭证，请务必在运行 Caddy 前设置好相应的环境变量。
    • 使用了 dns tencentcloud 进行 DNS 挑战，确保你的 Caddy 已安装对应的 DNS 插件 (github.com/caddy-dns/tencentcloud)。若使用其他 DNS 服务商，需安装和配置相应插件。

第二层：WAF 1 - “体力活”筛选器 - Anubis (工作量证明)

  • 角色: 重点拦截那些“傻快猛”的自动化爬虫和低级扫描。
  • 工具: Anubis WAF。
  • 怎么工作: Anubis 的绝活是工作量证明 (Proof-of-Work, PoW)。它会给来访的客户端（浏览器或脚本）布置一点小小的计算任务。普通用户通过浏览器访问，这点计算几乎感觉不到。但对于那些想疯狂抓取或扫描的程序来说，每次请求都要计算，累积起来成本就高得吓人，能有效逼退它们。
  • 注意事项: 不能一刀切。我们需要给搜索引擎（如 Googlebot, Bingbot）或者一些必要的 API 接口开白名单（通过 User-Agent 或特定 URL 路径），让它们可以跳过 PoW 检查，直接去下一关。Anubis 的配置通常涉及环境变量或配置文件，用于设定 PoW 难度、白名单规则以及上游服务地址（即雷池 WAF 的地址）。
  • 资源: 如果你想尝试部署 Anubis，可以参考它的官方安装文档：Anubis 安装指南。

第三层：WAF 2 - “脑力活”检测器 - 雷池 WAF

  • 角色: 捕获更“聪明”、更具针对性的攻击，识别恶意行为。
  • 工具: 雷池 WAF (长亭科技出品，这里指社区版)。
  • 怎么工作: 经过 Anubis 初步过滤后，到达这里的流量少了很多“噪音”。雷池 WAF 就能更专注地进行智能分析：
    • 语义分析: 它不只是看关键词，而是能理解请求的意图，识别像 SQL 注入、XSS 跨站脚本这类藏得更深的攻击。
    • 风险 IP 拦截: 内置了风险 IP 数据库，可以直接拒绝来自已知肉鸡、恶意代理 IP 的访问。
    • 灵活规则: 通常也支持自定义规则，可以根据你的业务逻辑，设置更精细的防护策略。
  • 配置要点: 雷池 WAF 通常有自己的 Web 管理界面，你需要在其管理界面中配置上游服务地址（指向 Anubis 或直接暴露的端口），并配置下游服务（指向你的业务 Caddy 或直接的应用）。同时，可以在界面中调整防护策略、查看日志、管理 IP 黑白名单等。
  • 资源: 详细的安装部署步骤可以参考官方文档：雷池 WAF (社区版) 安装指南。

第四层：业务代理 - 业务 Caddy

  • 角色: 把经过层层安检的“干净”流量，稳妥地送到最终的应用程序那里。
  • 工具: 可以是另一个 Caddy 实例，或者 Nginx 等其他反向代理。
  • 为什么需要: 这一层主要负责应用层面的路由、负载均衡等。把它和前面的安全层分开，可以让配置更清晰，方便管理。
  • 配置示例 (概念): 这个 Caddy 的配置相对简单，主要就是监听一个内部端口（例如 localhost:8080），然后 reverse_proxy 到你的后端应用（如 localhost:3000 的 Node.js 应用，或 php-fpm:9000 的 PHP 应用等）。具体配置取决于你的后端技术栈。

为什么要这样“叠 WAF”？

  • 1 + 1 > 2: Anubis 的 PoW 擅长挡“量”，雷池 WAF 擅长挡“质”，两者结合，防护面更广。
  • 减轻负担: Anubis 在前面挡住了大量无效流量，大大减轻了雷池 WAF 的运算压力，让它可以更高效、更准确地工作。
  • 增加攻击成本: 就算攻击者愿意花算力通过 PoW，后面还有雷池等着，层层设卡，提高了攻击的门槛和成本。

结语：组合防御，效果加倍

简单回顾一下我的这套“组合拳”：

  1. Caddy (入口): 负责搞定 HTTPS 加密，并将流量转给 Anubis。
  2. Anubis (第一道防线): 用“工作量证明”把大部分自动化脚本和低级爬虫拦在外面，将筛选后的流量转给雷池。
  3. 雷池 WAF (第二道防线): 精准识别复杂的攻击手法，比如 SQL 注入、XSS，还能挡掉已知的恶意 IP，将安全流量转给业务代理。
  4. Caddy (业务代理): 把经过筛选的“干净”流量交给后台应用处理。

这么做最大的好处是各司其职，效率更高。Anubis 用计算成本挡掉了绝大多数“噪音”流量，让后面的雷池 WAF 可以集中精力处理真正有威胁的请求。从我的实践来看，这套组合在拦截恶意流量和节省服务器资源方面，确实比单用一个 WAF 效果好不少。

当然，这只是我根据自己网站情况摸索出来的方案。你可能需要根据你的流量类型、业务特点和安全预算来调整工具或配置。但**“纵深防御”**这个核心思路是通用的——通过多层、不同机制的防护叠加，让攻击者更难得手。

希望我分享的这些踩坑和实践经验，能帮助你更好地武装自己的网站，从容应对日益复杂的网络环境。

Comments

kaer
感谢分享 waf 知识