上个月帮一个企业站排障，前台偶发 500，后台还进得去。翻日志才发现：核心和插件隔了大半年没更，某个过期插件被扫到已知漏洞后，上传目录里多了一堆陌生 PHP。站点没「彻底沦陷」，但已经够麻烦——清马、核对权限、重做备份链路，花的时间比平时按节奏更新多得多。
这篇不讲「装十个安全插件就高枕无忧」，只写我实际在用的一套最小安全基线：更新怎么排、文件权限怎么卡、登录面怎么收、备份怎么验。默认你有 SSH/面板权限，生产变更放低峰，改之前能回滚。
这套基线适合谁
- 单站或少量站点的 WordPress 运维；主题/插件不算夸张。
- 能改
wp-config.php、目录权限、Web 服务器配置（或至少能提工单）。 - 有（或准备做）可还原的备份，而不是「面板里显示已备份」就完事。
不适合：完全没主机权限、只能点「一键安全」按钮却看不到文件与日志的场景——那种先把可观测性补上再谈加固。
原则先说清
- 可回滚优先于「一次改到位」。权限收太死、登录限制写错，先把自己锁在门外更常见。
- 更新是安全动作，不是锦上添花。很多入侵入口就是过期组件 + 公开漏洞。
- 备份没演练过 = 没有备份。只验证「文件在」，不验证「能还原出可登录的站」。
下面按我平时的顺序写，每步带预期现象和回滚点。
一、更新策略：先 Staging，再分批，再核冲突
生产机半夜全量点「全部更新」最容易出事。更稳的节奏大致是：
- 清单化：后台 → 更新，记下待更新的核心 / 插件 / 主题版本；顺便看 changelog 有没有「breaking / migration」。
- Staging 先跑：同一 PHP 版本、同一插件组合上更新；重点点：登录、关键表单、结账（若有）、定时任务、关键接口。
- 生产分批：安全补丁与小版本可优先；大版本主题/页面构建器单独窗口。一次只动一类，出问题好定位。
- 更新后立刻看：
debug.log/ 服务器错误日志、前台关键路径、后台插件页是否有「需要数据库升级」提示。
插件互相踩脚时，更新后白屏、管理栏报错很常见。若你需要系统化排查激活顺序与冲突面，可参考这篇：插件冲突时怎么缩小范围。
预期：Staging 无阻塞错误后，生产同批更新；出问题能指到「哪一个包」而不是「今天上午所有更新」。
回滚注意：
- 更新前对
wp-content/plugins、当前主题、数据库各留一份可还原快照（或至少插件 zip + DB dump）。 - 用 WP-CLI 时，单个插件回退比「整站时光机」更干净，例如先停用问题插件再换回旧包：
# 示例：先停用再换包（路径按你环境改）wp plugin deactivate problematic-plugin# 用备份的 zip 覆盖后wp plugin activate problematic-plugin- 核心大版本回退成本高，尽量避免「生产试错」；必须回退时用整站备份还原，而不是只换
wp-includes几个文件。
二、文件权限：够用就行，别学教程抄成 777
常见踩坑是共享主机教程让你「目录 777、文件 666」——等于邀请写入。更稳妥的起点（Linux，站点用户运行 PHP 时）：
| 对象 | 建议起点 | 说明 |
|---|---|---|
| 目录 | 755 | 属主可写，其他只读+进入 |
| 普通文件 | 644 | 属主可写，其他只读 |
wp-config.php | 440或400（视部署） | 尽量让 Web 其它用户读不到 |
uploads | 755，文件644 | 禁止执行比「全开写」更重要 |
Web 服务器用户与部署用户分离时，以「PHP 进程能否写 uploads / 缓存目录」为准微调，而不是全局放宽。
最小自检（SSH）：
# 粗查异常可写目录 / 可疑权限（按站点根调整）findwp-content-typed-perm-00022>/dev/null|headfindwp-content/uploads-name'*.php'2>/dev/null|head预期：uploads下不应出现业务插件自己的 PHP（除非你明确知道某个插件就这么干——多数情况应警惕）。世界可写目录应尽量为零。
回滚注意：批量chmod前先find … -ls导出一份权限快照；收紧后若主题/缓存无法写文件，只对必要目录放开属主写，不要整树 777。
Nginx/Apache 侧尽量禁止在uploads执行脚本（具体指令因环境而异）。改虚拟主机配置后先nginx -t/ 语法检查再 reload；失败就用旧配置回滚。
三、登录面收缩：少暴露，比「再装一个登录美化插件」有用
目标不是把后台藏到谁都找不到（安全靠隐蔽不长久），而是减少无意义暴露与暴力尝试面：
- 强密码 + 少管理员：管理员账号数量可控；共用「admin」这类用户名尽早改掉（改登录名比改显示名重要）。
- 限制登录尝试：用服务器级（fail2ban / WAF）或成熟限制插件二选一，别叠三套互相锁死。
- 管理入口：能限制来源 IP 的（办公室 / VPN）优先；做不到再考虑改写登录路径——改完必须把书签、监控、CI 一并改，否则等于自我拒绝服务。
- XML-RPC / 应用密码：不用就关或限制；外部客户端、Jetpack 类依赖要先确认再动。
DISALLOW_FILE_EDIT：生产建议打开，避免后台直接改插件/主题文件（被盗会话时危害更大）：
// wp-config.php（放在「That's all, stop editing!」之前）define('DISALLOW_FILE_EDIT',true);预期：登录失败会记日志或触发限制；编辑器里「插件文件编辑」菜单不可用；未授权 IP 访问wp-admin被拒（若你做了 IP 限制）。
回滚注意：
- 加 IP 白名单前先留一个「紧急入口」（控制台 / 另一网络 / 主机商面板改配置）。
DISALLOW_FILE_EDIT删掉该行或改为false即可恢复后台编辑；改wp-config.php语法错误会导致整站白屏——改前备份该文件，FTP/SSH 可覆写。
四、备份验证：备份任务绿勾不等于能救命
基线里我要求至少满足：
- 内容：文件（至少
wp-content+ 配置）+ 数据库，两者时间点可对齐。 - 异地：不全放在同一块云盘/同一台机器。
- 保留策略：能回到「出事前一天」，而不是只留最新一份被加密软件一起加密。
- 演练：每季度至少一次在隔离环境还原，确认能打开前台、能登录后台、关键订单/表单数据还在。
可用 WP-CLI 做库导出（示例）：
wp dbexport/backup/wp-$(date+%F).sql --add-drop-table还原演练在临时目录 / 临时库做，不要直接冲生产。验收清单可以很短：
- 还原后
wp core is-installed成功（或后台可登录） - 随机抽 3 篇内容 / 1 个媒体 URL 可访问
- 关键插件、支付（若有）无致命报错
- 记录还原耗时，方便事故时估 ETA
预期：你能说清「RPO/RTO 大概多少」——哪怕很粗，也比「应该有备份」强。
回滚注意：演练用的临时站用完就毁；生产还原前再打一份「事故当下」快照，避免还原半截发现备份本身坏了却无退路。
五、一次性核对清单（建议贴进运维文档）
- 核心 / 插件 / 主题更新策略写明：谁批、谁点、失败找谁
- Staging 与生产 PHP、扩展大致一致
- 目录/文件权限非 777；
uploads无异常 PHP wp-config.php权限收紧；DISALLOW_FILE_EDIT已开（生产）- 登录限制或 IP 策略已测过「自己进得去」
- 备份含 DB+文件；异地；近 90 天内做过还原演练
- 出问题能回滚：配置副本、插件旧包、DB dump 路径写在文档里
常见坑
- 只装安全扫描插件、从不看报告：扫描噪声很多，要有人认领误报与真阳性。
- 更新与改主题文件搅在一起：出问题分不清是更新还是手工改动，回滚无从下手。
- 权限一次收到 PHP 无法写 cache：前台全动态、CPU 打满，看起来像「被打」，其实是自己关错写权限。
- 备份只备份 uploads：数据库没了，媒体文件也救不回文章与订单。
- 把安全当一次性项目：基线要定期复查，尤其是加人开权限、上新插件、迁主机之后。
小结
安全加固不是堆功能，而是把更新、权限、登录面、备份四件事做成可重复、可回滚的习惯。先保证「能更新、能还原、登录面不裸奔」，再考虑 WAF、双因素、更细的审计日志。任何收紧动作都以「改坏了 10 分钟内能撤」为前提。
延伸阅读
若你更需要先摸清当前站的配置与风险面，再决定加固优先级，可从这里做一次结构化自检：WordPress 站点诊断与问题优先级。（诊断给出的是排查方向与清单，不承诺「加固后一定不被入侵」或任何效果保证。）
