前言
服務器好端端的竟然中了挖礦病毒！！！
可憐我那 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 的這個漏洞外，就沒有其他收穫了。主要是，我的安全意識還是比較薄弱吧。
畢竟，服務器只是拿來玩玩用的。最後實在不行也可以重裝系統，完事又是一條好漢。
公司的服務器肯定不會這樣的，都有專門的運維人員來做這些安全工作。如果是線上服務器被人家拉去挖礦，好歹能拿我這篇文章吹牛逼了。。。
