GPU挖矿分析与处置惩罚

1 现象

显卡资源断断续续地被占用，nvidia-smi看不到历程号，指定gpu卡设备(nvidia-smi -i 0)能看到对应历程号：

曾经截图发现的历程：

历程中带有octopus、stratum关键字，以此作为历程线索。
2  排查过程

2.1  开启体系调用审计

因为只有历程的关键字，也不知道挖矿历程出现频率，而且挖矿时，/proc/目录下对应挖矿历程的可执行文件显示deleted，因此并不知道泉源是那里，所以先对体系调用开启审计，具体方式：
修改auditd的审计配置/etc/audit/auditd.conf，增长日志文件数量与日志巨细：

1. # 10M
2. max_log_file = 10
3. # 100个
4. num_logs = 100

复制代码

重启auditd服务：

1. systemctl restart auditd

复制代码

之后添加审计规则：

1. auditctl -a always,exit -F arch=b64 -S execve -F key=virus

复制代码

大概意义是对每个execve体系调用都开启审计追踪（linux步伐执行基本都是fork+exec），这样在日/var/log/audit/audit.log中就能观察到木马的频率了。
过一阵子，对审计日志进行观察，确实发现有木马相关历程的执行，并且也记录了所有执行的参数：

分析时间规律：

1. grep 'octopus' /var/log/audit/audit.log* | awk '{print $2}' | awk -F ':' '{print $1}' | awk -F '(' '{print $2}' |xargs -I{} date -d @{} +"%Y-%m-%d %H:%M:%S" | sort

复制代码

时间大概是6-7分钟一次，但具体秒数具有随机性，大概是木马步伐故意为之，因此并没有直接去相关定时任务中查看异常。
不过此时没法定位泉源，只能确切地知道挖矿历程停止性出现，没有具体的现场，难以分析。
2.2  暂停历程

因为挖矿历程常常性断断续续出现，没法一直保留历程现场，因此方式是采用SIGSTOP信号，将历程设置为T状态，使得历程HUNG住而不退出，编写如下脚本catch-virus.sh：

1. #!/usr/bin/env bash
3. while true;do
4.   ps aux|grep 'octopus' | grep -v grep | awk '{print $2}' | xargs kill -19 2>/dev/null
5.   if [ $? -eq 0 ]; then
6.     echo 'I catch the virus!!!!' && exit 0
7.   fi
8.   sleep 1
9. done

复制代码

实际意义表示，每秒钟检测一次历程，一出现octopus相关的历程便直接kill -19（即发送SIGSTOP信号），并提示'I catch the virus!!!'
2.3  历程隐藏处置惩罚

理论上来讲，上一步能在挖矿历程出现时，直接给抓取到历程，不让其退出。但是在实际后面过程中发现，服务器还是出现了挖矿现象，而上面暂停历程的方法并没有生效。
也就意味着，挖矿历程出现时，并没有在ps命令列表里出现，也就是出现了历程隐藏现象，隐藏历程一般会有两种方式：
1.  ps命令被篡改
这种环境，如果体系命令本身不可信托，那么需要采用应急处置惩罚，安装busybox：apt install -y busybox，后续执行命令时，加busybox前缀，如busybox ps aux。
但实际上也没有抓到，因此并不是ps命令篡改。
2.  动态链接劫持
通过修改LD_PRELOAD环境变量或/etc/ld.so.preload文件，配置动态链接库，实现将其注入到目的历程中。
当前服务器上，查看/etc/ld.so.preload文件（已经重定名为.bak的新文件），确实有一条.so文件内容：

因此历程隐藏大概率是通过ld.so.preload文件中加载的动态链接库实现的，所以办理方式是将该文件移除或重定名：mv /etc/ld.so.preload /etc/ld.so.preload.bak。
2.4  再次暂停历程

此时再次执行catch-virus.sh，后面便成功抓到了，ps命令显示历程已经变成了T状态，现场得以保留，隐藏历程的本领被成功打破：

但实际上去查看历程相关信息的时间，也没得到很多有代价的东西，/proc对应历程目录下，只能看到当前目录是根目录/，当前可执行文件显示deleted。不过从/proc/历程号/ns目录下能看到，当前的namespace空间是宿主机的空间（由lsns -p 1查看得出），并非某个docker容器的namespace，这样至少能定位到是宿主机上的题目。
2.5 排查定时任务

既然历程隐藏的题目办理了，也定位到是宿主机的题目，而且之前也观察到挖矿历程有肯定的时间频率规律，那么接下来排查方向应该是关注宿主机的异常历程以及定时任务，这里先主要排查定时任务：
起首执行crontab -l，无有代价输出。
再去/etc/下的各种cron相关目录下查看相关任务：ls -ltr /etc/cron*

其中发现一个可疑的/etc/cron.d下，3月27号修改时间的defunct文件：

[img=100%,100%]https://www.cnblogs.com/../upload/image-CPKm.png[/img]

查看文件内容：

执行其中部分内容echo L3Jvb3QvLmNvbmZpZy9odG9wL2RlZnVuY3QK|base64 -d：

[img=100%,100%]https://www.cnblogs.com/../upload/image-AeMo.png[/img]

可以看到，实际上是去执行/root/.config/htop/defunct文件，也的确在该目录下发现该文件（已经重定名）：

该文件是个二进制文件，无法查看具体执行了什么，此时选择手动执行该文件，同时用strace追踪该文件启动时的体系调用过程：
strace -ff /root/.config/htop/defunct
查看文件内容，发现几处可疑：
1、访问/etc/ld.so.preload ：

2、新打开一个/tmp/下的临时文件，并将该文件描述符设置为1：

3、往该文件描述符1中写入一些看不懂的二进制数据：

4、将该文件权限设为755，并切换到根目录/，执行该文件，并显示为[kworker/00:0]，这是linux内核线程的表现形式：

5、删除该文件：

[img=100%,100%]https://www.cnblogs.com/../upload/image-tllF.png[/img]

很显然，该历程的作用其实就是启动一个名为[kworker/00:0]的历程，伪装成内核线程在宿主机上，并且使用ld.so.preload加载动态链接库，隐藏历程并加以进一步的伪装，以致于极其难以发现。从体系调用过程也能看出来，chdir与unlinkat就是步伐所在执行目录是根目录/，并且文件显示deleted的原因。
3 规复措施

已经定位到该历程名，刚好此时在宿主机上执ps auxfww发现如下历程关系：

可以看到[kworker/00:0]下有个python3的子历程，也即我们最初发现的挖矿历程。
因此，实际挖矿现象产生本质原因，就是[kworker/00:0]历程定期去fork一个python3的挖矿历程，只不过这个期限应该是在步伐内部随机在7分半钟左右。
因此只需要避免[kworker/00:0]这个伪装出来的历程再次产生就行了，从上面的泉源可以看到，实际上就是定时任务天天去执行/root/.config/htop/defunct文件，那么只需要先将已有的历程kill掉，并将/root/.config/htop/defunct重定名即可。
进一步清算，应该是删除/etc/ld.so.preload文件，以及其中的库文件/lib64/libnss.so，删除/etc/cron.d/defunct文件，删除/root/.config/htop/defunct文件，不过先可以观察几天再删。
此时也仍然需要在后台执行catch-virus.sh，并查看/var/log/audit/文件下的日志，看是否有挖矿历程的产生，以便验证是否生效，没有任何结果输出就说明木马步伐确实消散了。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。