Hotdry.
归档
ai-security

Forgejo AI爬虫防护：基于请求模式识别与行为指纹的精准拦截系统

面对AI爬虫对Forgejo实例的分布式攻击，设计基于请求模式识别、用户代理分析与行为指纹技术的智能检测系统，结合Iocaine 3与Nam-Shub-of-Enki分类器实现精准拦截。

在 2025 年的互联网环境中，自托管 Forgejo 实例正面临前所未有的 AI 爬虫威胁。这些爬虫不仅无视robots.txt规则，还采用分布式策略，从数千个 IP 地址同时发起请求，导致服务器资源耗尽、性能急剧下降，甚至完全宕机。本文基于实际防护经验，探讨如何设计一个智能检测系统，通过请求模式识别、用户代理分析和行为指纹技术，实现对 AI 爬虫的精准拦截。

AI 爬虫的威胁模式与成本分析

资源耗尽攻击

AI 爬虫对 Forgejo 实例的攻击具有明显的特征模式。根据 VulpineCitrus 的监控数据，一个中等规模的 Linux 仓库（约 138 万次提交）理论上可以生成超过 3240 亿个可爬取页面。爬虫会系统地遍历这些页面，特别是源码归档文件（ZIP/TAR 格式），导致：

  1. 磁盘空间耗尽：Forgejo 在生成源码归档时会创建临时文件，大量并发下载请求会迅速填满磁盘
  2. 内存压力激增：处理大量并发请求导致内存使用率从正常的 1.5-2GiB 飙升至 2.5GiB 以上
  3. CPU 过载：4 核 CPU 使用率从 4% 飙升至 99% 以上

电力与带宽成本

实际测量显示，爬虫攻击期间服务器的功耗从 150W 增加至 170-200W，仅电力成本每年就增加约 60 欧元。同时，出口带宽持续维持在 4MBps（32Mbps），严重影响本地网络性能。

分布式攻击特征

AI 爬虫采用高度分布式的攻击策略：

  • 单日独立 IP 数量可达 47,252 个
  • 主要来源 ASN 包括：华为云（AS136907）、阿里云（AS45102）、VNPT Corp（AS45899）等
  • 攻击呈现规律性波动，每 3 小时出现一次持续 1.5 小时的高峰期

传统防护措施的局限性

robots.txt 的无效性

经验证明，robots.txt对 AI 爬虫完全无效。Jade Ellis 的案例显示，爬虫的 "消失" 实际上是因为仓库被设置为私有，它们收到 404 错误而停止，并非遵守了robots.txt规则。

简单速率限制的副作用

基于 IP 的速率限制在分布式攻击面前效果有限，且容易误伤正常用户：

limit_req_zone wholeforge zone=wholeforge:10m rate=3r/s;

location ^~ (/alopexlemoni/GenderDysphoria.fyi|/oror/necro|/Lymkwi/linux) {
    limit_req zone=wholeforge nodelay;
    proxy_pass http://<upstream>/;
}

这种配置虽然能限制单个 IP 的请求频率，但会导致正常用户访问热门仓库时频繁遇到 429（Too Many Requests）错误，严重影响使用体验。

反向代理缓存的失败

针对动态内容的缓存策略在爬虫攻击下完全失效：

proxy_cache_path /var/cache/nginx/forge/ levels=1:2 keys_zone=forgecache:100m;

location / {
    proxy_cache forgecache;
    proxy_cache_valid any 1h;
    expires 1h;
}

由于爬虫几乎从不重复请求相同资源，缓存命中率极低，同时还会破坏已认证会话的显示，导致正常用户无法使用。

智能检测系统设计

用户代理分析与模式识别

基于ai.robots.txt项目提供的爬虫标识列表，建立用户代理检测规则：

map $http_user_agent $bot_user_agent {
    default 0;
    
    ~*anthropic-ai  1;
    ~*applebot  1;
    ~*bytespider  1;
    ~*chatgpt-user  1;
    ~*claude-web  1;
    ~*cohere-ai 1;
    ~*diffbot 1;
    ~*facebookbot 1;
    ~*google-extended 1;
    ~*gptbot  1;
    ~*perplexitybot 1;
    ~*petalbot  1;
    ~*scrapy  1;
    ~*youbot  1;
    
    # 添加自定义模式
    ~*(?i)ai[-_]crawler 1;
    ~*(?i)llm[-_]scraper 1;
}

行为指纹技术

通过分析请求模式建立行为指纹：

  1. 请求间隔规律性：正常用户请求间隔不规则，爬虫往往保持固定频率
  2. 页面遍历模式：爬虫倾向于按特定顺序（如提交时间倒序）遍历页面
  3. 会话特征：爬虫通常无 Cookie、无 Referer 头，或使用伪造的浏览器指纹
  4. ASN 关联分析：同一 ASN 内多个 IP 的协同行为

请求深度与广度分析

监控单个 IP 或 ASN 在特定时间窗口内的请求特征：

  • 页面深度：连续请求同一仓库的深层页面（如具体文件的 blame 视图）
  • 请求广度：短时间内访问大量不同仓库
  • 归档文件下载：集中下载源码归档文件，特别是大尺寸文件

Iocaine 3 + Nam-Shub-of-Enki 集成方案

系统架构设计

Iocaine 3 作为中间件部署在反向代理和后端服务之间，实现智能流量分类：

客户端 → Nginx → Iocaine 3 → 分类决策
                         ↓
                 合法请求 → Forgejo后端
                 爬虫请求 → 垃圾内容生成器

Nam-Shub-of-Enki 分类器配置

分类器基于多个维度进行决策：

checks {
    disable cgi-bin-trap
    
    asn {
        database-path "/data/ipinfo_lite.mmdb"
        asns "45102" "136907"  # 阿里云、华为云
    }
    ai-robots-txt {
        path "/data/ai.robots.txt-robots.json"
    }
    generated-urls {
        identifiers "deflagration"
    }
    big-tech {
        enable #true
    }
    commercial_scrapers {
        enable #true
    }
    fake-browsers {
        enable #true  # 检测伪造的浏览器指纹
    }
}

Nginx 集成配置

智能路由配置，仅对 GET 和 HEAD 请求应用分类：

map $request_method $upstream_location {
    GET     <iocaine_upstream>;
    HEAD    <iocaine_upstream>;
    default <forgejo_upstream>;
}

server {
    location / {
        proxy_intercept_errors on;
        error_page 421 = @fallback;
        proxy_pass http://$upstream_location;
    }
    
    location @fallback {
        proxy_pass http://<forgejo_upstream>;
    }
}

当 Iocaine 判定请求来自爬虫时，返回 200 OK 并生成垃圾内容；判定为合法请求时，返回 421 Misdirected Request，由 Nginx 转发至真实后端。

实施参数与监控要点

速率限制调优参数

基于实际流量模式的速率限制配置：

# 针对已识别爬虫的严格限制
limit_req_zone $binary_remote_addr zone=crawlers:30m rate=1r/10s;

# 针对可疑IP的中等限制  
limit_req_zone $binary_remote_addr zone=suspicious:20m rate=5r/s;

# 正常用户的宽松限制
limit_req_zone $binary_remote_addr zone=normal:10m rate=30r/s;

location / {
    if ($bot_class = "confirmed") {
        limit_req zone=crawlers burst=5 nodelay;
    }
    if ($bot_class = "suspicious") {
        limit_req zone=suspicious burst=20 delay=10;
    }
    limit_req zone=normal burst=50;
}

监控指标与告警阈值

建立全面的监控体系：

  1. 请求分类统计：

    • 爬虫请求占比（目标：<5%）
    • 分类准确率（目标：>95%）
    • 误拦截率（目标：<0.1%）

  2. 资源使用监控：

    • CPU 使用率阈值：80%（警告），95%（严重）
    • 内存使用率阈值：85%（警告），95%（严重）
    • 磁盘空间阈值：80%（警告），90%（严重）

  3. 网络流量分析：

    • 出口带宽突增检测（>50% 增长持续 5 分钟）
    • 非常规 ASN 流量占比监控
    • 归档文件下载频率监控

Grafana 监控面板配置

关键监控面板应包括：

  • 实时请求分类饼图
  • 资源使用趋势图
  • 爬虫来源 ASN 分布
  • 误拦截事件时间线
  • Iocaine 垃圾内容生成量统计

风险控制与回滚策略

误拦截处理机制

建立多层防护以避免误伤正常用户：

  1. 白名单机制：为已知自动化工具（如 CI/CD 系统、Git 客户端）建立 IP / 用户代理白名单
  2. 人工审核队列：将可疑但不确定的请求记录到审核队列，定期人工检查
  3. 渐进式限制：对可疑 IP 先应用宽松限制，确认爬虫行为后再加强限制

紧急回滚流程

当系统出现大规模误拦截时：

  1. 立即禁用分类器：通过配置热重载临时关闭 Iocaine 分类
  2. 恢复基础速率限制：启用保守的全局速率限制（如 10r/s）
  3. 日志分析：分析误拦截模式，调整分类规则
  4. 渐进式恢复：先恢复对已验证用户的正常访问，逐步重新启用智能分类

规则更新与维护

建立定期维护流程：

  1. 每周规则更新：基于ai.robots.txt项目更新用户代理规则
  2. 月度行为分析：分析爬虫行为模式变化，调整检测算法
  3. 季度系统评估：全面评估系统效果，优化参数配置

实际效果与经验总结

防护效果数据

基于 VulpineCitrus 的实际部署数据：

  • 请求拦截率：96.7% 的爬虫请求被成功拦截
  • 资源使用改善：CPU 使用率从 99% 降至 4%，内存使用稳定在 1.5-2GiB
  • 电力成本降低：服务器功耗从 200W 降至 160W
  • 用户体验：页面加载时间从 15 秒以上恢复至正常水平

关键经验教训

  1. 不要依赖单一防护层：多层防护（分类 + 限制 + 重定向）比单一方案更有效
  2. 监控比防护更重要：没有监控的防护系统是盲目的
  3. 用户代理只是起点：现代爬虫会伪造用户代理，需要结合行为分析
  4. ASN 封锁需谨慎：避免封锁大型云服务商的整个 ASN，可能影响正常用户

未来改进方向

  1. 机器学习增强：基于历史数据训练爬虫检测模型
  2. 协同防护网络：多个 Forgejo 实例共享爬虫情报
  3. 动态规则生成：基于实时流量模式自动生成防护规则
  4. 区块链验证：为合法自动化工具提供可验证的身份凭证

结语

在 AI 爬虫日益猖獗的今天，保护自托管 Forgejo 实例需要从被动防御转向主动智能检测。通过结合用户代理分析、行为指纹技术和请求模式识别，配合 Iocaine 3 等专业工具，可以构建一个既有效又精准的防护系统。关键在于平衡防护效果与用户体验，建立完善的监控体系，并保持系统的可调整性以应对不断变化的爬虫策略。

防护 AI 爬虫不仅是一场技术对抗，更是对互联网开放性与可持续性的思考。在保护自身资源的同时，我们也应该思考如何维护一个更加健康、公平的网络环境。

资料来源：

  1. VulpineCitrus. "Guarding My Git Forge Against AI Scrapers" (2025-12-02)
  2. Jade Ellis. "Actually stopping AI scrapers from taking down my server" (2025-05-18)
  3. ai.robots.txt项目提供的 AI 爬虫标识列表
  4. Iocaine 3 官方文档与 Nam-Shub-of-Enki 分类器配置指南
查看归档