香港服务器的备份别和业务放一台机器上

栏目里 9 月 12 日那篇《香港服务器补丁全打了还被打穿》，讲的是暴露面——你以为关紧的门其实没关。这篇聊一个更尴尬的位置：备份。平时没人觉得备份是攻击面，出事的时候才发现，它是最后一道防线，也是最没人管的那道。

起因是上周的一条公告。9 月 15 日，Acronis 更新了一份安全说明，给它的面板备份插件补上了 CVE 编号 CVE-2026-87886，CVSS 7.8，类型是 Linux 本地提权。受影响的是 cPanel & WHM 的备份插件（构建号低于 1.9.3.1021）和 Plesk 的备份扩展（构建号低于 1.8.11.638），修复版本分别是 1.9.3 HF3 和 1.8.11。

Acronis 说已经监测到在野利用，形式是"有限的、有针对性的攻击"。但坦白讲，这个结论的证据链很薄——厂商后来向媒体承认，判断依据是一位"可能受影响"客户的单次上报，既没有公布入侵指标，也没有放技术细节，理由是要给管理员留打补丁的时间。

也就是说，你现在既查不了自己有没有中招，也做不了针对性缓解。能做的只有升级。

7.8 分的本地提权，在多站点机器上不是 7.8 分

本地提权在漏洞评分体系里通常算不上吓人，因为它有个前提：攻击者得先进来。但这个前提在共享环境里很容易满足。

我们在工单里见过的典型路径大概是这样：某个客户的 WordPress 装了个来路不明的插件，或者某个站点的 FTP 密码沿用了三年，攻击者先拿到一个低权限的站点用户。到这一步为止，影响范围还只是那一个站。接下来如果机器上存在本地提权漏洞，这个低权限用户就能变成 root——同一台机器上其他站点的数据库配置、备份文件、SSL 私钥，全部一次性暴露。

一台跑着二十个站的香港服务器，和一台只跑一个站的，面对同一枚提权漏洞时的风险完全不是一个量级。这也是为什么我们一直建议，站点数量多的客户不要图省事全塞一台机器。

面板这一层的问题在于，它天然处在"高权限、长期运行、很少更新"的交叉点上。系统补丁大家会打，PHP 版本大家会升，但面板插件的版本号，很多人从装完那天起就再没看过。栏目里 hk-panel 那篇比过 cPanel 和宝塔的取舍，当时讲的是功能和易用性，现在可以补一句：不管你选哪个，把插件版本纳入巡检范围这件事是一样的。

备份和业务在同一台机器上，等于没有备份

这次漏洞打的偏偏是备份插件本身，这个巧合值得多说两句。

很多团队的备份是这么做的：在服务器上装个插件或者写个 cron，把数据打包丢到同一块盘的另一个目录，讲究一点的挂个第二块硬盘。平时看起来没问题，每天都有新文件生成，监控也显示备份成功。

但只要攻击者拿到了这台机器的 root，这些备份和生产数据是同时丢的。勒索软件这两年的标准动作就是先删备份再加密——它们很清楚，能不能收到钱取决于你有没有退路。

比较稳的做法是三条：

备份落在业务机之外。可以是另一台机器，也可以是对象存储，关键是备份存储的访问凭据不要保存在生产机上，或者至少限制成只写不能删。

快照和文件级备份都要有。文件备份用来恢复单个站点，系统快照用来应对整机被搞掉的情况。SellBGP 的服务器托管和云产品支持配置定时快照与异地备份策略，客户后台里可以自己设周期，这一步花的钱远低于事后从零重建。

定期做恢复演练。这是最容易被跳过的一条。备份成功率和恢复成功率是两回事，我们遇到过好几次备份文件完整但恢复出来数据库起不来的情况，原因五花八门——版本不匹配、字符集不对、恢复脚本里写死了旧路径。建议至少每季度挑一个站点，从备份里完整拉起来跑一遍。

这两天可以先做的三件事

第一，登机器确认一下 Acronis 备份插件的版本，cPanel & WHM 侧升到 1.9.3 HF3，Plesk 侧升到 1.8.11。如果这个插件其实已经不用了，直接卸载比留着更省事。

第二，看一下面板的管理端口有没有对全网开放。WHM 的 2087、cPanel 的 2083、Plesk 的 8443，这几个端口没有理由让所有人都能访问，限制来源 IP 或者走跳板机都行。

第三，翻一遍机器上的低权限账户，把测试账号、离职同事的账号、已经下线站点的运行用户清掉。提权攻击需要一个起点，账户越少起点越少。

如果你的香港服务器上跑的站点已经不止个位数，或者手上有几台机器做不同业务，不妨趁这次把备份架构也理一遍。多数团队的备份方案是当年上线时随手搭的，之后业务长了三倍，备份还是原来那套。