从一次RCE到Root的完整攻击链，聊聊云服务器安全组的最小权限到底该怎么配

    前段时间复盘了一个很典型的云上入侵案例，攻击者没有使用任何0day，也没有暴力破解任何密码，却从一个暴露在公网的Web应用一路拿到了服务器的root权限，最终在上面跑起了门罗币挖矿程序。这个案例让我重新审视了一个老生常谈的问题：云服务器的安全组和权限边界，到底应该默认“放行”还是默认“拒绝”。

    这个案例的攻击链非常干净。根源是一台AWS Lightsail上的Ubuntu服务器，上面跑着一个长期没有更新的Next.js应用，直接暴露在公网80/443端口上。攻击者通过应用层的服务端RCE拿到了Node.js进程的执行权限。如果应用是以一个最低权限的独立用户运行的，故事到这里可能就结束了。但问题在于，这台服务器使用的是Ubuntu云镜像的默认用户 ubuntu，该用户拥有免密sudo权限。于是，一个应用层的RCE，因为运行用户的权限过大，直接等价于root沦陷。攻击者随后通过systemd和cron安装了持久化后门，并拉起了xmrig挖矿进程，CPU长期满载。

      这里最值得警惕的不是Next.js的漏洞本身，而是“默认配置的便利性”对安全边界的侵蚀。云厂商提供的默认镜像为了方便管理，往往给默认用户授予了接近管理员的权限。当应用以这个默认用户身份运行时，应用层的任何输入验证缺陷，都会被权限放大器直接放大为系统级的灾难。更麻烦的是，攻击者利用了systemd服务来实现持久化，单纯重启服务器并不会清除恶意进程，除非彻底排查并清理所有用户级的systemd单元和crontab条目。

     顺着这条线索，再看另一个几乎同期发生的云上安全事件，可以发现相似的模式。2026年10月，两个PHP运行时的高危漏洞（CVE-2026-109618和CVE-2026-109619）被披露，CVSS评分9.2，允许攻击者在无需认证的情况下远程执行代码。这个漏洞的特殊之处在于，它影响的是PHP运行时本身，而不是某个具体的WordPress插件或主题。这意味着，对于任何直接暴露PHP服务的云主机，如果安全组没有做源站保护、WAF没有启用对应的虚拟补丁规则，攻击窗口期就是完全敞开的。Kinsta的应急响应记录显示，在官方补丁可用之前，攻击者就已经开始大规模扫描和利用，Cloudflare的WAF在两天内拦截了超过55万次针对该漏洞的恶意请求。

     把这两个案例放在一起，指向的是同一个运维习惯问题：安全组和权限配置是否遵循了“最小可行”原则。在华为云上，安全组本质上是实例级别的虚拟防火墙，默认规则通常是出方向全通、入方向按需放行。很多开发者为了调试方便，会临时放行 0.0.0.0/0 访问22端口或某个应用端口，之后却忘记收回。正确的做法是遵循白名单原则：SSH登录只允许办公网或堡垒机的固定IP段，Web服务只放行80/443，并且源站安全组只允许WAF的回源IP段（如 100.125.0.0/16）访问后端端口，把其他来源全部封死。这样即使应用本身存在漏洞，攻击流量也无法绕过WAF直接触达源站。

     在权限层，应用进程不应该以带有sudo权限的默认用户身份运行。一个简单的加固动作是创建专用的非登录用户来运行Web服务，彻底剥离其sudo能力。这个改动成本极低，但能把一个应用层RCE的杀伤力从“root沦陷”压缩到“受限进程权限”，为应急响应争取到宝贵的时间窗口。同时，华为云的主机安全服务（HSS）可以对异常进程、暴力破解和网站后门进行持续检测，安装Agent后能够将入侵痕迹上报到云端控制台，弥补单纯依赖安全组这种“静态边界”的盲区。

     安全组规则越简洁越好，权限授予越窄越好，运行用户越“卑微”越好。这个案例最深的教训并不是某个框架的漏洞有多严重，而是默认的便利性会在不知不觉中把整条攻击链的每一环都打通。把“默认拒绝”作为基线，把“按需放行”作为例外，才是云上安全真正可持续的运维方式。