美国服务器自建虚拟化：vCenter 这次难住人的，不是打补丁

租美国服务器的团队里，有相当一部分不是拿它跑一个网站，而是买几台大配置的独立服务器装上 ESXi 或 PVE，切成几十台虚拟机自用或分租，等于自己做一朵小云。成本账很好算：同样的 CPU 和内存，独服切出来的单价比云实例低一大截，美国机房又便宜、带宽足、IP 好拿。

这个月的两起在野利用，把这种玩法里一项平时不显山露水的成本推到了台面上。

先把两件事的时间线摆准

VMware vCenter 的 CVE-2026-59310 是 Broadcom 在 7 月 29 日披露的，CVSS 9.8，缺陷位于 vCenter 的 Syslog 服务，属目录穿越，具备网络访问权限的攻击者可以借此执行任意代码。德国安全公司 QUIRSO 是在一次客户应急响应中发现这波攻击的，8 月 10 日公开了报告：被入侵系统最早在 8 月 3 日开始与攻击者域名通信，距披露只有 5 天；截至 8 月 7 日已识别到 47 个国家、361 个受害 IP，其中德国、美国、土耳其、伊朗、法国合计占了一半以上。攻击链是先利用漏洞进入，再用一个恶意 cron 任务拉起 reverse_ssh，建立一条向外的 SSH 隧道做持久化。QUIRSO 判断背后大概率是同一个 APT 组织，属于对所有能摸到的 vCenter 无差别扫一遍，而不是冲着谁去的。

有两点值得单独记一下。一是同一份公告（VMSA-2026-0006.1）里还修了 CVE-2026-59309，vCenter 目录服务的认证绕过，同样 9.8，近期扫描量在涨；两者若被串起来用，攻击者可以先绕过认证再触发 RCE——不过 QUIRSO 也说了，目前证据不足以把这波扫描和 59310 的攻击者关联起来。二是这个漏洞官方没有给任何临时缓解方案，不存在"先加条规则顶一顶"的选项，只能升级。

另一起是 GeoServer。8 月 12 日 UTC 10:46，研究员在 X 上直接公开了 jsonArrayContains 的未授权 SQL 注入，按他的说法，数据库账号是 sa 时顺理成章能拿到 RCE。watchTowr 说披露后数小时内就看到利用尝试，来自少量 IP 的探测有数百次。零日刚出来时无补丁可打，两天后项目方发布了 3.0.1、2.28.5、2.27.6 修复（安全公告编号 GHSA-mqjf-5f49-2fjh，CVSS 9.8），实质上是 2023 年那个 CVE-2023-25158 的回归。我们前几天的报道发出时补丁尚未落地，现在跑着 GeoServer 的可以直接升级了。

管理面不该暴露在公网、补丁不能等月度窗口，这些话我们在上线前的安全基线里写过，这里不重复。这次真正卡住自建虚拟化用户的，是另外两件事。

没有维护窗口，就等于没有打补丁的能力

官方不给缓解措施，意味着这次唯一的解法是升级 vCenter。升级要重启服务，而你的 vCenter 底下挂着几十台虚拟机，其中一部分还租给了别人。

跑单机业务的人可能体会不到这个难处：停十分钟、发个公告就过去了。自建虚拟化不一样——你要么有集群和在线迁移能力，可以把虚拟机腾到另一台宿主上再动这台；要么就得挨个通知租户，凑一个所有人都能接受的时间。多数自建的环境两样都没有，于是从"知道要打"到"真的打完"，中间就拖出了几天甚至一两周。这次的窗口是 5 天，拖不起。

所以自建虚拟化省下的钱，第一笔要还回去的不是买什么安全产品，是架构上留出一台机器能随时下线的余量。可以是两台宿主互为迁移目标，可以是关键虚拟机在另一台机器上有随时能拉起的备份，哪怕只是把"每季度会有一次不超过 30 分钟的维护窗口"写进给租户的说明里，也比事到临头再商量强。这件事看起来跟安全没关系，但它决定了你补丁能有多快。

顺带一提，同样的逻辑也适用于宿主机的内核和 BMC 固件，那两样比 vCenter 更少被想起来。

门关严了，但门是往外开的

这次攻击链里最值得琢磨的是 reverse_ssh 的用法：被控机器主动向外建连，而不是等攻击者打进来。多数人的防火墙策略是入站严格、出站全放，这条隧道因此在边界上看不出任何异常——它跟服务器去拉一个软件包在形态上没什么区别。

美国机房这个问题更突出一点，因为大带宽是卖点，出方向基本没人限，也很少有人留出站日志。落到自建虚拟化上，可以做的事其实不复杂：

管理网段（vCenter/PVE 管理口、IPMI、宿主机管理 IP）的出站按默认拒绝配，只放行确实需要的目标——操作系统和虚拟化平台的更新源、NTP、内部 DNS、日志服务器，别的一律不放。管理组件本来就不需要能访问整个互联网，收紧它几乎不影响业务。

出站 DNS 集中到自己指定的解析器上并留日志。这次事件里的关键线索就是被控机器去解析并连接了攻击者的域名，如果 DNS 查询没有任何记录，事后想倒查会非常吃力。

业务虚拟机的出方向不一定要一刀切，但至少给它们和管理网段分开的网段与出口策略。美国独服普遍好拿多 IP，把管理流量和业务流量分到不同网卡、不同 IP 段，做起来没什么额外成本，出事时也更容易切一半保一半。

还有一点属于常识但常被跳过：这次被打的环境，事后光升级补丁是不够的，攻击者留下的 cron 和隧道还在。如果你的 vCenter 在 7 月 29 日之后有过公网暴露，升级完请把定时任务、出站连接、账号和虚拟机列表都对一遍，必要时直接镜像取证后重建。

有一条建议我不太赞成

原来的思路里有一种说法是把管理面和业务面做地理分离，比如业务放美国、管理放香港。这个方案听着有纵深，实际落地一般得不偿失：控制面对时延和抖动很敏感，跨太平洋的 RTT 会让日常操作变得难受；链路一断你就同时失去了管理能力和排障能力；多一地机房也就多一套凭据、多一处配置漂移的可能。

管理面隔离靠的是网络层，不是地理距离。一台跳板机加 WireGuard，管理端口只对 VPN 网段放行，效果比横跨太平洋好得多，也便宜得多。真要为跨地区花钱，花在异地备份上比花在管理面上划算——业务在美国，备份放香港或者其他节点，这个组合在真出事的时候能救命。

选机器时和这件事有关的部分

自建虚拟化对底层的要求，其实就三条比较硬：网络能自己定，包括自定义防火墙策略、多 IP 和网段划分，否则前面说的管理面隔离和出站收敛都落不了地；带外管理要规范，IPMI 本身就是高危资产，最好由服务商在控制台侧代管而不是丢一个公网地址给你；再就是有没有条件加盘或者挂存储做本地备份，这直接关系到你敢不敢在工作日中午重启一台宿主机。

SellBGP 的美国服务器部署在 CoreSite LA2 等 T3+ 数据中心，支持自定义网络与防火墙策略，大配置机型适合 ESXi/PVE 场景，带外管理收在控制台里。具体到你现在这套虚拟化怎么划网段、维护窗口怎么排，可以提交工单聊，技术团队 7×24 在线。

说到底，这次事件里被打穿的人和没事的人，差别往往不在谁更懂安全，而在于漏洞公布那天，谁手上有一台能立刻重启的机器。