记一次服务器被挖矿的处理过程
背景
今天突然收到百度云发来的告警邮件，说我的服务器出现了异常挖矿行为，意味着我的服务器被黑了。导致我部署的服务响应慢，甚至无法访问。于是晚上就开始了排查工作。
last 命令查看登录记录
[root@ls ~]# last
root pts/0 112.111.24.78 Fri Mar 4 20:14 still logged in
root pts/0 106.44.60.63 Fri Mar 4 19:00 - 19:02 (00:02)
root pts/0 113.200.202.122 Fri Mar 4 17:16 - 17:17 (00:01)
root pts/0 117.35.117.234 Fri Mar 4 16:47 - 16:51 (00:04)
root pts/0 117.35.117.234 Fri Mar 4 16:31 - 16:41 (00:09)
root pts/0 117.35.117.234 Fri Mar 4 16:19 - 16:25 (00:06)
reboot system boot 3.10.0-1160.41.1 Fri Mar 4 15:29 - 20:15 (04:45)
root pts/0 112.111.24.94 Mon Feb 28 13:25 - 13:28 (00:02)
root pts/1 112.111.24.94 Mon Feb 28 11:17 - 11:29 (00:12)
root pts/0 112.111.24.94 Mon Feb 28 10:22 - 12:34 (02:12)
wtmp begins Sat Feb 26 16:42:17 2022经过 IP 查询，未发现异常，但是系统中间却重启了一次，此时推断应该是：攻击者清除了登录记录日志导致的。
last 命令
last 列出当前和曾经登入系统的用户信息
它默认读取的是/var/log/wtmp 文件的信息。
输出的内容包括：用户名、终端位置、登录源信息、开始时间、结束时间、持续时间。
注意最后一行输出的是 wtmp 文件起始记录的时间。
当然也可以通过 last -f 参数指定读取文件，可以是/var/log/btmp、/var/run/utmp
last -f btmp 查看记录错误的登录尝试日志
btmp 文件
/var/log/btmp 用于记录错误的登录尝试
/var/log/btmp 文件过大形成原因：可能存在暴力破解登录所致
文件过大的解决方法：
- 初步清理该文件 echo > /var/log/btmp
- 更换远程登录端口
- lastb 查看具体信息，查找出现次数较多的，封 IP
# 查找恶意登录的前十个IP
sudo lastb | awk '{ print $3}' | awk '{++S[$NF]} END {for(a in S) print a, S[a]}' | sort -rk2 |head
# 查看Linux 文件系统磁盘的使用情况
df -h[root@ls log]# last -f btmp
root ssh:notty 43.154.163.60 Fri Mar 4 20:19 gone - no logout
root ssh:notty 148.66.135.237 Fri Mar 4 20:15 - 20:19 (00:04)
foo ssh:notty 43.154.163.60 Fri Mar 4 20:15 - 20:15 (00:00)
...... 此处省略中间其他记录
root ssh:notty 143.110.182.208 Tue Mar 1 04:00 - 05:20 (01:19)
root ssh:notty 143.110.182.208 Tue Mar 1 04:00 - 04:00 (00:00)
root ssh:notty 143.110.182.208 Tue Mar 1 03:59 - 04:00 (00:00)
root ssh:notty 143.110.182.208 Tue Mar 1 03:58 - 03:59 (00:00)
btmp begins Tue Mar 1 03:58:56 2022可以发现，从最早的记录四天前就已经开始产生了很多错误登录日志。此时推断：大概率为被用字典暴力破解了密码。
查看 btmp 文件大小为：
[root@ls log]# ls -alh
total 44M
-rw------- 1 root utmp 502K Mar 4 20:49 btmp
-rw-rw-r-- 1 root utmp 11K Mar 4 20:50 wtmp可以发现，wtmp 文件记录的登录日志只有 11k，而登录错误日志记录却有 502k 大。基本可以实锤是被暴力破解了。
由于使用 last -f btmp 命令列出来的登录错误数记录太多了，因此这里找出恶意登录的前十个 IP，并查询其归属地如下：
[root@ls log]# lastb | awk '{ print $3}' | awk '{++S[$NF]} END {for(a in S) print a, S[a]}' | sort -rk2 |head
45.61.185.188 9 美国 加利福尼亚 洛杉矶
143.198.227.202 9 美国 科罗拉多
121.5.205.212 9 中国 上海市 上海市 腾讯云 数据中心
116.247.81.99 9 印度尼西亚 雅加达 阿里云 数据中心
116.235.92.247 9 中国 上海市 宝山区 电信
8.215.29.53 8 印度尼西亚 雅加达 阿里云 数据中心
60.10.199.104 8 中国 河北省 廊坊市 三河市 联通
49.234.45.241 8 中国 上海市 上海市 腾讯云 数据中心
46.19.139.42 8 瑞士 苏黎世
43.154.56.24 8 中国 香港特别行政区 腾讯云 数据中心再查看一下 root 用户执行的命令的历史记录
[root@ls log]# history 500
1 root 2022/02/26 16:41:48 cat /dev/null > /root/.bash_history
2 root 2022/02/26 16:41:48 echo > /var/log/wtmp
3 root 2022/02/26 16:41:48 echo > /var/log/btmp
4 root 2022/02/26 16:41:48 echo > /var/spool/mail/root
5 root 2022/02/26 16:41:48 chattr +i /var/spool/mail/root
6 root 2022/02/26 16:41:48 chattr -i /var/log/wtmp /var/log/btmp
7 root 2022/03/04 20:50:30 cd /var/log
8 root 2022/03/04 20:50:34 ll
9 root 2022/03/04 20:52:54 ls -alh
10 root 2022/03/04 21:03:51 history 500发现，果然，第 2~4 行清空了登录日志记录等信息。跟前面用 last 命令看到的结果对应。毫无疑问， history 也让攻击者清理了。大致推断 2022/02/26 服务器已经被攻破了。
第 5 行用 chattr 命令又锁定了 /var/spool/mail/root 文件。
第 6 行用 chattr 命令取消锁定 /var/log/wtmp /var/log/btmp 文件。
top 命令查看一下 CPU 占用
[root@ls log]# top
top - 21:17:52 up 5:47, 2 users, load average: 5.85, 5.89, 5.96
Tasks: 158 total, 1 running, 157 sleeping, 0 stopped, 0 zombie
%Cpu(s): 99.8 us, 0.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 4045012 total, 2788908 free, 348176 used, 907928 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 3468732 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
17225 root 20 0 89140 7792 8 S 199.7 0.2 438:59.29 bioser
# 进程 1428 后面再说
1428 root 20 0 88692 916 404 S 148.8 0.0 195:14.57 kworker
1700 polkitd 20 0 52812 9964 3128 S 0.3 0.2 0:31.44 redis-server可以发现 CPU 占用极高，长时间 99.8% us 了，其中 PID 17225 这个进程 CPU 占用率极大。
用命令 netstat -antlp 查看了应用连接
找到 PID=17255 进程的应用连接如下：
[root@ls log]# netstat -antlp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 1 192.168.0.4:37572 104.244.46.165:443 SYN_SENT 17225/bioser经过查询 IP 得知，IP 104.244.46.165 地址为 美国 加利福尼亚 （网络 Twitter）。我有点懵逼了，twitter 跟挖矿有关系？
查看这个程序的根源出自哪里，使用命令 ls -l /proc/进程号/exe 探查
[root@ls log]# ls -l /proc/17225/exe
lrwxrwxrwx 1 root root 0 Mar 4 15:40 /proc/17225/exe -> /usr/bin/bioser发现它指向 /usr/bin/bioser 文件。通过 ll 命令查看文件创建日期，也是 2022-02-26 日 16:41，时间对的上，所以这个程序文件肯定是有问题的。
-rwxr-xr-x 1 root root 2427132 Feb 26 16:41 bioser检查出现问题用户的 crontab 定时任务
检查出现问题用户的 crontab 定时任务，看是否被写入了定时计划，否则可能定时或者 reboot 之后又会启动病毒，使用命令 crontab -l -u root 检查。或者直接 crontab -l
[root@ls tmp]# crontab -l
*/5 * * * * /opt/hosteye/bin/upgrade --upgrade_mode=8>/dev/null 2>&1并没有发现有异常的定时计划。如果有的话就需要删除异常定时计划。
# 查看帮助
crontab -h
# 清除所有用户定时任务
crontab -r另外，还需排查以下目录的定时任务：
[root@ls etc]# cd /etc
[root@ls etc]# ll
drwxr-xr-x. 2 root root 4096 Jun 12 20:38 cron.d
drwxr-xr-x. 2 root root 4096 Jan 26 2021 cron.daily
-rw-------. 1 root root 0 Aug 9 2019 cron.deny
drwxr-xr-x. 2 root root 4096 Jun 12 20:38 cron.hourly
drwxr-xr-x. 2 root root 4096 Jun 10 2014 cron.monthly
-rw-r--r--. 1 root root 451 Jun 10 2014 crontab
drwxr-xr-x. 2 root root 4096 Jun 10 2014 cron.weekly
# 查看以上文件是否有指向异常进程相同的 url 或者未知的定时任务。检查 root 用户 .ssh 目录下 authorized_keys 是否被配置了后门的 ssh 的 key
[root@ls tmp]# cd ~
[root@ls ~]# ll
total 4
drwxr-xr-x 3 root root 4096 Jan 23 21:27 upload
[root@ls ~]#并未发现 root 用户目录下有 .ssh 目录，因此这里没有问题。如果有就删掉对应的 key。
病毒清理
通过以上排查，认为只需要杀掉 bioser(进程号：17225) 进程，然后清理掉 /usr/bin/bioser 文件即可。
[root@ls ~]# kill -9 17225
# 当我以为万事大吉的时候，却出现了下面的问题。
[root@ls bin]# rm -rf bioser
rm: cannot remove ‘bioser’: Operation not permitted我用 root 用户，居然删不掉它！！！
查看用户组，感觉没啥特别的：
[root@ls bin]# ll
-rwxr-xr-x 1 root root 2427132 Feb 26 16:41 bioser此时想到前面攻击者用 chattr 命令锁定和取消锁定了一些文件，我也尝试一下解锁 bioser 文件：
# 查看文件属性：
[root@ls bin]# lsattr bioser
-----a-------e-- bioser
# 去除属性
[root@ls bin]# chattr -a /usr/bin/bioser
[root@ls bin]# rm -rf bioser
# 删除成功了
[root@ls bin]#lsattr 查看文件属性
看到的情况如果是 -----a-------或者-----i------- 就要去除属性才能删除。---e--表示 ext4 或 ext3 文件系统所特有的
去除属性：chattr -a xxx 或者 chattr -i xxx
当我以为再次万事大吉的时候，用 top 命令看了下，发现 bioser 的进程又活过来了！！！这次变成了 PID 17816
# 再次查看进程指向，此时显示文件已被删除，应该是我删除操作慢了，还有恢复进程把它在我还没删除的时候又拉起来了。
[root@ls bin]# ls -l /proc/17816/exe
lrwxrwxrwx 1 root root 0 Mar 4 22:00 /proc/17816/exe -> /usr/bin/bioser (deleted)
# 于是，我尝试再次删除它
[root@ls bin]# kill -9 17816于是新的问题来了，是哪个进程把它重新拉起来的呢？(实际上是它自己把自己拉起来了，我中了两个病毒。) 再次用 top 命令查看 CPU 占用，发现进程号为 1428 的 CPU 占用率高。
[root@ls bin]# top
top - 22:24:59 up 6:55, 2 users, load average: 2.56, 3.48, 4.62
Tasks: 163 total, 2 running, 161 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8.2 us, 64.0 sy, 0.0 ni, 19.7 id, 0.0 wa, 0.0 hi, 7.9 si, 0.2 st
KiB Mem : 4045012 total, 1266032 free, 1646100 used, 1132880 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 2169340 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1428 root 20 0 88692 916 404 S 151.5 0.0 199:23.66 kworker
6 root 20 0 0 0 0 S 1.3 0.0 2:46.79 ksoftirqd/0
14 root 20 0 0 0 0 S 1.3 0.0 2:41.50 ksoftirqd/1
20575 root 20 0 1419924 39056 13664 S 1.3 1.0 0:31.09 hosteye
9 root 20 0 0 0 0 R 0.7 0.0 0:52.47 rcu_sched
5614 root 20 0 3711416 720748 13836 S 0.3 17.8 1:03.27 java
7178 root 20 0 3529616 540816 13648 S 0.3 13.4 0:36.47 java查看 1428 进程指向：
[root@ls bin]# ls -l /proc/1428/exe
lrwxrwxrwx 1 root root 0 Mar 4 15:30 /proc/1428/exe -> /etc/kworker
[root@ls bin]#
[root@ls bin]# cd /etc
[root@ls etc]# ll
total 2652
-rwsrwsrwt 1 root root 1223123 Feb 26 16:41 kworker查看 kworker 文件创建日期，和前面删除的 bioser 文件一样，也是 2022-02-26 日 16:41 创建的，时间对的上。那么这个文件也是有问题的。
貌似有个系统进程就要 kworker，这个新创建的文件也叫 kworker，不管了，直接杀进程，删文件。
[root@ls etc]# kill -9 1428
[root@ls etc]#
# 查看文件属性，猜测应该跟删除 bioser 文件一样，被锁定了，要先解锁才能删除。
[root@ls etc]# lsattr kworker
----ia-------e-- kworker
[root@ls etc]#
# 果然被锁定了，而且同时加了 i 和 a 属性。
# 去除属性。-ai：同时去除 i 和 a 属性
[root@ls etc]# chattr -ai /etc/kworker
# 删除
[root@ls etc]# rm -rf kworker到这里我感觉就已经万事大吉了。top 命令查看一下。发现 kworker 又活了，PID 变成了 18860
# 再次查看进程指向，此时显示文件已被删除，好吧，又是我手慢了，在我删除之前它已经拉起来了。
[root@ls etc]# ls -l /proc/18860/exe
lrwxrwxrwx 1 root root 0 Mar 4 22:31 /proc/18860/exe -> /etc/kworker (deleted)
[root@ls etc]#
# 于是，我尝试再次删除它
[root@ls bin]# kill -9 18860这下应该好了吧！top 命令查看，一切正常，重启一下看看，重启也没问题。等第二天再看看。夜深了，暂时可以洗洗睡啦。
正当我准备以为暂时没问题了，可以关电脑的时候，发现 /etc/kworker 文件自己又回来了！！！
通过查找资料，/etc/kworker 应该是一个系统程序，那为什么 CPU 占用率高呢？我认为应该是攻击者修改了 kworker 的代码，加入了恶意代码，然后覆盖掉操作系统原有的程序。
通过查看定时任务发现：百度云默认安装了 /opt/hosteye/bin/hosteye 软件，这个应该是百度云安全监控的。它可能会检测自动升级。
[root@ls etc]# crontab -l
*/5 * * * * /opt/hosteye/bin/upgrade --upgrade_mode=8>/dev/null 2>&1当我删掉 kworker 时，自然清理掉了恶意程序。
此时猜测，操作系统运行应该还是需要 kworker 程序的，它可能有什么自我修复的功能，又把安全的 kwoker 恢复了。
具体原因不明（有高手知道的话求分享）。反正第二天查看 CPU 占用，一切正常了。
思考和总结
感觉我应该中了两个病毒程序，一个是 bioser，有自我唤醒的特点；一个是被恶意修改了的 kworker。
只要这两个恶意文件存在，它们就能够被拉起来，不清楚还有没有其他某个地方被攻击者修改了，先观察一段时间。
后记
我以为我这个服务器就是自己测试用的，应该没有黑客大佬惦记，因此服务器 root 用户的密码设置的很简单，防火墙也没开，所有的应用端口也都是默认的，结果还真中奖了。
接下来，是要考虑增加一些安全措施了。大概列一下：
- 密码要设置的复杂一些，增加被暴力破解的难度；
- 时刻将防火墙开启，仅开放需要的端口号；
- 更改默认远程 SSH 端口。可以参考百度云服务器安全说明；
- 即使清除了挖矿程序，也不能确保攻击者还留有其他后门，最好备份数据后，重装系统。