十字符病毒，殺不死的小強，一次雲服務器淪陷實錄

1、現象

接到客戶的電話，說本身的雲服務器被提供商禁止訪問了，緣由是監測到網絡流量暴滿，服務器不停的向外發包，在確認客戶沒有業務量突增的狀況下，初步判斷可能服務器遭受了流量攻&擊（DDOS），不過按照常理來講，客戶的業務系統就是一個小的web系統，平時流量不大，影響力也通常，不至於遭受DDOs，帶着這些疑問，要到了客戶服務器的登陸方式，廢話少說，仍是進入系統，一查究竟吧。點擊此處有驚喜

2、排查問題

下圖是登陸系統後，執行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多萬，已經設置很大了，看來不是這個參數設置致使的。估計應該是上面的一些異常進程致使的。

3、開始幹活

經過上面發現的幾個線索，爲了能快速解決問題，先嚐試關閉或刪除進程和文件，而後看看網絡是否可以恢復正常，一不作二不休，開整吧!

第一步，先刪除/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等，讓×××程序開機自動運行。

這就是爲何沒法殺掉病毒進程的緣由。

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

4、清除病毒

清除病毒也是須要技巧的，若是直接刪除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下的全部可疑文件：

好比上圖中，第一、二、四、五、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海量可視化日誌分析系統》

能學到什麼技能

一、結合企業真實項目需求，分析ELK架構的應用場景和價值
二、動手實戰構建ELK 海量日誌分析平臺
三、利用Logstash實時採集不一樣項目系統的海量信息，對海量數據進行過濾和解析，同時能夠自定義匹配模式解析項目中的複雜結構日誌，並按日誌類別和日期回滾輸出到ElasticSearch集羣創建索引
四、利用Kibana 實現海量日誌的分析查詢、數據可視化及監控預警 。
五、Logstash核心配置語法以及Filebeat組件的靈活使用
六、Logstash Input插件、Filter插件、Output插件應用詳解
七、實戰：Logstash 實現海量日誌採集、過濾、解析、輸出