<sub id="gqw76"><listing id="gqw76"></listing></sub>
      <sub id="gqw76"><listing id="gqw76"></listing></sub>

    1. <form id="gqw76"><legend id="gqw76"></legend></form>
    2. 終于,病毒向我伸出了魔爪......

      前言

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

      可憐我那 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  煙雨星空  閱讀(2542)  評論(25編輯  收藏  舉報
      最新chease0ldman老人|无码亚洲人妻下载|大香蕉在线看好吊妞视频这里有精品www|亚洲色情综合网

        <sub id="gqw76"><listing id="gqw76"></listing></sub>
        <sub id="gqw76"><listing id="gqw76"></listing></sub>

      1. <form id="gqw76"><legend id="gqw76"></legend></form>