起因
事情的起因是前段时间,郭佬找到我说他们的实验室新配了一台AI服务器,不过在外地托管,问有没有什么远程ssh的方法,于是我给他推荐了内网穿透和 P2P 组网两种方案,并对比了两者的优劣,最终郭佬选择了内网穿透方案,当时特意嘱咐了郭佬,服务器密码千万别使用弱密码,否则可能会被别人扫描爆破,最好是直接关掉密码登录,只通过密钥登录。
![图片[1] - 服务器挖矿病毒排查记录 - 编程技术交流论坛 - 糯五游戏网](https://pica.zhimg.com/80/v2-4f37a3ed2e30d74810a466692cc95b6a_720w.webp?source=d16d100b)
![图片[2] - 服务器挖矿病毒排查记录 - 编程技术交流论坛 - 糯五游戏网](https://picx.zhimg.com/80/v2-3941e791ba25ad16c13c19f339e687e3_720w.webp?source=d16d100b)
过了几天郭佬找到我,说服务器被入侵了,有几个非Python进程一直占用着显存。
![图片[3] - 服务器挖矿病毒排查记录 - 编程技术交流论坛 - 糯五游戏网](https://picx.zhimg.com/80/v2-b317e19bc3689d4645d0df2d35ce2184_720w.webp?source=d16d100b)
![图片[4] - 服务器挖矿病毒排查记录 - 编程技术交流论坛 - 糯五游戏网](https://picx.zhimg.com/80/v2-a8aa71b3aa8804ba4e0ff3f91e96ad31_720w.webp?source=d16d100b)
图中可以看到有一个名为 /etc/system 的进程在每张显卡上都有占用显存,根据直觉,这个大概率就是挖矿病毒了,因为正常情况下etc目录是存放配置文件的,不排除有一些可执行的脚本,但是肯定不会有可执行的二进制程序,而且入侵者还起了个system这么迷惑性的名称,让受害者误以为是系统组件。
又过了一会,郭佬说进程杀不死,杀掉以后又自动重启了,于是我登上了服务器,准备排查一下。
初步排查
首先尝试使用ps查看了一下进程信息,看一下是谁启动的病毒进程,发现进程PPID是1,在Linux中PID为1的进程为systemd,主要用于管理系统服务,配置守护进程等功能,这里之所以杀不死病毒进程,大概率是配置了Restart策略。
接下来我查看了一下systemd配置文件里有哪些可疑的服务项 ls /etc/systemd/system/*service
稍微有一点多,懒得一个个看内容了,一般情况下service配置文件中都会使用 ExecStart 指定程序的执行路径,于是我把病毒文件改了个名字,重启系统以后,病毒果然没有启动,于是就先把病毒文件删掉了。
这里因为改了病毒文件名称,导致其没有正常启动,在系统日志中肯定有报错,于是继续排查一下日志记录 journalctl | grep “/etc/system”
![图片[6] - 服务器挖矿病毒排查记录 - 编程技术交流论坛 - 糯五游戏网](https://picx.zhimg.com/80/v2-4458c7f534a9fcceb1c9aa4d84c91372_720w.webp?source=d16d100b)
这里日志中可以看到是又一个名为k8s.service的服务产生的报错,看到这里忽然恍然大悟,郭佬这台服务器是拿来跑AI的,怎么可能会安装k8s,这又是入侵者的一个小把戏。
看一下service内容 cat /etc/systemd/system/k8s.service
看到了罪魁祸首 ExecStart=/etc/system,于是把这个service文件删除。
做到这里病毒应该就解决掉了,不过不排除还留有其他后门,于是就让郭佬先观察几天,同时嘱咐郭佬换一个强度高一点的密码,或者去改一下配置文件,禁用密码登录。
再次排查
过了一会,郭佬再次找到我,说 /etc/ssh/sshd_config 文件一直改不了。
![图片[8] - 服务器挖矿病毒排查记录 - 编程技术交流论坛 - 糯五游戏网](https://picx.zhimg.com/80/v2-76263ae7e6bf208781ef682350577fc7_720w.webp?source=d16d100b)
我想是不是权限问题,没有用sudo或者root用户没有写权限,郭佬告诉我用的root用户操作的,而且看了一下权限,是正常的644。
![图片[9] - 服务器挖矿病毒排查记录 - 编程技术交流论坛 - 糯五游戏网](https://picx.zhimg.com/80/v2-f8c70e2bde3af76b0ae5f5f7c89bd189_720w.webp?source=d16d100b)
这里我想到了可能是入侵者改了这个文件的属性,设置了immutable权限,被设置了immutable权限的文件不能被修改、不能被删除,于是让郭佬试一下用chattr改一下权限,但是没有成功,执行后返回了chattr的usage
![图片[10] - 服务器挖矿病毒排查记录 - 编程技术交流论坛 - 糯五游戏网](https://pic1.zhimg.com/80/v2-65789925a4382accd7d8a64ef3916447_720w.webp?source=d16d100b)
于是我再次登录了服务器,排查一下原因,为了方便登录,我想先把我的公钥加到服务器里,结果编辑 /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
没有回复内容