終于,病毒向我伸出了魔爪......

前言

服務器好端端的竟然中了挖礦病毒!!!

可憐我那 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 的這個漏洞外,就沒有其他收獲了。主要是,我的安全意識還是比較薄弱吧。

畢竟,服務器只是拿來玩玩用的。最后實在不行也可以重裝系統,完事又是一條好漢。

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

posted @ 2020-07-17 20:25  煙雨星空  閱讀(...)  評論(...編輯  收藏
最新chease0ldman老人