独立站安全加固:防火墙、登录限制、文件权限与恶意扫描
一、防火墙:云安全组加WAF,先把不必要的端口关掉
很多人以为防火墙是装在服务器里的软件,其实对云主机独立站,第一道防线是云厂商的安全组。安全组默认全开3306、6379、9000这些端口是最大隐患——数据库和Redis直接暴露公网,扫描器几分钟就能爆破进去。正确做法是安全组只放行80和443,22端口限到你公司的固定出口IP。
第二道防线是WAF(Web应用防火墙)。Cloudflare免费版就够用,自动拦截SQL注入、XSS、常见扫描器。WAF规则不要开得太激进,否则会把正常访客拦在外面。开的时候先选只记录模式跑3天,看误报率低于1%再切到拦截模式。
| 端口/服务 | 默认状态 | 加固后状态 | 原因 |
|---|---|---|---|
| 80/443 | 开放0.0.0.0/0 | 开放0.0.0.0/0 | 必须公网可访问 |
| 22 SSH | 开放0.0.0.0/0 | 限公司固定IP,改密钥登录 | 密码爆破重灾区 |
| 3306 MySQL | 常被误开 | 只允许本机127.0.0.1 | 绝不暴露公网 |
| 6379 Redis | 常被误开 | 只允许本机,设密码 | 未授权访问会被写公钥 |
| 9000 PHP-FPM | 本地socket | 保持本地socket,不开TCP | 不需要公网访问 |
| 8888/宝塔面板 | 常暴露 | 限IP+改默认端口 | 面板是高频攻击目标 |
场景示例:一个用宝塔面板的WordPress站,刚上线时安全组全开,三天后服务器CPU跑到100%。登上去看是3306端口被境外IP爆破,MySQL日志里全是连接失败记录。改成安全组只开80/443和限公司IP的22,CPU立刻降回5%。这个事故10分钟就能避免,但多数人上线时根本不看安全组。
WAF规则怎么配,和询盘表单反垃圾是同一套逻辑:先记录观察,再拦截,不要一上来就封所有可疑请求。
二、登录限制:把爆破入口收窄
WordPress的wp-admin是独立站被黑的第一入口。默认用户名admin、密码简单、登录页面公开可访问,扫描器几小时就能跑遍字典。反直觉的是:装一个登录限制插件比买任何安全扫描产品都管用,因为绝大多数爆破根本走不到利用漏洞那一步,卡在登录页就被拦了。
登录限制三件套:失败5次锁30分钟、改默认登录路径(/wp-admin改成随机字符串)、强制2FA。密码长度不少于16位,用密码管理器生成,不要用单词加数字。SSH同理,禁密码登录只允许密钥。
| 配置项 | 默认值 | 加固值 | 工具/实现 |
|---|---|---|---|
| 登录失败锁定 | 无限制 | 5次失败锁30分钟 | Wordfence或自定义fail2ban |
| 登录路径 | /wp-admin | 随机字符串如/login-7f3k | WPS Hide Login插件 |
| 双因素认证 | 无 | 强制TOTP 2FA | Wordfence或Two Factor |
| 密码长度 | 6位 | ≥16位随机 | 密码管理器生成 |
| SSH认证 | 密码登录 | 只允许密钥,禁密码 | sshd_config改PasswordAuthentication no |
| 数据库用户 | root远程 | 专用用户,限本机 | MySQL建独立账号 |
场景示例:一个出海SaaS站,后台登录页在/secret-admin,开了2FA,失败5次锁30分钟。监控日志显示每周有大概2000次来自境外IP的登录尝试,全部被锁在外面,没有一次成功。这些尝试如果没有限制,按平均密码强度算,3个月内被撞库成功的概率超过30%。
插件选型和技术栈的整体思路,见环形山技术栈四个自研插件。
三、文件权限:让被上传的恶意文件跑不起来
文件权限是很多人忽略的一层。WordPress被黑后,攻击者通常会往wp-content/uploads目录传一个PHP webshell。如果uploads目录允许执行PHP,这个webshell立刻就能控制全站;如果uploads目录禁止执行PHP,攻击者传上去也跑不起来,只能干瞪眼。
标准权限是:目录755,文件644,wp-config.php改成400(只有所有者可读)。不要图省事全设成777,那等于把钥匙挂在门上。uploads目录在nginx配置里加一段规则,禁止执行.php、.phtml、.php5等文件。
| 路径 | 权限 | 所有者 | 说明 |
|---|---|---|---|
| 网站根目录 | 755 | www-data:www-data | 不要给777 |
| wp-config.php | 400 | root | Web进程不可读 |
| wp-content/themes | 755 | www-data | 自动更新需要写权限 |
| wp-content/uploads | 755 | www-data | 禁执行PHP |
| wp-content/plugins | 755 | www-data | 插件更新需要写 |
| .git目录 | 不要暴露在web下 | — | 暴露会泄露源码 |
另一个高频被黑原因是数据库备份文件直接放在web目录下。很多备份插件默认把.sql.gz存在wp-content/backup/,攻击者扫到直接下载,拿到全站数据。正确做法是备份文件放到web根目录之外,或者备份完自动上传到对象存储并删除本地副本。备份策略见网站备份与恢复演练。
四、恶意扫描与补丁:每周一次,7天内打补丁
恶意扫描不是等被黑了才做。每周跑一次核心文件哈希比对,WordPress核心文件和已知版本的哈希对不上,说明被篡改了。插件和主题的更新要在7天内打完——公开漏洞从披露到被自动化扫描器利用,平均窗口是14天,7天内打完补丁就避开了大部分攻击。
扫描工具有三类:Wordfence这类插件扫描能查已知webshell签名;ClamAV跑服务器级病毒扫描;服务器日志分析能发现异常访问模式。三者配合用,不要指望单一工具全覆盖。AI爬虫日志分析的思路见AI爬虫日志分析,同样的日志分析方法可以用来发现恶意扫描器。
| 检查项 | 频率 | 工具 | 异常处理 |
|---|---|---|---|
| 核心文件哈希比对 | 每周 | Wordfence core integrity | 发现差异,从干净版本恢复 |
| 插件主题更新 | 每周一 | WP后台+日志 | 7天内必须更新完 |
| webshell扫描 | 每周 | ClamAV或Wordfence | 隔离并删除恶意文件 |
| 可疑登录记录 | 每日 | fail2ban日志 | 自动封禁攻击IP |
| web目录最近修改文件 | 每周 | find -mtime -7 | 非预期修改立即排查 |
| 数据库异常写入 | 每周 | wp_posts里base64内容 | 清理隐藏的eval代码 |
反直觉提醒:被黑后不要急着在线清理。在线清理最大的问题是藏在数据库里的webshell和cron任务你查不干净,过两周又复发。正确流程是:断开站点对外服务、从最近干净备份恢复、改所有密码和密钥、查cron和数据库里的残留、再重新上线。被黑后的完整流程见网站被黑之后的清理与重新收录。
日常巡检清单见官网维护期每月六件事,把安全加固固定进去。告警阈值怎么设,见站点监控与告警。
FAQ 常见问题
独立站被黑了,第一时间该做什么?
要不要买付费WAF,Cloudflare免费版够吗?
WordPress插件多久更新一次,自动更新安全吗?
wp-config.php和uploads目录权限怎么设?
SSH端口要改默认22吗,密码登录能留吗?
怎么发现网站被挂马了,有没有前兆?
写在最后
安全加固这件事,最贵的不是工具,是”以为没事”的心态。独立站不是银行,但它是你的询盘入口,一旦被挂马或者停摆,损失的是真金白银的线索。四层防御不需要一次到位,但要按顺序做:先关端口、再限登录、再调文件权限、最后上扫描。前三步一个下午就能做完,ROI最高。
落地三步:第一,登录云安全组,关掉3306、6379、8888这些不该公网的端口,SSH限到公司IP;第二,wp-admin改路径、开2FA、失败5次锁定,SSH改密钥登录;第三,每周固定时间跑一次核心文件哈希和插件更新。做完这三步,你已经挡住了80%的常见攻击。
一句可以记住的话:独立站被黑很少是因为高明的黑客,多半是因为弱口令、未更新插件和暴露的数据库备份——把这三个入口堵死,比买任何安全产品都管用。
