一次雲伺服器淪陷實錄:十字元病毒,殺不死的小強

一次雲伺服器淪陷實錄:十字元病毒,殺不死的小強

2 人贊了文章

本文作者:51CTO博客作者 南非螞蟻

一、現象

接到客戶的電話,說自己的雲伺服器被提供商禁止訪問了,原因是監測到網路流量暴滿,伺服器不停的向外發包,在確認客戶沒有業務量突增的情況下,初步判斷可能伺服器遭受了流量攻&擊(DDOS),不過按照常理來說,客戶的業務系統就是一個小的web系統,平時流量不大,影響力也一般,不至於遭受DDOs,帶著這些疑問,要到了客戶伺服器的登錄方式,廢話少說,還是進入系統,一查究竟吧。點擊此處有驚喜

二、排查問題

下圖是登錄系統後,執行top命令的輸出結果,綜合查看,系統整體負載並不高,但是帶寬佔用很高,由於雲伺服器帶寬基本耗盡,ssh登錄伺服器也非常慢,幾乎不能執行任何操作。

此外,還發現第一個進程佔用很大cpu資源,就是名為apgffcztwi的進程,這個進程名剛好10個字元,這是什麼進程,名字相當古怪,肯定有問題,從文件名看出,這不像一個正常的系統進程。

既然有古怪,那就看看這個進程是哪個程序啟動的,操作方式見下圖:

簡單吧,通過剛才那個進程的pid,然後去proc下面查看pid目錄下面對應的exe文件,就能找到進程對應的啟動程序,linux就是這麼敞亮,一下子找到了這個程序位於/usr/bin目錄下。

既然找到了這個程序,那就詳細查看下這個程序的屬性信息吧,如下圖:

看到了嗎,第一個文件,文件的讀、寫和執行屬性均沒有,相當古怪。好吧,先記錄下來這個文件的位置和路徑。

下面繼續查看系統進程信息,看看有無其它異常,通過ps命令又發現了新的線索,如下圖:

在/usr/bin目錄下有隱藏的.sshd文件,這個文件是正常系統所沒有的,又一個可疑線路,仍然記錄下來。

繼續查看系統進程,可疑進程還遠遠不止這些,這不,又發現了一個可疑進程,如下圖:

/usr/bin/dpkgd/ps -ef這個進程很明顯是個變種的病毒,因為我們指定ps命令肯定不會存在/usr/bin/dpkgd目錄下,既然說到/usr/bin/dpkgd目錄,那麼就到這個目錄下去看個究竟,繼續上圖:

又發現一些隱藏的病毒文件了,比如lsof ps netstat ss,這些都是變種病毒文件,主要用來替換系統中的一些命令,當看到netstat這個命令時,基本明白了這個病毒的意圖了,它無非就是發流量包,造成網路癱瘓,病毒替換了系統原有的包,換成自身經過改寫的命令包,這樣,既隱藏了自己的行為,又不會對伺服器造成太大影響,但是它的真正目的就是用咱們的機器做肉雞啊。真是用心良苦。

記錄這個線索,然後繼續通過dmesg命令查看系統信息,看看有沒有異常,上圖:

果然有異常信息,nf_conntrack是iptables裡面的連接跟蹤模塊,它通過哈希表記錄已建立的連接,包括其他機器到本機、本機到其他機器、本機到本機的連接,出現dropping packet,就是由於伺服器訪問量大,內核netfilter模塊conntrack相關參數配置不合理,導致新連接被drop掉。查看nf_conntrack_max,看看設置多大:

[root@server~]# cat /proc/sys/net/netfilter/nf_conntrack_max2097152

nf_conntrack_max設置200多萬,已經設置很大了,看來不是這個參數設置導致的。估計應該是上面的一些異常進程導致的。

三、開始幹活

通過上面發現的幾個線索,為了能快速解決問題,先嘗試關閉或刪除進程和文件,然後看看網路是否能夠恢復正常,一不做二不休,開整吧!

第一步,先刪除/usr/bin/.sshd文件,然後關閉此文件對應的進程,看下面的圖:

這樣先刪除進程對應的文件,然後kill掉.sshd進程,那麼,進程就無法重新啟動了。

第二步,刪除/usr/bin/dpkgd目錄下所有的變種病毒文件,同時刪除/usr/bin/apgffcztwi文件,寫個腳本,批量刪除如下:

執行刪除後,發現ps命令不好使了,可惡啊,不過,這點問題,難不倒俺,重新安裝一個ps命令即可,或者從別的機器拷貝一個ps命令過來,這裡來個乾脆的,重新安裝一個,安裝過程看下圖:

大家能看到這個操作吧,先看看ps命令屬於按個rpm包,然後yum在線安裝一個新的包即可。

這個procps包安裝完成後,ps命令又可以使用了,現在通過ps命令查看到的系統信息,才是真實的系統啊,剛才那個ps命令是加殼的,屏蔽了很多系統中黑暗的勾當。

還在興奮中,接著執行了一個lsof命令,又發現新情況了:

剛剛刪除了/usr/bin/apgffcztwi文件,但是又自動生成了新的文件,/usr/bin/fhmlrqtqvz,並且還有一個文件/usr/bin/fgqnvqzzck已經被刪除了,但是進程仍然存在,那個deleted就是文件的狀態。並且新生成的文件,仍然是10個字元。

看來是低估這個病毒程序了,繼續往下深究!

考慮到會自動產生病毒文件,感覺應該是linux下的crontab完成的工作,那麼是不是病毒在crontab裡面做了手腳,去看看就知道了。

切換到系統的/var/log/cron目錄下(此目錄記錄了linux下所有用戶的計劃任務信息,以crontab -u -e方式寫入的計劃任務都會在此目錄下生成文件),沒看到任何文件,看來不是用戶級別的crontab在作怪,那麼再看看系統級別的crontab,就是/etc/crontab文件,貼圖如下:

看最後一行,發現了一個定時任務,此任務每三分鐘執行一次,任務對應的是個kill.sh腳本,找到腳本就好辦了,看看這個腳本的內容:

腳本很簡單,但是卻是個重大發現,此腳本會自動重啟網卡,然後執行一個cp操作,將/lib/libkill.so文件複製一個/lib/libkill.so.6文件,然後執行這個文件。這個文件是個二進位的文件,無法查看內容,猜想應該就是自動生成那個十個字元文件的病原體。

這裡看到的病原體名稱是libkill.so,它的名稱不是固定的,常見的還有類似libudev.so、/lib/udev/udev等類似名稱,但是作用應該都是一樣的。

到這裡為止,思路基本清楚了,大概理了一下思路,這個×××執行的原理應該是這樣的:

libkill.so是所有進程的病原體,通過kill.sh腳本每隔3分鐘自動檢測一次,如果發現病毒程序不存在了,就從病原體複製一份兒到/lib/libkill.so.6,病毒副本/lib/libkill.so.6執行後,就會生成一個隨機命名(10個字元)的程序,放到/usr/bin/、/boot,/etc/init.d等目錄下。 同時還修改了自啟動配置chkconfig –add xxx,修改自啟動項/etc/rc.local等,讓×××程序開機自動運行。

這就是為什麼無法殺掉病毒進程的原因。

至此,病毒運行的原理已經清晰了,下面的工作就是清除病毒程序。

四、清除病毒

清除病毒也是需要技巧的,如果直接刪除kill.sh文件,你會發現,這個文件又自動生成了,這就是病毒程序在起作用。

那麼怎麼徹底清除呢,可通過下面方式實現:

通過top或者lsof命令可以獲取那個自動啟動的×××進程的pid為17161,然後執行如下操作:

kill -STOP 17161

注意,這裡-STOP選項的含義,不是關閉這個進程,而是停止這個進程。進程停止執行後,進程仍然存在,這樣就繞過了病毒進程就監測。緊接著,再來點硬貨:

chattr +i /etc/crontab

這樣,先鎖定crontab文件,不讓任何進程寫入數據。

下面就可以安靜的刪除之前的那些病毒文件了。

先刪除這個kill.sh文件,讓他不再定期執行:

[root@server ~]# ll /etc/cron.hourly/kill.sh

接著刪除/usr/bin下和/etc/init.d下的所有可疑文件:

比如上圖中,第1、2、4、5、6都是可疑文件,隨便看一個文件:

可以看到,這個文件又指向了/root/xd文件,而這個xd文件肯定也是病毒文件,需要刪除。

最後,刪除病原體文件:

[root@server ~]# rm -rf /lib/libkill.so.6

[root@server ~]# rm -rf /lib/libkill.so

最最後,別忘了,還要清理現場,關閉一直處於停止狀態的那個pid為17161的病毒進程:

[root@server ~]# kill -9 17161

現在就可以直接執行kill -9的操作了,因為病原體已經被刪除,定時任務文件也被鎖定,定時執行的腳本也被刪除,所以這個病毒再無回天之力了。

最後,再看下清除病毒後的系統狀態:

整個世界清靜了。

但是,但是,好像我又發現了什麼,是的,我發現了一個redis進程在運行。瞬間,明白了這個事件發生的原因了:估計是Redis未授權訪問漏洞導致的。

經過驗證,確實如此,伺服器上的redis沒有密碼驗證機制,可直接登錄,不過這不算什麼,最悲催的是redis的6379埠默認對全網開放。。。。。

這裡科普下什麼是十字叉病毒,它是一個或者多個十位隨機字母組成的木&馬病毒進程,主要目的消耗服務各項資源。屬於一種掛馬,此病毒會自我保護和自我恢復。主要特徵是會往外發送大量數據包。

最最最最後,引用別人一句話,安全無小事,防微杜漸是關鍵。做運維的要牢記啊!

彩蛋來啦

作為51CTO的特級講師和專家博主,我將多年來在新浪網和阿里雲擔任系統架構師的經驗,融合進51CTO訂閱專欄《輕鬆玩轉ELK海量可視化日誌分析系統》

51CTO社區13周年慶期間(2018.8.15-2018.8.31)購買兩個專欄,還有自選圖書免費領取>>>圖書挑選傳送門

能學到什麼技能

1、結合企業真實項目需求,分析ELK架構的應用場景和價值

2、動手實戰構建ELK 海量日誌分析平台

3、利用Logstash實時採集不同項目系統的海量信息,對海量數據進行過濾和解析,同時可以自定義匹配模式解析項目中的複雜結構日誌,並按日誌類別和日期回滾輸出到ElasticSearch集群建立索引

4、利用Kibana 實現海量日誌的分析查詢、數據可視化及監控預警 。

5、Logstash核心配置語法以及Filebeat組件的靈活使用

6、Logstash Input插件、Filter插件、Output插件應用詳解

7、實戰:Logstash 實現海量日誌採集、過濾、解析、輸出

輕鬆玩轉ELK海量可視化日誌分析系統 | 51CTO博客2.0訂閱專欄?

blog.51cto.com

?著作權歸作者所有:來自51CTO博客作者De8ug的原創作品,如需轉載,請註明出處,否則將追究法律責任

推薦閱讀:

Vultr VPS 節點選擇 | 各節點延遲一覽
遊戲伺服器:到底使用UDP還是TCP
AWS EC2 伺服器下線警告
一次最初級的程序失誤導致的伺服器癱瘓
Linux_跨伺服器複製命令

TAG:伺服器 | 運維 | DDoS |