百度云防护 Web 基础防护”观察”模式 = 裸奔！从某站长 5 个管理员账号被连夜改名事件说起
警告：所有已经接入百度云防护（已备案站点可用）的站长，请立刻登控制台看一眼自己的 Web 基础防护规则是不是还停在「观察」状态。如果是，立刻切到「拦截」。下面这个案例就是血淋淋的代价。
一、案例现场：5 个 adm*** 管理员账号一夜冒出来
昨天下午，我们接到一位站长的紧急求助，对话大致如下：
站长（bit）：奇怪，管理员用户名都变成这种 adm 开头的。
站长：被人改了？
主机吧：不知道啊，几个管理员账号都变成这种 adm 开头的，中午我改回正确（以前）中文昵称，刚才一看，又变了。
站长：郁闷死了。
主机吧：更新最新版本了没？
主机吧：把之前的管理员账号密码改了。已经全部更新的管理员密码。
站长：你连基础安全拦截都不开？要开启拦截，你开观察等于没开。现在漏洞可多了，防不胜防。
当事人 WordPress 后台的用户列表被改成了这样：
用户列表（截选）：
adm677x8、admziau6、admc8jxv、adm9q1f1、admuwlw2，全部是 adm + 随机 5~6 位后缀，昵称字段相同，中文管理员被替换。
站长反映：上午把账号改回正常中文名，下午一看又被改回去了，像一个跑在后端的轮询任务在持续回写。
二、直接原因：WAF 在「观察」模式，等于没开
我们登客户的百度云防护控制台一看，问题立刻浮出水面：
SaaS WAF 防护节点：
www.kuoyuwang.net（脱敏处理，本案例所有权归当事人）
规则 ID：1000054904，2 个站点
防护动作：观察
更新时间：2026-05-01（即自接入以来快 3 个月没切到拦截）
站长是今年 5 月接入的百度云防护 SaaS WAF。开通后页面默认停在「观察」模式——只记录攻击日志、不阻断请求——他没留意切换过。中间这几个月，黑客的所有 SQL 注入、XSS、WebShell 上传、木马探测行为，WAF 一路放行，只留在了日志里。
直到昨天，黑客终于触发成功：要么是利用了一个未拦截的注入点直接 UPDATE wp_users 修改用户名，要么是利用残留的管理员 Cookie / 后门类账号直接走 REST API 改的，反正——WAF 那一关没拦。
注：百度云防护的「观察」模式本来就是为规则试运行设计的，文档里也明确写着「上线生产前需切换为拦截」。问题在于很多站长忘了切，一旦忘记就一路裸奔。
三、技术复盘：这种改名是怎么发生的
把这起案例的攻击链拆开，几个关键动作：
| 步骤 | 攻击者做了什么 | 「观察」模式下的 WAF |
|---|---|---|
| 1. 探测 | 用工具扫描 wp-users、REST API、登录页 | 全部放行，仅记日志 |
| 2. 利用 SQL 注入 | 对老版本插件或主题进行注入读取 wp_users | 全部放行，仅记日志 |
| 3. 写入新管理员账号 | 通过注入或劫持的 REST 接口新增 adm*** 用户 | 全部放行，仅记日志 |
| 4. 修改原管理员用户名 | 把原中文管理员改成 adm***，让你找不到入口 | 全部放行，仅记日志 |
| 5. 持续驻留 | 在插件 / wp_options / wp_posts 留 cron / 计划任务定时回写 | 全部放行，仅记日志 |
| 6. 站长手动修复 | 改回原中文名 / 改密码 | WAF 还是只观察 |
| 7. cron 回写 | 几小时后又被改回去 | 全部放行，仅记日志 |
只要第 1 步开始的攻击流量进了源站，后续每一步都畅通无阻，WAF 形同虚设。
四、根因不是工具不行，是规则没生效
请大家记住一句话：没有处于「拦截」状态的 WAF 防护规则，等于没有这个规则。
很多站长对 WAF 的理解停留在「我买了」或「我接入了」，但实际上：
- 「观察」模式：WAF 检测引擎照样在跑，日志照样在写，但命中后只放行请求，不返回拦截页——等于你花的钱只买了「日志服务」。
- 「拦截」模式：命中规则后立刻阻断（返回自定义拦截页或 403），攻击流量到不了源站。
- 「JS 挑战 / 滑块验证 / 人机识别」：对真人正常，对自动化工具无效。
百度云防护的 WAF 引擎本身是靠谱的，但它的配置哲学是「最小意外」：默认观察，避免误伤；上线生产前才需要站长主动确认切到「拦截」。这位站长踩的就是这个「默认观察陷阱」。
五、应急处置：被改名之后立刻做的 8 件事
如果你或者你的客户也发现管理员账号被莫名改名，请按以下顺序排查：
- 立即把 WAF 规则切到「拦截」——这是止血，否则后面每一步都在攻击者眼皮下操作。
- 断开源站与公网的非白名单链路：能在 Nginx / CDN 上加临时 IP 白名单（仅放行自己办公 IP）就先限制。
- 进入数据库手工清理 wp_users：
- 删除所有 adm、admin、test*** 等可疑账号；
- 检查
wp_capabilities中是否含有administrator的非正常账号； - 把原管理员用户名的
user_login改回原始中文（注意 WordPress 用户名一旦改过不能直接改回，需要经 phpmyadmin 操作wp_users.user_login字段）。 - 强制重置所有管理员密码：用 phpmyadmin 直接覆盖
user_pass字段的 MD5 加 salt 值。 - 升级 WordPress 核心到最新稳定版，并把所有插件 / 主题更新到最新（当前高危的 wp2shell、文件上传插件 SQL 注入是重灾区）。
- 扫描 wp_options / wp_posts：搜可疑的
eval、base64_decode、exec、可疑的 cron 计划、可疑的 oEmbed 缓存条目。 - 扫描主题 / 插件目录：用
find . -name '*.php' -newer /tmp/empty找最近被改过的 PHP 文件，与官方包做 diff。 - 清空所有持久化缓存（Redis / Memcached），否则旧的 transient 还会被回放。
六、百度云防护的正确启用顺序（建议收藏）
为了不让别的站长再踩一遍坑，主机吧这边给一个通用的「百度云防护上线 7 步法」：
- CNAME 接入前 24 小时，全规则处于「观察」模式，用于摸底业务真实流量。
- 拿到「观察」日志后，逐一核对误伤记录，调整规则阈值。
- 自定义规则（如 IP 黑名单、UA 黑名单、JA3 指纹封禁）单独新建，先观察、再切拦截。
- Web 基础防护规则整体切到「中级（默认）→ 拦截」——这一步是真正开始防护。
- 跑 7 天「中级 + 拦截」，没有误伤投诉，再把核心页面切到「高级（严格）」。
- 同时开启 CC 防护（先智能 CC），启用自定义 CC 备用。
- 加入百度云防护官方运营通知 / 主机吧协助巡查，规则更新第一时间跟上。
任何一步停留在「观察」，只要你不知道自己在观察什么，就等于没开。
七、结语：先想清楚你买的到底是什么
这位站长买的不是「百度云防护」，买的是「百度云防护 + 一个我手动切到拦截的动作」。这一步不到位的站长，WAF 报再多的安全态势数据都救不了他。
请所有已经在使用百度云防护的站长，今天就登一次控制台：
- 看一眼 Web 基础防护规则；
- 看一眼你的「处置动作」是「观察」还是「拦截」；
- 不是「拦截」就立刻切。
主机吧也再次提醒：新接入的 WAF 默认观察模式是产品设计，不是产品问题，但忘记切换是站长的问题。把这条转给你的运维同事、你的客户、你的同行——少一个人踩坑，这一篇文章就值回票价。
主机吧 | 百度云防护官方合作伙伴
提供 WAF 接入、高防 CDN、高防 IP、高防服务器、SSL 证书一站式服务
接入不是结束，切到拦截才是开始。
