我还以为是内存泄漏，没想到是服务器被人下了蛊

一次真实的服务器入侵排查经历

起因

2026年5月29日晚上，用户反馈网站登录后点击其他功能需要重新登录。我第一反应是认证系统出了问题，开始排查代码。

但很快，更多的问题接踵而来：

API请求超时 (net::ERR_TIMED_OUT)
页面加载缓慢
服务器响应不稳定

我开始怀疑是服务器资源问题。

第一次误判：内存泄漏

登录服务器查看资源使用情况：

top - 19:10:55 up 11 days, 20:34
load average: 84.99, 76.23, 76.46
%Cpu(s):  0.0 us,  3.3 sy,  0.0 ni, 83.3 id, 13.3 wa
MiB Mem :   3495.2 total,    334.2 free,   2526.8 used
MiB Swap:   2048.0 total,    452.8 free,   1595.2 used

CPU负载 84.99，内存几乎用完，Swap用了1.6GB

我的第一反应是：Next.js应用内存泄漏了。毕竟这是一个全栈应用，有数据库连接、SSE推送、实时聊天等功能，内存泄漏是很常见的问题。

于是我开始：

检查PM2进程内存使用
分析数据库连接池
检查SSE连接是否正确释放

PM2报告显示每个实例只用了50-100MB内存，看起来很正常。

"奇怪，那内存去哪了？"

真相大白

当我执行 ps aux --sort=-%mem 查看内存占用最高的进程时，发现了端倪：

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      415370  188  7.5 2442240 270676 ?      Ssl  19:20   1:37 systemd -o xmr.kryptex.network:8029 -u 47S6DU9Qm3K848Krv6fAfZGgRn75653nbEPMxx3CYrWXBeTYnttJaWCDxDErGhH53u2cmbwahUymzPx71qDPneMsGjQ5pj4 --tls -t 2 --cpu-max-threads-hint=100

188% CPU，连接到 xmr.kryptex.network:8029

这是什么？我仔细一看：

进程名：systemd（伪装成系统进程）
连接地址：xmr.kryptex.network（门罗币矿池）
参数：--cpu-max-threads-hint=100（使用100% CPU）

这不是内存泄漏，这是服务器被植入了挖矿程序！

排查过程

1. 确认挖矿程序

ps aux | grep -E 'kryptex|xmr|mine'

输出：

root      415370  188  7.5 2442240 270676 ?      Ssl  19:20   1:37 systemd -o xmr.kryptex.network:8029 ...

确认是挖矿程序。

2. 查找程序位置

ls -la /proc/415370/exe
# 输出：lrwxrwxrwx 1 root root 0 May 29 19:26 /proc/415370/exe -> /usr/local/bin/systemd

挖矿程序伪装成了 /usr/local/bin/systemd，一个假的systemd二进制文件。

3. 检查自动重启机制

第一次直接 kill 进程，结果几秒后又启动了。说明有定时任务或服务在自动重启它。

检查systemd服务：

systemctl list-units --type=service --state=running

发现一个可疑服务：observed.service - "System Observer Service"

但进一步检查发现这个服务只是一个清理脚本，不是挖矿程序的来源。

4. 彻底清除

# 杀死进程
kill -9 415370

# 删除挖矿程序
rm -f /usr/local/bin/systemd

清理结果

指标	清理前	清理后
CPU负载	84.99	1.59
挖矿进程CPU	186%	0%
挖矿进程内存	270MB	0MB

CPU负载降低了98%！

入侵路径分析

挖矿程序是如何进入服务器的？可能的途径：

SSH弱密码 - 攻击者通过暴力破解SSH密码
软件漏洞 - 服务器上运行的软件存在安全漏洞
供应链攻击 - 安装的软件包被篡改
宝塔面板漏洞 - 宝塔面板存在安全漏洞

加固措施

立即措施

✅ 清除挖矿程序
✅ 检查并清理定时任务
✅ 检查systemd服务

后续措施

更换服务器密码 - 使用强密码
限制SSH访问 - 禁用密码登录，只允许密钥认证
更新系统 - 确保所有软件都是最新版本
配置防火墙 - 只开放必要的端口
定期安全扫描 - 使用安全工具定期扫描服务器
监控资源使用 - 设置CPU、内存使用告警

经验教训

不要只看表面现象 - CPU负载高不一定是应用问题，可能是被入侵
检查进程来源 - 不要只看进程名，要检查进程的完整路径和参数
注意自动重启机制 - 挖矿程序通常会配置自动重启，要彻底清除
定期安全检查 - 不要等出了问题才检查

总结

这次事件给我敲响了警钟。服务器安全不是一劳永逸的事情，需要持续关注和维护。

如果你的服务器也出现CPU负载异常高的情况，不要急着优化代码，先检查一下是不是被入侵了。

写于2026年5月29日晚，服务器恢复正常后

附录：快速排查命令

# 检查CPU负载
uptime

# 检查内存使用
free -h

# 查看CPU占用最高的进程
ps aux --sort=-%cpu | head -10

# 查看内存占用最高的进程
ps aux --sort=-%mem | head -10

# 检查可疑进程
ps aux | grep -E 'mine|xmr|kryptex|cryptonight'

# 检查定时任务
crontab -l

# 检查systemd服务
systemctl list-units --type=service --state=running

# 检查进程的完整路径
ls -la /proc/<PID>/exe