本文主要講述了WEB日誌安全分析時的思路和常用的一些技巧，並通過一個完整的例項講述了在發生安全事件後，如何通過分析WEB日誌並結合其他一些線索來對攻擊者進行追蹤。

WEB日誌作為WEB伺服器重要的組成部分，詳細地記錄了伺服器執行期間客戶端對WEB應用的訪問請求和伺服器的執行狀態。同樣，攻擊者對網站的入侵行為也會被記錄到WEB日誌中。因此，在網站日常運營和安全應急響應過程中，我們可以通過分析WEB日誌並結合其他一些情況來跟蹤攻擊者，還原攻擊過程。

WEB日誌結構

在對WEB日誌進行安全分析之前，我們需要先了解下WEB日誌的結構。從目前主流WEB伺服器支援的日誌型別來看，常見的有兩類：

1.Apache採用的NCSA日誌格式，2.IIS採用的W3C日誌格式。

其中，NCSA日誌格式又分為NCSA普通日誌格式（CLF）和NCSA擴充套件日誌格式（ECLF）兩類，具體使用哪一種可以在WEB伺服器配置檔案中定義。Apache也支援自定義日誌格式，使用者可以在配置檔案中自定義日誌格式，如在Apache中可以通過修改httpd.conf配置檔案來實現，如圖1。

圖1

接著我們來看一條Apache的訪問日誌：

192.168.1.66 - - [06/Sep/2012:20:55:05 +0800] "GET /index.html HTTP/1.1" 404 287 "-" "Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0"

其具體的解釋為：

192.168.1.66：表示客戶端IP地址

[06/Sep/2012:20:55:05 +0800]：訪問時間及伺服器所在時區

GET：資料包提交方式為GET方式，常見的有GET和POST兩種型別。

/index.html：客戶端訪問的URL

HTTP/1.1：協議版本資訊

404：WEB伺服器響應的狀態碼。404表示伺服器上無此檔案，200表示響應正常，500表示伺服器錯誤。

287：此次訪問傳輸的位元組數

Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0：客戶端瀏覽器和系統環境等資訊。

IIS訪問日誌格式及儲存路徑可以在IIS管理器中配置，如下圖2所示。

圖2

下圖3是IIS的W3C擴充套件日誌格式。

圖3

值得注意的是，IIS的W3C日誌格式中的訪問時間採用的是格林威治時間，和我們的北京時間差8個小時，而且沒有辦法修改。

WEB日誌安全分析原理

通過上面的知識，我們知道WEB日誌會記錄客戶端對WEB應用的訪問請求，這其中包括正常使用者的訪問請求和攻擊者的惡意行為。那麼我們如何區分正常使用者和惡意攻擊者呢？通過大量的分析，我們發現攻擊者在對網站入侵時，向網站發起的請求中會帶有特定的攻擊特徵，如利用WEB掃描器在對網站進行漏洞掃描時往往會產生大量的404錯誤日誌，如圖4所示。

圖4

當有人對網站進行SQL注入漏洞探測時，WEB訪問日誌中通常會出現如下日誌，如圖5所示：

圖5

因此，我們可以通過分析WEB日誌中是否存在特定的攻擊特徵來區分攻擊者和正常使用者的訪問行為。

但是，WEB訪問日誌並不是萬能的，有些攻擊行為並不會被記錄到WEB訪問日誌中，比如POST型SQL注入就不會記錄在WEB訪問日誌中。這時我們就需要通過其他手段來監測這種攻擊行為。

WEB日誌安全分析思路

在對WEB日誌進行安全分析時，可以按照下面兩種思路展開，逐步深入，還原整個攻擊過程。

一、首先確定受到攻擊、入侵的時間範圍，以此為線索，查詢這個時間範圍內可疑的日誌，進一步排查，最終確定攻擊者，還原攻擊過程，如圖6。

圖6

二、一般攻擊者在入侵網站後，通常會上傳一個後門檔案，以方便自己以後訪問，我們也可以以該檔案為線索來展開分析，如圖7。

圖7

WEB日誌安全分析技巧

WEB日誌檔案通常比較大，包含的資訊也比較豐富。當我們對WEB日誌進行安全分析時，我們通常只關注包含攻擊特徵的日誌，其他的日誌對於我們來說是無用的。這時我們可以通過手工或藉助工具來將我們關注的日誌內容提取出來單獨分析，以提高效率。在日誌分析中經常用到的幾個命令有”find”、”findstr”、”grep”和”egrep”等，關於這幾個命令的用法請自行查詢相關資料。

1.將資料提交方式為“GET”的日誌提取出來，如圖8

圖8

上面這條命令的意思是從iis.log這個檔案中查詢存在GET字元的日誌內容，並將結果儲存到iis_get.log中，得到的結果如圖9。

圖9

2.查詢WEB日誌中是否存在利用IIS寫許可權漏洞的攻擊行為，如圖10。

圖10

3.因為手工分析日誌比較費時，而且效率比較低。因此，筆者自行開發了一款WEB日誌安全審計工具，實現了WEB日誌安全分析的自動化。大家可以到http://secsky.sinaapp.com/157.html地址去下載該軟體，下面是該軟體的介面和生成的分析報告，如圖11和圖12。

圖11

圖12

例項分析

上面我們講了一些關於在WEB日誌安全分析過程中經常用到的技巧，現在我們通過一個例項來完整的瞭解下如何通過分析WEB日誌追蹤攻擊者，並還原攻擊過程。

背景介紹

某日，公司網站伺服器WEB目錄下突然多了一個名為shell.php.jpg的檔案，經過檢視檔案內容，發現該檔案是一個網站後門檔案，也就是常說的WebShell，於是懷疑網站被黑客入侵。接下來，網站管理員通過分析WEB日誌，並結合其他一些情況，成功追蹤到了攻擊者，還原了整個攻擊過程。在這個過程中還發現了網站存在的安全漏洞，並於事後及時修復了漏洞，對網站進行了全面的安全檢測，提高了網站的安全性。

分析思路

根據目前得到的資訊分析，得知WEB目錄下存在一個可疑的檔案，我們就以該檔案為線索，先來查詢都有哪些IP訪問了該檔案，然後並一步排查這些IP都做了哪些操作，最終確認攻擊者以及他運用的攻擊手段。

分析過程

1.首先找到存在的網站後門檔案，也就是上面提到的WebShell檔案，發現該檔案是在2013年2月7日被建立的，如圖13。

圖13

2.我們先來查詢下都有哪些IP訪問了這個檔案，可通過如下命令將相關日誌內容提取出來，如圖14和圖15。

圖14

圖15

3.通過上圖我們可以確定目前只有192.168.1.2訪問了該檔案。這個IP非常可疑，下面我們來查詢下該IP都做了哪些操作，如圖16和圖17。

圖16

圖17

4.從上面的日誌中我們可以看到這是典型的SQL注入。經過進一步分析，發現攻擊者利用SQL注入獲取到了網站後臺管理員賬號和密碼。

192.168.1.2 - - [07/Mar/2013:22:50:21 +0800] "GET /leave_show.php?id=40%20and%201=2%20union%20select%20unhex(hex(concat(0x5e5e5e,group_concat(id,0x5e,user,0x5e,pwd,0x5e,userclass,0x5e,loginip,0x5e,logintimes,0x5e,logintime),0x5e5e5e))),0,0,0,0,0,0,0,0%20from%20(select%20*%20from%20(select%20*%20from%20admin%20where%201=1%20order%20by%201%20limit%201,100)%20t%20order%20by%201%20desc)t%20-- HTTP/1.1" 200 18859 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 1.1.4322)"

5.接著攻擊者利用獲取到的賬號成功進入了網站後臺，詳見下面的日誌：

192.168.1.2 - - [07/Mar/2013:22:51:26 +0800] "GET /mywebmanage/web_manage.php HTTP/1.1" 200 5172 "http://192.168.1.107/mywebmanage/" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:51:44 +0800] "POST /mywebmanage/check.php HTTP/1.1" 200 47 "http://192.168.1.107/mywebmanage/web_manage.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:51:45 +0800] "GET /mywebmanage/default.php HTTP/1.1" 200 2228 "http://192.168.1.107/mywebmanage/check.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

6.然後攻擊者訪問了add_link.php這個頁面，該頁面是一個新增友情連結的頁面，如圖18。

圖18

通過分析網站原始碼，發現該頁面上傳圖片處存在一個檔案上傳漏洞，攻擊者正是利用這個漏洞上傳了一個名為shell.php.jpg的後門檔案，並且利用Apache的解析漏洞成功獲取到一個WebShell。關於Apache解析漏洞的詳細情況可以檢視筆者之前的一篇文章（http://secsky.sinaapp.com/89.html），對此漏洞有詳細的描述。

192.168.1.2 - - [07/Mar/2013:22:53:40 +0800] "GET /mywebmanage/link/add_link.php HTTP/1.1" 200 3023 "http://192.168.1.107/mywebmanage/LeftTree.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:54:50 +0800] "POST /mywebmanage/link/add_link_ok.php HTTP/1.1" 200 77 "http://192.168.1.107/mywebmanage/link/add_link.php" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:55:48 +0800] "GET /link/shell.php.jpg HTTP/1.1" 200 359 "-" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

192.168.1.2 - - [07/Mar/2013:22:55:54 +0800] "POST /link/shell.php.jpg HTTP/1.1" 200 132 "http://192.168.1.107/link/shell.php.jpg" "Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0"

7.到這裡，我們已經可以瞭解到攻擊者的攻擊過程了。具體如下：

首先對網站進行漏洞掃描，發現存在SQL注入漏洞利用SQL注入漏洞獲取到網站後臺管理員賬號、密碼及其他資訊以管理員身份登入網站後臺利用某頁面存在的檔案上傳漏洞，成功上傳一個名為shell.php.jpg的後門檔案，並結合Apache的解析漏洞，成功獲取到一個WebShell。

分析過程總結

通過上面對WEB日誌進行的安全分析，我們不僅追蹤到了攻擊者，也查出了網站存在的漏洞。下面就應該將攻擊者上傳的後門檔案刪除掉，並修復存在的安全漏洞，然後對網站進行全面的安全檢測，並對WEB伺服器進行安全加固，防止此類安全事件再次發生。