Linux服務器下Linux.BackDoor.Gates.5病毒的簡單處理方法

今年年初的時候，公司負責的項目有至關一批Linux服務器，被病毒侵襲了。。
有的人可能會問了，Linux也能被感染病毒？呵呵，答案是能夠的。

任何服務器只要把Root或者Administrator權限泄露出去了，對於Hacker來講就擁有無限可能，要知道Hacker就是高級的程序員，呵呵。

記錄這篇文章的目的，並非說按照這篇文章的描述方法，就能夠把病毒從服務器上完全清掉，而是傳達給你們一種面對緊急狀況時候的應對方法，這個Case歸根到底仍是要進行服務器的重裝的，有人可能會說了，你這不是標題黨嗎？明明處理不了的東西還要發出來——套用一句老話「就算死也得知道是怎麼死的」 。既然搞技術，多鑽研一點老是沒有錯的。

• 系統弱口令
  什麼是弱口令？說得簡單一點，就是你的密碼設定的過於簡單了嘛。這個病毒首先就是經過這種方式，來進行暴力破解系統的弱口令，再多說一點什麼是暴力？那就是寫個程序來回去實驗你的密碼究竟是什麼，若是密碼比較簡單，長度又不夠，又不夠複雜，基本很短期內就能夠被暴力破解。

• 問題初期
  其實公司負責安全的同事在病毒發現的時候，就已經把這個如何判斷是中了這個木馬告知了，可是很遺憾的是，給出的解決方法並不能阻止木馬繼續肆虐。
  1.用root 登陸系統，分別查看/root、/tmp、/dev/shm執行ls –lrt
  凡帶有文件：

  -rwxrwxrwx 1 oracle oinstall 646674 Mar 10 18:32 .lz1489875542
  -rwxrwxrwx 1 oracle oinstall      4 Mar 19 05:40 gates.lod
  ZTE
  3.22
  4.55

  均爲被攻擊。
  2.查看/etc/crontab凡帶有每三分鐘字樣的就是被攻擊了。
  3.用top查看cpu使用狀況，受到攻擊的系統，cpu會異常的高。

• 我所看到的現象
  跟安全同事發出來的現象不一樣，我這裏看到的現象，有木馬的服務器cpu並無很高，都維持在正常水平，一開始我也沒太當回事，由於就1-2臺服務器中了，按照安全同事給的操做方法處理了一下，也就沒再注意。到後來成片的擴散的時候，這時候意識到問題可能不是那麼簡單的了。

• 木馬初露鋒芒
  有句話說得好，永遠不要小看你的對手，哪怕他當前很是眇小。
  剛纔說過了，正是由於我一開始沒當回事，因此木馬大哥不樂意了，稍微露了兩手，直接致使了我將近2天的額外工做量。。。
  首先遭殃的是業務系統A，這個系統的實時性很高，用戶直接反映功能很差使。
  上去一看，程序還在運行，只不過裏面日誌不刷新了。當時我重啓了一下後好了。
  不過僅僅好了幾個小時，以後又不行了。。當時個人心裏有點波瀾。。
  一波未平一波又起，緊接着業務系統B、C、D...都同樣的現象，我當時只想說：我X!

• 緊急處理過程
  當時跟蹤了一下午，一直到晚上12點多，最後阻止我不能繼續排查問題的緣由，仍是木馬大哥。
  這哥們兒的最絕的地方就是，直接把一堆包發到你服務器的網絡環境裏，直接把你的網絡阻塞了。
  舉個例子：好比有一條馬路，有4條車道，如今有6輛車要經過，並且這6輛車頗有個性，就是按照6車道的標準去行駛，怎麼可能跑的下呢？因而反應到具體現象上，就是我經過crt工具遠程到服務器上執行命令，根本無法輸入命令，ping了一下，丟包率達到驚人的95%。。。
  留一個懸念，放到文章最後說。

• 那麼我以前都作了什麼操做呢？
  1.執行ps -ef|grep ZTE,用安全同事給的方法進行處理，結果刪掉以後立刻有新的進程出現，而且木馬有不少種展示形式。
  
  

  2.查看/tmp下目錄，執行ls -lart: 發現全部感染的機器，/tmp下均有這兩個文件：gates.lod 、 moni.lod
  
  3.上網搜索了下這兩個文件，查到一篇比較符合的文章，肯定病毒爲Linux.BackDoor.Gates.5

文章連接：http://blog.clzg.cn/home.php?...

4.嘗試着用文章中的方法來刪除病毒
看了文章後，能夠得出這麼一個結論：

這個病毒首先會替換系統中的一些命令，好比lsof ps netstat ss，看到Netstat，能夠知道這個病毒大概要幹什麼了，無非就是發流量包，形成網絡癱瘓，病毒替換了系統原有的包，換成自身通過改寫的命令包，可能對自己服務器沒影響，可是是用我們的機器作肉雞。。

執行命令：

刪除事後，發現執行ps -ef語句很差用了，同時從新登錄服務器報錯。。。
因而將正常機器上的ps命令複製到該機器上，可是沒多久又不行了，作到這裏，聯想到病毒原理，很容易就分析出來狀況了：
病毒是反覆覆蓋掉系統操做命令，將文件刪掉後，每次刪除病毒進程，病毒都會複製一個新的病原體到/bin下。
通過病毒修改的文件系統是沒辦法直接用的，這也就解釋了爲何放上去新的好使，過一下子又很差使了的狀況。

5.明白了這個道理，咱們能夠採用接下來的手段:

用chattr命令阻止病毒修改系統正常的命令：
咱們首先將正確的系統命令文件，放到對應目錄下，而且用chattr命令保護起來，不容許任何操做，好比rm,mv等。這裏放一篇文檔：

http://www.ha97.com/5172.html

cd /bin  
chattr +i /bin/ps
chattr +i /bin/netstat
cd /usr/sbin
chattr +i /usr/sbin/lsof
chattr +i /usr/sbin/ss

而後執行以下命令：由於病毒可能在的地方不少，因此有些地方須要手動去改一改，我這裏列的應該比較全了。

rm -rf /usr/bin/dpkgd
rm -rf /usr/bin/pythno
rm -rf /usr/bin/bsd-port
rm -f /usr/bin/.sshd
rm -f /usr/bin/sshd
rm -fr /root/ZTE
rm -fr /root/ZTE.1
rm -fr /root/Manager
rm -fr /root/Manager.1
rm -fr /root/1
rm -fr /root/jhost
rm -f /usr/local/zabbix/sbin/zabbix_AgentD
rm -f /usr/local/zabbix/sbin/conf.n
rm -f /root/cmd.n
rm -f /root/conf.n
rm -f /root/IP
rm -fr /tmp/ZTE
rm -f /tmp/gates.lod
rm -f /tmp/moni.lod
rm -f /tmp/notify.file
rm -f /tmp/gates.lock
rm -f /etc/rc.d/init.d/DbSecuritySpt
rm -f /etc/rc.d/rc1.d/S97DbSecuritySpt
rm -f /etc/rc.d/rc2.d/S97DbSecuritySpt
rm -f /etc/rc.d/rc3.d/S97DbSecuritySpt
rm -f /etc/rc.d/rc4.d/S97DbSecuritySpt
rm -f /etc/rc.d/rc5.d/S97DbSecuritySpt
rm -f /etc/rc.d/init.d/selinux
rm -f /etc/rc.d/rc1.d/S99selinux
rm -f /etc/rc.d/rc2.d/S99selinux
rm -f /etc/rc.d/rc3.d/S99selinux
rm -f /etc/rc.d/rc4.d/S99selinux
rm -f /etc/rc.d/rc5.d/S99selinux

6.執行ps -ef|grep root命令：
執行此命令的意義是：該病毒會假裝成經常使用的命令形式，好比：/usr/bin/dpkgd/ps就是一個異常進程。
參照網上的文章，把root用戶下有問題的進程，都找出來，而且kill掉：

kill -9  5663      1  0 Apr21 ?        00:04:55 /usr/bin/bsd-port/getty
kill -9  5698      1  0 Apr21 ?        00:00:00 /usr/bin/.sshd
kill -9 14913      1  0 Mar23 ?        00:00:02 /usr/bin/.sshd
kill -9 25423      1  0 13:15 ?        00:00:00 /usr/bin/pythno
kill -9 30589      1  0 Apr26 ?        00:02:18 /usr/bin/bsd-port/knerl           
kill -9 47879      1  0 13:35 ?        00:00:01 /usr/bin/bsd-port/knerl
kill -9 65205      1  0 14:08 ?        00:00:00 /usr/bin/bsd-port/getty
kill -9 65240      1  0 14:08 ?        00:00:00 /usr/bin/.sshd
kill -9 67423      1  0 14:12 ?        00:00:00 /usr/bin/bsd-port/getty
kill -9 67466      1  0 14:12 ?        00:00:00 /usr/bin/.sshd
kill -9 71342      1  0 Apr10 ?        00:00:01 /usr/bin/pythno
kill -9 71468      1  0 Apr10 ?        00:00:01 /usr/bin/.sshd
kill -9 71873      1  0 14:20 ?        00:00:00 /usr/bin/dpkgd/ps
kill -9 71985      1  0 14:20 ?        00:00:00 /usr/bin/pythno
kill -9 72062      1  0 14:20 ?        00:00:00 /usr/bin/dpkgd/ps
kill -9 72116      1  0 14:20 ?        00:00:00 /usr/bin/pythno
kill -9 72568      1  0 14:21 ?        00:00:00 /usr/bin/dpkgd/ps
kill -9 72626      1  0 14:21 ?        00:00:00 /usr/bin/bsd-port/knerl
kill -9 72631      1  0 14:21 ?        00:00:00 /usr/bin/pythno
kill -9 74582      1  0 Apr10 ?        00:10:44 /usr/bin/bsd-port/getty
kill -9 74615      1  0 Apr10 ?        00:00:01 /usr/bin/.sshd
kill -9 76088      1  0 Apr10 ?        00:00:01 /usr/bin/.sshd

7.進行觀察，ps -ef|grep ZTE ， 發現沒有該進程再重複產生了，查看 /usr/bin下，以前的病毒本體，主程序也都沒有了。

8.延遲一小時後再驗證，仍是沒有病毒進程及病毒本體文件產生，只是在/user/bin下會產生下圖的文件：看起來也像個異常的東西，可是由於沒有進程跟隨，能夠忽略了。隨後又試驗了一臺機器，另一臺就沒有這個隨機文件，猜測可能跟病毒發佈者的實際用途有關。

9.手動清理 .conf文件和 /bin下的 lsof ss文件
/bin下的ss 和lsof是病毒本身複製過去的，真正的文件在/usr/sbin下，這兩個能夠刪掉。
.conf文件可能在/tmp或者/root下，根據實際狀況刪除一下便可。

• 以上就是我對此問題的思路及全過程，從系統層面上，將該病毒暫時抑制掉了。
  要注意我說的，是從操做系統層面上。呵呵。我上面留的懸念，crt都無法操做了，到最後怎麼辦呢？

用戶緊急找了硬件廠商，去機房裏實際觀測端口的網絡流量狀況，由於是虛擬機，觀測到異常後，直接將虛擬機關閉，由於中木馬這事是很嚴重的問題，無法考慮什麼業務不業務的了，必須停掉進行處理。
以後又開始將一臺未中毒的虛擬機的系統二進制碼拿出來，跟問題服務器作對比，一對比發現。。整個操做系統，文件被篡改了90%以上。。。咱們剛纔作的那些只不過是九牛一毛而已。
可是隻有3臺服務器上的病毒在發做，已經經過關閉虛擬機的到了抑制，其餘的服務器上雖然系統命令被篡改，可是沒有達到不能用的地步。而且經過我們剛纔的初步處理方法，保證了病毒源再也不生成，經過限制ip訪問，也保證了病毒源再也不擴散。

分享這篇文章的目的是，若是你的root密碼管理不規範，那麼真中了木馬，沒人能幫獲得你了，其餘用戶中了的話，直接刪除用戶就能夠了，可是root權限是打開一臺服務器的大門，這個Case最完美的同時也是最殘酷的處理方式，就是重裝系統，這樣的話安全合規、漏掃的重要性就體現出來了，呵呵。