談到日志分析大多數人的感覺是這是一個事后行為，場景當黑客成功將網站黑了。運營人員發現的時候安全人員會介入分析入侵原因，通過分析黑客攻擊行為往往會回溯最近幾天甚至更加久遠的日志。
個人認為日志分析的過程分為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被大規模利用。
日志分析的未來，一定是以數據為前提的，通過機器學習和數據挖掘算法來實現對日志及攻擊趨勢的預測。
最后日志分析是個不斷進化的過程，不斷修煉。
數據庫層面的壓力比較大，使用Mysql對于千萬級別的數據庫查詢有點不太適合，后續會考慮hbase等來處理。
以及考慮到使用諸如：貝葉斯算法來對歷史數據進行評分及策略調整。