在大數據應用普及以及資訊安全上升為國家高度後，資訊安全能力落地的挑戰日益增多。一方面，企業內部的安全體系架構日益複雜，各式各樣的安全數據越來越多，傳統分析方法難以奏效。另一方面，傳統分析方法無法有效的檢測新型攻擊手法。同時，在大數據時代下對威脅的判斷以及響應有著更高的要求。為此，本文介紹如何通過開源組件搭建一個大資料安全分析平臺，並且分享部分相關經驗。本文主要從以下六個方面進行介紹：

1.平臺框架

2.資料庫設計

3.離線數據準備

4.Python2->3的陞級

5.歸一化注意事項

6.安全分析準備

在日誌管理方面有一套較為成熟方案就是ELK。ELK並不是指一個軟件，而是指三個軟件的組合：

E是指Elasticsearch，其主要負責日誌的檢索和分析。

L是指Logstash，其主要負責日誌的收集、處理和存儲。

k是指kibana，主要負責日誌的視覺化。

但如果直接採用上述所說的ELK來搭建大資料安全分析平臺會存在一定的不足，囙此我們需要對其進行一定的修改。

加入kafka

講解為什麼加入kafka之前，我們先瞭解下kafka是用來幹什麼的。Kafka用比較官方的話是具有高併發能力的一個消息隊列或消息分發系統。如果官方的解釋無法理解，那麼請記住下麵的解釋：kafka是讓合適的數據以合適的形式出現在合適的地方。

在大資料安全分析平臺中我們需要一個規則引擎來做實时檢測（後面會介紹規則引擎），而在規則引擎中常常需要檢測時序的數據，囙此對數據有著一定的要求。所以才需要引入kafka這個能讓數據以合適的形式出現在合適的地方的組件。

瞭解了kafka是幹什麼和為什麼加入kafka之後我們需要瞭解下一個問題：kafka這個組件應該放在框架中的哪個地方呢？在回答這個問題之前我們可以先簡單瞭解下kafka的架構圖：

通過上面圖可以發現Kafka本質的工作是獲取數據然後再把數據吐出去。而且上面我們提到過平臺中是需要一個規則引擎做實时分析的，並且ELK中的Logstash是用來收集日誌用的。囙此我們可以把新加入的kafka放在logstash之後，規則引擎之前。這樣做既可以以高容錯的管道存儲海量的數據，同時又可以保證數據的順序性。

規則引擎

首先要介紹這裡提及的規則引擎的概念：運行檢測規則的實时計算引擎。在大資料安全分析平臺中，我們需要對實时收集到的日誌進行檢測，一旦滿足某種規則就產生對應的安全事件或安全告警。這對於處理時間有著有著較高的要求：近乎實时，囙此我們需要在平臺中加入實时計算引擎。

而在實时計算引擎科技中比較成熟的是Flink以及Spark，這裡選用Flink作為我們的引擎，原因可以參考下麵對兩者之間的簡單對比：

Flink

• 流式處理，延遲較小，輸送量大。

流式處理，延遲較小，輸送量大。

• 提供狀態管理，可以保存和更新狀態資訊。

提供狀態管理，可以保存和更新狀態資訊。

• 一定容錯性，出現故障後可以從離開的位置再次開始處理。

一定容錯性，出現故障後可以從離開的位置再次開始處理。

• 提供事件時間處理，視窗等功能，保證處理複雜需求的功能。

提供事件時間處理，視窗等功能，保證處理複雜需求的功能。

Spark

• 基於微批次處理的流處理（並不滿足低延時需求）。

基於微批次處理的流處理（並不滿足低延時需求）。

• 同樣支持容錯性。

同樣支持容錯性。

• 同樣支持高吞吐。

同樣支持高吞吐。

• 調參較為麻煩。

調參較為麻煩。

• 高級功能並不十分豐富。

高級功能並不十分豐富。

看完上述的簡單對比應該明白為什麼採用flink作為我們的規則引擎。這時候就又要思考另一個問題了：規則引擎應該放在平臺的哪個位置。其實答案很簡單，因為之前說過規則引擎的作用是檢測收集到的日誌然後生成安全事件或者安全告警，而安全事件或告警最終是要存入到ES資料庫中的。囙此規則引擎的位置應該是在ES資料庫之前，kafka之後的。

至此，整個大資料安全分析平臺的總體框架就出來了，如下圖所示：

在上面平臺框架中我們可以看到只是用了Elasticsearch資料庫，是不是意味著在實際使用的過程中就不需要用到其他的資料庫呢？答案是否定的，同樣需要使用MySQL這類的關係型數據庫。

本章節的主要目的是簡單介紹在配寘ES資料庫和設計MySQL錶時的相關注意事項，因為錯誤的配寘或者錶設計往往會導致資料庫的效能降低以及帶來難以言喻的使用體驗。

Elasticsearch

在Elasticsearch中是把數據存放在一條條索引下的，囙此如何設計一個索引非常重要。根據筆者日常使用和觀察後總結為：

1.根據類型設定索引

大數據平臺的資料來源類型眾多，如防火牆、IPS、主機端數據等。囙此根據資料來源的類型進行索引設計不僅能够簡單的進行索引區分，更能够讓使用者快速上手。如保存A防火牆數據的索引名可以為“logstash-wafA”，保存終端數據的索引名可以為“logstash-endpoint”。

2.根據時間或固定時間內的大小進行設定

根據時間建立索引，時間可以是一天或是以一個月為週期。但具體是設定為一天還是一個月則要根據對應數據的大小進行確定。像是上述提及到的安全事件和安全告警概念，兩者的區別是：安全告警是安全事件的進一步選取產物，安全事件是直接從原始日誌中選取的結果。根據安全告警和安全事件的關係可以得出結論：同一段事件內產生的安全告警數的確比安全事件少。囙此安全告警相比安全事件而言更加適合以月為週期建立索引。

另外，在Elasticsearch中對欄位進行蒐索的前提是在配寘中把該欄位寫入到索引中。通常寫入索引中的欄位有src_ip（源ip）、dst_ip（目的ip）、hostname（主機名）等常見欄位，但在實際使用過程中往往需要對某些沒有開啟檢索功能的欄位進行蒐索。這時候就給分析帶來一定的挑戰性：無法進行快速檢索或不得不使用其他的欄位或搜索條件進行蒐索。而在Elasticsearch中如果開啟太多欄位進行蒐索或蒐索欄位中的內容太冗長往往會導致效能的下降。囙此哪些欄位開啟搜索功能需要謹慎考慮，爭取效能和功能之間得到平衡。

MySQL

實際中通常是把用戶的租戶資訊、身份關係等資料存放在MySQL的錶中，而日常開發過程中往往是隨著需求的變多而導致錶數目的增多以及錶之間的關係變得複雜，這同樣對後續分析帶來了一定的困難。

對於安全分析而言，更多的工作重心是對安全事件、告警進行分析然後進行響應。此時往往需要用到MySQL中的一些數據，儘管雖然有相關現成的介面可以獲取到某些資訊但更多時候不得不手動進行査詢以獲取真正想要的資訊。這時候過多的錶數量以及複雜的錶關係將會導致花費大量的時間在此，從而導致降低分析的效率。

假設這樣一個場景，需要獲取兩個資產出現的同樣類型的告警，而這兩個資產又分別在不同的網段和業務分組中，同時資產名字、資產網段資訊和資產業務分組資訊又分別存放在獨立的錶中，這是就需要先查看多張錶的資料結構然後進行聯合査詢，最後再根據獲取到的資訊進行告警査詢。分析上述的這個場景可以發現時間大部分都浪費在了獲取錶的相關資訊中，從而大大减少了用於進行分析的時間。囙此，實際情況中我們需要對錶的數量以及錶之間的關係進行一定程度的控制。

在實際中面臨著這樣一種情况：大資料安全分析平臺可能放置在無法訪問外網的環境中，而平臺中的部分功能卻又依賴於外部的數據。面對這種可能出現的情况就需要提前準備離線數據，這種類型的數據包括但不限於：IP地理位置、威脅情報、漏洞資訊等。

現有的大資料安全分析平臺針對上述所說的數據都有著自家的離線版本，囙此本章在這主要介紹如何通過開源手段進行離線數據收集。

IP地理位置

在對ip進行分析時一個較為重要的名額就是這個ip的歸屬地，囙此很有必要擁有能進行査詢ip地理位置歸屬地的資料庫。而關於ip地址庫的開源工具中，較為有名的莫過於ip2region這個工具。

對於ip2region工具的如何使用這裡並不作過多的介紹，只需要知道這個工具的提點有以下幾點便可：

1.標準化數據格式

2.資料庫檔案體積小

3.支持多用戶端査詢

4.査詢速度極快

威脅情報

威脅情報能够揭示不同攻擊者的攻擊手段以及攻擊之間的相互關係，同時又可以為安全事件/安全告警中的相關可疑項進行實錘，正因為有著這樣的優點最近幾年來這個概念非常火熱，正因如此一個優秀的安全分析平臺該功能是必不可缺的。

在開源的威脅情報中，比較著名的莫過於MISP了。MISP的中文名稱為：開源威脅情報和共亯平臺，正如其名MISP可以用於收集、存儲、分發和共亯有關安全事件分析和惡意分析的網路安全名額和威脅。同樣這裡省略該工具的使用方法，只是略為介紹該工具的優點：

1.支持多種形式的數據導入、匯出功能，這大大方便了和其他工具的聯動性。

2.靈活的api，這說明可以快速上手、對接該工具。

3.豐富的IOC名額，這有助於提高發現風險的概率。

漏洞資訊

獲取漏洞資訊這在傳統安全時代就已經非常重要了，如今在資料分析平臺中更是必不可缺的部分。這裡推薦OpenVAS這一款工具來獲取漏洞資訊，其中文名是開放式漏洞評估系統，對於這款工具不熟悉的人只需要知道它是商業漏掃工具Nessus的開源版本即可。該工具最大的優點有兩個，第一個是該工具以及其漏洞資料庫定時更新，囙此不用擔心某天出現“斷糧”的情况，另一個優點則是該工具所包含的漏洞資訊是較為全面的，但畢竟是開源軟件總有著它的局限性。

時間已經來到了2020年，正是今年是Python2版本停止進行維護而Python2和3之間的程式碼並不相容，囙此如果此時繼續使用2版本進行開發的話會為以後留下很多的問題。而實際上從Python2陞級到3中往往會有很多坑的存在，在此簡單總結如下：

1.升級後缺少動態連結程式庫檔案

在編譯安裝Python3後發現系統中缺少相關動態連結程式庫檔案而產生相關報錯資訊，但經過排查發現系統中卻存在該檔案，並且根據報錯資訊的提示需要我們更改gcc的相關配寘。但gcc所涉及的東西較多，一旦修改很可能導致系統中產生其他未知的錯誤，囙此需要在不修改gcc配寘的情况下進行修復。在經過多方測試和査詢資料後發現可以通過創建軟連結的管道進行處理。

2.升級後依賴Python2導致死迴圈

在實際中往往會遇到一種比較搞笑的情况就是：Python版本陞級為3後，運行yum或部分相關命令時提示你需要運行在版本2下。這種情況下網上給出的修復方案有很多，但有些修復方案如卸載版本2直接創建版本3的軟鏈卻會造成死迴圈的可能性。因為yum本身是基於python2開發的，一旦卸載後再重新安裝則會導致yum的不可用，要是想使用yum還得重新把python2進行安裝。建議在測試相關陞級方案時在測試環境中進行測試，並確保沒有錯誤的情况下再在生產環境中使用。

3.升級後沒有相關的協力廠商庫

Python是以豐富的協力廠商庫而出名的，如果一旦出現版本2中有某一個協力廠商庫而版本3中沒有對應的庫或對應庫的功能不及版本2時，這就變成了一個較為頭疼的問題：要麼放弃該庫，要麼自己手動的對版本2的程式碼改造陞級為版本3的程式碼。經過踩坑發現，比較高性價比的方法是採用相容的寫法。採用相容的寫法雖然也需要進行程式碼的改動，但改動量相比較少可以接受。同時也存在使用腳本把程式碼從版本2陞級為3的效果，但使用腳本進行陞級仍然可能會在實際運行中出錯，建議進行多次測試。

先簡單介紹歸一化的概念：把不同格式日誌中的欄位映射到統一標準中。

在進行大資料安全分析平臺時往往需要把不同設備、不同格式的日誌進行收集，而日誌中往往包含著大量有用的欄位值。但不同日誌之間對於同一個數據的名稱可能是不一樣，囙此需要把他們映射到相同欄位中。但在實際的使用中可能存在國內設備和國外設備同時使用的情况，這就導致日誌格式甚至日誌欄位名相差較大的情况。這個時候最簡單的做法就是除了功能效果相同的欄位以外其餘的欄位採用並集的方法進行囊括，這樣就不用擔心出現該欄位時無法進行映射的問題。

該做法的確是通用、可行的辦法，但卻會對安全分析時帶來一定的困難：

1.通過查看映射後的標準你可以發現標準中存在很多有用的欄位，但實際上日誌中並沒有提供該值。

這種情況往往會導致：如果想要把分析經驗固化為腳本時，往往需要編寫多個腳本：一個腳本可能是該欄位值存在時使用，另一個腳本則為該值不存在時使用。久而久之這樣的處理腳本會增多，最終出現難以維護的情况。

並且也會給人工分析帶來一定的麻煩：在進行日誌資訊關聯的時候必須先查看該欄位是否有值，如果沒有值時只能通過ip等基本元資訊進行關聯。但在複雜環境中，ip這樣的元資訊存在相同的情况（多網段情况下就可能存在ip一樣的情况），囙此稍不注意就可能得出錯誤的結果。

2.映射後的欄位值越多，越容易存在名字相近或含義相近而導致的使用錯誤情况。

以常見的http日誌中記錄的URL為例，在歸一化映射後的標準中可能存在相關欄位名稱為：xxxURL、URLxxx、interface、http.URL，面對類型名字相近或含義相近的欄位名往往需要先查閱相關說明檔案才能確定不同欄位值之間的含義；而想獲取某方面功能的欄位時同樣也需要輸入相關關鍵字，然後再從匹配結果中進行一個個的査詢，最終才能獲取到想要的結果（儘管該欄位往往沒有值存在）。

囙此，做歸一化的確是一件好事，但是否需要過多的歸一化後的欄位這需要我們去進行思考和實際測試了。

上面的幾部分都是搭建安全分析平臺以及相關踩坑的經驗分享，接下來這部分則是介紹使用該平臺進行分析前所需要做的準備工作。

基礎工作

1.熟悉Elasticsearch語法

上面提到Elasticsearch是用於日誌檢索和分析用的，它有著它一套的査詢語法，囙此事先掌握它的語法能够很好的提升分析效率和速度。簡單歸納了以下常用、簡單的査詢語法：

• 多條件值査詢在實際分析過程中，往往需要對滿足多個條件的結果進行査詢，囙此很有必要掌握多條件值査詢語法。

多條件值査詢

在實際分析過程中，往往需要對滿足多個條件的結果進行査詢，囙此很有必要掌握多條件值査詢語法。

• 模糊查詢同樣，在分析過程中可能會針對攻擊手法進行某些關鍵字的査詢，這個時候模糊查詢就非常有效，它可以快速的把相關可能的結果收集起來。

模糊查詢

同樣，在分析過程中可能會針對攻擊手法進行某些關鍵字的査詢，這個時候模糊查詢就非常有效，它可以快速的把相關可能的結果收集起來。

• 範圍査詢在實際過程中往往需要根據欄位值來匹配相關範圍內的結果，這個時候就需要用到範圍査詢。

範圍査詢

在實際過程中往往需要根據欄位值來匹配相關範圍內的結果，這個時候就需要用到範圍査詢。

2.熟悉常見日誌欄位值

使用安全分析平臺時往往要和各種各種的日誌打交道，囙此很有必要熟悉日誌中的欄位名以及欄位值含義。這樣在進行分析時能够快速從日誌中選取到自己想要的欄位，從而大大提升分析效率。

3.熟悉關聯引擎規則

關聯引擎可以幫我們產生一定的安全事件或告警，囙此只有在熟悉關聯引擎規則的情况下才能在產生事件/告警時明白問題的嚴重性以及發展到哪一步程度，這樣就能够為接下來的分析和處理流程提供一定的導向作用。

熟悉環境

1.瞭解網絡拓撲結構

不同的網路環境所受到的攻擊手法以及所暴露的攻擊面都是不一樣的，囙此在進行分析之前很有必要瞭解當前網路拓撲架構。只有一個內外網出入口的環境一旦被攻擊成功，攻擊痕迹往往在出入口中都會被記錄。而如果具有多個內外網出入口的環境被攻擊成功進行分析就較為困難了，往往需要對攻擊手法、暴露的風險點等特徵進行分析取證後才能確認整個的攻擊流程。

2.瞭解資產分佈、分類情况

對環境中的資產分佈、分類情况有一定的瞭解能够幫我們快速的判斷相關安全事件或告警到底是否為誤報。比如一個DNS伺服器產生的http攻擊事件/告警很大可能就是誤報；一個內網服務器中產生的病毒木馬告警則表明很有可能已經被攻擊者攻擊成功了。

3.瞭解歷史安全問題

瞭解系統中的歷史安全問題往往能給我們進行分析排查提供一定的思路：是舊的漏洞修復不完整導致的攻擊成功？還是攻擊者以前就已經留下木馬後門呢？同時還能揭示該系統的脆弱性存在哪個地方，以便為後續的相關修復工作做準備。

七、總結

本文先是簡單介紹了如何通過開源組件簡易的搭建一個大資料安全分析平臺，然後分享了部分搭建以及數據準備經驗，最後引出安全分析的相關必備技能。

本章只是我們：如何利用那個大數據平臺進行安全運營的開篇章節，後續會分享如何利用大數據平臺進行安全告警分析、攻擊溯源以及攻擊確認的經驗，有興趣的朋友們可以留意後續更新。

PS：文章作者只是一名安全工程師，並不是一名後臺開發人員。囙此上述內容中可能存在部分偏差，請大家原諒並謝謝指點。

該帳號主要圍繞智能化科技如何幫助企業提升網路安全水准展開，內容涉及機器學習、大資料處理等智能化科技在安全領域的實踐經驗分享，業界領先的產品和前沿趨勢的解讀分析等。通過分享、交流，推動安全智慧的落地、應用。歡迎關注~