OSSIM平台網絡日誌關聯分析實戰

OSSIM平台網絡日誌關聯分析實戰

本文簡要介紹了OSSIM平台下的網絡日誌關聯分析技術，希望對大家日常的網絡安全運維提供一些幫助。
本文主要對OSSIM實現的日誌關聯技術進行了深入分析。

一、網絡安全管理面臨的挑戰
目前，許多組織已經擁有防火牆、入侵檢測系統、防病毒系統和網絡管理軟件。然而，網絡管理者在安全溯源和安全管理方面面臨以下挑戰：

1、安全設備和網絡應用產生的安全事件數量巨大，誤報嚴重。 IDS 系統每天會產生近數万起安全事件。通常 99% 的安全事件都是誤報。真正具有威脅性的安全事件淹沒在海量信息中，難以識別。

2、安全事件之間橫向和縱向的關係（如不同的空間源、時間序列等）沒有綜合分析，漏報嚴重，無法實現實時預測。一個攻擊活動往往緊跟著另一個攻擊活動，前者的攻擊活動為後者提供了基本條件；一個攻擊活動在多個安全設備上產生安全事件；多個不同來源的安全事件實際上是協同攻擊，這些都缺乏有效的綜合分析。

3、安全管理者缺乏實時感知全網安全態勢的能力。安全設備獨立運行，設備產生的海量日誌冗餘、獨立、分散，真假難辨。顯然，它不能直接作為安全事件響應的依據。

下面以一家擁有 500 台計算機的中型企業為例，網絡安全產品每天產生的事件數量如表 1 所示。

表1 典型企業日誌輸出分析

安全目標

安全產品

原木產量（/天）

內網安全

桌面管理系統

超過 1000

防病毒系統

殺毒服務器、殺毒網管

50000

網絡安全

交換機、路由器

超過 1000

入侵檢測系統/IPS

超過 500000

防火牆、堡壘機

超過 200 萬

保護關鍵業務

主機審計、應用審計

超過 100,000
通過現有的日誌收集技術，我們收集這些日誌並不難。然而，安全人員很難在短時間內識別大量安全事件之間的內部線索，分析日誌的關聯性就更困難了。這時，我們就需要一種技術，可以幫助我們在對海量日誌數據進行處理分析後，自動獲取網絡異常告警，從而提高安全團隊發現網絡威脅的效率。

2、網絡相關性分析技術
面對上述問題，我們可以通過關聯分析平台來解決問題。該平台可以為我們提供網絡安全各個方面的概覽。它還提供實時監控和事件關聯、風險分析、報告和通知功能。全面管理和審計系統內的安全事務，大大提高識別網絡安全風險的能力。關聯分析平台依托關聯分析核心技術，重點關注日誌採集、日誌格式化（也稱歸一化）、日誌關聯分析三個方面。

1、日誌採集：SIM產品是否有優勢取決於日誌採集，是否支持更多類型，是否可以方便擴展，自動識別和支持未知設備日誌。比如需要支持的協議有syslog、snmp trap、windows log、database、file、xml、soap等。
2、日誌格式化：日誌採集完成後，需要進行統一的標準格式化。這些統一的格式會在原始日誌中添加風險值、可靠性、優先級等標籤，為後續的關聯分析做準備。如果格式不夠標準，則無法進行關聯分析。以下是規範化的格式：

下面是SSH原始日誌和標準化日誌的前後對比：
可以看出，SSH暴力攻擊事件的元素比原來的日誌要多很多，但是這些添加可以為以後的日誌關聯分析做準備。

3.日誌相關性分析
在日誌格式化的基礎上，利用一定的算法（上下文關聯、攻擊場景關聯等）從多個數據源獲取事件進行關聯分析，實現不同日誌的風險值，結合資產漏洞信息和入站和出站流量綜合計算網絡。資產受到威脅，最後發出警報提醒管理員。這大大降低了管理員分析海量日誌的難度。

為了達到對安全事件進行關聯分析的目的，需要有一個好的事件處理機制，比如上面提到的日誌採集的歸一化處理，以及一個好的關聯方法，而且關聯方法不止一種關聯多個實時 將這些方法組合在一起效果更好。大量標準化事件送入關聯引擎處理後，會經過事件分類處理、聚合、互相關、啟發式關聯等多種關聯方式。系統會根據數據庫中的安全事件進行統計分類。

我們來看一個相關性分析場景：

（1）比如VPN服務器日誌顯示，張三3:00從外網登錄到內網，3:05登錄FTP服務器，在FTP服務器上下載了某個文件。門禁系統的日誌顯示，張三不久前剛剛進入辦公區域，這三個日誌可以與一個安全事件相關聯。

(2) 某公司核心數據庫前端部署防火牆系統。一天，安防系統監控發現張三登錄了MySQL數據庫服務器，但是在防火牆日誌中沒有找到張三的訪問日誌，這說明張三很有可能繞過防火牆直接登錄數據庫服務器.
3）。在網絡中，OpenVas 掃描具有 Apache 2.2.x Scoreboard（繞過本地安全限制）漏洞的 Linux 主機。同時，NIDS 檢測到對主機漏洞的攻擊企圖。如果Linux服務器標有“如果打了相應的補丁”，則關聯分析結果為低風險值，不報警。如果沒有打補丁，審計系統會報警。

每個系統管理都有自己的安全保護措施，但它們只是安全孤島，但一切之間都必須有關係。將這些日誌鏈接在一起進行分析，就是我們上面介紹的相關性分析技術。

4. OSSIM關聯引擎
一、關聯引擎概述
OSSIM平台下實現的關聯分析技術的核心是關聯引擎。 OSSIM傳感器將大量標準化事件發送到關聯引擎進行處理後，會經過事件分類處理、聚合、互相關、啟發式關聯等多種關聯方法。系統會根據數據庫中的安全事件進行統計分類，找出安全事件的來源和經常被攻擊的端口。在這些階段將生成事件警報。安全事件關聯流程模塊如下圖所示。
管理引擎中的事件聚合模塊可以為後續關聯提供高質量的安全事件，提高關聯引擎的效率，分類處理可以直接升級已知安全事件，可靠性高，告警關注度高。此外，統計分類通過綜合分析告警庫、日誌庫、知識庫，生成受控網段內被攻擊頻率最高的主機和應用程序，統計同一數據源、同一目標端口的安全事件數量。客觀反映網絡異常。

在OSSIM系統中，關聯分析功能也是由關聯引擎實現的。關聯引擎策略文件定義位於/etc/ossim/server/，分析後的數據由探針採集。 Sensor（傳感器）每天從網絡上採集。有數以萬計的事件。如果不對這些海量的事件信息進行任何處理，直接生成事件是沒有意義的。在上報之前，可以通過相關性分析將這數千個事件濃縮（聚集）成幾十個甚至幾個事件，顯示在Web前端的SIEM中。簡單理解就是，OSSIM的網絡安全事件關聯分析可以去除不同功能的開源網絡安全檢測工具產生的誤報信息，從而挖掘出真實的網絡攻擊事件。
2.主要關鍵詞
OSSIM系統中的風險評估主要圍繞攻擊威脅（Threat）、漏洞（Vulnerability）、響應（Response，security measure）、資產（Asset）等。風險評估模型嵌入在 OSSIM 關聯引擎系統中。關聯引擎結合知識庫中的資產庫、漏洞庫和威脅庫，綜合考慮風險資產、漏洞和威脅三要素。

三、資產風險計算
風險=R（資產、漏洞、威脅）

將資產價值（Asset）、優先級（Priority）、可靠性（Reliability）三個參數結合起來計算風險，簡潔有效。 OSSIM系統中使用以下公式：

風險=資產*優先級*可靠性/25（風險模型計算公式1）

其中Asset（資產，取值範圍0~5）

優先級（優先級，取值範圍0~5）

Reliability（可靠性，取值範圍0~10）

每個警報事件的風險值由公式（1）計算，其中

Ø Asset的取值範圍為0到5，asset的默認值為2；在 OSSIM 系統中，資產的注意力等級分為 5 個等級，數值從低到高分別為 1、2、3、4、5。表面上可以理解，數字的大小決定了風險計算公式中風險值的大小，但也有其深層次的含義。比如普通工作站的資產等級是1，當它被DOS攻擊時，我們只需要一個簡單的端口網絡連接。如果是數據庫服務器，它的資產等級是5，數據庫服務需要實時在線，所以我們不能像工作站一樣處理DOS攻擊，而應該自動啟用備用IP地址並引導攻擊到網絡蜜罐系統。

Ø Priority的取值範圍為0~5，默認值為1。該參數描述了攻擊成功造成的傷害程度。數值越大，損壞程度越高；

Ø Reliability或Reliability的取值範圍為0到10。默認值為1。reliability參數描述了攻擊可能成功的概率。最高值為 10，表示 100% 的可能性。代表越不可靠，就越容易受到攻擊。

操作 OSSIM 時，在 Web UI 中打開 SIEM 控制台，觀察每個事件，可以發現風險值受資產價值優先級和可信度控制。網絡中的每一項資產都是有​​價值的，而這個價值的量化是通過資產價值來實現的。每個資產的默認值為 2（範圍 1~5）。在風險計算公式中可以分析出，風險計算不計算資產價值。作為影響風險結果的主要因素，比如一些數據庫服務器資產價值高，計算出來的風險值也會很大，而資產價值小的工作站在受到嚴重攻擊的節點上風險值小，所以很難失去原有的真實性，所以讓資產價值的範圍在1到5之間，風險值就小了。

場景示例：

一個主機連接到一個VLAN中5個不同IP地址的445端口，這可能是正常的網絡通信，如果有15台機器連接到445端口這是可疑的，如果有150個這樣的連接並且持續很長時間，它很可能被蠕蟲攻擊，需要人工進一步驗證。

4. Risk & Priority & Reliability 的關係例子
根據公式計算，任何人都可以做到。上述公式1中各個參數之間的內在關係是什麼？
在我們收集到的事件中，重複事件佔很大比例，其中風險主要是Risk=0。例如，以Cisco ASA的一個ICMP事件為例，它的PRIO=1，REL=1，ASET=2，根據上面的風險模型計算公式計算得出，大約等於0。

分析上圖可知，Reliability 系統在關聯規則中為它設置了一個初始值。想像一下，如果它是一個常數，在動態網絡攻擊中會產生大量的誤報。那麼，當引入互相關機制後，將網絡安全告警與具體網絡應用服務的漏洞信息、開放端口、開放端口進行空間關聯，判斷是否可以實現攻擊，所以可靠性值必須成為一個變量。包含無法存在的端口的安全事件直接丟棄（系統的KDB中有立即更新列表）。下圖是OSSIM關聯規則中可靠性參數的變化過程。

5. 事件聚合
我們知道，冗餘告警會嚴重干擾管理員對故障的判斷。此時，需要匯總這些信息。通過從海量告警中聚合一些類似告警，去除冗餘部分，減少告警數量。這大大減少了關聯模塊進行關聯分析的工作量。

合併冗餘告警信息主要從三個方面考慮：

(1) 合併基於主機的監控Ossec產生的冗餘告警事件。

(2) 合併基於網絡的監控 Snort/Suricata 產生的冗餘報警事件。

(3) 結合主機監控Ossec和網絡監控Snort告警信息進行同一攻擊。

Snort告警信息的屬性比較全面，具有明顯的特點。 Snort產生的告警事件合併過程可以採用基於屬性相似度的方法。對於Ossec的告警事件的合併，OSSIM採用了基於事件ID和告警類別信息相結合的方法。目前，Ossec 擁有 900 多條檢測規則，全部以 XML 格式存儲。經統計分析，根據告警行為可分為80個告警類別。常見的有：Syslog、Firewall、IDS、Web、Squid、Windows等。以OSSEC告警的事件ID作為入口，進行一級類和子類的匹配，實現匹配和合併的目的。

根據信息源分析，我們看到聚合對像是基於網絡的Snort/Suricata和基於主機的Ossec安全產品產生的告警數據。包含協議屬性，可以基於規則的方式進行聚合，可以保證在聚類過程中對告警信息進行正確分類。
Snort 支持多種協議，通過將警報事件聚類然後合併它們可以節省大量時間。並且由於其屬性的明顯特徵，冗餘信息的合併是基於其屬性的相似性進行的，因此合併誤差很小。對於Ossec產生的告警信息，以告警事件的ID為入口，按照告警類別逐步聚合，合併錯誤率低。按照以ID為入口的根類別進行合併的方法，省去了遍歷告警信息進行聚類的需要。是時候合併了。

OSSIM中使用主機監控軟件Ossec實現對主機的審計記錄、系統日誌和應用程序的收集和分析。它支持文件完整性監控、註冊表監控、端口監控、rootkit檢測和部分進程監控。同時，Snort 用於收集網絡上的數據包，完成實時流量分析和測試網絡上的 IP 包等，還可以進行協議分析、內容搜索和匹配，並可用於檢測各種攻擊和嗅探（例如緩衝區溢出和 ShellCode 攻擊）。

對於兩個事件，如果相似度高，則認為是同一次攻擊，合併；否則，它們被認為是不相關的攻擊。

我們可以從計算兩條警報消息之間的相似度開始。首先要考慮的是兩個警報的共同屬性。這些屬性包括攻擊源、目標（主機IP和端口）、攻擊類型、MAC地址、時間信息和事件ID等。據此，我們可以對告警事件的屬性進行抽象和形式化，將它們的屬性定義為一個事件屬性集。我們對冗餘告警事件採用的合併方法的出發點是同一攻擊行為的告警信息相似度高，不同攻擊行為的告警相似度低。我們在合併各個產品的冗餘告警信息時，還需要考慮兩個安全產品針對同一次攻擊產生的告警信息，盡量有效地壓縮所有重複的告警信息。

如果 Snort 發現基於目標 IP 的攻擊，則說明目標 IP 主機存在漏洞，其可靠性係數為 10（即 100% 攻擊成功）。下圖中REL的值為10，表示當前時間可靠性係數為10，因此風險值為4。這個值也可以在數據源中修改。
從上面可以看出，可靠性和優先級的數值決定了風險的大小。手動修改數據源REL/PRIO的方法如下圖所示。請注意，此修改在全局範圍內有效，而不是針對單個事件。通過傳感器將各個監控節點的數據關聯起來，形成一條數據鏈，然後關聯分析引擎和規則協同工作，分析黑客的攻擊行為，溯源，發出告警。下面分析其生成原理。

警報事件由關聯指令和規則生成。 Alarm中顯示的告警信息是通過關聯規則匹配大量事件得到的。 OSSIM 5以後，系統採用圖形顯示OSSIM系統。報警模式，便於管理員過濾大量安全事件的重要部分。告警事件生成流程如圖所示。
具體的Alarm生成步驟如下：

(1) 將日誌收集到 OSSIM；

（2）日誌統一規範化後，產生事件；

(3) 將這些事件導入關聯引擎；

(4) 根據關聯規則匹配新的事件。
通過上圖，即使是安全新手也可以輕鬆檢測出針對 SSH 服務的暴力攻擊。
在這張圖中，我們僅以系統入侵→蠕蟲感染→內部主機掃描警報為例。在系統損壞中，會出現內部主機的掃描行為。這種行為被懷疑是網絡蠕蟲的掃描。我們知道，掃描主機漏洞往往是通過蠕蟲傳播的。前提是蠕蟲經常被ICMP Ping包、TCP SYN、FIN、RST和ACK包檢測到，而且是隨機的。從圖中可以看出，系統定義了此類事件的風險值、掃描的持續時間以及源地址。 、目的地址、源端口、目的端口和關聯級別，OSSIM很容易發現這種異常行為。
5. 關聯規則說明
關聯分析的核心是由一個或一組關聯指令完成的。下面是一個 SSH 暴力破解的例子。 SSH蠻力破解（Brute Force）是從UNIX誕生之日就衍生出來的一種攻擊行為。據統計，大約50%以上的用戶名是root。低可靠性SSH服務器100次登錄成功，而高可靠性SSH服務器10000次登錄成功，則關聯引擎在一定時間內可以通過。 ，登錄次數，以及這些時間不同的源地址和相同的目的IP地址，以及這些IP地址來自哪些國家，以及他們的聲譽，以綜合判斷攻擊和應對。
檢測SSH暴力攻擊的關聯指令規則源代碼XML描述如下：
<directive id="50113" name="AV-FREE-FEED Bruteforce attack, SSH service authentication attack against DST_IP" priority="4">
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="1" occurrence="1" from="ANY" to="ANY" port_from="ANY" port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="2"occurrence="5"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="30"port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected"reliability="4"occurrence="10"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="60"port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="6"occurrence="50"from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="300"port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="8"occurrence="500" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="36000"port_to="ANY" plugin_id="4003" plugin_sid="1">
<rules>
<rule type="detector" name="SSH service authentication attempt failed detected" reliability="10"occurrence="1000" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="86400"port_to="ANY" plugin_id="4003" plugin_sid="1"/>
<rule type="detector" name="SSH service authentication sucessful" reliability="10" occurrence="1" from="1:SRC_IP" to="1:DST_IP" port_from="ANY" time_out="10" port_to="ANY" plugin_id="4003" plugin_sid="7"/>
</rules>

參數說明：
這些指令通常用 XML 描述。如果你不理解它們的含義，你自己編寫或修改腳本時就無法開始。整個關聯規則體系具有完整的規則屬性，含義如下：

Id，該屬性允許為相關指令定義一個唯一標識符。此類編號必須遵循 OSSIM 發布的說明。從而可以準確的實現框架中實現的分類顯示（上下文菜單的子命令菜單）。此子菜單中提供編號命令。

名稱，該屬性允許定義指令的名稱。 （命令匹配時顯示）

源IP地址

DST，目的IP地址

Port_from 源端口

Port_to 目標端口

優先級，該屬性允許定義相關指令的優先級。

Type，定義規則類型。只有兩種類型的規則。

檢測器，使用規則檢測零件信息，包含在服務器數據庫中。

可靠性（reliability，也叫可信度），這個參數越大（越接近10），報警越真實。此參數在關聯過程中至關重要。事實上，隨著規則的先後匹配，該組的誤報概率會降低。因此可以在每個標記規則中修改高級警報的可靠性。後續規則將對其可靠性進行相對估計（例如：+3，表示整體可靠性相對於之前規則提高了3個級別）或絕對（例如：7，表示當前可靠性級別為7）。年級。
發生,發生頻率

Plugin_id，這個屬性定義了規則所期望的警報的來源。實際上，每個插件都有一個關聯 ID，允許在關聯規則中引用該插件。

Plugin_sid，這個參數定義了與插件相關的事件。事實上，OSSIM 恢復的所有事件都被索引（根據其插件）和配置。可以通過在配置菜單的插件子菜單中單擊所需的 plugin_id 來配置 plugin_sid。例如，plugin_id 1501 和plugin_sid400 提供的警報等價於：“apache: Bad Request” 有了這兩個屬性（plugin_id 和plugin_sid），就可以準確地定義規則所期望的內容。

Time_out，超時設置，該屬性可以表示滿足一定規則的事件的等待時間。如果在給定時間內（通過屬性以秒為單位）沒有發生此事件，則關聯指令結束並返回到先前規則計算的結果。此屬性確定必須顯示規則預期的警報（事件）的臨時窗口。

協議，此屬性允許配置規則預期的網絡事件類型。可以定義三種類型的協議：TCP、UDP、ICMP，並且該屬性允許絕對引用。這意味著可以重用匹配先前規則的協議類型。因此，只需執行以下操作：protocol="1:PROTOCOL" 明確該規則的協議與一級規則匹配的協議相同。如果要恢復二級規則匹配的協議，只要明確表示：protocol="2:PROTOCOL"。

從，該屬性允許明確指示預報警的 IP 源地址。它可以用 6 種不同的方式表示：

①ANY，表示任意地址源匹配該屬性。

②x.xxx IP 地址。

③ 通過引用，符合引用協議屬性的原則。 （例：1：SCR_IP=與一級依賴指令匹配的告警源地址，2：DST_IP=與二級依賴指令告警的目的地址）。
6.關聯規則實戰
將規則導入OSSIM關聯分析引擎後，即可顯示規則，如下圖所示。


一切準備就緒後開始測試：

在攻擊機（Kali 2021, 192.168.183.158）上啟動美杜莎對，測試目標機開放的ssh端口（命令省略）。然後登錄目標機器（192.168.183.139）查看SSH日誌：
傳統的分析這些日誌的方式既費時又費力，而且往往無法及時確定故障。下面我沒有看到OSSIM的歸一化事件，如下圖所示。

相關分析結果：

從上圖可以看出，風險值為3，很明顯可以表徵為針對SSH服務的蠻力攻擊。此過程自動完成，規則編寫正確，自動實現報警，無需人工干預。

千言萬語不如視頻清晰：以下視頻是對數相關性分析的實際剪輯。

https://mp.weixin.qq.com/s/BnedVIy8h4eCf80dNJG_Gw?source&ADUIN=1989365079&ADSESSION=1650851489&ADTAG=CLIENT.QQ.5887_.0&ADPUBNO=27211

七、總結
初學者從一張白紙開始寫規則有點困難，但按照系統給出的默認規則，還是可以做到的。不管模型是否完美，先使用，再逐步修改。在適當的時候，對系統進行滲透測試，然後監控 SIEM 的響應以查看它是否生成正確的警報，以及警報是否提供了足夠的信息來幫助確定發生了哪些威脅，如果沒有，那麼規則需要進行修改，然後需要不斷優化閾值。本文簡要介紹了OSSIM平台下的網絡日誌關聯分析技術，希望對大家日常的網絡安全運維提供一些幫助。