Windows 企業資訊安全稽核應用導入系列 (3)

利用稽核強化 WEB 的安全性與可追蹤性

**作者：**圖文／林柏甫

稽核不只可用在檔案處理與登入，也可應用至 WEB 的安全稽核中。

前兩期的深入介紹，相信各位讀者已經具備了充分的基礎並了解 Windows 稽核的強大了。筆者認為，一個強大的技術如果無法應用於周遭，那此技術就真的是雞肋了，接下來將會開始深入介紹稽核於各方面的應用，讓原本認為 Windows 稽核是雞肋的人們化解對它的誤會。我們先以兩個真實案例做開頭，讓各位讀者先為WEB與稽核的關係暖暖身。

WEB 與稽核的關係

於協同作業面來看

在有許多 WEB 設計師與程式設計師的環境中，有時會發生「蓋錯檔」的事情，且每次問每次都沒人承認。程式人員將版面套上程式後，想說可以下班了，但因網頁設計人員的粗心大意不小心將檔檔蓋過去，導致之前套的程式都付之一炬，只好加班重新套程式。以上事情最常發生在沒有版本管理的多人團隊中，就筆者本身就遇過兩次檔案被蓋，那種心情瞬間會覺得昏天暗地，只有親身體驗才能感受其中啊！偏偏又沒人承認更叫人氣結，只好自認倒楣，在沒有加班費的夜晚重套嗎？不，事情可以更明朗化。雖然我們常說：「先不要追究責任歸屬，應該先將眼前問題盡速解決」，但是…往往在解決之後起因追查也跟著不重要了，息事寧人讓團隊心結與低壓氛圍越來越擴大，造成工作效率的降低。當然，在此要說明這裡只是舉個團隊中常發生的案例而已，不是每個網頁設計人員都會這樣的。

於網站安全面來看

當發現網站目錄中總是莫名的多出幾個檔案，系統組態常常被變更，核心元件檔案總是搞失蹤時，那很肯定的…系統中一定有後門存在！朋友在一個匆忙的下午中緊急以MSN訊息詢問：「我們稽核也進行了，安全性都導入了，設定也依照標準安全設置完成，MBSA的掃描一切都 Pass，為什麼客戶網站還是一直被竄改？在這樣下去這個月的款項可能請不到，拜託幫個忙吧！」。在這個案例中，所有的準備都OK了，MBSA 的掃描也都是 PASS，問題從何而來？我們將會在下面說明前因始末與處理方式分享。

WEB 變動痕跡追蹤

WEB 目錄中的檔案變動一向是很難掌控的，尤其可讓使用者上傳檔案的站台更相形複雜。上面提到，在多人團隊中的網站維護老是被蓋錯檔，且追查不易。其實在這個案例中，我們可以對WEB根目錄設定「物件存取稽核」，並將所有可更新網站人員全員加入至稽核清單中，配合適當的稽核設定，即可在當下找出粗心的人。找到對事情會有幫助嗎？當然是沒有幫助的…但至少可讓這名粗心的人員了解到「一切的行為都會有證據」，除了請該人員下次務必注意外，也讓想賴的人賴不掉，並請求它與程式設計人員一同加班到完成處理為止(了解深夜加班的無奈)。

如果是要針對一般WEB上傳檔案進行稽核，要稽核的帳號就比較特別點，要將[Network Service]帳戶加到稽核清單並設定適當的稽核項目，即可在記錄中看到經由 WEB 上傳的檔案。如有發現允許副檔名以外的檔案被上傳，可能就是程式的邏輯出錯了，要盡快聯絡相關人員進行修正。但不是程式出錯的話呢…除了 Windows 本身的稽核機制外，還要加上內建的工具進行人工稽核，來抓出WEB "鬧鬼" 的根本原因了。

實戰！找出系統的後門！

筆者朋友緊急詢問的異常現象是怎麼回事？系統檔案莫名消失與增加是靈異現象嗎？其來自有因，這個案例中除了要從 Windows 的稽核紀錄來分析外，還需要搭配 WEB Server 的 Log 進行交叉比對，透過多重來源的稽核分析找出事發時間有在活動的「犯人」。

稽核好幫手 - LogParser

LogParser 是微軟所推出的免費 Log 分析工具，可分析的 Log 類型有 IISW3C、NCSA、IIS、IISODBC、BIN、IISMSID、HTTPERR、URLSCAN、CSV、W3C、XML、EVT、ETW、NETMON、REG、ADS、TEXTLINE、TEXTWORD…等，而筆者最常用的是 IISW3C 與 EVT 的紀錄分析。LogParser 分析語法是以 SQL 語法的方式進行撰寫，熟悉SQL語法的讀著們應該可以很輕易的上手。在接下來的稽核過程中，LogParser 占了很重要的角色，熟練的使用它絕對可以輕易找出線索。

由於系統方面都已經確定其安全性設置，MBSA 也顯示 PASS，追查方向則從系統轉移至 WEB。WEB 的檔案從何查起？每一個檔案副檔名都是 aspx，目錄又有好幾個階層，這種狀況下檔案比對的效果很有限，用所謂的 "人肉搜尋" 又太浪費時間，沒有更好的風法嗎？別忘了 LogParser 可支援 Windows Event 與 IISW3C 的 LOG 格式，只要了解簡單的語法即可開始追查。

找出異常存取紀錄

第一次使用 LogParser 時，最常遇到的問題就是不知道需選擇哪些欄位與來源，請放心，絕對沒有想像中的那麼難。SQL語法有個特色，當不知道欄位需選擇什麼的時候，只要輸入「*」所有的欄位就會全數選取了。同樣的，我們要開始選擇安全性紀錄時，可以這樣下語法：

程式1

::切換至LogParser工作目錄並進行一筆資料的輸出
CD "C:\Program Files\Log Parser 2.2"
LogParser.exe -i:evt -o:csv "select top 1 * from security > C:\Audit.csv

接下來至輸出的目錄開啟 csv 檔案即可看到第一列的資料欄位名稱，這邊挑選 [TimeGenerated]、[EventID], [Message]，而新增檔案的 EventID 於稽核紀錄中為 "560"，將此條件納入查詢語法，撰寫成以下的 T-SQL：

程式2

Select TimeGenerated, Message
From security Where EventID='560'

將以上與法另存成 .sql 檔案備用(這裡存在 C:\560.sql)，並開啟 LogParser 查詢介面後，輸入以下指令：

程式3

LogParser.exe -i:evt -o:csv "file:C:\560.sql" > C:\ileName.csv

透過將查詢分析語法先存成 SQL 指令檔，可以讓較長的查詢語法更好修改與撰寫，建議在使用 LogParser 時可先測試語法，在測試完成後將 SQL 指令另存，日後才可方便修改。

剛剛的查詢語法為我們選取出新增資料的紀錄，我們拿其中一個來剖析看看是否正常。下圖的資訊說明事件來源為安全性記錄中的物件存取事件 (ID:560)，並由使用者 NETWORK SERVICE (IIS 的處理緒帳戶) 上傳 AddRoute.bat 的批次檔，在 WEB 目錄由 IIS 的處理緒上傳 bat 批次檔？這個紀錄怎麼看都覺得奇怪，一定要好好的深入追查！

圖1 事件 ID 560 中的重要項目

現在，讓我們把事件描述重點深入分析一次：

表1  稽核事件重點節錄

物件開啟：
          物件伺服器:           Security
          物件類型:    File
          物件名稱:    C:\wwwroot\img\AddRoute.bat   重點 1：WEB Root 下的 img 資料夾上傳 bat
          處理識別碼:           468
          操作識別碼:           {0,535259}
          程序識別碼:           2808
          影像檔案名稱:       C:\WINDOWS\system32\inetsrv\w3wp.exe
          主要使用者名稱:  NETWORK SERVICE  重點 2：檔案是經由 IIS 上傳

 (中間略)

          存取:  READ_CONTROL
                                SYNCHRONIZE
                                ReadData (或 ListDirectory)
                               WriteData (或 AddFile)  重點 3：檔案已經被寫入
                                AppendData (或 AddSubdirectory 或 CreatePipeInstance)
                                ReadEA
                                WriteEA
                                ReadAttributes
                                WriteAttributes

看來後門就是來自於 WEB 了！確定標的之後就可以針對範圍進行分析，減少猜測與嘗試的時間成本了。接下來，把這個事件的發生時間 "記錄下來"，我們要用此時間再對 IIS LOG 進行交叉比對，看看這個時間內是否有可疑的程式存取。

時間範圍比對

緊接著進入了 IIS LOG 分析的階段，照慣例的我們將語法寫成 SQL 並存成 C:\IIS_Analytics.sql，其中 From 來源為 IIS 紀錄的目錄：

程式4

select date,s-ip,cs-method,cs-uri-stem,c-ip,sc-status
from C:\WINDOWS\system32\LogFiles\w3svc1\*.log
where date='2009-04-11' and cs-uri-stem like '%.aspx%'

眼尖的讀者會注意到日期是 "2009-04-11"，為什麼不是"2009/4/12"？IIS 的 LOG 是以格林威治標準時間 (GMT 0) 為記錄，台灣的時區為 GMT + 8，因此時間要減 8 小時。此紀錄由於是跨日，所以減去 8 小時候就是前一天，如果在 IIS 選項中有勾選 "請使用本地時間為檔案命名" 的選項則不在此範圍內。

我們再一次將查詢語法組合起來並輸出一個 CSV 檔案來查閱：

程式5

LogParser.exe -i:evt -o:csv "file: C:\IIS_Analytics.sql"

查詢的結果發現在 WEB 中的 img 目錄有 aspx 執行的紀錄，怪哉，一般人不會把網站應用程式放在這個目錄，看來有必要好好分析 "/img/aspxspy.aspx" 這一隻程式。

圖2 LogParser 分析出的可疑應用程式與存取 IP。

WEB 被植入 Rootkit

將上一節所分析出的路徑於瀏覽器中執行時，赫然發現是相當有名氣的 WEB Rootkit。這支 Rootkit 功能非常強大，除了可上傳檔案以外，還可隨意刪除磁碟中的檔案。只有這樣而已嗎？不… 還可透過 WEB 直接對伺服器下 Command，如果上傳的是惡意的批次檔，就可直接從 WEB 執行，很可怕吧。

圖3 WEB Rootkit 的上傳介面，幾乎什麼都可以上傳

圖4 連 Command Line 的 dir 指令都可完整呈現

後續處理

當務之急先將所有類似的檔案全部刪除，但保留一份檔案下來以供作為證據。接著，使用此 Rootkit 的攻擊者一定還會繼續使用，而檔案已經移除了，所以存取之後會產生 IIS LOG 的 404 紀錄。後續只要針對其 IP 與存取進行追蹤，就看各位的公司政策如何處理了。這個案例持續追蹤的結果出人意料，據說是之前的維護廠商將此程式放至於 WEB 目錄中，因後面的合作鬧得不太愉快，所以在解約之後就一點一滴的進行破壞。目前已經進入法律訴訟程序，但因證據確鑿，筆者覺得廠商那邊應該沒什麼可以辯駁的了，歹路真是不可行啊。

後記

這一次的實戰案例是不是很精采呢？利用多重來源交叉比對的稽核可以非常準確從各面向找到證據，進而保護公司的安全與資產。當然，因為機密的關係無法放上真實案例的截圖，只能以筆者家中的伺服器來模擬"案發過程”，在實際的環境中CSV可不是像文中的那麼簡單可用肉眼分析，但只要累積更多的實務經驗則可以更精準的下正確的分析語法。要將企業害蟲遠離我們所保護的環境中，就讓稽核來幫助吧！加油！

回到頁首