0x00：前言

---

談到日誌分析大多數人的感覺是這是一個事後行為，場景當駭客成功將網站黑了。運營人員發現的時候安全人員會介入分析入侵原因，透過分析駭客攻擊行為往往會回溯最近幾天甚至更加久遠的日誌。

0x01：處理過程。

---

個人認為日誌分析的過程分為3個階段：

• 過去:

在之前很多網站的運營日誌並不多少，只有幾G多的可能幾十，上百G，當出現了攻擊行為時，利用grep、perl或者python指令碼可以來完成，但這也是基本偏向於事後階段。原始階段，透過grep關鍵字來發現異常，這樣並不能達到實時分析的結果，往往也是需要到出事後才能介入。 在後來，我們在伺服器上部署了perl指令碼想透過實時tail日誌來發現攻擊者的行為從而進行一個好的分析。這裡的問題是對伺服器負載壓力大，運維人員未必會協助你部署，比較苦逼。那麼我們能否在事前階段介入呢？ 答案是有的，透過下文介紹的方法來逐步實現。

• 現在:

現在是大資料時代資料的最根本的體現就是大，隨著電子商務的興起。每天日誌量上億或者上十幾億基本成為了主流，如果還是依賴之前的指令碼或者grep根本無法完成既定的分析，更談不上能實時分析。

大資料給我們帶來了很多針對大量資料處理的方案，比如hive(離線分析)、storm(實時分析框架)、impala(實時計算引擎)、haddop(分散式計算)、以及hbase，spark這樣的技術。

那麼在有了資料之前，我們應該做點什麼能夠支撐我們的安全資料分析平臺呢？

我覺得可以分為幾個階段來進行：

資料收集。

資料處理。

資料實時計算。

資料儲存 分為2個部分：離線和實時。

首先第一點沒有資料的話，就不要往下看了。

安全分析的基礎是資料，所有的資料來源都源自web日誌，從業務的角度來說，這些都是業務日誌，但是在我的眼裡這些資料是“蜜罐”。

日誌當中存在好的壞的人，我們的目標就是從中篩出壞人。

基於大資料的技術如此多，透過架構及技術選型，選擇的資料型別是這樣：

資料收集透過flume實現，資料訂閱使用kafka來實現，資料實時計算框架使用strorm來實現實時處理，資料儲存透過2個方面來實現，實時儲存和離線儲存。

flume： Flume提供對資料進行簡單處理，並寫到各種資料接受方（可定製）的能力 Flume提供了從console（控制檯）、RPC（Thrift-RPC）、text（檔案）、tail（UNIX tail）、syslog（syslog日誌系統，支援TCP和UDP等2種模式），exec（命令執行）等資料來源上收集資料的能力。

kafka： Kafka1是linkedin用於日誌處理的分散式訊息佇列。

storm： 實時計算框架，透過流處理來實現對資料的實時處理，storm具有實時性高、吞吐量大，低延遲，實時等特點，適合的場景是源源不斷的資料來源。 下圖為storm ui介面：

• 日誌基本處理：

透過這些方式，我們有了日誌後，需要觀察日誌的格式理解其各個欄位的意思，將日誌格式化方便進行提取，此處使用正則完成匹配。 比如一段nginx 日誌規則：

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

對於惡意攻擊日誌，在這裡的關鍵字有哪些用的上呢？ $request、$status、$body_bytes_sent、http_user_agent等。

透過格式化整理工作，在有了大量資料後，我們要做的就是儘可能去除眼前的障礙。

這些障礙包括各種掃描，各種爬蟲，各種有意無意的入侵行為。

對於基本過濾，我們關注的主要是2個：疑似成功的和不成功的，這些透過日誌可以做基本的判別。

HTTP code = 403，404，502，301，這些基本都可以判斷為不成功的攻擊。

而htttp code 等於200和500狀態基本可判斷為疑似“成功攻擊”。那麼在有了這些基礎的篩選後，可以去除較多的無用資料。

我們的目標：記住我們要抓的那種隱藏在大量障礙資料下的攻擊，並不能僅僅依靠這些來實現分析，這是不專業且不負責任的行為。

規則定製：

透過規則定製，可以結合攻防經驗加之前分析過程中發現的問題整理成為規則，加入到storm實時分析job中，來發現攻擊行為，將攻擊行為入庫。發現的多少，完全取決於規則的多少與精準，包括正則的編寫， 規則的定製。

Storm規則捕獲：

在storm裡的實現方式是，透過正規表示式匹配關鍵字，如：phpinfo。

Storm裡的資料流向是storm接入Kafka topic，我們可以透過tupple接收到的資料，將資料做預處理。

這個部分storm是使用prepare來做預處理，這裡可以將正規表示式寫入到prepare裡。

Storm job是使用java編寫的，這裡匹配phpinfo的程式碼是：

有了資料的預處理後，需要執行搜尋，正規表示式的邏輯就是，非黑即白，有就匹配沒有就略過，這裡忽略大小寫。

Storm 使用execute來做執行層的邏輯判斷，透過匹配tupple裡是否包含Phpinfo，如果是則顯示已找到phpinfo，如果不是則不回顯結果。

透過將storm job，上傳到Nimbus後，執行結果可發現如下資訊，可實時發現phpinfo關鍵字，storm job的編譯使用mvn來做。

最後透過資料庫將匹配後的結果輸出到資料庫內，匹配到的結果是這樣子的：

storm 實時計算支援本地除錯和遠端除錯，本地訪問http://hostname/phpinfo.php，storm 抓取到的資訊：

寫入資料庫內的資訊：

最後寫入資料庫後資訊，可以看到14：23：41秒測試，14：23：49秒插入資料庫。

透過Phpinfo 這個關鍵字匹配到的資訊如下：

• 資料視覺化：

透過基礎的資料分析可以將結果繪成圖，這樣做的好處可以將攻擊的監控時間段拉長不在拘泥於單一的資料庫查詢，當然不是為了視覺化而視覺化這就失去不 了了其意義，視覺化的目的是為了運營需要。

表不如圖，要做的足夠好就應該考慮使用者體驗，但這樣的視覺化是有用的嗎？

答案未必，視覺化的目標是為了讓別人清晰的看出來你所做的資料分析的真諦。

• 資料儲存：

資料分析後，需要有針對性的儲存，以備後續聯合分析，資料儲存主要採用離線和實時，實時主要是提供一天內的攻擊趨勢展現。

• 資料分析：（重點）

透過將這些規則的檢查結果寫入資料庫，透過資料庫查詢方式將日誌篩選，提煉出攻擊時間，攻擊ip，攻擊次數，ip來源歸屬地以及一天有哪些時間段攻擊最多，由此可以給駭客畫一張活動軌跡圖。

判斷駭客的技術能力，是否是常客，以及作案動機是什麼，但比較悲觀的是即使分析了這些，對於攻擊行為還是需要採取一定的行為，比如把前top20 提取出來封掉。

其次就是攻擊行為是否可進一步分析？如果只是這樣分析是人人都會的，需要將這些資料結合漏洞來分析比如出現個shellshock漏洞，php cgi遠端程式碼執行漏洞是否能發現？經過一段時間內的分析是可以總結個趨勢的。

這一切的重點是特徵、關鍵字，透過關鍵字勢識別，就像識別你是胖的、瘦的、高的、矮的一樣，先將你以類別區分出來，然後進行分析。

分析的前提是，先建立表，你想做啥查詢，資料庫表結構需要設定好，比如：

這裡，我們關心的資訊是：攻擊日誌、攻擊payload、攻擊方法、攻擊返回狀態、攻擊ip、攻擊者瀏覽器指紋。

• 確定分析範圍：

需要確定想找到哪些問題？sql注入、xss、檔案包含、目錄遍歷、爆破、各種掃描器掃描。將這些資訊彙集後，寫入到規則中，透過storm實時計算，運算一段時間我們就會得到各種各樣的資料，有了分析的基本樣本。

分析，其實就是個彙總的過程，使用mysql就可以完成。

我們所有的分析都是從安全的角度來進行的，所以看看大家感興趣的內容，有哪些user_agent？這裡是awvs的掃描器指紋

各種各樣的各種掃描資料：

從資料分析上來看，攻擊者似乎對discuz的.bak檔案情有獨鍾。又或者，我們來看看攻擊者最熱衷哪些phpmyadmin？

以及各種各樣的xss：

以及我們熟悉的struts2？

等等這些都是有特徵，可被查詢到的，查詢到了其實不是目標，我們的目標是能不能在智慧點？

因為很多的攻擊資料，都是無意義的，怎麼從這些當中篩選出真正的危險，這部分是自動化測試的範疇，這裡先不講。

透過對這些資料的分析，可以比較輕易的知道有哪些東西是攻擊者感興趣的，以及市面上是否出現了1day被大規模利用。

0x02：未來：

---

日誌分析的未來，一定是以資料為前提的，透過機器學習和資料探勘演算法來實現對日誌及攻擊趨勢的預測。

最後日誌分析是個不斷進化的過程，不斷修煉。

資料庫層面的壓力比較大，使用Mysql對於千萬級別的資料庫查詢有點不太適合，後續會考慮hbase等來處理。

以及考慮到使用諸如：貝葉斯演算法來對歷史資料進行評分及策略調整。