一次Linux系統被攻擊的分析過程

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

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

　　攻擊是linux系統下最常見的攻擊手段和攻擊方式。

　　1、受攻擊現象

　　這是一台客戶的門戶網站伺服器，托管在電信機房，客戶接到電信的通知：由于此伺服器持續對外發送資料包，導緻100m帶寬耗盡，于是電信就切斷了此伺服器的網絡。此伺服器是centos5.5版本，對外開放了80、22端口。

　　從客戶那裡了解到，網站的通路量并不大，是以帶寬占用也不會太高，而耗盡100m的帶寬是絕對不可能的，那麼極有可能是伺服器遭受了流量攻擊，于是登入伺服器做詳細的檢測。

　　2、初步分析

　　在電信人員的配合下通過交換機對該伺服器的網絡流量進行了檢測，發現該主機确實存在對外80端口的掃描流量，于是登入系統通過“netstat –an”指令對系統開啟的端口進行檢查，可奇怪的是，沒有發現任何與80端口相關的網絡連接配接。接着使用“ps –ef”、“top”等指令也沒有發現任何可疑的程序。于是懷疑系統是否被植入了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      0sep 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");

　　}

　　修改為如下即可：

　　$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登入的源位址。

最新内容請見作者的github頁：http://qaseven.github.io/