回復本來面貌

Zone-H網站(www.zone-h.org)是一個讓入侵者可以張貼他們『功績』的網站，任何個人或團體只要置換了任意網站的網站內容，就可以去登錄他們成功置換網頁的資訊。在2003一整年台灣就有超過750筆網頁置換的紀錄登錄在Zone-H網站，即表示有750台以上的電腦可供惡意入侵者當作跳板，用來發動進行其他的攻擊。調查Web-based的入侵是一件很惱人的工作，尤其是當您手頭上的資訊只知道此一入侵是透過web-based的時候。在探查數百萬甚至是數十億的log檔案來挖掘出可疑的行為是很花費時間的。但挖掘的結果經常是只有找出一些有用的證據。本文章，將針對發生網頁置換時，網站管理人員應當進行哪些程序來尋找入侵來源進行說明，並使用IIS伺服器來當成案例進行舉例。
追查前的準備工作
追查任何入侵事件的第一步，就是盡可能的紀錄所有關於安全事件的資訊。IIS伺服器可針對每一筆web請求，記錄許多有意義的資訊。但是許多有用的log欄位預設值並沒有啟動紀錄。開啟『Internet服務管理員』並對您所使用的網站目錄選取『內容』，在『Web站台』項目中點選『啟用紀錄(E)』的『內容』。從『擴充紀錄內容』中，就可以了解系統目前會紀錄的LOG欄位。如果，硬碟空間允許，建議勾選所有可用的LOG欄位，以便查出隱藏的入侵行為。若硬碟空間有限，最少也應該要啟用預設的LOG欄位，千萬不要關閉『啟用紀錄』。以下的表格說明IIS LOG欄位所紀錄的資訊，以及在追查入侵時的用處。
觀看LOG的時候，必須要了解針對每一個WEB請求，伺服器所回應的狀態碼是多少。透過這些狀態碼，可以了解這些WEB請求是否成功的被伺服器接受，或者是惡意使用者的入侵行為是否已經成功達成。下表舉出一些常見的狀態碼：
筆者曾接到事件處理請求，該單位說明他們從LOG中看到一大堆入侵的行為，請求協助處理。結果從LOG中發現，這些所謂的入侵行為，都被伺服器回應404 error。請求根本沒有被伺服器接受，入侵沒有成功。所以了解狀態碼所代表的意義是根本之二。

第一步：蒐集、備份所有相關資訊
當任何入侵事件發生的時候，最重要的第一件事，就是保持冷靜。就算是再老練的專家、高手，只要處於驚慌的狀態，就會容易犯錯。在事件處理的過程中，有時候小小的一個錯誤，都有可能造成調查嚴重的失敗。在正式的調查當中，應該對所有的調查過程做下紀錄，有了這些紀錄才能確定哪些方向已經調查，哪些部分尚未調查，甚至發現調查過程中的錯誤。
當發現網頁遭受置換，先紀錄以下資訊，以供後續調查使用：
1.入侵事件被發現的時間、入侵事件發生的時間—年、月、日、幾點幾分。
2.置換網頁的檔案資訊—檔案名稱、檔案建立時間、檔案修改時間、檔案大小。
3.圖片檔案資訊—如果入侵者有上傳圖片檔案應做紀錄，如圖片檔案名稱、檔案建立時間、檔案修改時間、檔案大小等。
4.伺服器資訊—伺服器名稱、被入侵的站台名稱、IP位址如果備份機制、備份設備空間足夠，應當在入侵發生後立即將整台主機的硬碟做完整備份，以供調查使用。若空間不足，也應當備份整個網頁目錄下的檔案以及IIS LOG目錄，以預防入侵者事後湮滅證據。

第二步：找尋恰當的時間點
當您把相關資料都蒐集完成並執行完備份程序，接下來就要開始檢視這些證據，並期望從這些證據中找出入侵的軌跡。由於上面蒐集了許多的資訊，甚至是IIS LOG也有可能有數百個檔案，於是第二步就是要先從這些雜亂的證據之中，找出哪些檔案是我們所關心的。IIS LOG會使用日期當成檔名，在此時，先前所紀錄的入侵被發現時間、或者是入侵發生的時間就非常的有用，依據這個時間，我們可以先直接拿取該時間三天內的資料，來進行檢查。如果無法確定網頁被置換的確切時間，可以檢視入侵者所上傳網頁的建立時間、或者是被修改檔案的修改時間，通常這些時間就是入侵發生的時間點。
普遍來說，每一天的IIS LOG檔案內會有數千到數萬筆的連線紀錄資料，當我們將檢視目標縮小為三天的LOG檔之後，接下來就是要找出這三天資料中，敏感的時間點。如果單位有確實遵照第一個步驟執行資料蒐集、備份的工作，就可以推知入侵發生的時間點，便可以直接觀看那個時間點的LOG紀錄。然而，取出特定時間點LOG的時候，必須留意時區的問題。由於台灣的時區是GMT+8，而IIS LOG檔案裡面所顯示的時間預設是使用標準格林威治時間。由此延伸，假設入侵發生的時間是台灣時間下午13:36，那麼這個事件在IIS LOG中的紀錄時間會是早上05:36。所以在檢視LOG的時候，如果您的時區是設定台灣（台北），請記得往前八個小時找尋LOG紀錄。
有的時候，有些管理人員，會在發現入侵的時候，忽略了作相關紀錄的備份以及紀錄；甚至有的管理人員會因為緊張、害怕（或者為了即時恢復網站服務功能），在發現入侵後的第一個步驟是將所有的入侵檔案給移除。因此造成無法得知入侵發生的時間點。此時只能利用有限的資訊對LOG進行檢視，以期找出入侵的時間點。例如，如果還記得入侵者上傳的圖片檔案名稱，就可以利用作業系統所提供的『檔案裡的字或片語(W)』搜尋功能，對LOG目錄搜尋，尋找哪些LOG日誌檔案裡面曾出現過此一圖片檔案名稱的紀錄。而最早一筆的紀錄，可能就是入侵者進行入侵的時間點。如果入侵者不是置換網站的首頁，而是傳一個特定的檔名，可以使用上述的搜尋方式，來推論出入侵的時間點。
如果說，入侵者沒有上傳圖檔，又是置換網站的首頁，管理人員可以透過檢查使用者瀏覽網站模式的方式來找出入侵發生的時間。管理人員先觀察當網站尚未被入侵前的LOG模式，通常一般的使用者連線到首頁的時候，應該會開始下載首頁的圖檔、FLASH檔案，可是當首頁被置換之後，這些檔案便不可能被下載。所以，管理者可以透過觀察來檢查LOG，在哪個時候開始使用者瀏覽首頁便不會下載這些檔案。或者是，有些網站首頁的撰寫方式是，經過數秒後，會自動把使用者轉向到其他的網頁。透過觀察，看看這些正常的模式何時開始變成不正常，以此推斷入侵的時間點。
為何要找到入侵的時間點呢？因為，透過找到入侵的時間點，管理者就可以找到此一入侵的來源IP位址。透過這個IP位址，可以從LOG中檢查在入侵發生的時間點之前，入侵者是否進行過哪些弱點掃描的行為。並且從這些掃描行為中來發現網站是否還有存在其他的弱點可以被用來入侵。以及檢查入侵者是否在置換網頁之外，還透過網頁服務進行了哪些入侵行為。

第三步：分析入侵者行為
當我們找到了入侵的時間點，接下來就是要分析LOG，看看是否可以推論出入侵者是如何透過弱點進行入侵的。筆者所使用的推論準則是，找出非正常的來源，是否進行了非正常的連線請求。以下我們舉一些實例來說明如何進行推論。
非正常的來源，對非正常的檔案進行連線
一般來說，網站提供給使用者所連線的檔案都是HTML，並透過這些HTML來顯示圖形檔。或者是提供ASP、PHP、JSP、CGI、CFM等互動式網頁。如果在入侵的時間點看到非以上所舉例的常見檔案，通常這些檔案就是入侵者所攻擊的目標。以下LOG就是入侵者透過存取特殊的動態連結檔(DLL)來進行入侵的範例：
以上的LOG顯示，入侵者對網站/_vti_bin/shtml.dll
檔案進行連線嘗試使用FrontPage Server Extension功能，由於伺服器回應狀態碼編號200，因此可以確定網站支援FrontPage Server Extension功能。LOG中顯示入侵者存取/_vti_bin/_vti_aut/author.dll檔案可以取得伺服器回應狀態碼編號200，可以推斷入侵者通過認證，取得授權使用FrontPage Server Extension功能。此時，網站的管理者就必須思考被入侵的網站是否需要使用這個有機會被入侵的功能服務，如果不需要使用這個服務，便將之移除，以解決下次被透過同樣的弱點被入侵。如果，網站管理者需要使用FrontPage Server Extension這個服務，就必須思考為何入侵者可以輕易的通過認證取得授權。是否因為網頁的所在目錄(例如：C:\inetpub\wwwroot\)及FrontPage Server Extension所在目錄(C:\Program Files\Common Files\Microsoft
Shared\WebServerExtensions\40\isapi)設定權限上的錯誤，允許這兩個目錄的權限是everyone完全控制，以至於攻擊者得以在無權限的條件下修改網頁內容。如果目錄權限設定沒有錯誤，檢查系統管理者的密碼是否設定過於簡單，可以讓入侵者透過猜測密碼來取得使用FrontPage Server Extension的使用權。不過，如果入侵者曾嘗試透過猜測密碼來取得使用權限，應該可以在LOG中發現入侵者對/_vti_bin/_vti_aut/author.dll檔案連線時，被伺服器回應403狀態碼。
入侵者透過對非正常的檔案進行連線達成入侵目的，最有名的例子就是Code Red。Code Red透過IIS Union Code的弱點，跳脫目錄限制，對/系統目錄/system32/cmd.exe檔案進行連線，進而透過網站服務來執行command shell指令完成入侵者所要進行的入侵動作。
非正常的來源，執行非正常的指令
一般使用者瀏覽網頁的時候，都是透過GET指令來取得檔案。透過POST指令把資料傳給網站上的網頁作接收。如果在入侵的時間點看到不是使用這兩個指令在存取網站，通常這些指令就是入侵者用來進行攻擊的方法。以下LOG就是入侵者透過WebDAV指令來進行入侵的範例：
根據LOG顯示，入侵者執行OPTIONS指令，詢問伺服器提供支援哪些WebDAV指令，並且從狀態碼200得知伺服器回應入侵者網站支援哪些指令。入侵者再執行PROPFIND指令，查詢網站目錄的權限。再執行HEAD指令，查詢網站根目錄(/)下是否存在default.cfm此一檔案。從狀態碼404可以得知，伺服器通知入侵者default.cfm此一檔案並不存在於根目錄之中。最後入侵者透過PUT指令，上傳一個名稱為default.cfm的檔案至網站的根目錄之下。
在此一例子中，入侵者僅僅是上傳了網頁檔案cfm來表達伺服器存在弱點。然而透過PUT指令，入侵者可以上傳常見的ASP後門至網站目錄中，並透過此一ASP來執行任意的指令。
非正常的來源，連線需特殊權限的網頁
有些時候，入侵者並不需要使用特殊的指令、連線非正常的檔案，而是透過正常的網頁來進行入侵。以下的LOG顯示，在入侵的時間點中，忽然有非管理者群組的IP位址對網站上管理網頁內容用的權限控管頁面進行連線，並且入侵者傳遞資料給此一管理者頁面程式(POST /admin/index.asp)。在入侵者傳遞資料後，便可以存取管理網頁的主程式(GET /admin/index1.asp)。入侵者繼續使用管理者程式中的新增圖片功能，並且傳遞了資料給新增圖片用的網頁承接。再傳遞完資料後，入侵者連線至檔案名稱看似圖片檔的ASP頁面。
經過追蹤以上LOG中可疑使用者的瀏覽行為，可以推知網站的管理者頁面程式沒有做好輸入驗證的程序。因此造成入侵者可以透過程式的弱點，跳脫程式的權限控管，進而使用管理者的功能。而且入侵者使用上傳圖片的功能來上傳一個ASP後門，進而使用此一ASP來達成置換網頁的目的。此處入侵者所使用的可以跳脫權限的弱點，就是所謂的SQL Injection。

第四步：追蹤入侵後的軌跡
上面第三步所做的，其實就是在找入侵時間點中異常的行為。只要了解哪些行為是屬於正常的瀏覽模式，就可以分析出來入侵者是透過哪個弱點進行入侵。然而，第三步所做的是找出入侵者利用哪個弱點進行入侵，有時候沒有辦法找出來入侵者是否透過弱點安裝了其他的後門。例如SQL Injection例子中，我們只能從LOG中找出來入侵者上傳了ASP後門，但是無法得知入侵者透過這個ASP進行了哪些惡意行為。我們可以透過入侵的時間點來分析，入侵者是否在入侵發生的時間點內安裝、下載了其他工具。
使用以上簡單的DOS指令，搜尋整個磁碟機中哪些檔案是在入侵當天被建立、修改，在後續分析這些被找出來的檔案是否是屬於惡意的程式。

最後一步：復原系統的安全
透過LOG分析、檔案搜尋來找出系統哪裡存在弱點，以及是否得知被安裝後門。在了解之後，儘速的把弱點進行修補、後門程式進行移除，保持系統處於安全的狀態，避免被其他的入侵者透過同樣的弱點進行入侵。在復原網站的過程中應該注意幾件事：1.如果不確定系統是否存在後門，在發現入侵後就應該將系統重新安裝。2.若要從備份中復原網站程式，必須確認備份的資料是安全的。不要將入侵者上傳的ASP後門也備份回網站中。
本篇文章筆者雖然使用IIS LOG舉例來說明如何找出入侵方式，但是其他的網站LOG也可以透過同樣的方式來找出入侵行為。網站管理者也可以使用上述的檢查方式來檢視目前的LOG檔案，看看是否可以找出潛在的入侵行為。