清理之前先遏制事件
意外的重定向、陌生的管理员账户,或包含垃圾内容的搜索结果,都可能意味着网站已被入侵。插件扫描结果干净,并不能排除入侵。同样,单一症状也无法证明存在某个特定的后门或攻击手法。请调查服务器实际向不同会话和设备返回了什么内容。
首先保护访客。如果可能出现有害内容或支付被拦截,请限制访问或暂时停用受影响的功能。当继续运行一个已被入侵的服务可能让更多人受害时,承诺“零停机”并不明智。
保全证据并摸清影响范围
- 把文件、数据库以及可获得的访问、错误和认证日志制作带日期的副本,保存在受限位置。记录当前时区以及你所做的每项改动。
- 清点共享访问权限的域名、托管账户、WordPress 安装、管理员、插件和部署凭据。
- 查找核心文件、must-use 插件、上传目录、计划任务、服务器配置和数据库选项中的异常改动。
- 在选择备份之前,先确定已知最早的可疑活动时间。较新的备份可能已经包含了入侵内容。
在可信环境中检查完整性
WP-CLI 的校验和可以找出与官方软件包的差异。请在副本或受控环境中使用可信的工具。有些命令会加载网站代码,而被入侵的安装并不是可信的执行环境。
wp core verify-checksums --include-root
wp plugin verify-checksums --all --strict
这些检查并不能证明整个网站都是干净的。定制插件和商业插件可能没有公开的校验和。数据库中的恶意载荷、服务器层面的持久化以及被盗的凭据,都需要单独调查。发现差异也可能只是需要复核的正当修改。
重建并封堵入口点
用可信的发布版本替换被入侵的组件,并审查定制代码。修补或移除存在漏洞的入口点;只删除被注入的文件,问题根源依然存在。在重新连接各项服务之前,检查计划任务、管理员账户、数据库内容、上传目录和同一环境中的相邻网站。
完成遏制后,更换已泄露的托管、部署、数据库和应用凭据,撤销会话,并视情况更新 WordPress 的密钥(salts)。遵循最小权限原则并启用多因素认证。根据你的 Web 服务器配置,限制上传目录中的可执行代码。
重新开放前验证恢复情况
- 从干净的会话中测试页面、表单、登录和购买流程。
- 检查是否有异常的对外请求、被修改的文件和反复出现的计划任务。
- 确认备份确实可以在隔离环境中恢复。
- 查看 Search Console 中的安全问题,并在解决所报告的问题后再申请审核。审核时间由服务提供方决定。
重新开放后继续监控。保留一份简短的事件记录:影响范围、可能的入口点、证据、改动、未解决的问题以及后续跟进的负责人。不要在公开的事后分析中发布客户数据或未经处理的敏感日志。
常见问题
应该立即恢复备份吗?
一份确认干净的备份可以成为恢复的一部分,但请先保全证据,把备份日期与事件时间线进行比对,并修复入口点。还要规划如何补回该备份之后产生的正常订单或内容。
安全扫描结果干净,就能证明 WordPress 是安全的吗?
不能。扫描器可能漏掉数据库注入、服务器层面的持久化或已泄露的凭据。请把文件完整性检查与账户、日志、数据库和计划任务的审查结合起来。确认网站在干净会话中返回预期内容,并调查最初的入口点。
被黑的网站在清理期间应该继续在线吗?
这取决于它可能造成的危害。如果访客可能收到恶意软件、欺骗性重定向或支付被拦截,请在调查期间限制受影响的服务。保持可用性并不比遏制正在进行的入侵更重要。
恢复网站后应该检查哪些内容?
验证表单、身份验证和购买流程;确认入口点已修复;检查异常的文件、账户和对外请求;并测试恢复一份新的备份。如果 Search Console 报告了安全问题,请在解决后申请审核。重新开放并不代表恢复结束,所以要持续监控。
参考资料与延伸阅读
继续阅读
如需直接协助,请查看 WordPress 恶意软件恢复。恢复完成后,再检查网站的可抓取性和搜索展示。

Leave a Reply