前言
服務器好端端的竟然中了挖礦病毒！！！
可憐我那 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 的這個漏洞外，就沒有其他識訓了，主要是，我的安全意識還是比較薄弱吧，
畢竟，服務器只是拿來玩玩用的，最后實在不行也可以重裝系統，完事又是一條好漢，
公司的服務器肯定不會這樣的，都有專門的運維人員來做這些安全作業，如果是線上服務器被人家拉去挖礦，好歹能拿我這篇文章吹牛逼了，，，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/141149.html
標籤：Java
上一篇：WebFlux快速上手