昨天刚消杀完病毒，今天服务器又出问题了。
早上登录服务器，发现系统又开始卡顿，服务器占用100%。
不会又中毒了吧？赶紧打开终端查看，执行 top 命令后，画面让我有些困惑。
top - 10:04:54 up 13:33, 2 users, load average: 9.36, 9.66, 9.77
Tasks: 12281 total, 9 running, 192 sleeping, 0 stopped, 12080 zombie
%Cpu(s): 50.5 us, 49.5 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st12080 个僵尸进程，系统负载飙到 9.7，CPU 直接拉满了。
但是这一次和昨天。但这次和昨天不太一样——没有看到明显的恶意进程疯狂占用 CPU，只有一个 Docker 容器和 Next Server 在运行，但内存占用很高。
我一度以为是内存溢出或者应用本身的问题，但继续往下看进程列表，果然又看到了熟悉的身影。
30316 1001 20 0 1616 256 204 R 11.9 0.0 0:00.89 strings
30317 1001 20 0 1612 400 340 R 11.9 0.0 0:01.33 grep xmrig
30391 1001 20 0 1624 384 324 D 4.5 0.0 0:00.03 pkill又是 1001 用户，又是 grep xmrig，这不就是昨天的病毒吗？
在 AI 的帮助下，我开始逐步排查。首先检查了 Docker 容器状态：
docker stats --no-stream结果一目了然：
e5c23165954e 1Panel-umami-yQto 173.22% ... 12157Umami 容器 CPU 占用 173%，进程数 12157 个。一个正常的 Node.js 应用（umami）应该只有几个到十几个进程，但这个容器里居然有 12157 个进程，CPU 占用 173%。病毒藏在 umami 容器里！
原来昨天我只是删除了宿主机上的恶意进程，但病毒的源头——被感染的 Umami 容器——还在运行。它就像一个"毒瘤"，不断向外释放恶意进程，导致系统反复中毒。
这次也不管数据了，直接断舍离（当然在此之前我已经备份了MySQL数据库了）。
1. 停止并删除被感染的容器
docker stop e5c23165954e
docker rm e5c23165954e2. 杀死所有残留的恶意进程
pkill -9 -f "strings"
pkill -9 -f "xmrig"
pkill -9 -f "kinsing"3. 删除 Umami 相关的所有数据和镜像
rm -rf /opt/1panel/apps/umami
docker rmi ghcr.io/umami-software/umami:mysql-v2.19.0清理完成后，再次查看系统状态：
top - 10:09:36 up 13:38, 2 users, load average: 0.47, 5.43, 8.13
Tasks: 179 total, 1 running, 178 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st僵尸进程清零，负载恢复正常，CPU 空闲 100%。Umami服务下次再重建吧。
这次事件反映了几件事：
1. 容器逃逸的威胁
病毒通过 Umami 容器的漏洞入侵，然后在容器内疯狂创建进程。由于我没有给容器设置资源限制，病毒几乎可以无限制地消耗系统资源。
2. 清理要彻底
昨天只清理了宿主机上的进程，却没有检查 Docker 容器，导致病毒源头依然存在。
3. Umami v2.19.0 可能存在已知漏洞
这个版本发布于 7 个月前，很可能已经有公开的 CVE 漏洞被攻击者利用。我应该升级，或者最起码检查一下安全公告。
4. 防护措施不到位
为了避免再次中毒，我决定：
docker stats 应该成为日常巡检项目网络安全这事儿，真的不能掉以轻心。
好在有 AI 辅助排查，不然光靠我自己，估计得折腾一整天。
希望这次是最后一次了。🤞
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。