最近伺服器碰到反應速度變慢問題。一看程序，有個程序名字為亂碼的9-10位英文的程序（例如rrgjpvryri），一直在滿CPU在跑。并且啟動方式是綁定基本的系統指令（例如top，ls等指令）啟動的。
并且不斷kill之後，過一小段時間又會産生一個新的另一個名字的程序繼續跑。在網上查找了一些資料，發現是自己的伺服器中了病毒，被别人當成礦機在挖bitcoin了。
解決問題的方法：
第一步： 檢視與該程序相關聯的檔案
[email protected]:~# 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密碼等，防止再次被入侵。