Composer镜像站应对爬虫高频扫目录的动态WAF防护-composer-PHP中文网

应采用动态waf进行行为识别拦截，因composer扫描使用分布式代理、ua轮换、随机间隔且模拟真实header，传统限速和ip黑名单易误伤ci构建或云厂商出口ip；需区分正常依赖解析（有序请求packages.json后按hash拉dist）与暴力扫描（无序高并发/p2/路径、accept无json、referer为空）。

composer镜像站应对爬虫高频扫目录的动态waf防护

Composer 镜像站被高频扫描 /packages.json、/p2/、/dist/ 等路径，不是业务请求而是爬虫或探测行为——直接封 IP 效果差、误伤大，必须用动态 WAF 做行为识别和拦截。

为什么传统限速和 IP 黑名单对 Composer 扫描无效

扫镜像站的爬虫通常使用分布式代理池、User-Agent 轮换、请求间隔随机化，甚至模拟 Composer 客户端真实 header（如 User-Agent: Composer/2.5.8）。单纯靠 limit_req 限速会卡住合法 CI 构建；硬封 IP 段容易误杀云厂商出口 IP 或企业 NAT 出口，导致整批构建失败。

真正有效的防护点在于：区分「Composer CLI 正常依赖解析」和「目录暴力遍历」。前者有明确的请求模式（如先查 packages.json，再按需拉 dist），后者是无序、高并发、路径无逻辑的扫荡式请求。

正常 Composer 请求：GET /packages.json → 解析后发若干个带 hash 的 GET /dist/xxx.zip
扫描行为：1 秒内连续请求 /p2/vendor1/、/p2/vendor2/、/p2/abc/、/p2/def/ 等无规律路径
关键差异：扫描请求几乎不带 Accept: application/json，且 Referer 为空或为非 Composer 相关域名

雷池 WAF 上配置 Composer 行为规则的关键参数

雷池（SafeLine）支持基于请求上下文的语义识别，比 Nginx 原生模块更适合这类场景。重点不是“拦什么路径”，而是“在什么条件下放行/拦截”。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

启用「HTTP 方法 + 路径前缀 + Header 组合规则」：匹配 GET 请求且路径以 /p2/ 或 /dist/ 开头，但 Accept 不包含 application/json 或 application/vnd.composer. 的，标记为可疑
开启「路径熵值检测」：对连续 5 次请求中路径最后一级目录的字符熵 > 4.2 的（说明不是规范 vendor 名，而是随机字符串），自动触发人机验证
设置「Referer 白名单豁免」：允许来自已知 CI 平台域名（如 github.com、gitlab.com、jenkins.example.com）的请求绕过该规则
注意：不要开启「User-Agent 黑名单」——Composer 官方客户端和第三方工具（如 phpstan、roave/better-reflection）UA 差异极大，极易误判

Nginx 层做兜底：用 map + geo 实现轻量级动态过滤

如果暂时没上 WAF，可在 Nginx 配置里加一层低成本识别。核心思路是：用 map 提取请求路径特征，再结合 geo 模块做临时标记，避免全量日志分析。

map $request_uri $is_composer_scan {
    ~*^/p2/[^/]+/$      1;
    ~*^/dist/[0-9a-f]{32}\.zip$  0;
    ~*^/packages\.json$  0;
    default             1;
}
<p>geo $scan_flag {
default         0;
123.45.67.0/24  1; # 临时标记高危网段
}</p><p>if ($is_composer_scan = "1") {
set $rate_limit_key "$binary_remote_addr:$scan_flag";
}
limit_req zone=scan burst=3 nodelay;</p>

这段配置的作用是：只对疑似扫描路径（如 /p2/xxx/）且非白名单 UA 的请求启用严格限流，而 /packages.json 和带确定 hash 的 /dist/ 请求完全放行。关键是 $scan_flag 可动态更新，运维可通过日志快速把新出现的攻击源网段写入 geo 段。

真正难的不是写规则，而是区分“CI 构建高峰”和“扫描潮”——它们的 QPS 可能接近，但请求路径分布和 header 组合完全不同。上线前务必用真实 Composer 日志回放测试，别只靠模拟请求验证。