今天（9 月 17 日）下午照例打开百度云防护控制台看日志，吓了一跳：主机吧（www.zhujib.com）的攻击详情一天之内刷出了 10000+ 条拦截记录——分页直接显示 1000 页。好在扫了一眼，所有记录的处置动作清一色是「拦截」，响应码全部 403，源站毫发无损。这篇文章就带大家看看这批攻击到底在扫什么、WAF 是怎么接住的，文末附上站长可以直接抄的防护配置。
一、攻击全景：一天一万条，都在扫什么？
从列表看，今天的扫描来自至少三个不同 IP，攻击时间集中在中午到下午，手法覆盖了自动化扫描器的经典套路：
| 攻击 IP | 安全事件 | 典型路径 | 命中规则 |
|---|---|---|---|
| 91.92.241.196 | 敏感信息探测（中风险） | /.git/config、/.git/HEAD | Info_scanner.CodeLeak_A |
| 221.7.228.136 | 敏感信息探测 / 威胁情报 / 文件上传 | /WEB-INF/war、/shop/phpspy*、/shop/2008* | Info_scanner.SensitiveFil、Suspicious_threat.Webshell、File_upload.Generic_J |
| 61.170.244.202（上海） | 注入（中风险） | /cc-domain-can-beian-2026-mit-approved-list.html | Injection.header_B |
第三条比较特殊，是个有意思的插曲，放在第四节单独讲。先看前两个 IP，它们是今天扫描的主力。
二、拆解：扫描器到底在找什么？
1. 探测 /.git/ —— 想把我的源码整个拖走
91.92.241.196 在 12:02:09 到 12:02:17 这 8 秒内连续请求了 /.git/config 和 /.git/HEAD。这是非常经典的「源码泄露」探测：程序员如果在部署时不小心把整个 .git 目录传上了服务器，攻击者就能用 githack 类工具还原出完整源码，包括数据库配置、密钥、全部业务逻辑。检测到 .git/HEAD 存在，就等于确认了这个宝藏。百度云防护的 Info_scanner.CodeLeak_A 规则直接 403，一条没漏。
2. 探测 /WEB-INF/ —— 盯上了 Java 站点的家底
221.7.228.136 在 11:45 前后连续请求 /WEB-INF/7z、/WEB-INF/war 等路径。WEB-INF 是 Java 应用的私有目录，如果配置失误被直接下载到 war 包（整个应用的编译产物+配置文件+数据库连接串）或者管理员打包的 7z 备份，基本等于全站沦陷。这类探测被 Info_scanner.SensitiveFil 系列规则全部拦下。
3. 探测 /shop/phpspy* —— Webshell 与上传点扫描
更有节奏感的是 11:37 那一波：同一 IP 每隔 1-2 秒发一次请求，先后探测了 /shop/phpspy*、/shop/2008*、/shop/autog* 等路径，分别命中三类规则——Suspicious_threat.Webshell（威胁情报直接命中 Webshell 探测行为）、File_upload.Generic_J（文件上传点探测）。phpspy 是黑客圈经典的 Webshell 管理工具，扫描器在猜站点上有没有遗留的历史后门文件，这套动作属于「接管式攻击」的前置侦察。
三、JA3/JA4 指纹：换 IP 也没用
这次攻击详情里最有技术含量的字段是 JA3 / JA4 指纹。点开攻击详情可以看到：
JA3/JA4 是对 TLS 握手特征（协议版本、密码套件、扩展顺序等）计算的指纹，同一个扫描工具发出的所有请求，指纹完全一致。截图里 221.7.228.136 的 JA3 指纹始终是 acbd2dd7b517a2...、JA4 固定为 t13d52131h1_019...——这说明上万次请求其实出自同一个工具。IP 可以换、UA 可以改，但 TLS 指纹是工具的「出厂声纹」，基于指纹做封禁可以直接团灭一整个扫描器家族，这也是现代 WAF 区别于传统防火墙的硬实力。
四、一个插曲：连 Claude 的爬虫都被拦了
翻日志时还发现一条有趣的记录：上海 IP 61.170.244.202 用 Claude-User（claude-code/2.1.260）——Anthropic 官方 AI 工具的爬虫 UA——访问本站页面，结果命中了 Injection.header_B 规则（规则 ID 3747）被拦截，攻击载荷显示触发点是请求头特征。
这说明两件事：一是 AI 爬虫现在是真的无孔不入，连代码助手的抓取都会跑进网站日志；二是 WAF 的基础防护规则讲究「宁可错杀」，对带特殊 header 特征的请求一律从严。对站长来说这就是个选择题：如果你欢迎 AI 爬虫来抓内容（毕竟 AI 引用也是流量入口），可以在 WAF 里为可信 AI 爬虫 UA 配置放行规则；如果不想被抓，保持拦截即可。AI 时代的流量治理，关键在于「分级」，而不是一刀切。
五、站长防御清单：抄作业版
结合这次实战，给几条可以直接落地的建议：
- WAF 保持拦截模式：观察模式只能看不能挡，今天的 10000 次扫描如果有 1 次命中就是事故；
- 源站再兜一层底：WAF 之外，Nginx 也应该禁掉敏感目录，双保险配置如下——
# 禁止访问版本控制目录与隐藏文件
location ~ /\.(git|svn|hg|env) {
return 404;
}
# 禁止访问 WEB-INF 及敏感备份文件
location ~* ^/WEB-INF/ {
return 404;
}
location ~* \.(bak|sql|tar|gz|7z|war|config)$ {
return 404;
}- 定期翻攻击详情：重点看「未拦截」记录，WAF 规则也有覆盖率边界，日志里发现漏网路径要立刻补自定义规则；
- 利用 JA3/JA4 指纹封禁：对持续变换 IP 的扫描器，直接封指纹比封 IP 高效得多；
- 敏感路径加设备门槛：登录、后台地址可以配合设备情报规则（参考之前写的设备情报能力详解），对新设备加验证。
这次事件最庆幸的一点：攻击者换了三个 IP、扫了一万次，拿到的全是 403。漏洞扫描本质是概率游戏——扫描器翻遍你的站点一个口子都没找到，自然就走了；而只要漏掉一个，源码、数据、服务器都可能交代。安全投入平时看着没用，出事那一刻就是全部。
如果你的站点也常年被扫描、采集，除了 WAF 的应用层拦截，网络层的大流量攻击（DDoS/CC）建议用速度网络高防 IP（包年包月，买多少峰值防多少，无后付费）兜底，应用层加网络层，防线才算完整。
