看不见的攻击：BGP劫持如何威胁你的服务器

最近一起安全事件在 hosting 圈子里炸开了锅。攻击者通过劫持 BGP 路由，精准瞄准了 Softaculous 和它旗下的 Virtualizor。目的很明确：骗取 TLS 证书，然后在软件分发渠道里塞入恶意更新。

这不是什么茶余饭后的安全新闻，这是给所有在互联网上跑基础设施的人敲响的警钟。

事情经过

这次攻击的手法相当老练：

1. 路由劫持：攻击者宣布了根本不属于自己的 BGP 前缀，把原本应该去往特定 IP 的流量硬生生拐进了自己的基础设施
2. 证书造假：通过拦截正常流量，从 Let's Encrypt 那里骗到了他们根本控制不了的域名的证书
3. 恶意更新：有了合法的证书，就开始给客户推送被篡改过的 Virtualizor 更新

可怕的是，这三步是一环扣一环的。BGP 劫持是一切的起点。

BGP 是什么？

BGP（边界网关协议）就是互联网的导航系统。你请求服务器上的数据时，BGP 决定流量要穿过哪些网络才能到达目的地。业内把它比作互联网的 GPS，但问题在于——它完全不验证。

网络之间互相宣布自己拥有哪些 IP 地址，其他网络就信了。没有任何验证机制。这套信任机制在互联网还是学术小圈子的时候没问题，但现在成了大漏洞。

开发者为什么要关心这个？

你可能会觉得这事儿归网络工程师管，跟写代码的没关系。那你就想错了。

你每次部署代码、更新依赖包、安装面板软件的时候，其实都在信任这套传输机制。如果这套机制被 BGP 劫持搞坏了，你整个 infrastructure 跑的都可能是被动过手脚的代码。

Softaculous 这次被攻击说明，攻击者可以：

• 绕过你用来验证安全连接的证书机制
• 通过看起来完全合法的更新渠道分发病毒
• 在应用代码运行之前就从底层入侵服务器

RPKI：黑暗中的一点光

好消息是，有解决方案。RPKI（资源公钥基础设施）就是给 BGP 公告加上密码学验证的框架。有了 RPKI，网络可以证明自己宣布的 IP 前缀确实是自己拥有的。

部署到位的话，RPKI 能堵死路由劫持的路——攻击者根本没法宣布不属于自己的前缀。主流云厂商和运营商都在逐步采用 RPKI，但还没做到全覆盖。

你需要知道的是：

• RPKI 验证能拦截大多数意外路由泄漏，也能阻止恶意劫持
• 部署在推进中，但很多小网络还没跟上
• 这是网络层面的解决方案，你得看你 hosting 提供商的基础设施是否到位

怎么保护自己

你没法单枪匹马修复 BGP，但可以降低风险：

选 Hosting 的时候

• 挑安全做得好的提供商：看他们有没有上 RPKI、ROV，路由策略透不透明
• 查资质认证：你的 hosting 公司有没有做过安全审计
• 直接问：问他们 BGP 安全方面怎么做的，正规厂商应该能说清楚

代码层面

• 独立校验 checksum：别光靠 HTTPS 来验证软件
• 尽量用可复现构建：这样能验证软件的完整性
• 自己部署的时候加上代码签名

证书验证

• 用 Certificate Transparency 日志：盯一下有没有人偷偷给你的域名申请了证书
• 上 HSTS：强制走 HTTPS，缩小攻击面
• 对关键连接考虑证书锁定

更大的问题

Softaculous 这事不是孤例。类似的 BGP 劫持已经盯上过交易所、主流云厂商、CDN 服务商。这种手法越来越成熟，随着越来越多东西搬到云上，潜在危害也在扩大。

这次攻击也暴露了互联网安全的一个现实：路由层出了漏洞，再强的应用层防护也白搭。我们无条件信任的 TLS 证书，到了坏人手里就变成了武器。

写在最后

Web hosting 这个行业得把 BGP 安全当成基本要求，而不是锦上添花的功能。

对于开发者和创业团队来说，这件事也提醒我们：安全不只是应用层代码的事。你得了解你代码底下跑的是什么基础设施——这不是运维才需要懂的东西，是所有对数字资产负责的人都得掌握的知识。

保持警惕，验证来源，选那些在安全上舍得投入的 hosting 合作伙伴。攻击者越来越狡猾，你的防御也得跟上。

好消息是安全社区一直在推进解决方案。RPKI 的采用在加速，监控工具也在完善。但在这些保护措施全面落地之前，多了解情况、选靠谱的提供商，仍然是你最实际的防线。

你在用什么方法验证基础设施的完整性？有什么好思路，欢迎来聊。