一次Linux系統被***的分析過程

IT行業發展到現在，安全問題已經變得至關重要，從最近的“稜鏡門”事件中，折射出了很多安全問題，資訊保安問題已變得刻不容緩，而做為運維人員，就必須瞭解一些安全運維準則，同時，要保護自己所負責的業務，首先要站在***者的角度思考問題，修補任何潛在的威脅和漏洞。

一、 一次Linux被***後的分析

下面通過一個案例介紹下當一個伺服器被rootkit***後的處理思路和處理過程，rootkit

***是Linux系統下最常見的***手段和***方式。

1 受***現象

這是一臺客戶的入口網站伺服器，託管在電信機房，客戶接到電信的通知：由於此伺服器持續對外傳送資料包，導致100M頻寬耗盡，於是電信就切斷了此伺服器的網路。此伺服器是Centos5.5版本，對外開放了80、22埠。

從客戶那裡瞭解到，網站的訪問量並不大，所以頻寬佔用也不會太高，而耗盡100M的頻寬是絕對不可能的，那麼極有可能是伺服器遭受了流量***，於是登入伺服器做詳細的檢測。

2 初步分析

 在 電信人員的配合下通過交換機對該伺服器的網路流量進行了檢測，發現該主機確實存在對外80埠的掃描流量，於是登入系統通過“netstat –an”命令對系統開啟的埠進行檢查，可奇怪的是，沒有發現任何與80埠相關的網路連線。接著使用“ps –ef”、“top”等命令也沒有發現任何可疑的程式。於是懷疑係統是否被植入了rootkit。

為了證明系統是否被植入了rootkit，我們將網站伺服器下的ps、top等命令與一個同版本可信作業系統下的命令做了md5sum校驗，結果發現網站伺服器下的這兩個命令確實被修改過，由此斷定，此伺服器已經被***並且安裝了rootkit級別的後門程式。

3 斷網分析系統

由 於伺服器不停向外發包，因此，首先要做的就是將此伺服器斷開網路，然後分析系統日誌，尋找***源。但是系統命令已經被替換掉了，如果繼續在該系統上執行操 作將變得不可信，這裡可以通過兩種方法來避免這種情況，第一種方法是將此伺服器的硬碟取下來掛載到另外一臺安全的主機上進行分析，另一種方式就是從一個同 版本可信作業系統下拷貝所有命令到這個***伺服器下某個路徑，然後在執行命令的時候指定此命令的完整路徑即可，這裡採用第二種方法。

我們首先檢視了系統的登入日誌，檢視是否有可疑登入資訊，執行如下命令：

more /var/log/secure |grep Accepted

通過對命令輸出的檢視，有一條日誌引起了我們的懷疑：

Oct 3 03:10:25 webserver sshd[20701]: Accepted password for mail from 62.17.163.186 port 53349 ssh2

這 條日誌顯示在10月3號的凌晨3點10分，有個mail帳號從62.17.163.186這個IP成功登入了系統，mail是系統的內建帳號，預設情況下 是無法執行登入操作的，而62.17.163.186這個IP，經過查證，是來自愛爾蘭的一個地址。從mail帳號登入的時間來看，早於此網站伺服器遭受 ***的時間。

接著檢視一下系統密碼檔案/etc/shadow，又發現可疑資訊：

mail:$1$kCEd3yD6$W1evaY5BMPQIqfTwTVJiX1:15400:0:99999:7:::

很明顯，mail帳號已經被設定了密碼，並且被修改為可遠端登入，之所以使用mail帳號，猜想可能是因為***者想留下一個隱蔽的帳號，以方便日後再次登入系統。

然後繼續檢視其他系統日誌，如/var/log/messages、/var/log/wtmp均為空檔案，可見，***者已經清理了系統日誌檔案，至於為何沒有清空/var/log/secure檔案，就不得而知了。

4 尋找***源

到目前為止，我們所知道的情況是，有個mail帳號曾經登入過系統，但是為何會導致此網站伺服器持續對外傳送資料包呢？必須要找到對應的***源，通過替換到此伺服器上的ps命令檢視系統目前執行的程式，又發現了新的可疑：

nobody   22765     1  6 Sep29 ?        4-00:11:58 .t

這個.t程式是什麼呢，繼續執行top命令，結果如下：

PID USER    PR  NI  VIRT  RES  SHR  S  %CPU %MEM    TIME+  COMMAND

22765 nobody  15  0   1740m 1362m 1228  S  98.3    91.5      2892:19   .t

從 輸出可知，這個t程式已經執行了4天左右，執行這個程式的是nobody使用者，並且這個t程式消耗了大量的記憶體和cpu，這也是之前客戶反映的網站伺服器 異常緩慢的原因，從這個輸出，我們得到了t程式的程式PID為22765，接下來根據PID查詢下執行程式的路徑在哪裡：

進入記憶體目錄，檢視對應PID目錄下exe檔案的資訊：

[root@webserver ~]# /mnt/bin/ls -al /proc/22765/exe 

lrwxrwxrwx 1 root root 0 Sep 29 22:09 /proc/22765/exe -> /var/tmp/…/apa/t

這 樣就找到了程式對應的完整程式執行路徑，這個路徑很隱蔽，由於/var/tmp目錄預設情況下任何使用者可讀性，而***者就是利用這個漏洞在/var /tmp目錄下建立了一個“…”的目錄，而在這個目錄下隱藏著***的程式源，進入/var/tmp/…/目錄，發現了一些列***者放置的rootkit文 件，列表如下：

[root@webserver ...]#/mnt/bin/ls -al

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 apa

-rw-r--r-- 1 nobody nobody     0 Sep 29 22:09 apa.tgz

drwxr-xr-x 2 nobody nobody 4096 Sep 29 22:09 caca

drwxr-xr-x 2 nobody nobody 4096   Sep 29 22:09 haha

-rw-r--r-- 1 nobody nobody      0 Sep 29 22:10 kk.tar.gz

-rwxr-xr-x 1 nobody nobody      0 Sep 29 22:10 login

-rw-r--r-- 1 nobody nobody      0 Sep 29 22:10 login.tgz

-rwxr-xr-x 1 nobody nobody      0 Sep 29 22:10 z

通過對這些檔案的分析，基本判斷這就是我們要找的程式***源，其中：

1）、 z程式是用來清除系統日誌等相關資訊的，例如執行：

./z 62.17.163.186

這條命令執行後，系統中所有與62.17.163.186有關的日誌將全部被清除掉。

2）、 在apa目錄下有個後門程式t，這個就是之前在系統中看到的，執行此程式後，此程式會自動去讀apa目錄下的ip這個檔案，而ip這個檔案記錄了各種ip 地址資訊，猜想這個t程式應該是去掃描ip檔案中記錄的所有ip資訊，進而獲取遠端主機的許可權，可見這個網站伺服器已經是***者的一個肉雞了。

3）、 haha目錄裡面放置的就是用來替換系統相關命令的程式，也就是這個目錄下的程式使我們無法看到作業系統的異常情況。

4）、login程式就是用來替換系統登入程式的***程式，此程式還可以記錄登入帳號和密碼。

5 查詢***原因

到這裡為止，伺服器上遭受的***已經基本清晰了，但是***者是如何侵入這臺伺服器的呢？這個問題很重要，一定要找到***的根源，才能從根本上封堵漏洞。

為 了弄清楚***者是如何進入伺服器的，需要了解下此伺服器的軟體環境，這臺伺服器是一個基於java的web伺服器，安裝的軟體有 apache2.0.63、tomcat5.5，apache和tomcat之間通過mod_jk模組進行整合，apache對外開放80埠，由於 tomcat沒有對外開放埠，所以將問題集中到apache上面。

通 過檢視apache的配置發現，apache僅僅處理些靜態資源請求，而網頁也以靜態頁面居多，所以通過網頁方式***系統可能性不大，既然漏洞可能來自於 apache，那麼嘗試檢視apache日誌，也許能發現一些可疑的訪問痕跡，通過檢視access.log檔案，發現瞭如下資訊：

62.17.163.186 - - [29/Sep/2013:22:17:06 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;ps+-aux%00 HTTP/1.0" 200 12333 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"

62.17.163.186 - - [29/Sep/213:22:17:35 +0800] "GET http://www.xxx.com/cgi-bin/awstats.pl?configdir=|echo;echo;cd+/var/tmp/.../haha;ls+-a%00 HTTP/1.0" 200 1626 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1) Gecko/20121010 Firefox/2.0"

至此，發現了漏洞的根源，原來是awstats.pl指令碼 中configdir的一個漏洞，通過了解此伺服器的應用，客戶確實是通過一個Awstats的開源外掛來做網頁訪問統計，通過這個漏洞，***者可以直接 在瀏覽器上操作伺服器，例如檢視程式、建立目錄等。通過上面第二條日誌可以看出，***者正常瀏覽器執行切換到/var/tmp/.../haha目錄的操 作。

這個指令碼漏洞挺可怕的，不過在Awstats官網也早已給出了修補的方法，對於這個漏洞，修復方法很簡單，開啟awstats.pl檔案，找到如下資訊：

if ($QueryString =~ /configdir=([^&]+)/i)

{

$DirConfig=&DecodeEncodedString("$1");

}

修改為如下即可：

if ($QueryString =~ /configdir=([^&]+)/i)

{

$DirConfig=&DecodeEncodedString("$1");

$DirConfig=~tr/a-z0-9_\-\/\./a-z0-9_\-\/\./cd;

}

6 揭開謎團

通過上面逐步分析和介紹，此服務遭受***的原因和過程已經非常清楚了，大致過程如下：

（1） ***者通過Awstats指令碼awstats.pl檔案的漏洞進入了系統，在/var/tmp目錄下建立了隱藏目錄，然後將rootkit後門檔案傳到這個路徑下。

（2） ***者通過植入後門程式，獲取了系統超級使用者許可權，進而控制了這臺伺服器，通過這臺伺服器向外發包。

（3） ***者的IP地址62.17.163.186可能是通過代理過來的，也可能是***者控制的其他肉雞伺服器。

（4） ***者為了永久控制這臺機器，修改了系統預設帳號mail的資訊，將mail帳號變為可登入，並且設定了mail帳號的密碼。

（5） ***者在完成***後，通過後門程式自動清理了系統訪問日誌，毀滅了證據。

通過對這個***過程的分析，發現***者的手段還是非常簡單和普遍的，雖然***者刪除了系統的一些日誌，但是還是留下了很多可查的蹤跡，其實還可以檢視使用者下的.bash_history檔案，這個檔案是使用者操作命令的歷史記錄。

7 如何恢復網站

由於系統已經檔案被更改和替換，此係統已經變得完全不可信，因此建議備份網站資料，重新安裝系統，基本步驟如下：

（1） 安裝穩定版本的作業系統，刪除系統預設的並且不需要的使用者。

（2） 系統登入方式改為公鑰認證方式，避開密碼認證的缺陷。

（3） 安裝更高版本的apache和最新穩定版本的Awstats程式。

（4） 使用Linux下的Tcp_Wrappers防火牆，限制ssh登入的源地址。

本文發表在程式設計師雜誌2013年11期！

本文出自 “技術成就夢想” 部落格，請務必保留此出處http://ixdba.blog.51cto.com/2895551/1431305