頭條楓林網
文章摘要： 0×04 威脅分析處理 既然威脅分析系統也是信息系統的一種可以把資料與我們的威脅特徵庫進行比較分析
* 本文作者：xsecurity，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載
0×01 概要
開源日誌系統分析很常見， 現在基於開源中介軟體可以很有效的搭建日誌中心，處理各種資料的收集與分析。 日誌系統也是信息系統，從軟體工程的角度來看和一般的信息系統有很多類似的地方，我們可以從伺服器物理部署的角度來解釋這種系統，這種更多的是從運維角度來看，我們也可以從軟件系統構成的角度來分析，也可以從數據流向看系統。我們這次把物理部署和軟體邏輯系統放到一起，展示出整個系統的數據流向，資料儲存和處理邏輯，也展示了從系統設計到外掛工廠的實現邏輯。
0×02 需求
現實的需求很簡單，就是從我們要從收集到日誌資料中，分析各種可能存在威脅，按照高中低危進行報警，並統計威脅資料，進行報警與後續動作。
簡化威脅定義表同，如下：
SRC_IP,DST_IP,LEVEL,TYPE 192.168.1,192.168.6,high,php_injection 192.168.1,192.168.6,middle,xss_injection 192.168.1,192.168.6,low,sql_injection
整個系統要做的就是：
1.資料收集：生產中很多伺服器的日誌和狀態資料，我們都可以拿來分析。如果是nginx伺服器，我們可以通過訪問日誌發現訪問中的威脅，如果部署有HIDS，我們可以分析單機伺服器的狀態，並與長期聚合的白名單進行比對，發現威脅。 2.資料清洗：實際我們收集了大量的各種日誌資料，這些資料，我們不能直接拿來用，初級階段的日誌分析和簡單查詢可以做到，之後，我們需要對資料的格式進行整形，如果進行威脅分析，就要把大量不關鍵的資訊清洗掉。 3.威脅分析：我們的資料在先期經過了整型和規範化後，可以把資料與我們的威脅特徵庫進行比較分析，用我們積累的威脅特徵庫來威脅判斷，發現數據中是否存在異常的威脅行為存在。 4.威脅展示：經過資料的清洗與威脅初步判斷，我們找出了，存在於日常中日誌中的威脅行為，我們需要對這些資料，按優先順序，威脅高低程度顯現，給安裝安全運維人員使用。 5.威脅報警：在實際的工作中，會有各種威脅報警產生，但是真正危害到系統的關鍵性威脅，是有一個優先層級的，我們往往把優先順序高，危害大的威脅行為，第一時間通知管理人員，比如：生產伺服器發生與危險主機的外連通訊，伺服器產生了，根本不該產生的SQL注入行為。
0×03 資料收集與儲存
我們儘量從現有的生產環境中，取得對我們來說有用的資料來源資訊，前期開源工具起動很大的作用，比如，我們用nxlog、filebeat之類的工具在服務上架設資料agent，架設syslog server伺服器，使用共享ES資料叢集， 在這個階段我們關注資料來源來源，資料內容，接受的方式，部署資料agent的平臺環境，這是構建資料日誌信息系統必經的一條路。
資料儲存：
1.Syslog伺服器： Syslog是基於UDP協議的，很多裝置都支援syslog日誌傳送，生產中有很多nginx為基礎的web應用，nginx也可以傳送syslog格式的日誌。 2.ES資料庫伺服器叢集：ES對於存JSON形式的資料非常友好，我們可以把syslog資料進行資料整形存到ES中。 3.Kafka佇列：有時資料IO特別大時，需要一個快取來存資料，然後再消費到ES或是ClickHouse中。 4.ClickHouse：ClickHouse支援大資料儲存，可以支援SQL查詢。 5.MongoDB：這種KV資料庫幾乎也是要用的，用於存放共享配置資訊。 6.Graylog資料閘道器：如果我們支援通過HTTP介面去ES中取資料，要處理跨index的查詢，而實際當中，如果可以把ES的操作按業務單元再抽象出一層，把對業務資料的操作，歸併成大類的REST API操作，會讓處理邏輯更清晰，更好維護，這種情況下，Graylog提供的REST服務就為我們解決了這個問題，Graylog提供了原始資料「流」資料組織的跨越，具體的此處不細說。
資料收集：
1.NxLog：Nxlog是支援跨平臺的系統級日誌收集，我們可以在Windows好部署Nxlog解決特定日誌的收集問題。 2.CatKafka：catkafka可以把本地落地的日起文字推送到kafka佇列中，然後從佇列中消費到ES或是ClickHouse中。 3.Logger：這個就是把文字放到syslog伺服器接受埠。 4.Filebeat：把文字內容發到ES中。
0×04 威脅分析處理
既然威脅分析系統也是信息系統的一種，我們把重點放在，如果對系統劃分，如果對接，如果組織和設計程式單體這些點上。如果，我們系統是基於ES為資料庫為基礎核心，或是Graylog這種提供了REST API的資料查詢介面服務的系統，我們可以很簡單的劃分組織資料，通過一套REST API就可以取得我們想要的日誌資料。日誌資料有了，如何識別日誌中是否有威脅行為，就是要針對不同的資料來源做分析工作，就是構建整威脅分析系統的大腦靈魂部分，我們要有根有據的識別出那些資料是有問題的， 威脅分析過程如下：
1.取特定業務資料來源的資料。->2.與威脅規則庫進行比較。->3.判斷結果根據黑白名單。->4.進行威脅定級。->5.生成威脅報告。
完成這些事，關鍵的3個點：
1.資料來源：沒有資料來源無從進行分析。 2.判斷策略：對威脅和異常的定義，是我們判斷的主要依據，實際生產中，有各種威脅，這種威脅的定義都是不一樣，我們只有有這種對異常的判斷依據，才能分析出什麼是問題行為。 3.黑白名單：威脅報警噪音，各種系統和裝置的誤報其實是一直存在，我們實際事況也很複雜，應對誤報比較有效的一種方式，就是構建黑白名單機制，把明顯的誤報都放到白名單裡，把特別需要注意的，出現過問題的服務列表放到黑名單裡。
資料分析：
從軟件系統設計的角度來看，3個角度來分析信息系統：
1.架構設計：整體的架構設計很明瞭，基於ES和ClickHouse為資料儲存核心，圍繞核心寫子系統。 2.概要設計： 如果非系統的概要級描述， 從技術角度來看，我們採用外掛方式組織模組，從業務上來講，SQL注入和PHP注入的關聯性是不大的，我們採用外掛的方式也是爲了解開模組間的耦合關係。 3.單元外掛設計： 體現出單體設計大不同，可以從單體類的介面設計和目錄構成來區分。
0×05 模組單體設計
1.單體設計：
模組物件介面設計：爲了使用類工廠集中排程模組，我們預定了外掛模組必須要有介面函式。
/*定義單體可處理的輸入資料*/
class input_data {
string src_ip,
string dst_ip,
string payload
};
/*定義單體輸出的資料型態*/
class output_data {
string src_ip,
string dst_ip,
string payload,
int level
};
class xxx_Injection {
vritual int Init(void); // 負責所有相關外部資料資源的獲取和黑白名單的設定。
virtual output_data* main(input_data *message); // 主要的威脅判斷和特徵判斷。
virtual int fin(void); // 釋放相關資源
};
2.目錄構成設計
我們除去預定的介面，同時約定了外掛目錄結構構成。
lib、src、data、config資料夾，Makefile、run.sh、logs三個檔案。 lib資料夾：所有的特徵庫都在這裏，比如libInjection這個庫。 src資料夾：外掛的原始碼。 data資料夾：單體測試用的CSV檔案。 config資料夾：黑白名單配置檔案。 Makefile檔案：單體配置檔案。 run.sh檔案：執行指令碼。 logs檔案：除錯日誌。
3.程式碼實現。
有了特徵庫，預定了介面，剩下就是具體的編碼，這個因專案和資料業務而不同，佔不展示。
0×06 威脅報表與報警
整個系統起到點睛作用的部分就是威脅報告輸出，最開始我們簡單的約定了威脅輸出了的格式：
1.威脅輸出格式。
SRC_IP,DST_IP,LEVEL,TYPE 192.168.1,192.168.6,high,php_injection 192.168.1,192.168.6,middle,xss_injection 192.168.1,192.168.6,low,sql_injection
如果是在ClickHouse生產系統中建立威脅表格要比這個多，欄位和展現的資料聚合是有關係的，我們簡單的舉例一下：
SRC_IP：攻擊IP，是誰發起的IP，我們可以對應IP在表中產生地理位置資訊，典型的報表形式就是用於地圖跑。攻擊IP是可以威脅情報進行比對的。 DST_IP：被攻擊IP，具體那個伺服器被攻擊，一般的公司都有伺服器管理的CMDB資料庫，可以在生成報告時，直接找到對應的IDC、機房、管理員。 LEVEL：威脅級別，高中代危，看黑白名單和特徵庫的定級。 TYPE：具體是什麼威脅，比如：SQL注入、XSS注入、PHP注入。
2.威脅報告的形式。
郵件： 每天早上傳送昨天的攻擊總結日報告、週報告、月報告等。被威脅IP的top10、被攻擊總數top10、威脅聚合分佈。
實時報告：提供實時查詢介面，直接給出ClickHouse威脅情報的聚合資訊，實時查詢掛在牆上。
0×07 總結
目前我們把一個基於開源技術的微型日誌威脅分析系統介紹完了，並沒給出更具體的實現程式碼，更多的為基礎部署架構和設計方式提代了一個思路，具體到包括單體介面實現的約定，理想狀態下，按照這種模式寫出的模組的大同小異，我們這麼預定也是爲了後續系統擴充套件和除錯更方便。如果有人不太喜歡這種方式，其實也是沒有問題，一定會有更好更高效的方式處理系統的設計和實現，然後呢？然後我們後續會更具體針對某一些特定業務，給出對應業務外掛的實現。
* 本文作者：xsecurity，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載