Web攻擊日誌分析的過去如今與將來

　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等來處理。

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