沒想到竟是由於它！讓個人服務器變成了別人的挖礦工具

前言

服務器好端端的居然中了挖礦病毒！！！

可憐我那 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。直接，就出來了一堆結果，挖礦病毒。

我去，聽這名字，難不成就是傳說中的比特幣挖礦？無論那麼多了，先解決當前的問題吧。

 

解決問題

一、確認病毒位置

先經過 systemctl status {進程號} 查看一下它的狀態信息，以及有沒有相關聯的進程。以  sysupdate 進程號 16142爲例。

能夠發現它是從昨天晚上九點開始運行起來的。怪不得，昨天下午下班前還能用，今天就不能用了。

還能夠經過 ls -l proc/{進程號}/exe 命令查看它具體的位置。最後發現都在 /etc 目錄下。

如上圖，這五個都是「挖礦病毒所用到的文件」。哼哼，從顏色上就能看出來他們是一夥的。

然而，我並無着急把它們清除掉，卻忽然腦子一抽，想研究一下它們的腳本。由於我看到有一個 update.sh ，裏邊確定寫了一些病毒執行相關的命令。

我把他們所有都複製到了我本身的目錄下 /root/test/。而後打開了 update.sh 腳本，看裏邊寫了些什麼。

我估計，能看着服務器都被病毒***了，還有閒情研究人家是怎麼製做病毒的，我是第一個吧。。

雖然菜雞我對 linux 不熟，可是大概能夠看出來一些東西，如SELINUX 系統被關閉了，個人 authorized_keys 文件也被改動了，居然無恥的還把 wget、curl 等命令改了名字。

下邊，還能夠看到病毒腳本的網絡路徑。難不成是從這個地址下載下來的？

二、刪除定時任務

看一下有沒有定時任務，由於有可能它會跑一個定時任務，定時的執行腳本，生成病毒文件和進程等。

能夠進入 /var/spool/cron/ 目錄查看定時任務。也能夠經過 crontab -l查看。

沒想到卻都沒有發現。

**若是有的話，**刪除 /var/spoool/cron/目錄下的全部文件。或者執行crontab -r命令，清空任務列表。

三、殺掉進程，刪除病毒文件

用 kill -9 {進程號} 把上邊的兩個進程都殺掉，而後刪除 /etc 目錄下的那五個文件。

注意刪除文件時，直接用普通的 rm -rf 不能行。由於病毒文件被鎖定了，須要經過 chattr -i {文件名} 解鎖以後，再刪除。

四、刪除 authorized_keys 文件

這個文件裏記錄了能夠經過 ssh 免密登陸的全部終端的公鑰。路徑在 ~/.ssh/authorized_keys 。經過 vi 命令打開。

能夠看到文件裏已經被改動了，多了兩個未知的公鑰，這確定就是***者的公鑰。前面的三個都是我本身的公鑰。

能夠直接刪除此文件，等稍後再修復爲本身的公鑰。

五、恢復 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

六、修復 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 的這個漏洞外，就沒有其餘收穫了。主要是，個人安全意識仍是比較薄弱吧。

畢竟，服務器只是拿來玩玩用的。最後實在不行也能夠重裝系統，完事又是一條好漢。

公司的服務器確定不會這樣的，都有專門的運維人員來作這些安全工做。若是是線上服務器被人家拉去挖礦，好歹能拿我這篇文章吹牛逼了。。。

有道無術，術可成；有術無道，止於術