如何從Web Logs 看出網站被駭的蛛絲馬跡?
這篇文章主要探討的是如何從 Web IIS Logs 中看出網站被害的蛛絲馬跡.
從 Log 中了解相關攻擊的來源,網站那些出現弱點,
進而提供網站防護上的參考以及相關防火牆設定的補強
當收集到一推的 Logs 之後,要從許多的 Log 中找出線索確實不容易,要如何開始分析呢?
首先,先將所有的 LOG 存放在同一個目錄夾中,
接著,工具的準備上可以使用
- NotePad ++ http://notepad-plus-plus.org/
或是專門分析 Web logs 的工具,例如
工具與環境都準備好之後,要如何分析呢?
可以先用 NotePad ++,將所有的IIS Log 檔案都打開,
接著利用關鍵字搜尋列出我們要找的資訊
搜尋的關鍵字取決於相關網站攻擊的行為,因為”關鍵字”搜尋說明如下。
網站攻擊 | 關鍵字搜尋 IIS Logs | 說明 |
XSS Injection Attack | Alert | 這類的攻擊,通常駭客會先測試 <script>alert(“a”)</script>看看該輸入的地方是否會執行該 JavaScript因此,如果 IIS log 之中,有類似的 Scripts 出現,表示有潛在的 XSS attcks發生,因此可以利用關鍵字 “alert”搜尋 |
Login Attacks | PasswordPwdLogin | 駭客可能利用程式在短時間發出大量的 HTTP Request Get or Post,嘗試帳號與密碼的組合。因此如果在 Log 中看到短時間有大量的 HTTP request Login 而且都來自同一個 host IP/User Agent,則表示該來源host,不斷的在測試帳號密碼。 |
SQL Injection | Syntax Error語法不正確 | SQL Injection的基本測試一開始是透過 ‘ 輸入,看看是否會有 Syntax error 語法錯誤產生,如果在 IIS log 中看到取多的”語法錯誤”,就必須要看輸入的參數為何。進一步檢視什麼導致 Syntax error。因為正常瀏覽器的存取,我們不會預期會有很多的”語法錯誤”舉例來說:type=2&&Item_category_no=4接近_’-‘_之處的語法不正確。 80 – 110.1.87.3GET / set=login’+AND+5%3d5+OR+’s’%3d’0 80 – 111.34.7.12如果將 %3d 進一步透過 URL decode ,就會得到下列語法,常見 SQL injection 的測試語句。
AND 1= OR ‘a’=’0 |
HTTP Methods | OptionsHead | 正常用瀏覽器瀏覽網站通常會送出 HTTP Post or HTTP Get但是如果看到 HTTP head 或是 HTTP Options呢?這都表示有人利用工具送出其他的 http methodHTTP head主要用來探知該網頁是否存在HTTP Options 主要用來得知該網站所有支援的 HTTP methods
例如: 駭客利用 HTTP Head 來探知該網站 sms.mp3 是否存在 2014-05-06 14:12:35 21.3.41.17 HEAD /images/sms.mp3 – 80 – 111.2.98.115 contype 200 0 0 31
|
Return Code | HTTP return code | Web server 根據每一個網頁存取的狀況會回傳相關的 HTTP return code200: 表示網頁正常回復這邊要特別注意的是是否有大量的 40x 與 50×403: Forbidden Access500: Internal Server Error
如果有大量且密集的 403/404 ,很有可能表示駭客對於整個網站在做 Directory traverse。但是要注意的是 Google crawler 到網站爬文時,也有可能造成這樣的結果。所以必須還要再看該 Http request 的 User Agent是否為Google or Yahoo crawler. |
Admin | Admin | 用 “Admin” or “Administrator”關鍵字來搜尋主要是因為有些網站上面,有 admin 的管理介面,從 IIS log 可以知道是否有外部電腦試著存取 admin 管理介面。以網站安全角度來說,Admin 的管理應該是要與網站分離,如果網站上需要有 admin 管理介面,也應該將 admin 存取的來源IP 限定於特定內部電腦,而非對外開放存取。 |
透過這些方法都可以讓我們大致了解攻擊的類型與來源,
那麼網站防護安全上有什麼建議呢?
防護建議
1. 帳號密碼失敗三次後鎖定機制,降低帳號密碼字典攻擊的成功機率
2. 圖形驗證碼,降低帳號密碼字典攻擊的成功機率
3. 避免在網站上建立 “Admin”管理介面
4. 設定相關的防火牆規則阻擋基本的 SQL/XSS Injection