一、現象
接到客戶的電話，說自己的雲伺服器被提供商禁止通路了，原因是監測到網絡流量暴滿，伺服器不停的向外發包，在确認客戶沒有業務量突增的情況下，初步判斷可能伺服器遭受了流量攻&擊（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指令屬于按個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端口預設對全網開放。。。。。