前言
服務(wù)器好端端的竟然中了挖礦病毒！??！
可憐我那 1 核 2 G 的服務(wù)器，又弱又小，卻還免除不了被拉去當(dāng)?shù)V工的命運(yùn)，實(shí)在是慘啊慘。
事情原來是這樣的。。。
就在今天下午，我準(zhǔn)備登陸自己的遠(yuǎn)程服務(wù)器搞點(diǎn)東西的時(shí)候，突然發(fā)現(xiàn) ssh 登陸不上了。
如上，提示被拒絕。這個(gè)問題很明顯就是服務(wù)器沒有我的公鑰，或者不識別我的公鑰，然后拒絕登錄。
這就很難辦了，我確定我的公鑰是一直沒有變動(dòng)過的，不應(yīng)該會(huì)出現(xiàn)這種情況啊。
還有讓我頭疼的是，我當(dāng)初為了安全起見，設(shè)置過此臺服務(wù)器只能通過 ssh 的方式免密登錄。而且禁止了密碼直接登錄，這樣也防止了別人通過破解我的密碼而登錄服務(wù)器。
當(dāng)前，只有我這個(gè) mac 還有家里的 win 兩臺電腦有 ssh 權(quán)限。（其實(shí)，當(dāng)時(shí)我也想到了這種情況，就怕萬一有一天某臺電腦登錄不上，另外一臺還能做備選。嘿嘿，我是不是很機(jī)智?。?/p>
那么，目前的解決辦法，就是要么等著下班回家，用另外一個(gè)電腦操作，把當(dāng)前這個(gè)電腦的公鑰加到服務(wù)器的authorized_keys 文件里。要么，就只能把服務(wù)器重裝了。
但是，好奇心驅(qū)使我去探究一下，到底是什么原因?qū)е铝朔?wù)器連接不上，而不是直接重裝服務(wù)器。那樣的話，就太沒意思了。
通過 VNC 方式登錄服務(wù)器
因?yàn)槲矣玫氖球v訊云服務(wù)器嘛，于是，就登錄到了騰訊云的控制臺，想看一下是否還有其它“走后門”的方式，讓我繞過 ssh 或者不受密碼登錄的限制。
沒想到，還真的有方法。如下圖，可以通過 VNC 的方式進(jìn)去，然后輸入賬號密碼就可以直接登錄，不受限制。
可以看到已經(jīng)進(jìn)入服務(wù)器了。上一次登錄時(shí)間是昨天下午，這個(gè)時(shí)間點(diǎn)沒錯(cuò)。
發(fā)現(xiàn)問題
當(dāng)然，正常來講，我應(yīng)該先去 authorized_keys 文件檢查一下我的公鑰是否有問題。但是，習(xí)慣性的操作讓我 top 了一下，卻發(fā)現(xiàn)了另外一個(gè)問題。
等等，這是什么鬼！ 有一個(gè) sysupdate 進(jìn)程占用了 CPU 51.2%，另外還有一個(gè)進(jìn)程 networkservice 占用了 47.8% 。這兩個(gè)加起來，就已經(jīng)占用了 99% 了。
實(shí)際上，在騰訊云后臺也能監(jiān)控到服務(wù)器的實(shí)時(shí)狀況。
很明顯，這兩個(gè)進(jìn)程是比較異常的。而且，之前也沒有見過這種名字。于是，習(xí)慣性的，我就在網(wǎng)上搜了一下 sysupdate。直接，就出來了一堆結(jié)果，挖礦病毒。
我去，聽這名字，難不成就是傳說中的比特幣挖礦？不管那么多了，先解決當(dāng)前的問題吧。
解決問題
1、確認(rèn)病毒位置
先通過 systemctl status {進(jìn)程號} 查看一下它的狀態(tài)信息，以及有沒有相關(guān)聯(lián)的進(jìn)程。以 sysupdate 進(jìn)程號 16142為例。
可以發(fā)現(xiàn)它是從昨天晚上九點(diǎn)開始運(yùn)行起來的。怪不得，昨天下午下班前還能用，今天就不能用了。
還可以通過 ls -l proc/{進(jìn)程號}/exe 命令查看它具體的位置。最后發(fā)現(xiàn)都在 /etc 目錄下。
如上圖，這五個(gè)都是“挖礦病毒所用到的文件”。哼哼，從顏色上就能看出來他們是一伙的。
然而，我并沒有著急把它們清除掉，卻突然腦子一抽，想研究一下它們的腳本。因?yàn)槲铱吹接幸粋€(gè) update.sh ，里邊肯定寫了一些病毒執(zhí)行相關(guān)的命令。
我把他們?nèi)慷紡?fù)制到了我自己的目錄下 /root/test/。然后打開了 update.sh 腳本，看里邊寫了些什么。
我估計(jì)，能看著服務(wù)器都被病毒攻擊了，還有閑情研究人家是怎么制作病毒的，我是第一個(gè)吧。。
雖然菜雞我對 linux 不熟，但是大概可以看出來一些東西，如SELINUX 系統(tǒng)被關(guān)閉了，我的 authorized_keys 文件也被改動(dòng)了，竟然無恥的還把 wget、curl 等命令改了名字。
下邊，還可以看到病毒腳本的網(wǎng)絡(luò)路徑。難不成是從這個(gè)地址下載下來的？
2、刪除定時(shí)任務(wù)
看一下有沒有定時(shí)任務(wù)，因?yàn)橛锌赡芩鼤?huì)跑一個(gè)定時(shí)任務(wù)，定時(shí)的執(zhí)行腳本，生成病毒文件和進(jìn)程等。
可以進(jìn)入 /var/spool/cron/ 目錄查看定時(shí)任務(wù)。也可以通過 crontab -l查看。
沒想到卻都沒有發(fā)現(xiàn)。
如果有的話 ，刪除 /var/spoool/cron/目錄下的所有文件。或者執(zhí)行crontab -r命令，清空任務(wù)列表。
3、殺掉進(jìn)程，刪除病毒文件
用 kill -9 {進(jìn)程號} 把上邊的兩個(gè)進(jìn)程都?xì)⒌簦缓髣h除 /etc 目錄下的那五個(gè)文件。
注意刪除文件時(shí)，直接用普通的 rm -rf 不能行。因?yàn)椴《疚募绘i定了，需要通過 chattr -i {文件名} 解鎖之后，再刪除。
4、刪除 authorized_keys 文件
這個(gè)文件里記錄了可以通過 ssh 免密登錄的所有終端的公鑰。路徑在 ~/.ssh/authorized_keys 。通過 vi 命令打開。
可以看到文件里已經(jīng)被改動(dòng)了，多了兩個(gè)未知的公鑰，這肯定就是攻擊者的公鑰。前面的三個(gè)都是我自己的公鑰。
可以直接刪除此文件，等稍后再修復(fù)為自己的公鑰。
5、恢復(fù) wget 和 curl 命令
從 update.sh 文件中可以看到這兩個(gè)命令名稱被改了，對于習(xí)慣了這樣使用的人來說肯定不爽，那就改回來就好了。
如下為可選的的命令。我這里就需要前兩行就行了，因?yàn)?which cur 之后發(fā)現(xiàn)，只存在 /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、修復(fù) SELINUX
SELinux 是 linux 的一個(gè)安全子系統(tǒng)?？梢酝ㄟ^命令 getenforce 查看服務(wù)狀態(tài)。
其實(shí)從 update.sh 文件中也可以看到此服務(wù)被關(guān)閉了。
修改 /etc/selinux/config 文件，將 SELINUX=disabled 修改為 SELINUX=enforcing。
修改完成后，需要重啟服務(wù)器才能生效。
找到原因
其實(shí)，以上步驟搞完，還差一步。
你總不能被攻擊的不明不白吧，為什么別人會(huì)攻擊到你的服務(wù)器呢。
后來，從網(wǎng)上找到了一篇介紹，說：
挖礦病毒，利用Redis的未授權(quán)訪問漏洞進(jìn)行攻擊。
Redis 默認(rèn)配置為6379端口無密碼訪問，如果redis以root用戶啟動(dòng)，攻擊者可以通過公網(wǎng)直接鏈接redis，向root賬戶寫入SSH公鑰文件，以此獲取服務(wù)器權(quán)限注入病毒
我去，看完之后，感覺這個(gè)描述簡直不能太準(zhǔn)了。
因?yàn)?，昨天下午，我就是因?yàn)橐獪y試通過 redis 的 zset 來實(shí)現(xiàn)延時(shí)隊(duì)列的一個(gè)功能。用本地代碼連接了服務(wù)器的 redis 。當(dāng)時(shí)就在防火墻中把 6379 端口打開了。
誰曾想，一晚上的功夫，就被人家攻擊了。
我想，挖礦人肯定也是找大量的機(jī)器來實(shí)驗(yàn)，看能否通過這些漏洞（肯定不限于只有 redis），操縱對方的服務(wù)器。于是，我就幸運(yùn)的成為了那個(gè)倒霉蛋。
最后，我粗暴的把 redis 服務(wù)關(guān)了，并且去掉了 6379 的端口。
額，其實(shí)有更溫柔的方案可選，比如更改 redis 的默認(rèn)端口號，或者給 redis 添加密碼。
最后
感覺整篇下來，好像除了知道 redis 的這個(gè)漏洞外，就沒有其他收獲了。主要是，我的安全意識還是比較薄弱吧。
畢竟，服務(wù)器只是拿來玩玩用的。最后實(shí)在不行也可以重裝系統(tǒng)，完事又是一條好漢。
公司的服務(wù)器肯定不會(huì)這樣的，都有專門的運(yùn)維人員來做這些安全工作。如果是線上服務(wù)器被人家拉去挖礦，好歹能拿我這篇文章吹牛逼了。。。
