**：
在乙個嘈雜的環境中，怎樣才能盡可能的發現異常？不外乎黑白名單。
黑名單，又可以總結出兩種方式：
1.基於特徵的檢測，2.基於行為的檢測基於行為，是一種較為複雜的方式，是通過數學統計的方式來尋找異常，通過模式學習來尋找異常，但缺點是準確度不確定，可以做到很高，但誤報率也很高。
為了能夠防範未知漏洞和實時性的要求，同時能夠靈活變通，我開始建立以hadoop，mongodb，python為基礎的大資料分析平台，用來從公司的流量以及web日誌中進行資料探勘。
在進行了一段時間的思考和調研後，初步確定了下面的架構：
採集部分：
統計分析模組：
m/r python 分析程式-》hdfsm/r python 過濾-》 hdfsm/r python 規則-》mongodbphp jquery -》監控平台ips掃瞄器
防火牆
通過這個架構，可以讓我對整個公司web應用的訪問情況，伺服器的負載情況，攻擊情況，異常訪問進行直觀的展示。
同時為整個網際網路區域提供基礎的分析平台。
由於公司使用的是iis，所以在採集的時候遇到了一些困難：
1.flume在linux下工作良好，但是在windows下用的人相對較少，版本也不夠新；
2.iis日誌格式較為複雜，乙個日誌目錄下，多個子站點的資料夾，每個資料夾的名字是隨機的，並且設定了日誌切分，檔案會不斷重新整理，而flume的日誌採集是基於tail的；
3.windows下的tail(gnu32)工作不穩定，出現各種崩潰錯誤。
為了解決這些問題，需要對flume進行一些配置和編寫自己的程式。
1)使用靜態編譯的flume1.31-bin版本，測試過後發現沒問題。
2)編寫了pathtail.py，編譯成exe來代替tail.exe，兼顧目錄監控，同時整合所有的web日誌成乙個flume程序輸出，還可以跟蹤最新的日誌檔案。。
3)將flume打包註冊成service，方便管理。
4.擴充套件pathtail.py,編寫監控模組，用來監控實時的訪問流量和負載。
為了實現iis日誌的準實時性分析，需要計算每分鐘負載，設定每天高峰交易時間為早上8點至晚上9點，共13個小時，計算得到每5分鐘負載約為：180g/24*13/60*5 約為10g。
根據目前在實驗環境進行的測試得結果：
計算節點數量
計算量消耗時間
結果統計
總耗時3
73.5g
約15分鐘
約30秒
約16分鐘
推測計算時間為：
計算節點數量
計算量消耗時間
結果統計
總耗時3
10g約3分鐘
約10秒
約4分鐘
勉強能夠完成任務。
因此為了保證實時性，計畫部署的初期hadoop集群為：
計算節點數量
計算量消耗時間
結果統計
總耗時6
10g約3分鐘
約10秒
約4分鐘
**在這裡
flume 配置
根據flume的配置，我們將iis的日誌進行一分鐘切割，按照每分鐘乙個資料夾，每個資料夾按照10秒鐘/128m檔案進行切割，然後通過m/r框架，對資料夾的日誌進行1初步統計分析。這裡的統計內容為日誌內字段的關聯結果。
iis的日誌字段，根據配置的不同，可以多達22個字段，分別是：
date：發出請求時候的日期。time：發出請求時候的時間。
注意：預設情況下這個時間是格林威治時間，比我們的北京時間晚8個小時，下面有說明。
cs-username：使用者名稱，訪問伺服器的已經過驗證使用者的名稱，匿名使用者用連線符-表示。
s-sitename：服務名，記錄當記錄事件執行於客戶端上的internet服務的名稱和例項的編號。
s-computername：伺服器的名稱。
s-port：為服務配置的伺服器端口號。
cs-method：請求中使用的http方法，get/post。
cs-uri-stem：uri資源，記錄做為操作目標的統一資源識別符號（uri），即訪問的頁面檔案。
sc-status：協議狀態，記錄http狀態**，200表示成功，403表示沒有許可權，404表示找不到該頁面，具體說明在下面。
sc-substatus：協議子狀態，記錄http子狀態**。
sc-win32-status：win32狀態，記錄windows狀態**。
sc-bytes：伺服器傳送的位元組數。
cs-bytes：伺服器接受的位元組數。
time-taken：記錄操作所花費的時間，單位是毫秒。
cs-version：記錄客戶端使用的協議版本，http或者ftp。
cs(user-agent)：使用者**，客戶端瀏覽器、作業系統等情況。
cs(cookie)：記錄傳送或者接受的cookies內容，沒有的話則以連線符-表示。
乙個簡單的例子：
從iis欄位中，我們選取幾個要素ip，返回碼，訪問url，即
c-ip,sc-status,cs-uri-stem如果對這三個字段進行分別統計分析，我們可能可以得到一定時間範圍內，伺服器的訪問情況，url請求情況，返回碼情況，是無法檢測出一定異常的，因此我會對這三個字段進行關聯分析，如：
1.每個ip在訪問伺服器的時候，他的狀態碼比例是如何的，如果是相同的業務訪問，狀態碼的比例波動應該變化不大
2.對於乙個ip，訪問的url應該是離散的，而不是聚合（收束）的，就是說，如果出現乙個ip訪問特定的幾個url的頻率很高，那麼很有可能這個就是個採集器，或者正在進行漏洞的驗證。
3.對於特定的url，其相關請求，如url之間的關聯關係，應該是類似的，因為所有頁面請求基本有一樣，同理同樣的url請求，它的狀態碼應該也是一樣的，不應該出現較大波動，比如訪問index.aspx,那肯定會訪問index.css,如果沒有，那可能就是自動化提交的工具。
4.url的rank值在很大程度上也是有規律的，即ip使用者的入口點是有規律的，在總結了所有的高可能性入口點後，如果出現某個ip突然訪問乙個新的入口點，那麼這個ip可能是被xss或者csrf或者是webshell。
我們對iis日誌的所有22個字段都進行了這樣的單獨分析和關聯分析，通過1維，二維，三維，多維的關聯，進行統計分析，得出異常行為和使用者的訪問模式，變成外掛程式的形式加載入m/r框架進行分析。
**例子
專案還在進行中，後續會不斷更新進展..
大資料時代，我們安全嗎？
大資料時代，世界各地新鮮事一觸便知，技術越發達，生活就越便利。我們能隨時知曉自己喜歡的歌星要在 開演唱會，能隨時搜尋到偶像的歌曲，當然啦，最喜歡的影視明星，搜一搜就有有有啦 看著新聞，吃著瓜，時事熱點在眼前。某酒店5億條資料洩露，哦，還好我不住酒店。等等，什麼？1000餘萬份快遞客戶資料被盜，16萬...
我們怎樣確保從大資料計算中獲得價值
我們怎樣確保從大資料計算中獲得價值 支援大資料方案並不是在硬體以及軟體層次終止，企業要想真正地從大資料中受益，領導者必須改變思考與對待資訊的方式。我們怎樣確保從大資料計算中獲得價值？當所有可用資料都可用時，大資料分析給出了最佳結果。企業領導者通常存放他們認為重要的資料 一般叫做 資料囤積 囤積使大資...
大資料場景 使用者行為日誌分析
使用者日誌 訪問的系統屬性 作業系統 瀏覽器型別 訪問資訊 session id，訪問ip 資料處理 有資料者有未來，有資料意味著每乙份使用者行為資料都是寶貴的資源。經過資料清洗，再用演算法提取分析，商業價值，商業決策 線上推廣 等等 當然一切建立在有大量使用者有流量的情況下的。資料處理流程 資料採...