爬虫与扫描器的边界 (Crawler vs Scanner Boundary)

2026-08-31 暂无评论

公网站点的访问日志里,"爬虫"和"攻击扫描器"高度混淆:同一个 GET /.env 请求,可能是正经公司的健康检查,也可能是攻击者的密钥捞取——日志层面无法区分,因为请求本身一模一样。理解这个边界,才能既不误封搜索引擎(SEO 灾难),又不放走真攻击。

三类"爬虫"的真实画像

类型	例子	打 `.env` 吗	目的
搜索引擎爬虫	Googlebot、bingbot、Baiduspider	从不打	只爬页面/robots.txt/sitemap,服务搜索索引
AI 公司爬虫	Amazonbot、GPTBot 类	会打(实测 36% 请求是攻击路径)	抓内容给 AI 训练/问答,顺带"安全健康检查"
纯扫描器	无 UA / 伪造 UA,云主机上的批量任务	主力业务	只捞密钥、探漏洞

为什么"正经公司"也扫 `.env`

不是公司恶意,是爬虫工程里的防御性健康检查:

爬虫抓页面前先探测目标站有没有泄漏 .env / .git / .aws credentials(新手部署最常见的事故)
检测到泄漏就通过站长工具告警(如 Google Search Console 的安全问题提醒)
坑在实现上:这个检查和攻击者的扫描是同一套 HTTP 请求,区别只在拿到 200 之后的动作——正经爬虫记录报告,攻击者下载利用

另一层混淆:云上 IP 是一锅粥。AWS/腾讯云国际段的同一 IP,可能既跑真爬虫又被租去跑黑扫描。实测案例:腾讯云国际段 43.146.64.33 同一 IP 既带 Googlebot UA 抓 CSS,又打过 /@fs/../../root/.env 攻击路径。所以按 IP 封禁会误伤搜索引擎出口,必须配合路径规则。

防护的正确姿势(结构优先,不赌人心)

真被"打到"的前提是密钥文件在 web 目录里(GET /.env 返回 200 + 内容)。防护两层,与扫描器多疯狂无关:

密钥文件不进 web 目录——.env 放应用目录,web root 里物理上没有,HTTP 层摸不到(结构性免疫)
nginx 路径封禁——对 /.env /.git /.aws /.ssh /.docker xmlrpc phpinfo @fs/ 这类全站皆非法的探测路径统一 403,SPA 的 try_files fallback 之前会把它们兜成 index.html 回 200(内容无害但递梯子),封禁后直接 403

封禁实施要点(tx 实战,2026-08-31)

只封路径 + 已核验的境外恶意 IP;国内 IP 一律不封(校园导航等真实用户),搜索引擎爬虫段(Googlebot 66.249.x、bingbot 40.77/52.167.x、百度 180.101/220.181.x)绝不进黑名单
WordPress 站的 wp-* 路径不能进路径黑名单——那是它自己的合法后台
nginx 的 if 只能在 server/location 层;执行 snippet 不能放进被 *.conf glob 的目录,否则在 http 层被加载直接报 "if" directive is not allowed here
验证方法:curl -H "Host: xxx" https://127.0.0.1/.env 看回 403;再抽查真实用户路径 200 正常