自动更新如何纳入主机安全基线

自动更新一开，很多站长就以为“系统自己会处理”，但安全基线不能跟着省略。WordPress 更新时，wp-content/upgrade/ 可能短暂出现解压文件；如果 Web 服务器能直接访问这个目录，自动更新就可能留下一个没人盯着的时间窗口。把自动更新纳入主机安全基线，关键是让主机层提前兜底。

先把入口控制固定下来

wp-content/upgrade/ 通常不需要对访客开放，因此可以在实际生效的 Nginx 虚拟主机中长期拒绝访问：

location ^~ /wp-content/upgrade/ {
    deny all;
    return 403;
}

如果站点部署在 /blog/，规则也要匹配 /blog/wp-content/upgrade/。这项控制应放在 Web 服务器层，而不是只依赖 WordPress 安全插件，因为请求会在进入 PHP 和 WordPress 代码前被拦截。修改后先执行 nginx -t，确认语法无误，再平滑加载配置，并从站点外部测试该路径，确保没有出现 200、目录列表或 PHP 响应。

自动更新也要留下证据

主机基线不能只记录“是否开启自动更新”，还应记录更新前后的核心版本、更新时间、配置变更和业务检查结果。更新完成后，至少核对首页、后台登录、媒体上传、关键插件和定时任务。wp-content/upgrade/ 中若留下不明脚本、压缩包或异常文件，应结合文件权限、修改时间和访问日志判断，不能只看目录是否为空。

日志里要重点关注升级目录是否曾被公网成功访问，尤其是 PHP、配置文件和压缩包请求。若规则生效前出现异常成功响应，应保留日志并按安全事件流程检查核心文件、插件、主题、管理员账号和计划任务。

把例外写进基线

如果主机面板或更新服务因这条规则失败，应先确认它是否依赖公开 HTTP 路径，再决定是否开一个受控的短暂窗口。更新完成后重新启用拒绝规则。只有版本已核验、业务测试通过、日志检查完成，并且配置可恢复时，才考虑撤销控制。这样，自动更新才算真正进入主机安全基线，而不是把风险交给后台任务自行碰运气。