解決伺服器滿CPU被當礦機問題

    最近伺服器碰到反應速度變慢問題。一看程式，有個程式名字為亂碼的9-10位英文的程式（例如rrgjpvryri），一直在滿CPU在跑。並且啟動方式是繫結基本的系統指令（例如top，ls等指令）啟動的。

  

    並且不斷kill之後，過一小段時間又會產生一個新的另一個名字的程式繼續跑。在網上查詢了一些資料，發現是自己的伺服器中了病毒，被別人當成礦機在挖bitcoin了。

     解決問題的方法：

     第一步： 檢視與該程式相關聯的檔案

root@ubuntu:~# lsof -p 24183

COMMAND     PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
rrgjpvryr 16137 root  cwd    DIR  252,0     4096 29622273 /root
rrgjpvryr 16137 root  rtd    DIR  252,0     4096        2 /
rrgjpvryr 16137 root  txt    REG  252,0   625878  8920905 /usr/bin/rrgjpvryri
rrgjpvryr 16137 root    0u   CHR    1,3      0t0        6 /dev/null
rrgjpvryr 16137 root    1u   CHR    1,3      0t0        6 /dev/null
rrgjpvryr 16137 root    2u   CHR    1,3      0t0        6 /dev/null
rrgjpvryr 16137 root    3u  sock    0,8      0t0 32843925 protocol: UDP

    可以看出來，這個程式的啟動檔案是在/usr/bin/下面，然後通過UDP與對方（挖礦的人）保持連線的。

    第二步： 檢查/etc/crontab

    這種病毒大多數是通過定時任務來啟動的。檢查/etc/crontab，會發現這裡有個每3分鐘定時啟動的gcc.sh (剛看到這個檔案完全不敢相信這是病毒檔案）    

                   

      將這句話註釋掉。然後我們來看一下gcc.sh下到底是什麼內容：

     

       像這種頭部沒註釋（一般系統檔案都會帶有較長的註釋，還有License之類的），建立時間又不長的檔案，極大概率就是病毒。然後可以看見，這個檔案將 libudev.so 不斷複製，這麼來看，病原體主要就是這個檔案。

      瞭解後將/etc/cron.hourly下的gcc.sh刪除。注意刪除gcc.sh之後不要直接kill掉挖礦程式，這樣gcc.sh又會重新出現

    

       第三步：處理libudev.so

        找到病原體之後，嘗試將libudev.so刪除，但是已刪除之後，立馬又會出現一個新的libudev.so。這時候檢查gcc.sh還是被刪除的狀態。我懷疑是現在正在跑的挖礦程式在監視這個檔案，一旦刪除立馬新建一個這樣的.so檔案。於是我嘗試直接kill掉rrgjpvryri程式，但是這樣又會出現一個新的亂碼挖礦程式繼續跑，並且這時候再看/etc/cron.hourly下面，gcc.sh又再次出現。

        這樣看來，這個病毒是自己組成了一個環路，一旦執行起來之後互相不斷建立。所以想要解決問題，只能說是減斷某條道路，讓他們不能組成一個環路。

        成功的步驟：

        1. 刪除gcc.sh，如步驟一。

        2. 刪除所有的病毒系統啟動項

                    這個病毒把自己新增到了開機啟動的目錄中。檢查/etc/init.d目錄，/etc/rc#.d/目錄下的所有檔案，通過建立日期和程式名判斷該啟動項是否為病毒。也可以通過內容檢視是否為病毒，一般病毒檔案裡面內容短小，並且寫法一樣，如下圖：

        

            然後/bin目錄下的所有病毒啟動檔案最好也一併刪除，一般啟動檔案都是當天建立的，把/bin目錄下的當天建立的啟動項刪掉就好：

             

            以上這些當天建立的啟動檔案都是病毒建立的，通過命令：

    find /bin -mtime -1 -file f -print | xargs rm -rf

            記住一定要加 -file f， 要不它會把/bin下面的所有檔案刪掉（我就照著某傻逼知道來做，然後全刪了gg，系統命令用不了，沒想到最後靠git曲線救國了）。

            3. 重啟伺服器

                   到這裡按道理一開始病毒沒有通過守護程式開機啟動的話，就不會再啟動了，這時候再把libudev.so刪掉，就沒有問題了。注意要按照順序來，要不生生死死輪迴不止。。。

            中間還有用到一些限制更改之類的操作，如果中間某個步驟跟預想的不符的話，可以試試：

    chattr +i /etc/init.d/

    chattr +i /lib/libudev4.so 

            4. 檢查

             重啟之後再檢查一下程式。到這裡應該是沒問題了。

思考：

        這個病毒是怎麼進來的呢？阿里雲伺服器上似乎有很多人都遭遇了這個問題，這個問題是由於Redis的漏洞造成的。要把未授權的redis服務設定密碼，修改埠號，修改root密碼等，防止再次被入侵。