前言
伺服器好端端的竟然中了挖礦病毒！！！
可憐我那 1 核 2 G 的伺服器，又弱又小，卻還免除不了被拉去當礦工的命運，實在是慘啊慘。
事情原來是這樣的。。。
就在今天下午，我準備登陸自己的遠端伺服器搞點東西的時候，突然發現 ssh 登陸不上了。
如上，提示被拒絕。這個問題很明顯就是伺服器沒有我的公鑰，或者不識別我的公鑰，然後拒絕登入。
這就很難辦了，我確定我的公鑰是一直沒有變動過的，不應該會出現這種情況啊。
還有讓我頭疼的是，我當初為了安全起見，設定過此臺伺服器只能通過 ssh 的方式免密登入。而且禁止了密碼直接登入，這樣也防止了別人通過破解我的密碼而登入伺服器。
當前，只有我這個 mac 還有家裡的 win 兩臺電腦有 ssh 許可權。（其實，當時我也想到了這種情況，就怕萬一有一天某臺電腦登入不上，另外一臺還能做備選。嘿嘿，我是不是很機智！）
那麼，目前的解決辦法，就是要麼等著下班回家，用另外一個電腦操作，把當前這個電腦的公鑰加到伺服器的authorized_keys 檔案裡。要麼，就只能把伺服器重灌了。
但是，好奇心驅使我去探究一下，到底是什麼原因導致了伺服器連線不上，而不是直接重灌伺服器。那樣的話，就太沒意思了。
通過 VNC 方式登入伺服器
因為我用的是騰訊雲伺服器嘛，於是，就登入到了騰訊雲的控制檯，想看一下是否還有其它“走後門”的方式，讓我繞過 ssh 或者不受密碼登入的限制。
沒想到，還真的有方法。如下圖，可以通過 VNC 的方式進去，然後輸入賬號密碼就可以直接登入，不受限制。
可以看到已經進入伺服器了。上一次登入時間是昨天下午，這個時間點沒錯。
發現問題
當然，正常來講，我應該先去 authorized_keys 檔案檢查一下我的公鑰是否有問題。但是，習慣性的操作讓我 top 了一下，卻發現了另外一個問題。
等等，這是什麼鬼！ 有一個 sysupdate 程式佔用了 CPU 51.2%，另外還有一個程式 networkservice 佔用了 47.8% 。這兩個加起來，就已經佔用了 99% 了。
實際上，在騰訊雲後臺也能監控到伺服器的實時狀況。
很明顯，這兩個程式是比較異常的。而且，之前也沒有見過這種名字。於是，習慣性的，我就在網上搜了一下 sysupdate。直接，就出來了一堆結果，挖礦病毒。
我去，聽這名字，難不成就是傳說中的比特幣挖礦？不管那麼多了，先解決當前的問題吧。
解決問題
1、確認病毒位置
先通過 systemctl status {程式號} 檢視一下它的狀態資訊，以及有沒有相關聯的程式。以 sysupdate 程式號 16142為例。
可以發現它是從昨天晚上九點開始執行起來的。怪不得，昨天下午下班前還能用，今天就不能用了。
還可以通過 ls -l proc/{程式號}/exe 命令檢視它具體的位置。最後發現都在 /etc 目錄下。
如上圖，這五個都是“挖礦病毒所用到的檔案”。哼哼，從顏色上就能看出來他們是一夥的。
然而，我並沒有著急把它們清除掉，卻突然腦子一抽，想研究一下它們的指令碼。因為我看到有一個 update.sh ，裡邊肯定寫了一些病毒執行相關的命令。
我把他們全部都複製到了我自己的目錄下 /root/test/。然後開啟了 update.sh 指令碼，看裡邊寫了些什麼。
我估計，能看著伺服器都被病毒攻擊了，還有閒情研究人家是怎麼製作病毒的，我是第一個吧。。
雖然菜雞我對 linux 不熟，但是大概可以看出來一些東西，如SELINUX 系統被關閉了，我的 authorized_keys 檔案也被改動了，竟然無恥的還把 wget、curl 等命令改了名字。
下邊，還可以看到病毒指令碼的網路路徑。難不成是從這個地址下載下來的？
2、刪除定時任務
看一下有沒有定時任務，因為有可能它會跑一個定時任務，定時的執行指令碼，生成病毒檔案和程式等。
可以進入 /var/spool/cron/ 目錄檢視定時任務。也可以通過 crontab -l檢視。
沒想到卻都沒有發現。
如果有的話 ，刪除 /var/spoool/cron/目錄下的所有檔案。或者執行crontab -r命令，清空任務列表。
3、殺掉程式，刪除病毒檔案
用 kill -9 {程式號} 把上邊的兩個程式都殺掉，然後刪除 /etc 目錄下的那五個檔案。
注意刪除檔案時，直接用普通的 rm -rf 不能行。因為病毒檔案被鎖定了，需要通過 chattr -i {檔名} 解鎖之後，再刪除。
4、刪除 authorized_keys 檔案
這個檔案裡記錄了可以通過 ssh 免密登入的所有終端的公鑰。路徑在 ~/.ssh/authorized_keys 。通過 vi 命令開啟。
可以看到檔案裡已經被改動了，多了兩個未知的公鑰，這肯定就是攻擊者的公鑰。前面的三個都是我自己的公鑰。
可以直接刪除此檔案，等稍後再修復為自己的公鑰。
5、恢復 wget 和 curl 命令
從 update.sh 檔案中可以看到這兩個命令名稱被改了，對於習慣了這樣使用的人來說肯定不爽，那就改回來就好了。
如下為可選的的命令。我這裡就需要前兩行就行了，因為 which cur 之後發現，只存在 /bin下，/usr/bin/不存在
mv /bin/wge /bin/wget
mv /bin/cur /bin/curl
mv /usr/bin/wge /usr/bin/wget
mv /usr/bin/cur /usr/bin/curl
6、修復 SELINUX
SELinux 是 linux 的一個安全子系統。可以通過命令 getenforce 檢視服務狀態。
其實從 update.sh 檔案中也可以看到此服務被關閉了。
修改 /etc/selinux/config 檔案，將 SELINUX=disabled 修改為 SELINUX=enforcing。
修改完成後，需要重啟伺服器才能生效。
找到原因
其實，以上步驟搞完，還差一步。
你總不能被攻擊的不明不白吧，為什麼別人會攻擊到你的伺服器呢。
後來，從網上找到了一篇介紹，說：
挖礦病毒，利用Redis的未授權訪問漏洞進行攻擊。
Redis 預設配置為6379埠無密碼訪問，如果redis以root使用者啟動，攻擊者可以通過公網直接連結redis，向root賬戶寫入SSH公鑰檔案，以此獲取伺服器許可權注入病毒
我去，看完之後，感覺這個描述簡直不能太準了。
因為，昨天下午，我就是因為要測試通過 redis 的 zset 來實現延時佇列的一個功能。用原生程式碼連線了伺服器的 redis 。當時就在防火牆中把 6379 埠開啟了。
誰曾想，一晚上的功夫，就被人家攻擊了。
我想，挖礦人肯定也是找大量的機器來實驗，看能否通過這些漏洞（肯定不限於只有 redis），操縱對方的伺服器。於是，我就幸運的成為了那個倒黴蛋。
最後，我粗暴的把 redis 服務關了，並且去掉了 6379 的埠。
額，其實有更溫柔的方案可選，比如更改 redis 的預設埠號，或者給 redis 新增密碼。
最後
感覺整篇下來，好像除了知道 redis 的這個漏洞外，就沒有其他收穫了。主要是，我的安全意識還是比較薄弱吧。
畢竟，伺服器只是拿來玩玩用的。最後實在不行也可以重灌系統，完事又是一條好漢。
公司的伺服器肯定不會這樣的，都有專門的運維人員來做這些安全工作。如果是線上伺服器被人家拉去挖礦，好歹能拿我這篇文章吹牛逼了。。。
