最近这几天，几乎把所有业余时间都投入到了 VPS 安全排查中。
事情的起因，是一台 Oracle Cloud VPS 被发现运行了疑似恶意程序。虽然最终没有造成明显损失，但整个事件却让我意识到一个问题：
真正危险的不是服务器被攻击，而是服务器被攻击了很久，而自己却毫不知情。
这次事件，也促使我重新设计了整个 VPS 安全监控体系。从最初的发现异常，到紧急处置，再到监控体系建设和持续能力升级，对自己的运维理念产生了很大的影响。
一、问题的发现：一次持续多天的安全隐患
最初收到的并不是入侵告警，而是一条来自自己编写的巡检脚本的提示：
可疑高 CPU 进程。
登录服务器后，很快发现了异常。
进程运行在 /tmp 目录，文件名随机，长期占用大量 CPU，父进程指向 LiteLLM，随后又发现多个 Python Loader 以及已经退出的僵尸进程。
继续分析时，所有程序已经全部删除，只留下运行痕迹。
整个行为非常符合目前 Linux 挖矿木马常见的模式：
- 下载恶意程序
- 临时运行
- 删除自身
- 不留下文件
虽然最终没有找到矿池地址和程序样本，无法做到百分之百确认，但综合各种行为特征来看，基本可以判断是一类典型的 CPU 挖矿木马。
更让我后怕的是：
从日志推算，这个程序已经运行了接近二十天。
如果不是偶然触发巡检，我甚至不知道服务器曾经执行过恶意程序。
二、紧急处置：先控制风险，再寻找原因
确认异常后，并没有急于寻找攻击入口，而是先进行了风险控制。
首先检查了系统是否已经被进一步控制：
- SSH 登录记录
- authorized_keys
- Cron 定时任务
- Systemd 服务
- 网络连接
- 新监听端口
- Docker 容器
- 临时目录
幸运的是，没有发现持久化后门，也没有发现异常网络连接。
随后又检查了 LiteLLM 保存的各种 API Key。
由于服务器已经运行过未知程序，虽然没有发现盗刷迹象，但为了避免风险扩大，还是全部进行了轮换，包括：
- Gemini API Key
- LiteLLM Master Key
与此同时，也重新评估了 Oracle Cloud Free Tier 的风险。
结合官方 Abuse 策略来看，只要没有持续挖矿、DDoS、垃圾邮件等行为，被封禁账号的概率较低。
最后还是决定：
这台服务器不再继续使用，重装恢复可信环境。
对于安全来说，“怀疑已经失陷”和”已经失陷”并没有本质区别。
三、重新认识监控：没有监控，就没有安全
整个排查过程中，一个问题不断出现：
很多异常，其实已经发生了。
但是没有任何证据留下。
例如：
/tmp程序已经删除- Python Loader 已删除
- 临时端口已经关闭
- 高 CPU 已恢复正常
等人登录服务器的时候，现场已经消失。
这让我意识到：
传统的”发现问题再登录服务器分析”已经越来越难应对现在的恶意程序。
因此，我开始重新设计整个监控体系。
四、构建多层监控体系
目前已经初步形成四层监控架构。
第一层：Healthchecks
负责监控所有定时任务是否仍然正常执行。
任何一个定时任务停止运行，都能够第一时间收到通知。
第二层：Sentinel 自检
每台服务器都会定时向 Telegram 发送自检消息。
例如：
✅ Sentinel 自检：Telegram 通道正常
如果某台服务器突然没有发送自检信息，即使 Healthchecks 正常，也说明监控程序自身可能已经失效。
这次排查过程中，就发现了三台服务器没有发送 Sentinel 自检消息。
虽然 VPS 本身正常，Healthchecks 也正常，但最终定位到 Sentinel 部署存在遗漏。
这也验证了：
监控程序本身，也需要被监控。
第三层：安全巡检
目前已经能够自动检测：
- 新监听端口
- 高 CPU 可疑进程
- SSH 登录变化
- Root 登录
- 新增用户
- Systemd 服务变化
- Cron 变化
- Docker 异常
- API Key 风险
- 临时目录可执行文件
所有异常统一推送 Telegram。
第四层：人工复核
自动监控负责第一时间发现问题。
真正的判断仍然需要人工分析。
因为：
安全最大的敌人，不一定是漏报。
还有误报。
五、监控上线后的第一次”考试”
监控刚上线，很快连续收到几条安全告警。
例如：
发现新的 UDP 监听端口。
第一时间登录服务器检查。
结果发现：
只是 WireGuard、rpcbind 等系统组件。
还有一次：
可疑高 CPU。
最后发现：
居然是巡检脚本自己执行 ps 命令时，把自己识别成了高 CPU 进程。
这些误报虽然没有真正的安全风险，却让我认识到：
监控不仅要能够发现异常，更要尽可能减少误报。
否则时间久了，真正的重要告警也容易被忽略。
六、监控能力持续升级
结合这几次排查，目前已经规划了 Sentinel 下一阶段升级方向。
包括：
- 新端口二次确认，过滤瞬时监听
- 进程白名单机制
- 自动保存现场证据
- SHA256 校验
- 可执行文件 Hash 监控
- Docker 配置变化检测
- Caddy、Xray 配置变更监控
- API Key 泄漏检测
- 服务器在线数量自动统计
- Healthchecks 与服务器清单自动一致性校验
未来收到告警时，希望不仅知道：
“发现异常。”
而是能够直接看到：
- 哪个进程
- 谁启动的
- 来自哪里
- 是否属于白名单
- 风险等级
- 是否保留现场证据
真正做到收到告警即可判断风险，而不是再登录服务器开始排查。
七、最大的收获
这次事件最大的收获，并不是找到了某个漏洞，也不是确认了攻击入口。
而是重新理解了安全运维。
以前认为：
安全，就是系统没有被攻击。
现在更认同：
安全，是能够及时发现攻击，并快速恢复。
对于个人维护多台 VPS 来说，不可能做到绝对安全。
真正能做的，是建立一套持续运行的监控体系：
- 能够发现异常；
- 能够验证监控自身是否正常；
- 能够尽可能保留现场；
- 能够不断降低误报；
- 能够在最短时间完成处置。
安全不是安装几个工具，也不是一次性的加固，而是一项持续演进的工程。
这次疑似木马事件，更像是一堂昂贵但值得的实践课。它让我从”出了问题再排查”的思维，逐步转变为”持续监测、快速发现、及时响应”的运维理念。
未来，我也会继续完善 Sentinel，将其打造成适合个人多 VPS 管理的一套轻量级安全监控平台，让服务器真正实现可观测、可追踪、可告警、可恢复。
