WordPress安全加固与挂马排查实战：攻击面、插件漏洞与配置防护

1. 先弄清攻击面：WordPress 为什么总在被扫描

如果你手上有一台对公网开放的服务器，跑着一个 WordPress 站点，那你大概见过这样的日志场景：/wp-login.php每天被 POST 几百次，/wp-content/plugins/下面被挨个目录翻，/xmlrpc.php被反复戳，偶尔还有人在找/wp-config.php.bak。这些流量很多都不是冲着你来的，而是自动化扫描器在按字典做批量作业——WordPress 在全球站点里占比太高，扫描器的投入产出比很高，所以它天然是第一批被照顾的对象。

这篇内容想聊的不是“怎么打”，而是站在建站方和运维方的角度，把 WordPress 这类 CMS 上最常见的安全问题掰开揉碎：漏洞到底出在哪些层、为什么出、怎么验证自己有没有中招、加固该从哪儿下手。适合三类人看：自己搭站点的独立开发者、负责几十上百个站点的运维、以及刚接触 Web 安全想找个真实样本练手的同学。哪怕你只会装主题、装插件，照着文里的清单走一遍，也能把大部分自动化扫描挡在门外。

先说一个很多人容易忽略的判断：绝大多数 WordPress 站点被攻陷，原因不在于 0day，而在于“知道但没做”。版本没更新、插件废弃了还留着、后台路径没改、备份文件放在 Web 根目录、数据库用的是默认前缀。这些事情每一件单独看都不致命，叠在一起就是一个敞开的后门。所以后面讲的所有内容，你都可以理解成一句话的展开——把已知的、低成本的错误逐个堵死。

1.1 把攻击面拆成三层来看

我习惯把 WordPress 的安全问题拆成三层，这个划分在排查的时候特别有用，因为它直接决定了你该去哪儿找痕迹。

第一层是应用核心。WordPress 本体经过多年打磨，核心代码里直接可利用的漏洞已经很少了，一旦爆出来，官方修复速度也快。但核心层有两个长期存在的“功能即风险”的点：一是登录与接口入口（wp-login.php、xmlrpc.php、REST API 的用户枚举），二是内置的主题/插件在线编辑器，只要后台账号拿到手，编辑器就能直接改文件，等于把后台账号变成了文件写入权限。

第二层是插件与主题。这是重灾区，占的比例最高。原因不复杂：生态里插件数量巨大，质量参差不齐，很多小团队写完就不再维护，而站点主又倾向于“装上就不管了”。一个废弃插件留下的上传点、SQL 拼接、文件包含，可以放好几年没人修。

第三层是主机与配置。这一层经常被完全忽略，但它决定了“被打进去之后损失多大”。文件权限、目录索引、备份文件位置、PHP 运行用户、数据库账号权限，这些都归这一层。同样的漏洞，配置好的站点可能只是被人读到一个无效文件，配置差的站点直接从网站被穿透到数据泄露。

三层的关系是：第一层和第二层决定“能不能进来”，第三层决定“进来之后能拿走什么”。加固的时候，两层都要管，但优先做第三层——因为第三层的成本最低、收益最稳定，而且不依赖任何第三方代码的质量。

1.2 漏洞分布的经验比例与判断误区

我不太喜欢引用具体统计数字，因为口径差别太大，这里说个经验判断：在真实遇到的失陷案例里，插件和主题贡献的问题大概占七成以上，配置类问题占两成左右，核心本体直接被打穿的比例很低。这个比例不是精确统计，但足够指导你把精力放在哪儿。

围绕这个，有三个特别常见的误区，我见过太多人踩：

• 误区一：只要版本是最新的就安全。不是的。更新解决的是“已知 CVE”，但你的插件组合、你的配置、你的弱口令，官方更新管不着。而且很多站点更新失败自己都不知道——文件权限不对、磁盘满、DISALLOW_FILE_MODS被某个配置文件打开了，结果后台显示“已是最新”，其实根本没更新成功。
• 误区二：装了安全插件就等于加固了。安全插件主要做的是规则拦截和日志，它改不了你插件的代码质量，也拦不住有权限的合法操作。它是一层缓冲，不是保险。
• 误区三：站点小、没流量，不会被盯上。扫描是自动化的，不看你的流量。小站反而更容易成为跳板，因为没人管、没人看日志。

提示：判断一个站点有没有被扫描过，不用装任何工具，直接看 Web 服务器访问日志里/wp-login.php的 POST 次数和/wp-content/plugins/的 404 数量就够了。这两个指标异常高，说明已经被扫过很多轮了。

2. 六类高频问题逐个拆解

下面这几类，是我在帮人看站点的过程中反复遇到的。每一类我都会说清楚“问题长什么样、为什么会出现、怎么快速自查”。

2.1 登录入口暴露与凭据强度不足

这是最低成本也最高频的一类。自动化程序不需要任何漏洞，只要用户名和密码猜对了就能进后台，进来之后想干什么干什么。

问题的根子在于三点。第一，/wp-login.php这个路径是固定且公开的，扫描器根本不需要探测。第二，WordPress 默认允许通过作者归档页、REST API 的用户接口、以及?author=1这类重定向来枚举用户名，用户名一旦确定，暴力破解的计算量直接少一半。第三，很多站点的管理员账号名就是站点名或者admin，配合常见弱口令字典，命中率不低。

还有一个被大量滥用的点：xmlrpc.php。这个接口本来是为老式客户端准备的，但它支持在单次 HTTP 请求里携带多个方法调用，等于把暴力破解的“请求次数”这个限制绕过去了——原本限流是一分钟 5 次请求，现在一次请求里塞几百个密码尝试。很多站点的登录限流插件对wp-login.php有效，对xmlrpc.php完全没拦住。

自查方法很简单，浏览器里依次访问这几个地址，看返回什么：

2.2 插件与主题的已知漏洞与“废弃依赖”

这类问题的典型形态是：站点上装了一个两三年前很流行、现在已经停止更新的插件，或者装了一堆功能重叠的插件，其中某个只在后台用了一次就再没管过。

漏洞的具体形态五花八门，但成因基本归为几类。一是输入没有做能力校验，比如一个处理表单提交的接口，只检查了 nonce，却没检查当前用户有没有对应权限，导致低权限用户甚至未登录用户能触发管理员级操作。二是文件操作路径拼接不严，上传、删除、导入导出这类功能最容易出问题，参数里带../就可能越界。三是数据库查询手工拼接，虽然 WordPress 提供了预处理接口，但老代码里字符串拼 SQL 的写法依然大量存在。四是反序列化入口，很多插件用unserialize处理缓存或者导入数据，一旦可控就是一个对象注入链的起点。

这里我不点具体插件名，也没必要——你需要的是一个可执行的判断流程，而不是一份名单。流程是这样的：

1. 导出当前所有插件和主题的清单（后台插件页复制，或者直接ls wp-content/plugins）。
2. 逐个确认“最后更新时间”和“兼容的 WordPress 版本”。超过一年没更新、兼容版本落后两个大版本以上的，标记为高风险。
3. 对高风险项问一句：这个插件现在还有实际功能在被使用吗？如果只是当初装着想试试、后来忘了删，直接停用并删除。这一条能砍掉大部分风险，而且零成本。
4. 剩下的必须保留的，去官方仓库看它的更新日志，重点看“安全修复”字样的版本，确认自己是不是在那个版本之上。

注意：停用和删除是两回事。停用只是不加载，文件还在磁盘上，如果插件目录里有一个可以被直接访问的 PHP 文件（比如某个调试脚本），它依然可能被直接请求执行。不需要的插件，删干净。

2.3 配置疏漏：被遗忘的文件与目录

这一类问题不涉及任何代码漏洞，纯粹是“东西放错地方了”。但它的杀伤力经常比漏洞还大，因为泄露的是原始信息。

我按危害从高到低列一下常见的：

• wp-config.php的备份副本。有人改配置之前习惯复制一份wp-config.php.bak、wp-config.php.old、wp-config - 副本.php，就放在同目录。服务器如果没做特殊处理，这些文件会被当纯文本返回，里面明文写着数据库地址、库名、用户名、密码、以及各种密钥盐值。拿到这些，数据库基本等于敞开。
• 数据库导出文件。backup.sql、xxx.sql.gz、dump.zip放在网站根目录，扫描器有一整套常见备份文件名字典，命中率不低。
• 版本管理残留。部署时把.git目录一起传上去了，.git/config和.git/HEAD可读，配合工具可以把整个源码历史拉下来，包括已经删掉的、含密钥的历史提交。
• 目录索引未关闭。/wp-content/uploads/直接列出所有文件，攻击者不用猜文件名就能拿到全部上传内容，包括一些本该私有的文档。
• 调试日志外泄。开了WP_DEBUG_LOG之后，/wp-content/debug.log会记录所有报错，里面常有完整文件路径、数据库查询语句、甚至会话信息。

自查就一条命令的事，在站点根目录下用 find 找可疑文件名，或者直接浏览器里挨个试。养成习惯：任何以.bak、.old、.sql、.zip、.log、.swp结尾的文件，都不应该出现在 Web 可访问目录里。这条规则简单，但能挡掉大量真实事故。

2.4 后台文件编辑能力与上传路径

WordPress 后台自带两把“双刃剑”：外观里的主题文件编辑器，和插件里的插件文件编辑器。它们的本意是方便临时改点小东西，实际效果是——后台账号一旦失守，等于直接拿到文件写入权限。

从攻击链的角度看，这是一个非常顺滑的升级路径：弱口令进后台 → 打开主题编辑器 → 往functions.php里塞一段代码 → 站点每个页面加载时都会执行。整个过程不需要任何提权，也不需要服务器层面的漏洞。而且这种改动藏在主题文件里，很多站点主只检查插件目录，根本想不到去看主题。

同样的道理适用于上传目录。wp-content/uploads/默认是 Web 可访问的，如果某个插件对上传文件的类型校验不严，允许传.php或者允许双扩展名（a.jpg.php），那上传目录就变成了一个可执行目录。这里的关键点在于服务器配置：如果 Web 服务器对 uploads 目录禁用了 PHP 解析，那么即便传上去也执行不了，风险降一个量级。

所以这块的加固是双管齐下：应用层把编辑器关掉，服务器层把 uploads 目录的执行权限关掉。两道闸门，任何一道失效，另一道还在。

2.5 权限模型与数据库账号的最小化

WordPress 的用户角色体系是“管理员 / 编辑 / 作者 / 投稿者 / 订阅者”。问题在于很多人图省事，给合作方、给外包、给临时帮忙的人都开管理员。管理员能装插件、能改主题文件、能改其他用户密码，一个账号泄露就是全站沦陷。

正确做法是按实际需要给最小角色。只写文章的给作者或投稿者，只改页面的给编辑，需要装插件的再单独开管理员，而且管理员账号数量控制在两三个以内。多站点环境下还要注意超级管理员的范围。

数据库账号也是同理。很多人装 WordPress 时直接用了 root 或者一个拥有全库权限的账号。WordPress 只需要自己那个库的增删改查权限，DROP、FILE、以及跨库访问的权限都不需要。把这些收掉，即便有一天应用层被 SQL 注入，攻击者能做的事情也被压缩了——他没法用INTO OUTFILE写文件，也没法读别的库。

表前缀不要用默认的wp_。这件事经常被说成“安全措施”，其实它更像“降低自动化攻击的便利度”。它的真实作用是：让那些硬编码了wp_users的自动化注入语句失效。手工攻击者不受影响。所以它的定位是“提高一点点门槛”，不是“防护手段”，别把它当成主要依赖。

2.6 对象注入与反序列化问题的现实影响

反序列化这块值得单独说两句，因为它是近几年 WordPress 生态里比较典型的一类问题，而且普通站点主很难自己判断。

原理不复杂：PHP 在把一个对象序列化成字符串（便于存数据库或者传输）的时候，只记录类名和属性值；反序列化时会根据类名去实例化对象，并自动调用一些魔术方法。如果某个插件里有一个可被控制的unserialize入口，同时代码库里又存在带有危险操作的魔术方法，两者串起来就能形成一个利用链。真实案例里，经常是“某表单插件存草稿”加上“某页面构建器的魔术方法”组合成一条链。

对站点主来说，你不需要会写这条链，但你需要知道两件事：

第一，这类漏洞几乎都出现在插件里，且大多需要一定的前置条件（比如能提交某种数据、能拿到某个低权限账号）。所以降低影响面的办法还是那几条：少装插件、及时更新、权限最小化。

第二，这类问题的修复完全依赖插件作者。你没法通过配置绕过去。所以当你在某个安全公告里看到自己用的插件命中，唯一正确的做法是升级到修复版本；如果作者不修了，那就换插件，不要心存侥幸。

3. 加固实操：从服务器到应用的完整清单

这一节是可以直接照着做的部分。我按“从上到下”的顺序排，即先服务器、再应用配置、最后运营习惯。每一层都给出具体的做法和背后的理由，不是那种“建议加强安全”的空话。

3.1 服务器层：先把执行权限管住

这一层的核心思想是：不是所有目录都需要执行 PHP。WordPress 的目录结构很规整，每个目录的职责是固定的，那就按职责配权限。

假设站点根目录是/var/www/example，Nginx 的配置里可以这样处理：

# 禁止访问隐藏文件与备份文件 location ~* /\.(?!well-known) { deny all; access_log off; log_not_found off; } location ~* \.(bak|old|orig|save|swp|sql|sql\.gz|tar\.gz|zip|log)$ { deny all; } # uploads 目录不解析 PHP location ^~ /var/www/example/wp-content/uploads/ { location ~ \.php$ { deny all; } } # wp-content 下的 PHP 只允许特定场景，视插件情况调整 location ^~ /var/www/example/wp-content/ { location ~* /(cache|uploads|upgrade)/.*\.php$ { deny all; } } # 屏蔽 xmlrpc location = /xmlrpc.php { deny all; }

这段配置解决三个问题：备份文件不再能被下载、上传目录不再是可执行目录、xmlrpc.php直接关掉。第三点如果站点确实有用到（比如老版本的移动端 App 发布），可以改成只允许特定 IP，而不是完全关闭。

Apache 用户用.htaccess也能实现同样效果，在wp-content/uploads/下放一个：

<FilesMatch "\.(?i:php|phtml|php3|php4|php5|php7|phps)$"> Require all denied </FilesMatch>

注意：改完配置一定先nginx -t验证再 reload，别把站点搞挂了。另外，如果你的站点会通过 CDN 回源，deny all拦的是回源请求，前端可能还在正常显示缓存页面，别被假象骗了，直接 curl 源站 IP 验证。

服务器层还有两个细节值得做。一是PHP 运行用户与文件属主分离，Web 进程不要以 root 跑，也不要把整个站点目录设成 777——777 意味着任何进程都能改你的代码，一旦别的站点或服务被拿下，你这儿也跟着完蛋。目录 755、文件 644、wp-config.php设 600 或 640，这是基准值。二是关闭目录索引，Apache 里Options -Indexes，Nginx 里autoindex off，这是默认值，但很多整合包会把它打开。

3.2 应用层：wp-config.php 里值得改的几项

wp-config.php是 WordPress 的配置中心，里面有几个开关直接影响安全表现。我按重要性排序说。

第一，把文件编辑功能关掉。加这一行：

define('DISALLOW_FILE_EDIT', true);

它的作用是移除后台的主题编辑器和插件编辑器。前面说过，后台账号一旦泄露，编辑器就是文件写入入口。关掉它，攻击者进后台之后还得另找上传点，成本上升一大截。副作用是有些站长习惯了在线改代码，关掉之后得用 SFTP，这其实是好事。

第二，调试模式只开日志、不开显示。生产环境应该是这样：

define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); define('SCRIPT_DEBUG', false);

WP_DEBUG_DISPLAY设成 false 是关键，否则 PHP 报错会直接渲染到页面上，把完整文件路径、甚至某些配置信息暴露给访客。日志文件会写到wp-content/debug.log，记得用上一节的规则把这个路径挡掉，或者干脆把日志重定向到 Web 根目录之外。

第三，禁用后台插件/主题安装，如果你的部署流程是代码化的话。

define('DISALLOW_FILE_MODS', true);

这一条要谨慎，因为它会同时禁掉自动更新。适合那种“本地开发 → 提交 → 流水线部署”的团队；如果你的更新是靠在后台点按钮，那就不要开。

第四，密钥盐值要唯一。AUTH_KEY、SECURE_AUTH_KEY、LOGGED_IN_KEY、NONCE_KEY这一组八个常量，必须是随机且唯一的。有些一键安装包会给所有站点塞同一组默认值，这意味着一个站点的 Cookie 可以被拿去伪造另一个站点的登录态。换掉它们的方法很简单，用官方提供的在线生成器生成一组，替换进去，然后所有人重新登录一次。

第五，数据库账号权限收窄。装 WordPress 用的那个数据库用户，只给它自己那个库的SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP就够了（DROP在升级时要用，如果不打算在后台升级可以收掉），不要给FILE、PROCESS、SUPER，也不要给其他库的权限。

3.3 登录与接口的访问控制

登录这块的加固思路是“减少暴露面 + 提高尝试成本”。

减少暴露面最直接的办法是改登录路径。用一个插件或者一段服务器规则，把/wp-login.php换成一个只有你知道的路径。这不是“隐藏即安全”，因为老路径仍然要返回 404 而不是跳转，否则一眼就被人看出来了。它的价值在于把海量的自动化扫描请求直接过滤掉——扫描器不会为单个站点定制路径。这一招的效果非常明显，日志里/wp-login.php的 POST 会立刻归零。

提高尝试成本的做法有三个，可以叠加：

• 限制登录失败次数，比如同一 IP 5 分钟内失败 5 次就锁 15 分钟，同一账号失败 10 次就锁。注意要同时按 IP 和按账号计数，只按 IP 会被代理池绕过，只按账号会被人拿字典刷别人账号导致误锁。
• 强制管理员开启两步验证，现在主流的双因素插件都支持 TOTP，手机上一个验证器 App 就行。这一条对防弱口令的效果最好，因为密码泄露了也进不去。
• 在服务器层给/wp-admin/加一层额外认证，比如 Nginx 的auth_basic，或者只允许固定 IP 段访问。这层是独立于 WordPress 的，账号体系再出问题，这层还在。

接口方面，REST API 的用户枚举要关掉。可以在主题的functions.php里加一段过滤，或者用插件处理。原则是：未登录用户不需要看到用户列表。同时检查一下/wp-json/根路径返回的路由列表，如果里面有一堆你没在用的插件暴露的接口，考虑按需禁用。

还有一个小小的但很实用的规则：禁止后台直接访问 PHP 文件。wp-admin/和wp-includes/下的 PHP 文件大多数是给 WordPress 内部 include 的，不应该被直接请求。在服务器层加一条规则，对这两个目录下除admin-ajax.php、admin-post.php等少数入口外的 PHP 请求返回 403，能挡掉不少针对特定文件的探测。

3.4 更新策略与插件准入制度

技术手段只是一半，另一半是流程。我见过太多站点，加固做得挺到位，结果因为“半年没登录后台”而躺在某个插件的旧版本上。

我的建议是把更新分成三档：

配套的是插件准入制度。新装一个插件之前问三个问题：它解决什么问题？现有插件能不能替代？作者最近一年有没有更新？这三个问题能挡掉一半的冲动安装。装完之后记一笔，写清楚装的时间、用途、负责人，每季度review一次，把不用的删掉。

还有一个很实际的做法：在测试环境跑一遍再上生产。WordPress 的更新出问题，绝大多数是插件兼容性，而不是核心本身。有个测试站，把生产的数据导一份过去（记得脱敏），先在那儿点更新，观察一天，没问题再上生产。这个流程听起来麻烦，但比半夜被叫起来恢复站点要轻松得多。

3.5 日志与告警：让自己能看见

没有日志，前面所有的加固都是“盲修”。你改了什么、有没有效果、有没有人正在试，全靠日志说话。

最低限度要保留三类日志：Web 服务器的访问日志和错误日志、PHP 的错误日志、WordPress 自身的日志（配合审计类插件记录登录、插件安装、用户变更、文件修改）。

看日志不用天天看，但要设几个告警规则：

• 单个 IP 在 5 分钟内对/wp-login.php的 POST 超过 20 次。
• 出现对/wp-content/plugins/*/下不存在目录的批量 404（说明在扫描）。
• 后台出现新的管理员账号，或者现有管理员密码被改。
• wp-content目录下有文件被修改（用文件完整性监控，或者简单的定时校验和比对）。
• 出现对.env、.git/config、wp-config.php.bak的请求。

前两条是“有人在外面敲门”，后三条是“可能已经进来了”。分开设，响应动作不一样。

4. 站点被挂马之后，我是怎么一步步定位的

这一节讲排查。假设你已经发现异常了——页面底部多了奇怪的链接、搜索结果里站点标题被改、浏览器报恶意跳转、或者服务器 CPU 莫名跑满。别慌，按顺序来。

4.1 先确认现象，别急着删文件

第一步是把现象记录下来：哪个页面有问题、什么时候开始的、访客看到的是什么、有没有特定来源才触发（比如从搜索引擎点进来才跳转）。这一步很多人跳过，直接开始删文件，结果删错了地方，问题还在，还丢了线索。

几个典型的“选择性触发”现象值得注意：只在移动端 UA 下跳转、只在来自搜索引擎 referer 时跳转、只在管理员登录状态下隐藏。这类隐蔽手法说明攻击者已经拿到了较高的控制权，而不是简单的注入一段 HTML。

4.2 定位落地点的四个方向

按经验，落地点集中在这几个地方，我按排查顺序排：

方向一：主题文件，尤其是functions.php和header.php。因为后台编辑器就在这儿，改起来最方便。检查方法不是肉眼看，而是拿官方同版本的主题包做对比，或者找一个干净的备份做 diff。看新增的eval、base64_decode、gzinflate、str_rot13，以及大段看起来像乱码的字符串。

方向二：wp-content/uploads/下的可疑文件。上传目录本来不该有 PHP 文件，出现了就是问题。用find按扩展名筛一遍，重点看时间戳和站点正常运营时间不匹配的。

方向三：数据库里的wp_options表。有两个键经常被利用：siteurl和home（改了会跳转），以及active_plugins（塞一个恶意插件进去）。另外wp_posts表里的文章内容可能被批量插入了隐藏链接，用 SQL 搜一下display:none、<iframe、position:absolute;left:-这类特征。

方向四：计划任务。WordPress 有个wp_cron机制，恶意代码可能挂在cron数组里定时执行。在wp_options里搜cron键，看有没有不认识的钩子。同时检查系统层的 crontab，有些后门是直接写系统定时任务的。

排查时有个技巧很省时间：按时间排序看最近修改的文件。用find . -type f -newermt "2024-01-01" -name "*.php"，把最近改动的 PHP 文件列出来，跟你的正常发布记录对照。哪个对不上，哪个就可疑。

4.3 清理顺序与验证

找到之后不要直接删，先备份一份到 Web 目录之外，留作分析。然后按这个顺序处理：

1. 先断开入口——改所有管理员密码、改数据库密码、换密钥盐值（这一步会让所有登录态失效）、如果怀疑服务器层被拿下，还要检查 SSH 密钥和系统用户。
2. 清理文件——用官方包覆盖核心文件（wp-admin、wp-includes整个覆盖，不要挑着改），主题和插件重新从官方源下载覆盖。
3. 清理数据库——手工删掉可疑的wp_options记录、可疑文章、可疑用户（尤其是隐藏的管理员，检查wp_users里注册时间和最后登录时间异常的账号）。
4. 清理计划任务——WordPress 的 cron 和系统的 crontab 都要看。
5. 重新扫描一遍——用文件完整性比对工具再跑一次，确认没有残留。

验证的标准不是“页面看起来正常了”，而是：所有文件与官方源一致，数据库里没有未知的管理员和未知的 options 记录，日志里没有新的异常请求。这三条都满足，才算收工。

4.4 复盘：问清楚“它是怎么进来的”

清理完别急着结束，花半小时想清楚入口在哪。常见答案就那么几个：某个插件的老版本漏洞、某个账号的弱口令、某个泄露的备份文件、某台机器上的其他站点被拿下后横向渗透。

如果找不出入口，那大概率还会再来一次。这时候的务实做法是：把整站迁到一台干净的新机器上，只迁内容和必要的插件，旧服务器直接下线。听起来粗暴，但比重装一遍又被同一路径打进来要省事。

5. 常见问题速查表

把前面散落的问题集中成一张表，出问题的时候可以直接对照。

6. 几个我踩过之后才当回事的细节

最后说几个具体的东西，都是从实际处理中总结的，文档里通常不会写。

第一，wp-content/debug.log会长得非常大。一旦开了WP_DEBUG_LOG，一个报错频繁的插件能在几天内把日志写到几个 G，直接把磁盘撑爆。所以要么定期轮转，要么把这个日志路径指向/var/log/下面，交给系统的日志轮转管。

第二，改表前缀这件事，光是改wp-config.php里的$table_prefix没用，数据库里的表名也要一起改，而且还要改wp_options里wp_user_roles这个键名（它里面硬编码了表前缀）。改错了站点直接白屏。所以要改就一次改到位，改之前先备份。

第三，.htaccess里的规则不是越多越好。我见过有人在里面堆了几十条规则，结果某次插件自己往.htaccess里写规则（很多缓存插件会这么干），把自定义规则覆盖掉了，加固全部失效，还没人发现。所以关键规则尽量放服务器主配置里，.htaccess只放必须在应用层解决的。

第四，备份要放在 Web 根目录之外，而且要有恢复演练。备份文件本身是最大的泄露源之一，前面说过。另外，很多人备份了好几年，从来没恢复过，真出事的时候才发现备份是坏的。每季度挑一个备份，在测试环境恢复一次，确认能用。这个动作花不了多少时间，但能救命。

第五，也是最重要的一条：安全不是一个状态，是一个持续的动作。你今天把这些都做完了，三个月后装了两个新插件、改了一次配置、换了个服务器，状态就变了。所以把它做成清单，每季度过一遍，比一次性做得多完美都管用。我自己的清单就十几行，每次照着走一遍，二十分钟，能解决绝大部分问题。