Web日志安全分析淺談

一、為什么需要對日志進行分析？

隨著Web技術不斷發展，Web被應用得越來越廣泛，所謂有價值的地方就有江湖，網站被惡意黑客攻擊的頻率和網站的價值一般成正比趨勢，即使網站價值相對較小，也會面對“腳本小子”的惡意測試攻擊或者躺槍于各種大范圍漏洞掃描器，正如安全行業的一句話：“世界上只有兩種人,一種是知道自己被黑了的,另外一種是被黑了還不知道的”

此時對網站的日志分析就顯得特別重要，作為網站管理運維等人員如不能實時的了解服務器的安全狀況，則必定會成為“被黑了還不知道的”那一類人，從而造成損失，當然還有一個場景是已經因為黑客攻擊造成經濟損失，此時我們也會進行日志分析等各種應急措施盡量挽回損失，簡而言之日志分析最直接明顯的兩個目的，一為網站安全自檢查，了解服務器上正在發生的安全事件，二為應急事件中的分析取證。

二、如何進行日志分析？

在說如何進行分析之前，我們先來了解一下Web服務器中產生的日志是什么樣子.我們以Nginx容器為例：

隨機抽取一條日志：

61.144.119.65 - - [29/May/2017:22:01:32 +0800] "GET /page/1 HTTP/1.1" 200 6403 "http://www.baidu.com" "Scrapy/1.1.2 (+http://scrapy.org)"

作為Web開發或者運維人員，可能對圖中的日志信息比較熟悉，如果對日志不那么熟悉也沒關系，我們可以查看Nginx中關于日志格式的配置，查看nginx.conf配置文件：

可以看到日志格式為：

remote_addr - remote_user [time_local] "request" 'status body_bytes_sent "http_referer" 'http_user_agent" "$http_x_forwarded_for"';

翻譯過來即為：遠程IP – 遠程用戶  服務器時間 請求主體 響應狀態 響應體大小 請求來源 客戶端信息 客戶端代理IP

通過以上信息，我們可以得知服務器會記錄來自客戶端的每一個請求，其中有大量來自正常用戶的請求，當然也包括來自惡意攻擊者的請求，那么我們如何區分正常請求和惡意攻擊請求呢？站在攻擊者的角度，攻擊者對網站進行滲透時，其中包含大量的掃描請求和執行惡意操作的請求，而這兩者在日志中都有各自的特征，如掃描請求會訪問大量不存在的地址，在日志中體現則為大量的響應狀態碼為404，而不同的惡意請求都有各自相應的特征，如當有人對服務器進行SQL注入漏洞探測時：

   (圖中以"select"為關鍵字進行過濾)

聰明的你肯定想到了，如果此時加上時間條件，狀態碼等條件就能查詢到最近可能成功的SQL注入攻擊了，當然實際情況中，僅僅只依靠狀態碼來判斷攻擊是否成功是不可行的，因為很多時候請求的確成功了，但并不能代表攻擊也成功了，如請求一個靜態頁面或者圖片，會產生這樣一個請求:/logo.png?attack=test';select//1//from/**/1,此時請求狀態碼為200，但是此注入攻擊并沒有得到執行，實際情況中，還會有更多情況導致產生此類的噪聲數據。

拋開這類情況不談，我們來說說在一般應急響應場景中我們分析日志的常規辦法。

在常規應急響應常見中，一般客戶會有這幾種被黑情況：

1.帶寬被占滿，導致網站響應速度變慢，用戶無法正常訪問

2.造成已知經濟損失，客戶被惡意轉賬、對賬發現金額無端流失

3.網站被篡改或者添加暗鏈，常見為黑客黑頁、博彩鏈接等

..........

對于這些情況，按照經驗，我們會先建議對已知被黑的服務器進行斷網，然后開始進行日志分析操作。假設我們面對的是一個相對初級的黑客，一般我們直接到服務器檢查是否存有明顯的webshell即可。檢查方式也很簡單：

1.搜索最近一周被創建、更新的腳本文件

2.根據網站所用語言，搜索對應webshell文件常見的關鍵字

找到webshell后門文件后，通過查看日志中誰訪問了webshell，然后得出攻擊者IP，再通過IP提取出攻擊者所有請求進行分析

如果不出意外，可能我們得到類似這樣一個日志結果：（為清晰呈現攻擊路徑，此日志為人工撰造）

eg:

00:01  GET http://localhost/index.php 9.9.9.9  200  [正常請求]

00:02  GET http://localhost/index.php?id=1' 9.9.9.9 500  [疑似攻擊]

00:05  GET http://localhost/index.php?id=1' and 1=user() or ''=' 9.9.9.9  500  [確認攻擊]

00:07 GET http://localhost/index.php?id=1' and 1=(select top 1 name from userinfo) or ''=' 9.9.9.9 500 [確認攻擊]

00:09 GET http://localhost/index.php?id=1' and 1=(select top 1 pass from userinfo) or ''=' 9.9.9.9 500 [確認攻擊]

00:10  GET http://localhost/admin/ 9.9.9.9 404 [疑似攻擊]

00:12  GET http://localhost/login.php 9.9.9.9 404 [疑似攻擊] 00:13  GET http://localhost/admin.php 9.9.9.9 404 [疑似攻擊]

00:14  GET http://localhost/manager/ 9.9.9.9  404 [疑似攻擊]

00:15  GET http://localhost/admin_login.php 9.9.9.9 404 [疑似攻擊]

00:15  GET http://localhost/guanli/ 9.9.9.9 200 [疑似攻擊]

00:18  POST http://localhost/guanli/ 9.9.9.9 200 [疑似攻擊]

00:20  GET http://localhost/main.php 9.9.9.9 200 [疑似攻擊]

00:20  POST http://localhost/upload.php 9.9.9.9 200 [疑似攻擊]

00:23  POST http://localhost/webshell.php 9.9.9.9 200 [確認攻擊]

00:25  POST http://localhost/webshell.php 9.9.9.9 200 [確認攻擊]

00:26  POST http://localhost/webshell.php 9.9.9.9 200 [確認攻擊]

首先我們通過找到后門文件“webshell.php”，得知攻擊者IP為9.9.9.9，然后提取了此IP所有請求，從這些請求可以清楚看出攻擊者從00:01訪問網站首頁，然后使用了單引號對網站進行SQL注入探測，然后利用報錯注入的方式得到了用戶名和密碼，隨后掃描到了管理后臺進入了登錄進了網站后臺上傳了webshell文件進行了一些惡意操作。

從以上分析我們可以得出，/index.php這個頁面存在SQL注入漏洞，后臺地址為/guanli.php,/upload.php可直接上傳webshell

那么很容易就能得出補救方法，修復注入漏洞、更改管理員密碼、對文件上傳進行限制、限制上傳目錄的執行權限、刪除webshell。

三、日志分析中存在的難題

看完上一節可能大家會覺得原來日志分析這么簡單，不過熟悉Web安全的人可能會知道，關于日志的安全分析如果真有如此簡單那就太輕松了。其實實際情況中的日志分析，需要分析人員有大量的安全經驗，即使是剛才上節中簡單的日志分析，可能存在各種多變的情況導致提高我們分析溯源的難度。

對于日志的安全分析，可能會有如下幾個問題，不知道各位可否想過。

1.日志中POST數據是不記錄的，所以攻擊者如果找到的漏洞點為POST請求，那么剛剛上面的注入請求就不會在日志中體現

2.狀態碼雖然表示了響應狀態，但是存在多種不可信情況，如服務器配置自定義狀態碼。

如在我經驗中，客戶服務器配置網站應用所有頁面狀態碼皆為200，用頁面內容來決定響應,或者說服務器配置了302跳轉，用302到一個內容為“不存在頁面”（你可以嘗試用curl訪問http://www.baidu.com/test.php看看響應體）

3.攻擊者可能使用多個代理IP，假如我是一個惡意攻擊者，為了避免日后攻擊被溯源、IP被定位，會使用大量的代理IP從而增加分析的難度（淘寶上，一萬代理IP才不到10塊錢，就不說代理IP可以采集免費的了）

如果一個攻擊者使用了大量不同的IP進行攻擊，那么使用上面的方法可能就無法進行攻擊行為溯源了

4.無惡意webshell訪問記錄，剛才我們采用的方法是通過“webshell”這個文件名從日志中找到惡意行為，如果分析過程中我們沒有找到這么一個惡意webshell訪問，又該從何入手尋找攻擊者的攻擊路徑呢？

5.分析過程中我們還使用惡意行為關鍵字來對日志進行匹配，假設攻擊者避開了我們的關鍵字進行攻擊？比如使用了各種編碼，16進制、Base64等等編碼，再加上攻擊者使用了代理IP使我們漏掉了分析中攻擊者發起的比較重要的攻擊請求

6.APT攻擊，攻擊者分不同時間段進行攻擊，導致時間上無法對應出整個攻擊行為

7.日志數據噪聲（這詞我也不知道用得對不對）上文提到過，攻擊者可能會使用掃描器進行大量的掃描，此時日志中存在大量掃描行為，此類行為同樣會被惡意行為關鍵字匹配出，但是此類請求我們無法得知是否成功掃描到漏洞，可能也無法得知這些請求是掃描器發出的，掃描器可使用代理IP、可進行分時策略、可偽造客戶端特征、可偽造請求來源或偽造成爬蟲。此時我們從匹配出的海量惡意請求中很難得出哪些請求攻擊成功了

四、日志分析工程化之路 [探索篇]

（上一節留下的坑我們留到最后討論[因為我也覺得比較頭疼]，我們現在來討論一點讓人輕松的~）

曾經有運維的人員問我們公司的大神，該如何分析日志？

大神回答了三個字：“用命令”

因為站在安全經驗豐富的人角度來看，的確用命令足矣，可是對于安全經驗不那么豐富的人來說，可能就不知道從何入手了。但是即使身為一個安全從業人員，我也覺得用命令太過耗時耗力（還有那么多有趣的事情和偉大的事情沒做吶，當然還要節約出一點時光來嗨嗨嗨呀，難道每次分析日志我們都用命令一個個給一點點分析？）

于是，聰明的黑客們就想到了，將這些步驟流程寫成工具，讓工具來幫我們分析日志，當然我也想到了，可是在我造這么一個輪子之前，我習慣性的到各大網站上先翻一翻，看看有沒有人實現過，還真讓我找到一些，見FAQ區域。

我以“Web安全日志分析”為關鍵字，百度&Google了一番，發現并沒有找到自己覺得不錯的日志分析工具，難道安全行業就沒有大牛寫個優秀的日志分析工具出來？年輕時的我如此想到，后來我發現并非如此，而是稍微優秀一點的都跑去做產品了，于是我轉戰搜尋關于日志安全分析產品，通過各種方式也讓我找到了幾個，如下：

1. 首先是推廣做得比較好的:日志易

日志易確實像它推廣視頻里所說的：“國內領先的海量日志搜索分析產品”

前段時間，有客戶聯系到我們，說他們買了日志易的產品，但是其中對安全的監控比較缺乏，讓我們能不能在日志易的基礎上添加一些安全規則，建立安全告警，他們要投放到大屏幕，然后來實時監控各個服務器的安全狀態。然后我就大概看了一遍日志易的產品，安全方面的分析，基本為0.

但是日志易確實有幾個優點：

1.日志采集方面相對成熟，已經能針對多種日志格式解析并結構化，還支持用戶自定義日志格的輔助解析

2.海量日志存儲相對完善，可接收來自各個客戶端的日志，Saas服務成熟，能對接各大云主機

3.搜索方面技術優秀，千億級別數據索引只需60秒（但是，我要的安全分析啊，其他的再成熟，也始終是個不錯的日志分析平臺而已，我要的是安全分析、安全分析、安全分析[重要的話說三遍]）

補：（后來我發現，日志易其實有在安全方面進行分析，但是這個如圖這個結果，并沒有讓我覺得眼前一亮，而且其中還有大量的誤報）

2. 看到一個稍微像那么回事的產品：安全易

他們推廣做得不那么好，所以在我一開始的搜索中，并沒有從搜索引擎找到它，這個產品是可以免費注冊并試用的，于是我迫不及待注冊了一個賬號進去看看，如圖：

當我試用過安全易這個產品之后，提取出了他們在關于安全方面所做的統計列表，如下：

1.威脅時序圖

2.疑似威脅分析

3.疑似威脅漏報分析

4.威脅訪問流量

5.威脅流量占比

6.境外威脅來源國家(地區)統計

7.境內威脅來源城市統計

8.威脅嚴重度

9.威脅響應分析

10.惡意IP

11.惡意URL分析

12.威脅類型分析 

13.威脅類型分布

14.威脅分類計數

15.威脅來源熱力圖

16.威脅總數

17.威脅日志占比

結果似乎挺豐富，至少比我們開始使用命令和工具得到的結果更為豐富，其實在看到這個產品之前，我們內部就嘗試使用過各種方法實現過其中大部分視圖結果，但是似乎還是缺少點什么

攻擊行為溯源，也就是我們在第二節中對日志進行簡單的分析的過程，得到攻擊者的整個攻擊路徑已經攻擊者執行的惡意操作。不過想要將這個過程工程化，難度可比如上17個統計視圖大多了，難在哪里？請回看第三節..

雖然安全易的產品并沒有滿足我對日志分析中的想法，但是也不能說它毫無價值，相反這款產品能輔助運維人員更有效率的監控、檢查服務器上的安全事件，甚至他們不用懂得太多的安全知識也能幫助企業更有效率的發現、解決安全問題

五、日志分析工程化之路 [實踐篇]

在了解了很多分析日志的工具后，也嘗試過自己折騰出一個方便分析日志的工具，以便以日常工作中的應急響應場景

記得是在半年前左右，我的思路是這樣的：

1.首先確認日志結構

我在Mysql中建立了如下結構的一張表來存儲日志：

日志字段

請求時間

服務器名稱

客戶端IP

請求方法

請求資源

服務器端口

服務器IP

瀏覽器信息

響應狀態碼

請求來源

響應長度

請求協議

2.給Web攻擊進行分類

攻擊類型表

攻擊類型名稱

危險等級

攻擊/掃描

3.建立攻擊規則表對應不同的攻擊類型

攻擊規則表

攻擊規則正則表達式

攻擊發生的位置

攻擊規則對應的攻擊類型ID

此時不得不說一下當時日志是怎么入庫的，不知道大家是否知道awk命令

echo "aa bb cc" | awk -F '{print $1}'

我們對日志采用了類似的方式，通過空格分割，然后生成出Mysql中可用的insert語句

大約為：INSERT INTO web_log VALUES ($1,$3,$4,…),至于你說其中列數是如何對應到Mysql里的表結構的,我們當時是人工核對的，為每一個不同的日志文件進行人工對應..（可想而知這活工作量多大）

扯回正題，當我們入庫完畢后有了這么三張數據表，聰明的童鞋可能已經知道下一步要干什么的，那就是拿著安全規則正則表達式去逐條匹配日志表里面的日志

然后得到結果：

攻擊日志ID

攻擊類型ID

攻擊規則ID

最后我們只需要寫SQL語句，就能輕松統計各個攻擊類型都分別有多少攻擊請求了，如圖：

最后我們思考了從各個角度來進行查詢，得到了如下以下列表中的結果：

1.網站受攻擊次數排名

2.網站高危請求排名

3.網站攻擊者數量排名

4.網站受攻擊頁面排名

5.可疑文件排行

6.被攻擊時間統計

7.攻擊來源分布

8.高危攻擊者排行

9.攻擊者攻擊次數排行

10.網站危險系數排行

11.攻擊者數量統計

12.各站點攻擊者數量統計

13.各掃描器占比

14.使用掃描器攻擊者統計

由于這是一次針對多個(70+)站點的分析，所以只需突顯安全趨勢即可，在此次日志分析中，還并未涉及到溯源取證

記得當時我們是用SQL語句查詢出結果，然后將數據填入Execl，然后進行圖標生成，整個日志分析的過程，從日志原文件到入庫到匹配到統計到出數據最后到Execl出統計圖表基本都需要人工參與

對了，上幾張圖瞧瞧吧

（篇幅原因，其他統計圖不貼上來了）

可以看出，我們僅僅只是采用了一些安全攻擊規則來對日志進行匹配就已經得到了不錯的結果，雖然整個過程有點漫長，但是得到的這一份日志分析報告是具有實際意義和價值的，它可以幫我們發現哪些站點受到的攻擊行為最多，那一類攻擊最為頻繁，哪些站點風險系數較高，網站管理和運維人員可以通過這份報告，來著重檢查危險系數較高的請求和危險系數較高的站點，從而大大提高效率。

但是日志分析工(lan)程(duo)化(hua)之路到此結束了嗎？不，遠遠沒有。

六、日志分析工程化之路 [進階篇]

有沒有覺得像上面那樣折騰太累了，雖然確實能得到一個還不錯的結果。于是開始找尋一個較好的日志分析方案，最后采用了開源日志分析平臺ELK,ELK分別為：

Elasticsearch 開源分布式搜索引擎

Logstash 對日志進行收集、過濾并存儲到Elasticsearch或其他數據庫

Kibana 對日志分析友好的Web界面,可對Elasticsearch中的數據進行匯總、分析、查詢

因為它開源、免費、高可配，所以是很多初創企業作為日志分析使用率最高的日志分析平臺

當理清楚ELK的搭建方式和使用流程后，我們用ELK實現了一遍第五節中的日志分析

流程大概如下：

1.編寫Logstash配置文件

2.將攻擊規則應用于logstash的filter插件

3.利用載入了安全分析插件后的logstash進行日志導入

4.查詢分析結果

5.利用Kibana進行統計、可視化

到這里，所得結果已經比“HanSight瀚思”安全易這個產品的結果更為豐富了~ ，但是日志安全分析之路遠遠沒有結束，最重要也最具有價值的那部分還沒有得到實現 —— 攻擊行為溯源。

七、日志安全分析攻擊溯源之路 [探索篇]

故技重施，我搜尋了和攻擊溯源有關的相關信息，發現國內基本寥寥無幾。

最后發現其實現難度較大，倒是聽說過某些甲方內部安全團隊有嘗試實現過，但至今未要到產品實現的效果圖，不過最后倒是被我找到某安全公司有一個類似的產品，雖然是以硬件方式實現的流量監控，從而獲取到日志進行分析。這里提一句，通過硬件方式獲取流量從而可以記錄并分析整個請求包和響應包，這可比從日志文件中拿到的信息全面多了，從而將日志溯源分析降低了一個難度，不過某些優秀的分析思路還是值得學習的，先上幾張產品效果圖：

（圖1）

（圖2）

（圖3）

由于圖1中的分析已經實現，這里暫且不談。我們看圖2中的攻擊溯源，這好像正是我們需要的效果。

第一個信息不難理解，三個中國的IP發起了含有攻擊特征的請求，他們的客戶端信息(userAgent)分別為Linux/Win7/MacOs

第二個信息據我經驗應該是他們內部有一個IP庫，每個IP是否為代理IP，所處什么機房都有相應的記錄，或者調用了IP位置查詢接口，從而判斷IP是否為代理IP、機房IP、個人上網出口IP，繼而判定未使用跳板主機

第三個信息為攻擊者第一次訪問站點，從圖中卻到看到jsky的字樣，竭思為一款Web漏洞掃描器，而根據我的經驗來看，掃描器第一個請求不應該是訪問一個txt文件而是應該請求主頁從而判斷網站是否能正常請求，所以這里我猜測應該是從時間鏈或者IP上斷掉的線索，從而導致對攻擊者的入站第一個請求誤判，不過誤判入站請求這個倒是對分析的影響不是特別大

第四、第五、第六個信息應該分別為訪問了后臺地址、對后臺進行了爆破攻擊、使用常見漏洞或CMS等通用漏洞對應用進行了攻擊，除了后臺訪問成功之外，爆破攻擊、應用攻擊均為成功。因為此攻擊溯源分析通過硬件方式實現，猜想應該是判斷了響應體中是否包含各種登錄成功的跡象，而應用攻擊則判斷響應中是否存在關于數據庫、服務器的敏感信息，如不存在則視為攻擊未成功

第七個信息展示出了攻擊者總共發起了79166次注入攻擊，且對服務器已經造成了影響，但是從效果圖中看來，此溯源并沒有具體展示對哪臺哪個應用攻擊成功造成了影響，故斷定為綜合判斷，可能存在一定誤報率，判斷方式可通過響應體中的敏感信息、響應平均大小等方式判斷已攻擊成功的概率

對于圖3中的效果，開始覺得結果豐富，意義深遠，但是細看發現結果豐富大多來源于相關數據豐富。

綜上所訴，此攻擊溯源產品利用了兩個優勢得出了比常規分析日志方法中更有價值的結果

1.請求和響應數據完整，能進行更大維度的日志分析

2.安全關聯庫較多，能關聯出更為豐富的信息

如下為產品中引用的關聯庫：

1. 全球IPV4信息知識庫，包括該IP對應的國家地區、對應的操作系統詳情、瀏覽器信息、電話、域名等等。并對全球IP地址實時監控，通過開放的端口、協議以及其歷史記錄，作為數據模型進行預處理。

2. 全球虛擬空間商的IP地址庫，如果訪問者屬于該范圍內，則初步可以判定為跳板IP。

3. 全球域名庫，包括兩億多個域名的詳細信息，并且實時監控域名動向，包括域名對應的IP地址和端口變化情況，打造即時的基于域名與IP的新型判斷技術，通過該方式可以初步判斷是否為C&C服務器、黑客跳板服務器。

4. 黑客互聯網信息庫，全球部署了幾千臺蜜罐系統，實時收集互聯網上全球黑客動向。

5．獨有的黑客IP庫，對黑客經常登錄的網站進行監控、對全球的惡意IP實時獲取。

6. 黑客工具指紋庫，收集了所有公開的（部分私有的）黑客工具指紋，當攻擊者對網站進行攻擊時，可以根據使用的黑客工具對黑客的地區、組織做初步判斷。

7. 黑客攻擊手法庫，收集了大量黑客攻擊手法，以此來定位對應的黑客或組織。

8. 其他互聯網安全廠商資源，該系統會充分利用互聯網各種資源，比如聯動50余款殺毒軟件，共同檢測服務器木馬程序。

9. 永久記錄黑客攻擊的所有日志，為攻擊取證溯源提供詳細依據。

八、日志安全分析攻擊溯源之路 [構想篇]

我也希望我在這一節能寫出關于溯源的實踐篇，然而事實是到目前為止，我也沒有太好的辦法來解決在傳統日志分析中第三節中提到的問題，期間也做過一些嘗試，得到的結果并不怎么盡人意，當然之后也會不斷嘗試利用優秀的思路來嘗試進行攻擊溯源分析。由于還并未很好的實現攻擊溯源分析，下面只討論一些可行思路（部分思路來源于行業大牛、國內外論文資料）

通過前幾節，我們已經知道了我們分析日志的目的，攻擊溯源的目的和其意義與價值

這里簡短概括一下：

一、實時監控正在發生的安全事件、安全趨勢

二、還原攻擊者行為

   1.從何時開始攻擊

   2.攻擊所利用的工具、手法、漏洞

   3.攻擊是否成功，是否已經造成損失和危害

三、發現風險、捕獲漏洞、修復漏洞、惡意行為取證

在傳統日志分析過程中，想要實現以上效果，那么就不得不面對第三節中提到的問題，這里回顧一下：

1.POST數據不記錄導致分析結果不準確

其實在服務器端，運維管理人員可自行配置記錄POST數據，但是這里說的是默認不記錄的情況，所以配置記錄POST數據暫且不提。

其實我覺得要從不完整的信息中，分析得到一個肯定的答案，我覺得這從邏輯上就不可行。但是我們可以折中實現，盡量向肯定的答案靠近，即使得到一個90%肯定的答案，那也合乎我們想要的結果。

在常規日志分析中，雖然POST數據不被記錄，但是這些“不完整信息”依然能給我們我們提供線索。

如通過響應大小、響應時間、前后請求關聯、POST地址詞義分析、狀態碼等等依然能為我們的分析提供依據，如某個請求在日志中的出現次數占訪問總數30%以上，且響應大小平均值為2kb，突然某一天這個請求的響應值為10kb，且發起請求的IP曾被攻擊特征匹配出過，那么可以80%的懷疑此請求可能存在異常，如攻擊者使用了聯合注入查詢了大量數據到頁面，當然這里只是舉例，實際情況可能存在誤報。

2.狀態碼不可信

對于那些自行設置響應狀態的，明明404卻302的，明明500卻要200的(~~我能說這種我想拖出去打死么- -,~~) PS：其實設置自定義狀態碼是別人的正常需求。

 因為狀態碼不可信了，我們必須從其他方面入手來獲取可信線索，雖然要付出點代價。

 我的思路是，對于不同的攻擊行為，我們應該定義不同的響應規則，如攻擊規則命中的為網站備份文件，那么應該判斷請求大小必須超過1k-5k，如攻擊者發起/wwwroot.rar這種攻擊請求，按照常理如果狀態碼為200，那么本來應該被定性為成功的攻擊行為，但是因為狀態碼不可信，我們可以轉而通過響應大小來判斷，因為按照常規邏輯，備份文件一般都不止只有幾kb大小，如攻擊者發起Bool注入請求則應該通過判斷多個注入攻擊請求的規律，Bool注入通常頁面是一大一小一大一小這種規律，如攻擊者發起聯合注入攻擊，則頁面響應大小會異常于多部分正常頁面響應大小，如果攻擊者發起延時注入請求，則頁面響應時間則會和延時注入payload中的響應相近，但是這需要分析攻擊payload并提取其中的延時秒數來和日志中的響應時間進行比較誤差值,當然，這里只是嘗試思路，實際可行率有待實踐。

3.攻擊者使用多個代理IP導致無法構成整個攻擊路徑

假設同一攻擊者發起的每個請求都來自不同的IP，此時即使攻擊規則命中了攻擊者所有請求，也無法還原攻擊者的攻擊路徑，此時我們只能另尋他法。雖然攻擊者使用了多個IP，但是假設攻擊者不足夠心細，此時你可以通過攻擊時間段、請求頻率、客戶端信息(Ua)、攻擊手法、攻擊工具(請求主體和請求來源和客戶端信息中可能暴露工具特征。如sqlmap注入時留下的referer)

4.無惡意webshell訪問記錄

常規分析中，我們通過找到后門文件，從而利用這一線索得知攻擊者IP繼而得知攻擊者所有請求，但是如果我們并沒有找到webshell，又該用什么作為分析的入口線索呢？

利用盡可能全面的攻擊規則對日志進行匹配,通過IP分組聚合，提取發起過攻擊請求的所有IP，再通過得到的IP反查所有請求，再配合其他方法檢測提取出的所有請求中的可疑請求

5.編碼避開關鍵字匹配

關于編碼、加密問題，我也曾嘗試過，但是實際最后發現除了URL編碼以外，其他的編碼是無法隨意使用的，因為一個被加密或編碼后的請求，服務器是無法正確接收和處理的，除非應用本身請求就是加密或編碼的。且一般加密或編碼出現在日志里通常都是配合其他函數實現的，如Char()、toHexString()、Ascii()..

6.APT分時段攻擊

如果同一攻擊者的攻擊行為分別來源不同的時間，比如攻擊者花一周時間進行“踩點”，然后他就停止了行為，過了一周后再繼續利用所得信息進行攻擊行為，此時因為行為鏈被斷開了一周，我們可能無法很明顯的通過時間維度來定位攻擊者的攻擊路徑。我目前的想法是，給攻擊力路徑定義模型，就拿在前面講到的常規日志分析舉例，那么攻擊路徑模型可定義為：訪問主頁>探測注入>利用注入>掃描后臺>進入后臺>上傳webshell>通過webshell執行惡意操作。

其中每一個都可以理解一種行為，而每種行為都有相應的特征或者規則。比如主頁鏈接一般在日志中占比較大，且通常路徑為index.html、index.php、index.aspx,那么符合這兩個規則則視為訪問主頁，而在探測注入行為中，一般會出現探測的payload，如時間注入會匹配以下規則：

.(BENCHMARK(.)).*.(WAITFOR.DELAY).*.(SLEEP(.).*.(THENDBMS_PIPE.RECEIVE_MESSAGE).

Bool注入

.*and.*(>|=|<).*.*or.*(>|=|<).*.*xor.*(>|=|<).*

聯合注入：

.*(order.*by).*.*(union.*select).*.*(union.*all.*select).*.*(union.*select.*from).*

顯錯注入:

.*('|"|\)).*.*(extractvalue\(.*\)).*.*(floor\(.*\)).*.*(updatexml\(.*\)).*

利用注入則會體現出更完整，帶有目的性的攻擊請求，我們以同理制定規則即可，如查詢當前數據庫名、查詢版本信息、查詢數據庫表名、列名則會出現database、version、table_name、column_nam（不同數據庫存在不同差異，這里僅舉例）。

掃描后臺則會產生大量的404請求，且請求較為頻繁，請求特征通常為/admin、/guanli、/login.php、/administrator。

對于是否進入后臺，我認為假如一個疑似后臺訪問的鏈接被頻繁請求，且每次響應大小都不相同，我則認為這是已經進入了后臺，但是也有可能是網站管理員正在后臺進行操作的，這暫且不談。

關于上傳webshell，這個比較難得到較準確的信息，因為我們沒有POST數據，無法知道上傳的內容是什么，但是我們可以通過反推法，先利用webshell訪問特征進行匹配，找到可能為webshell的訪問地址，然后以時間為條件往前匹配包含上傳特征的請求，如果成功匹配到了存在上傳特征，那么可將其視為攻擊路徑中的“上傳webshell”行為。

至于“通過webshell執行惡意操作”，可以簡單定義為webshell地址被請求多次，且響應大小大多數都不相同，當我們對以上每種行為都建立對應的規則之后，然后按照攻擊路徑模型到日志中進行匹配，攻擊路徑模型可能有多個

這是一個相對常規的攻擊路徑：

訪問主頁>探測注入>利用注入>掃描后臺>進入后臺>上傳webshell>通過webshell執行惡意操作

可能還會有：

訪問主頁>爬蟲特征>掃描敏感信息>掃描識別CMS特征>利用已知組件漏洞進行攻擊>執行惡意代碼>獲取webshell>通過webshell執行惡意操作。

掃描路徑>掃描到后臺>疑似進入后臺>上傳webshell>通過webshell執行惡意操作。

當我們用多個類似這樣的攻擊路徑模型對日志進行匹配時，可能在同一個模型中可能會命中多次相同的行為特征，此時我需要做一個排查工作，通過IP、客戶端特征、攻擊手法、攻擊payload相似度等等進行排除掉非同一攻擊者的行為，盡可能得到一條準確的攻擊路徑。

我們通過一整個攻擊路徑來定義攻擊，從而即使攻擊者分時段進行攻擊，行為也會被列入到攻擊路徑中

通過這樣方式，也許能實現自動化展示出攻擊者的攻擊路徑，但是具體可行率、準確度還有待進一步實踐后確認。

7.日志噪聲數據

通常，除了攻擊者惡意構造的攻擊之外，日志中還包含大量的掃描器發出的請求，此類請求同樣包含一些攻擊特征，但是多半都為無效的攻擊，那么我們如何從大量的掃描攻擊請求中判斷出哪些請求較為可疑，可能攻擊已經成功呢？我所認為的方法目前有兩種，一種是給每種攻擊方法定義成功的特征，如延時注入可通過判斷日志中的響應時間，聯合注入可通過與正常請求比較響應大小，Bool注入可通過頁面響應大小的規律，當然實際情況中，這種做法得到的結果可能是存在誤報的。第二種辦法就是通過二次請求，通過重放攻擊者的請求，定義攻擊payload可能會返回的結果，通過重放攻擊請求獲取響應之后進行判斷，其實這里已經類似掃描器，只是攻擊請求來自于日志，這種方法可能對服務器造成二次傷害，一般情況下不可取，且已經脫離日志分析的范疇。

九、日志安全分析之更好的選擇

回到那個最基本的問題，如何從日志中區分正常請求和攻擊請求？

可能做過安全的人都會想到：用關鍵字匹配呀。

對，關鍵字匹配，因為這的確是簡單直接可見的辦法，用我們已知的安全知識，把每一種攻擊手法定義出對應的攻擊規則，然而對日志進行匹配，但Web技術更新速度飛快，可能某一天就出現了規則之外的攻擊手法，導致我們無法從日志中分析出這些行為。

其實從接觸日志分析這個領域開始，我就想過一個問題？有沒有一種算法，可以自動的計算哪些是正常的，哪些是不正常的呢？然而思索很久，也嘗試過一些辦法，比如嘗試過使用統計，按照請求的相似度進行歸并，統計出一些“冷門”請求，后來發現其實這樣做雖然有點效果，但是還是會漏掉很多請求，且存在大量無用請求。

后來又思索了一種辦法，能不能對用戶的網站產生的請求建立一個白名單，然后不在白名單內的請求皆為異常請求。這種做法效果倒是更好了一點，可是如何自動化建立白名單又成為了一個問題？如果我們手動對網站請求建立一個單獨的白名單，那么一旦站點較多，建立白名單這個工作量又會巨大，但是如果只有單個站點，手工建立這樣一個白名單是有意義的，因為這樣就能統計所有的異常請求甚至未知的攻擊行為。

后來我發現其實我最初的想法其實是一個正確的思路，用統計的方法來區分正常和異常請求，只不過我在最開始實現的時候認為的是：某個URL被訪問的次數越少，那么次請求為可疑。

更好的思路是：正常總是基本相似 異常卻各有各的異常（來源：http://www.91ri.org/16614.html）

文中關于此理論已經講得很詳細，這里簡單描述一下實現方法：

搜集大量正常請求，為每個請求的所有參數的值定義正常模型

      通過Waf或者攻擊規則來剔除所有發起過攻擊請求的IP，從而得到所有來自用戶的正常請求，將每個正常請求構造出對應的正常模型，比如：

      http://test.com/index.php?id=123

      http://test.com/index.php?id=124

      http://test.com/index.php?id=125

      那么關于此請求的正常模型則為 [N,N,N],不匹配此模型的請求則為異常請求。

當對日志中的請求建立完正常的模型，通過正常模型來匹配找出所有不符合模型的請求時，發現效果的確不錯，漏報較少，不過實踐中發現另一個問題，那便是數據的清洗，我們能否建立對應的模型，取決于對日志數據的理解，如果在數據前期提取時，我們無法準確的提取哪些是請求地址那些為請求參數可能無法對某個請求建立正常模型

關于此理論已經有人寫出了Demo實現，地址：https://github.com/SparkSharly/Sharly

十、日志安全分析總結問答

1.日志分析有哪些用途？

感知可能正在發生的攻擊，從而規避存在的安全風險

應急響應，還原攻擊者的攻擊路徑，從而挽回已經造成的損失

分析安全趨勢，從較大的角度觀察攻擊者更“關心”哪些系統

分析安全漏洞，發現已知或位置攻擊方法，從日志中發現應用0day、Nday

2.有哪些方法可找出日志中的攻擊行為？

攻擊規則匹配，通過正則匹配日志中的攻擊請求

統計方法，統計請求出現次數，次數少于同類請求平均次數則為異常請求

白名單模式，為正常請求建立白名單，不在名單范圍內則為異常請求

HMM模型，類似于白名單，不同點在于可對正常請求自動化建立模型，從而通過正常模型找出不匹配者則為異常請求

3.日志分析有哪些商業和非商業工具/平臺？

工具：

LogForensics 騰訊實驗室

https://security.tencent.com/index.php/opensource/detail/15

北風飄然@金烏網絡安全實驗室

http://www.freebuf.com/sectool/126698.html

網絡ID為piaox的安全從業人員：

http://www.freebuf.com/sectool/110644.html

網絡ID：SecSky

http://www.freebuf.com/sectool/8982.html

網絡ID：鬼魅羊羔    

http://www.freebuf.com/articles/web/96675.html

平臺（商業項目）：

Splunk >> 機器數據引擎 

賽克藍德 >> SeciLog

優特捷信息技術 >> 日志易

HanSight瀚思 >> 安全易

百泉眾合數據科技 >>LogInsight

江南天安 >> 彩虹WEB攻擊溯源平臺

開源項目：

elk ： https://www.elastic.co

scribe ：https://github.com/facebook/scribe

chukwa：http://incubator.apache.org/chukwa/

kafka：http://sna-projects.com/kafka/

Flume：https://github.com/cloudera/flume/

4.有哪些方法適合分析攻擊是否成功？

Kill Chain Model

十一、擴展閱讀

http://netsecurity.51cto.com/art/201506/478622.htm

http://www.freebuf.com/articles/web/86406.html

https://wenku.baidu.com/view/f41356138bd63186bdebbca8.html

http://www.freebuf.com/articles/web/96675.html

http://dongxicheng.org/search-engine/log-systems/

http://www.361way.com/scribe-chukwa-kafka-flume/4119.html

http://www.jianshu.com/p/942d1beb7fdd

https://xianzhi.aliyun.com/forum/attachment/big_size/WAF%E6%98%AF%E6%97%B6%E5%80%99%E8%B7%9F%E6%AD%A3%E5%88%99%E8%A1%A8%E8%BE%BE%E5%BC%8F%E8%AF%B4%E5%86%8D%E8%A7%81.pdf

http://techshow.ctrip.com/archives/1042.html

http://www.ixueshu.com/document/b33cf4addda2a27e318947a18e7f9386.html

http://www.ixueshu.com/document/602ef355997f4aec.html

http://xueshu.baidu.com/s?wd=paperuri%3A%288b49643ad2a4ba7ea2d4cf46e366188d%29&filter=sc_long_sign&tn=SE_xueshusource_2kduw22v&sc_vurl=http%3A%2F%2Fwww.doc88.com%2Fp-0157694572004.html&ie=utf-8&sc_us=16365123920770356600    ;

十二、結束語

在安全領域中，防護為一個體系，感知風險和應急響應僅僅只算安全體系中的兩個環節。而想要盡可能更好的實現這兩個環節，單憑從日志中分析數據是遠遠不夠的。

至于未來或許我們可以將日志分析和Waf、RASP、等其他安全產品進行聯動，還可以將Web日志、系統日志、數據庫日志等各種其他日志進行關聯從而分析更準確、更具有價值的信息。

日志分析本質為數據分析，而數據驅動安全必定是未來的趨勢。

關于日志分析還有很遠的路要走，目前國內還并沒有發現較為優秀的產品，日志數據中存在的價值還有待進一步挖掘。