十字元病毒,殺不死的小強:一次雲伺服器淪陷實錄
一、現象
接到客戶的電話,說自己的雲伺服器被提供商禁止訪問了,原因是監測到網路流量爆滿,伺服器不停地向外發包,在確認客戶沒有業務量突增的情況下,初步判斷可能伺服器遭受了流量攻擊(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_max
2097152
nf_conntrack_max設定200多萬,已經設定很大了,看來不是這個引數設定導致的。估計是上面的一些異常程序導致。
三、 開始解決問題
通過上面發現的幾個線索,為了能快速解決問題,先嚐試關閉或刪除程序和檔案,然後看看網路是否能夠恢復正常,一不做二不休,開整吧!
第一步,先刪除/usr/bin/.sshd檔案,然後關閉此檔案對應的程序,看下面的圖:
這樣先刪除程序對應的檔案,然後kill掉.sshd程序,那麼,程序就無法重新啟動了。
第二步,刪除/usr/bin/dpkgd目錄下所有的變種病毒檔案,同時刪除/usr/bin/apgffcztwi檔案,寫個指令碼,批量刪除如下:
執行刪除後,發現ps命令不好使了,可惡啊,不過,這點問題,難不倒俺,重新安裝一個ps命令即可,或者從別的機器拷貝一個ps命令過來,這裡來個乾脆的,重新安裝一個,安裝過程看下圖:
大家能看到這個操作吧,先看看ps命令屬於 哪個R PM包,然後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埠預設對全網開放。
這裡科普下什麼是十字叉病毒,它是一個或者多個十位隨機字母組成的木馬病毒程序,主要目的是消耗服務各項資源。屬於一種掛馬,此病毒會自我保護和自我恢復。主要特徵是會往外發送大量資料包。
最後,引用別人一句話,安全無小事,防微杜漸是關鍵。運維人要牢記啊!