⭐ 推荐:社区规则条款 V1.0

安装完 CMS 后必须做的安全加固步骤有哪些?

chinaz
chinaz 归队站长新人站长
发布于 2026-10-14 17:41 ·3 浏览 ·3 回复
内容摘要

安装完CMS后应先完成改默认账号与后台入口、设文件权限、锁定更新通道、上HTTPS与安全响应头、加固数据库、配好备份和登录防护六项加固再上线,可挡九成以上自动化扫描和批量爆破。

装完 CMS 后最该做的不是发第一篇文章,而是先完成 6 项加固:改默认账号与后台入口、设定文件权限、锁定更新通道、上 HTTPS 与安全响应头、加固数据库、配好备份和登录防护。做完这 6 项再上线,能把 90% 以上的自动化扫描和批量爆破挡在门外。

安装完 CMS 第一件事做什么?先处理默认账号和后台入口

结论:默认管理员用户名(admin、root、administrator)和默认后台路径是自动化脚本扫描的第一目标,必须在发布内容前改掉。

具体做法是三步。第一,新建一个用户名不含 "admin" 的管理员账号,用新账号登录后删除或降权旧账号,昵称也不要暴露登录名(WordPress 会默认用昵称做作者页 URL)。第二,密码长度至少 16 位,用密码管理器生成,不用字典词加数字的组合。第三,开启两步验证(TOTP 类型,即 Google Authenticator 这类 6 位动态码),这一步比改密码更有效,因为被拖库的密码对 2FA 无效。

后台入口可以通过插件或 Nginx 规则改路径,但要清楚:隐藏入口只是降低扫描噪音,不能替代 2FA 和强密码。

文件权限应该设成多少?

结论:目录 755、文件 644、配置文件 600,属主设为 Web 运行用户(如 www-data),任何情况下都不要出现 777。

命令层面可以这样执行:

find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 600 /var/www/html/wp-config.php
chown -R www-data:www-data /var/www/html

同时关掉 PHP 的危险函数,在 php.ini 中设置:
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,show_source
并把 expose_php = Off,避免响应头泄露 PHP 版本。

另外要禁止上传目录执行 PHP,Nginx 加一条:
location ~* /(uploads|files)/.*\.php$ { deny all; }
这条规则能直接掐断大部分「传个图片马再访问」的提权路径。

CMS 核心和插件要多久更新一次?

结论:核心安全补丁建议开启自动更新,插件和主题每月检查一次,装而不用的一律删除。

WordPress 从 3.7 起支持小版本自动更新,5.6 起支持大版本自动更新,建议至少开启小版本自动更新。插件是第三方代码,漏洞占比最高,判断标准很简单:最近 12 个月没有更新、安装量低于 1 万、作者已停止维护,这三类直接换掉。

停用插件不等于安全,未删除的插件文件仍可能被直接访问,所以不用的要删除而不只是停用。主题同理,默认主题之外保留一个备用即可。

HTTPS 和安全响应头怎么配?

结论:全站 HTTPS 是底线,再补 4 个响应头可以挡掉点击劫持、MIME 嗅探和降级攻击。

证书用 Let's Encrypt 免费签发,certbot 支持自动续期(证书有效期 90 天,certbot 默认提前 30 天续)。强制跳转 301 从 HTTP 到 HTTPS。然后在 Nginx 加:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;

HSTS 的 max-age 建议先用 300 秒测试,确认全站没有混合内容后再调到 31536000(一年)。

数据库和登录爆破怎么加固?

结论:数据库用户只授权单个库、只允许本机连接;登录失败 5 次锁定 15 分钟,能挡掉绝大多数暴力破解。

建站时改掉默认表前缀(wp_ 改成随机 6-8 位),并单独建库用户,只授予该库的 SELECT/INSERT/UPDATE/DELETE 权限,不给 DROP 和 GRANT。MySQL 的 bind-address 设为 127.0.0.1,禁止 3306 对外网开放。

登录防护用 fail2ban 的 WordPress jail,配置 maxretry = 3、bantime = 3600,即失败 3 次封 IP 一小时。云服务器上再叠加安全组的 22 端口限源,能减少 80% 以上的 SSH 爆破日志噪音。

备份和日志要怎么做?

结论:按 3-2-1 原则做备份——3 份副本、2 种介质、1 份异地,数据库每日一次、整站每周一次,并每季度做一次恢复演练。

只备份没验证过恢复的备份等于没有备份。日志方面至少保留 Web 访问日志和登录日志 30 天,定期查 404 突增和 /wp-login.php 的高频访问,这两个信号通常出现在入侵之前。

把这 6 项做完,CMS 的安全基线就算立住了。顺序上优先做账号、权限和备份三项,因为它们投入最小、收益最大;HTTPS 和安全头属于一次性配置,配完长期有效;更新和日志是持续动作,需要每月检查一次。

本文转载自 GJ站长论坛,原文地址:https://www.gj0.com/thread-1967.html
转载请注明出处,版权归原作者所有。
—/ 5暂无评分
还没有评分,来打第一分吧

全部回复 3

liulian
liulian 归队站长新人站长 1楼 2026-10-14 17:49

这 6 项的顺序是对的,但建议在最前面补一步:先做一次能验证恢复的全量备份(含数据库),再动手改权限和入口——因为前两步最容易把自己锁在门外。

权限这块有几个细节帖子里没提。chown -R www-data 之后,你后续如果用 root 通过 SFTP 传文件,属主会变回 root,结果是后台装插件、传图全失败,得重新修一遍属主;保险做法是给自己的账号加进 www-data 组并把目录设成 775/664,而不是每次都 root 直传。另外 chmod 600 wp-config.php 对部分面板(宝塔、cPanel 这类)会让后台改配置失效,遇到报错就退到 640 并确认属组正确。

登录防护上,光改后台入口不够,/wp-login.php 和 xmlrpc.php 仍是爆破重灾区,尤其 xmlrpc 的 system.multicall 能绕过很多限速插件。建议直接禁用 xmlrpc,并关掉 /wp-json/wp/v2/users 的用户枚举;Nginx 前面有 CDN 或反代时,记得配 real_ip_header 和 set_real_ip_from,否则 fail2ban 封的是 CDN 的 IP,等于白封。2FA 启用后一定要把恢复码离线存好,插件冲突或换手机时它就是唯一退路。

你帖子里被截断的响应头部分,补一句:HSTS 先只写 max-age,稳定运行一段时间再加 includeSubDomains,preload 别急着上——一旦提交 preload 列表,回退周期以月计,子域名有 HTTP 服务的话会直接全站打不开。

延伸一个最常被忽略的:加固完记得在 wp-config.php 里加 define('DISALLOW_FILE_EDIT', true),堵住后台直接编辑主题/插件文件这条提权路,比再装一个安全插件实在。

lqyyzz
lqyyzz 观望站长 #1517 2楼 2026-10-14 18:05
liulian:这 6 项的顺序是对的,但建议在最前面补一步:先做一次能验证恢复的全量备份(含数据库),再动手改权限和入口——因为前两步最容易把自己锁在门外。 权限这块有几个…

这几条我基本都踩过,尤其属主和 real_ip 那两条,属于「配置看着全对、实际完全不生效」的典型。在此基础上补几个容易反噬的细节。

权限 775/664 别全站放开,只给 uploads、cache、upgrade 这几个真正需要写的目录,其余保持 755/644。否则等于把可写权限从上传目录扩到了全站,一个图片马或插件漏洞就能直接改核心文件,前面那条 deny all 也没意义了。备份同理:文件别落在 Web 根目录下,或者 Nginx 补一条拦 .sql|.zip|.tar|.gz 的 location,否则备份本身就是最大的泄露源。至于「能不能恢复」,光看备份文件生成成功不算数,把 sql 导进一个临时库跑一遍 mysql < backup.sql 才知道,这一步偷懒的人最多。

set_real_ip_from 只填 CDN 的回源 IP 段,千万别图省事写 0.0.0.0/0——那等于任何人伪造一个 XFF 头就能冒充任意 IP,fail2ban 不但封不准,还能被拿来反向封掉真实用户。用户枚举除了 /wp-json/wp/v2/users,还有 ?author=1 的 301 跳转会把用户名暴露在 Location 里,可以一并 rewrite 掉。

两个提醒:DISALLOW_FILE_MODS 别顺手加,它会把插件安装和自动更新一起禁掉,除非你全走手动部署;禁 xmlrpc 之后 WP 官方 App 和 Jetpack 会受影响,用的话得放行白名单。

最后一句和你的建议呼应:切换新账号、启用 2FA 之前,一定先用无痕窗口把新账号登录、TOTP 和恢复码各验证一遍,确认无误再删旧账号,这是唯一能避免「把自己锁在门外」的保险。

域名注册
域名注册 版主归队站长新人站长 👑年卡会员 #1519 3楼 2026-10-14 18:26
lqyyzz:这几条我基本都踩过,尤其属主和 real_ip 那两条,属于「配置看着全对、实际完全不生效」的典型。在此基础上补几个容易反噬的细节。 权限 775/664 别…

这几条补充基本把「配置生效」和「配置看着生效」的差别说透了,我只在两三个地方再往下补一层。

权限那块还能再狠一点。只给 uploads/cache/upgrade 写权限是对的,但更彻底的是给 uploads 单独挂个 noexec,nosuid 的挂载点,没条件就用 open_basedir 把 PHP 能触达的范围圈死在站点目录内。还有个隐藏坑:很多一键包默认把源码 chown 给 www-data,而 PHP-FPM 又跑在 www-data 下,这种情况下 755 也拦不住进程改自己的代码,理想状态是 Web 用户对代码目录只读、只对 uploads 可写。

real_ip 我补一句,CDN 的回源段是会变的,Cloudflare 得定期同步官方列表,同时 real_ip_header 要跟 CDN 实际传的头对齐(CF 是 CF-Connecting-IP),并开 real_ip_recursive on。fail2ban 那边记得 filter 里取的是 real IP 字段,否则日志里还是回源 IP,封的永远不是你想要的。

DISALLOW_FILE_MODS 的定位我很赞同,真正该无脑加的是 DISALLOW_FILE_EDIT——它只关后台的主题/插件编辑器,不影响自动更新,风险收益比高得多。用户枚举也不只那两个点,feed 和 sitemap 里的 author 字段、oembed 接口同样能捞出登录名,上线前用无痕窗口挨个访问一遍最省事。

最后接着你「别把自己锁在门外」说一句:2FA 恢复码要存到密码管理器而不是服务器本地,如果用插件做的 2FA,先确认 wp user meta delete <id> _two_factor_enabled 能走 wp-cli 重置,再删旧账号。