生产环境 VPS 被攻陷

Source: Dev.to

初始症状

安全事件往往悄无声息地出现，没有警报铃声或戏剧性的警告。它们在我们最不经意的时候潜入生产环境——周末、停机时段，或是日常警惕稍有松懈时。

一个平静的星期日晚，我打开生产应用检查一些东西，却发现页面根本不加载。没有错误页，也没有超时——只有启动画面静静地显示着一个空白屏幕。以为是临时卡顿，我尝试 SSH 进入 VPS。连接一次又一次超时，我怀疑是因为账单逾期导致服务器被关机。

经过多次尝试后，SSH 提示符终于出现，但机器异常缓慢。连 ls 这种简单命令也要花 3–4 秒。

初步调查

登录后，系统感觉痛苦地卡顿。我运行：

top

看到一个名为 rysyslo（位于 /usr/bin/rsyslo）的进程占用了约 80 % 的 CPU、大量内存，几乎耗尽了所有磁盘空间。Ubuntu 并不自带此二进制文件，快速搜索后确认它是恶意的。我的服务器已经被入侵。

我删除了可疑的二进制文件，移除了不熟悉的服务，并杀掉了恶意进程。负载下降，系统恢复正常——但我知道，仅凭这些简单操作并不能彻底根除妥协。

事态升级

第二天早上，应用仍然不可用，SSH 行为异常，时常数分钟拒绝连接。终于重新取得访问后，top 显示：

• xmrig – 一个臭名昭著的加密货币挖矿工具
• 多个伪装的随机命名二进制文件
• 冒充系统进程的假内核线程
• 一个名为 monarx-agent 的神秘程序占用内存
• 我未启动的 Node 进程

杀掉这些进程毫无效果；攻击者已经设置了持久化机制。

持久化机制

扫描恶意服务时发现了两个 systemd 单元：

• alive.service
• lived.service

两者都指向以下脚本：

/tmp/runnv/alive.sh
/tmp/runnv/lived.sh

单元文件中包含：

Restart=always
RestartSec=5s

这些脚本不断获取、恢复并重新启动矿工——删除后几秒钟就会再次出现。这解释了为何每次杀死或删除后都只能短暂生效。

影响与数据备份

随着时间推移，VPS 越来越不稳定：

• SSH 频繁卡顿或掉线
• 系统操作慢得像爬行
• 内存使用不规律地飙升
• 日志出现异常
• 即使删除，假 monarx-agent 仍会复现

既然攻击者已经取得了 root 权限，操作系统已不可信。我的首要任务转为在机器彻底不可用之前提取重要数据。

备份步骤

我系统地备份了：

• PostgreSQL 数据库转储（pg_dump）
• 应用服务器文件
• 媒体目录
• 配置文件
• 用户上传的内容
• 必要的环境变量
• 反向代理配置
• 供后续分析的日志

由于系统几乎没有响应，我使用 rsync 通过 SSH，配合自定义脚本处理间歇性的连接中断。最终所有关键资产都安全备份并得到验证。

决定退役

在确认数据完整性后，我发现应用数据本身并未被篡改——攻击者仅想挖矿。于是我决定 永久关闭受损的 VPS，并迁移到全新实例，因为该系统已无法修复。

根本原因分析

我审查了取证数据，包括：

• /var/log/auth.log
• SSH 访问尝试记录
• systemd 单元文件时间戳
• root 级别进程创建日志
• Cron 任务
• 不明脚本来源
• 不熟悉的可执行文件
• 开放端口（netstat/ss）
• 位于 /usr/bin、/tmp、/dev/shm、/usr/share/updater 的二进制文件

日志仅显示被拒绝的 SSH 尝试——没有泄露密钥或直接暴力破解成功的证据。最可能的入口是近期披露的 React2Shell 漏洞 (CVE‑2025‑55182)，该漏洞允许在配置错误的环境中远程代码执行。Nginx 访问日志中出现大量强制 POST 请求到不同端点，表明攻击者利用了易受攻击的 Web 路由。

此外，VPS 的网络配置开放（没有限制性的防火墙），相较于云平台的严格安全组，攻击面大幅增加。

教训

• 绝不要以 root 身份运行应用。 即使是非特权服务（如 PostgreSQL）也保持安全，因为它们在专用用户下运行。
• 及时应用安全补丁，尤其是像 CVE‑2025‑55182 这样的新披露漏洞。
• 使用防火墙或安全组限制网络暴露，关闭未使用的端口。
• 实现适当的监控和告警，针对异常的 CPU、内存和磁盘使用。
• 采用不可变基础设施：从已知良好的镜像重新构建服务器，而不是尝试深度清理。
• 定期备份关键数据 并测试恢复流程。

这次事件强化了一条我再也不会忽视的原则：绝不要以 root 身份运行应用。