我的数据————

我的数据————

目前GXDE主仓库，星火自动构建系统和星火分流仓库都部署在上面

• GXDE主仓库已改为301跳转到国内高校镜像站，安装应用和构建ISO不受影响，系统更新暂停

• 星火自动构建系统已在国内云主机重新部署，星火商店/APM商店的国内软件自动更新已恢复，github等国外平台软件更新暂停

• 星火商店主页/APM商店主页加载速度会略微下降

美国廉价服务器提供商 CloudCone 位于洛杉矶的机房多台虚拟机离线时间超过 24 小时，现在该公司也在状态页发布详细说明解释此次服务器失联的原因，并且看起来短时间内服务器可能无法恢复运行。

该提供商使用的服务器底层基于 KVM 等虚拟化技术，管理团队则使用 Virtualizor 控制面板对所有客户虚拟机进行管理，可以快速创建、删除、启动、重启、监控客户虚拟机等。

此次引起问题的主要原因就是 Virtualizor 程序遭到黑客利用，但目前尚不清楚引发问题的是 Virtualizor 本身存在的安全漏洞，还是 CloudCone 团队在部署时出现的失误。

下面是背景信息：

最初管理团队通过监测系统发现多台客户虚拟机失去网络连接，经过调查所有受影响的虚拟机在启动时都会显示勒索信息 (部分用户甚至可以在 VNC 控制台中看到黑客留下的勒索信息)。

工程团队介入后首先立即隔离所有受影响的虚拟机并展开分析，分析后确认所有受影响的虚拟机磁盘的引导扇区已经被勒索信息覆盖，这也是虚拟机无法启动的原因。

目前整个团队都在尝试恢复数据，包括检查原始块设备、重建分区表和查找还没有损坏的文件系统，然而如此长时间还没能恢复，可能后续数据完整恢复的概率比较小。

安全团队的分析与调查：负责调查此次安全事件的团队发现，某个当前已经无法访问的远程 bash 脚本在所有受影响的节点上运行 (每个节点运行不同数量的虚拟机)，这些主机上的 shell 历史记录也被清空。团队使用系统日志、轮换日志文件、登录记录和审计数据对身份验证活动进行彻底调查，调查显示没有任何未经授权的 SSH 访问行为，所有记录的用户登录信息也与已知的内部账户相符。

找不到攻击路径后，安全团队转而将目标放到内部基础设施上，因为有个 Virtualizor 实例的日志在事件发生前后被清除，并且所有受影响的节点都连接到这个实例。

根据现有证据，安全团队认为攻击者利用 Virtualizor 的服务器终端功能获取连接节点的 shell 权限并执行恶意脚本，这种访问方式不依赖于 SSH，因此无法在 SSH 中找到证据。

此外，通过这种方式连接并执行脚本不会在节点上留下任何登录记录，这也解释了为什么在黑客发起攻击时 CloudCone 团队和警报系统都没有收到任何异常提醒。

受影响的节点 / 虚拟机范围：CloudCone 主要使用 Virtualizor 实例来提供 VPS 服务，目前可以确认的是只有连接到单个 Virtualizor 实例的节点受影响，连接其他平台的节点未受影响。该公司也不会在实例中存储用户的个人信息或账单信息，所以暂时也没有任何证据表明客户购买服务器时提供的个人信息和支付信息存在泄露情况。

最后该公司正在研究后续方案并向所有受影响的客户发送电子邮件通知，至于能不能恢复只能继续观察了