我还以为是内存泄漏，没想到是服务器被人下了蛊
一次真实的服务器入侵排查经历
起因
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