服务器挖矿病毒排查记录
2024-03-29
起因
事情的起因是前段时间，郭佬找到我说他们的实验室新配了一台 AI 服务器，不过在外地托管，问有没有什么远程 ssh 的方法，于是我给他推荐了内网穿透和 P2P 组网两种方案，并对比了两者的优劣，最终郭佬选择了内网穿透方案，当时特意嘱咐了郭佬，服务器密码千万别使用弱密码，否则可能会被别人扫描爆破，最好是直接关掉密码登录，只通过密钥登录。
过了几天郭佬找到我，说服务器被入侵了，有几个非 Python 进程一直占用着显存。
图中可以看到有一个名为 /etc/system 的进程在每张显卡上都有占用显存，根据直觉，这个大概率就是挖矿病毒了，因为正常情况下 etc 目录是存放配置文件的，不排除有一些可执行的脚本，但是肯定不会有可执行的二进制程序，而且入侵者还起了个 system 这么迷惑性的名称，让受害者误以为是系统组件。
又过了一会，郭佬说进程杀不死，杀掉以后又自动重启了，于是我登上了服务器，准备排查一下。
初步排查
首先尝试使用 ps 查看了一下进程信息，看一下是谁启动的病毒进程，发现进程 PPID 是 1，在 Linux 中 PID 为 1 的进程为 systemd，主要用于管理系统服务，配置守护进程等功能，这里之所以杀不死病毒进程，大概率是配置了 Restart 策略。
接下来我查看了一下 systemd 配置文件里有哪些可疑的服务项
ls /etc/systemd/system/*service
稍微有一点多，懒得一个个看内容了，一般情况下 service 配置文件中都会使用 ExecStart 指定程序的执行路径，于是我把病毒文件改了个名字，重启系统以后，病毒果然没有启动，于是就先把病毒文件删掉了。
这里因为改了病毒文件名称，导致其没有正常启动，在系统日志中肯定有报错，于是继续排查一下日志记录
journalctl | grep "/etc/system"
这里日志中可以看到是又一个名为 k8s.service 的服务产生的报错，看到这里忽然恍然大悟，郭佬这台服务器是拿来跑 AI 的，怎么可能会安装 k8s，这又是入侵者的一个小把戏。
看一下 service 内容
cat /etc/systemd/system/k8s.service
看到了罪魁祸首 ExecStart=/etc/system ，于是把这个 service 文件删除。
做到这里病毒应该就解决掉了，不过不排除还留有其他后门，于是就让郭佬先观察几天，同时嘱咐郭佬换一个强度高一点的密码，或者去改一下配置文件，禁用密码登录。
再次排查
过了一会，郭佬再次找到我，说 /etc/ssh/sshd_config 文件一直改不了。
我想是不是权限问题，没有用 sudo 或者 root 用户没有写权限，郭佬告诉我用的 root 用户操作的，而且看了一下权限，是正常的 644
这里我想到了可能是入侵者改了这个文件的属性，设置了 immutable 权限，被设置了 immutable 权限的文件不能被修改、不能被删除，于是让郭佬试一下用 chattr 改一下权限，但是没有成功，执行后返回了 chattr 的 usage
于是我再次登录了服务器，排查一下原因，为了方便登录，我想先把我的公钥加到服务器里，结果编辑 /root/.ssh/authorized_keys 后发现是同样的问题，而且文件里已经有一个公钥了，我问了一下郭佬之前有没有添加过公钥，郭佬说没有，那么，这个公钥应该就是入侵者留的后门了。
当尝试使用 lsattr 命令查看一下权限，发现一样是返回 Usage，网上搜了下资料，发现是 lsattr 和 chattr 被入侵者替换了，而且这两个命令也被设置了 immutable 属性。
这里参考了 阿里云服务器 chattr 文件被删问题 的方法。
# 下载chattr源码
wget https://raw.githubusercontent.com/posborne/linux-programming-interface-exercises/a93a73842cac2143c873d78a30df5f8f32f5dab8/15-file-attributes/chattr.c
# 编译
cc chattr.c
# 重命名
mv a.out chattr
# 修改权限
chattr -i /etc/ssh/sshd_config
chattr -i /root/.ssh/authorized_keys
chattr -i /usr/bin/chattr
chattr -i /usr/bin/lsattr
# 重装chattr
apt install --reinstall e2fsprogs
至此，后门问题也是基本上解决了。
通过此事也说明了任何处于公网的设备都有被入侵的风险，以下是一些防护措施
-
不要使用弱密码，尽可能使用包含数字、字母、符号多个组合的高强度密码
-
尽量不要使用 ssh 默认的 22 端口
-
禁用 ssh 密码登录，改为使用密钥、F2A 等认证方式
-
编写脚本，屏蔽高频 ssh 登录的 IP