本文主要對OSSIM實現日志關聯技術進行深入分析。
一、網絡安全管理中面臨的挑戰目前很多組織都已經擁有了防火墻、入侵檢測、防病毒系統、網管軟件，但是網絡管理者在安全追根溯源及安全管理面臨如下挑戰：
1 .安全設備和網絡應用產生的安全事件數量巨大，誤報嚴重。一臺IDS系統一天產生的安全事件數量近成千上萬。通常99%的安全事件都是誤報。真正有威脅的安全事件淹沒于海量信息中難于識別。
2. 安全事件之間存在的橫向和縱向方面(如不同空間來源、時間序列等)的關系未能得到綜合分析，因此漏報嚴重，不能實現實時預測。一個攻擊活動之后常常接著另一個攻擊活動，前一個攻擊活動為后者提供基本條件;一個攻擊活動在多個安全設備上產生了安全事件;多個不同來源的安全事件其實是一次協作攻擊，這些都缺乏有效的綜合分析。
3.安全管理者缺乏對整個網絡安全態勢的全局實時感知能力，安全設備各自為政，設備所產生龐大的日志冗余，獨立而分散，真假難辯，顯然無法直接作為安全事件響應的依據。
下面舉例一個擁有500臺電腦的中型企業，網絡安全產品每天產生的事件數量，如表1所示。
表1 典型企業日志產量分析
安全目標 | 安全產品 | 日志產量（/天） |
網絡內網安全 | 桌面管理系統 | 大于1000條 |
防病毒系統 | 防病毒服務器、防病毒網管 | 50000條 |
網絡安全 | 交換機、路由器 | 大于1000條 |
IDS/IPS | 大于500000條 | |
防火墻、堡壘機 | 大于2000000條 | |
保護關鍵業務 | 主機審計、應用審計 | 大于100000條 |
我們通過現有的日志采集技術收集這些日志難度并不大，然而安全人員很難在短時間內識別出海量安全事件之間內部端倪，分析日志相關性更是無從下手。此時我們需要一種技術能夠幫助我們實現從海量日志數據處理分析后能自動得到網絡異常報警，這樣才能提高安全團隊發現網絡威脅的效率。
二、網絡關聯分析技術面對上述問題，可以關聯分析平臺來解決問題，這種平臺可以為我們集中展示網絡安全各方面的概況，同時還提供有實時監視和事件關聯、風險分析、報告、通知功能，可在企業范圍內全面管理、審計安全事務，大大提高了網絡安全風險識別能力。關聯分析平臺依托關聯分析核心技術集中在：日志收集、日志格式化(也叫做歸一化)、日志關聯分析3個方面。
1.日志收集：一個SIM產品是否有優勢，就要看日志收集，能否支持更多的類型，能否容易擴展，自動識別支持未知設備日志。例如需要支持的協議有syslog、snmp trap、windows log、database、file、xml、soap等。
2.日志格式化：日志收集之后，需要格式化統一標準，這些統一格式會在原有日志基礎上附加風險值、可靠性、優先級等標簽，為后面的關聯分析做準備，如果格式化不夠標準，關聯分析無法實現。以下是歸一化格式：
下面以SSH原始日志和標準化日志的前后對比：
可以看出SSH暴力破解事件比原始日志多了許多元素，但這些增加項可以為今后日志關聯分析做好了準備。
三、日志關聯分析在日志格式化基礎之上通過一定算法(上下文關聯、攻擊場景關聯等)從多個數據源獲取事件進行關聯分析，實現不同日志的風險值，并結合資產的漏洞信息以及進出流量綜合計算出網絡資產受威脅程度，最后發出報警，以便提醒管理員。這就大大降低了管理員分析海量日志的難度。
為了達到安全事件關聯分析的目的，就要有好的事件處理機制，比如前面講的日志收集的歸一化處理，還得有好的關聯方法，而且不止一種關聯方法，將多種實時關聯方法結合到一起效果更佳。大量標準化處理的事件被送入關聯引擎處理后，它們會經歷事件分類處理、聚合、交叉關聯、啟發式關聯等多種關聯方法，系統會根據數據庫中的安全事件進行統計分類。
下面我們再看個關聯分析場景：
(1)比如在VPN服務器日志顯示張三3:00點鐘，從外網登錄到內部網，3:05分登錄FTP服務器，并在FTP服務器上下載了某一文件。在門禁系統的日志顯示張三在不久前剛剛進入辦公區域，這三個日志可以關聯出一個安全事件。
(2)某公司核心數據庫前端部署了防火墻系統，某日安全系統監測發現張三登錄了MySQL數據庫服務器，但是在防火墻日志中并沒有發現張三的訪問日志，則說明張三很有可能繞過防火墻直接去登錄數據庫服務器。
3).網絡中OpenVas掃到某Linux主機存在Apache 2.2.x Scoreboard(本地安全限制繞過)漏洞，與此同時，NIDS檢測到了一個對該主機漏洞的嘗試攻擊事件，如果此時該Linux服務器打上了相應補丁，則關聯分析結果就是低風險值，不會報警，如果沒有打補丁此時審計系統就會報警。
對于每套系統管理都有它的安全防護措施，只不過都是安全孤島而已，但是萬事萬物之間必然有它的聯系，將這些日志聯系到一起分析，就是我們上面介紹的關聯分析技術。
四.OSSIM關聯引擎1.關聯引擎概述OSSIM平臺下實現關聯分析技術核心是關聯引擎，在OSSIM傳感器將大量標準化處理的事件被送入關聯引擎處理后，它們會經歷事件分類處理、聚合、交叉關聯、啟發式關聯等多種關聯方法，系統會根據數據庫中的安全事件進行統計分類，找出經常導致安全事件的發源地和經常被攻擊的端口，在這些階段都會產生事件告警，其安全事件關聯過程模塊如下圖所示。
在管理引擎中的事件聚合模塊可以為后續關聯提供高質量的安全事件，提高關聯引擎效率，而分類處理可將已知可信度高，受關注高的安全事件直接提升為報警。而且統計分類通過對報警數據庫、日志數據庫、知識庫綜合進行分析統計，產生受控網段內最常被攻擊的主機和應用，統計相同數據源和相同目標端口的安全事件的數量，這樣就可以客觀反映網絡異常情況。
在OSSIM系統中關聯分析功能同樣是由關聯引擎來實現，關聯引擎策略文件定義位于/etc/ossim/server/，分析的數據由探針來收集，Sensor(傳感器)每天要從網絡上收集到成千上萬的事件，如果對這些海量的事件信息不加任何處理就直接生成事件，這種做法是沒有意義的。而在報告之前通過關聯分析可以將這些成千上萬的事件進行濃縮(類聚)，并確認成數十個甚至數個事件，顯示在Web前端的SIEM中。簡單理解就是OSSIM的網絡安全事件關聯分析能將不同功能的開源網絡安全檢測工具產生的報警信息進行去偽存真，從而挖掘出真正的網絡攻擊事件。
2.主要關鍵詞OSSIM系統中的風險評估主要圍繞著攻擊威脅(Threat)、漏洞(Vulnerability)、響應(Response,即安全措施)、資產(Asset)等來監控。風險評估模型嵌入在 OSSIM 關聯引擎系統中，關聯引擎結合知識庫中的資產庫、漏洞庫、威脅庫將風險的資產、漏洞、威脅三要素綜合考慮。
3.資產風險計算Risk=R(asset,vulnerability,threat)
將資產價值(Asset)、優先級(Priority)、可靠性(Reliability)三個參數組合在一起進行風險的計算是簡潔有效的，在OSSIM系統中使用以下公式：
Risk=asset*priority*reliability/25 (風險模型計算公式1)
其中Asset(資產， 取值范圍0~5)
Priority(優先級， 取值范圍0~5)
Reliability(可信度，取值范圍0~10)
由公式(1)計算每個Alert事件的Risk值，其中
? Asset 的取值范圍為 0～5，asset默認值為2;在OSSIM系統中將資產的關注程度分為5級，取值由低到高分別為1、2、3、4、5。從表面上理解，數字的大小決定了風險計算公式中Risk值的大小，但也有它深層次的含義，比如普通工作站資產等級為1，當它遭受DOS攻擊時，我們只需要簡單端口網絡連接，如果是數據庫服務器，它的資產等級為5，數據庫服務需要實時在線，所以同樣遭受DOS攻擊我們就不能象工作站那樣處理，而應自動啟用備用IP地址并將攻擊引向網絡蜜罐系統。
? 優先級Priority 的取值范圍為 0～5，默認值為 1，該參數描述一次成功攻擊所造成的危害程度，數值越大，則危害程度越高;
? 可信度或者叫可靠性Reliability 的取值范圍為 0～10，默認值為 1，可靠性參數描述一次攻擊可能成功的概率，最高值是10，代表100%可能，所以其值越高，代表越不可靠，大家也可以將此理解為被攻擊的可能性。
大家在操作OSSIM時，打開Web UI中的SIEM控制臺，觀察每條Event時就能發現風險值由資產值優先級和可信度來控制。而網絡中每個資產都是有價值的，這個價值的量化就通過資產值來實現，默認每個資產為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(可信度)系統為它已經設定好了一個初始值，試想如果是個常量，那在動態的網絡攻擊中將會產生大量誤報，那么在引入交叉關聯機制之后，就將網絡安全報警和具體網絡應用服務、開放端口、開放端口的漏洞信息進行空間上的關聯，以便確定攻擊是否可達到，這樣可信度值(reliability)就必定為變量，對于那些含有不可能存在端口安全事件直接丟棄(系統的KDB中有一張即時更行的列表)下圖展示了reliability參數在OSSIM關聯規則變化過程。
5.事件聚合我們知道冗余報警會嚴重干擾管理員對故障的判斷，此時需要這些信息進行聚合，通過從海量報警中，將一些相似的報警進行聚合處理，把冗余部分去掉，減少了報警條數，大大減輕了關聯模塊做關聯分析的任務量。
合并冗余的報警信息主要是從3方面來考慮：
(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 的報警數據(包括IP 地址，攻擊內容和端口等之類的要素)中含有協議屬性，可對其用基于規則的方式進行聚合，在聚類過程中可以保證報警信息得到正確的歸類。
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。下面分析一下它的產生原理。
Alarm Events由關聯指令(Correlation Directives)配合Rules所產生，在Alarm中展示的警告信息是通過關聯規則從大量的事件中匹配而得出，在OSSIM 5以后的系統采用了一種圖形化展示OSSIM系統Alarm報警的模式，這便于管理員重大量安全事件中篩選重要的部分。Alarm事件產生過程如圖所示。
具體Alarm生成步驟如下：
(1)日志收集到OSSIM;
(2)將日志統一進行歸一化處理后生成事件;
(3)將這些事件導入關聯引擎;
(4)根據關聯規則匹配出新的事件。
通過上圖顯示的畫面，即使是一個安全小白也能輕松檢測到針對SSH服務的暴力破解行為。
在這張圖中僅以System Compromise→Worm infection →Internal Host scanning 告警為例，在系統危害中出現了內部主機的掃描行為，這類行為疑似為網絡蠕蟲的掃描，我們知道掃描主機漏洞往往是蠕蟲傳播的前提，蠕蟲常常會通過ICMP Ping包、TCP SYN、FIN、RST以及ACK包探測，而且具有著隨機性，從圖中看出，系統定義出這類事件的風險值，掃描的持續時間，源地址、目的地址，源端口、目標端口以及關聯等級，對于這種異常行為很容易被OSSIM發現。
五、關聯規則指令關聯分析的核心通過一個或一組關聯指令來完成，下面用SSH暴力破解的例子加以說明，SSH暴力破解(Brute Force)大約自UNIX誕生之后，就衍生出來的一種攻擊行為，據統計發現大約有50%以上的用戶名是root。一個低可靠性(low reliability)的SSH 服務器，在經過100登錄嘗試之后成功登錄，而高可靠性(high reliability)的SSH服務器，則經過10000次登錄才成功，那么關聯引擎可通過在一定時間內，登錄的次數，以及這些時間的不同源地址和相同目標IP地址，以及這些IP地址來自于那些國家，它們信譽度如何等信息來綜合判定攻擊以及作出響應。
檢測SSH暴力攻擊的關聯指令規則源碼用XML描述如下：
這些指令常用XML來描述，如果不理解其含義，如果自己寫腳本或修改腳本時就無從下手。整個關聯規則系統有個完整的規則屬性，含義如下： Id，該屬性允許定義相關聯指令的唯一標識。這種編號必須遵循由OSSIM發布的指令。以便在框架中(關聯菜單的子指令菜單)實現的分類顯示得到準確實現。編號指令在此子菜單中可用。 Name，此屬性允許定義指令的名稱。(當指令匹配時顯示) SRC , 源IP地址 DST，目標IP地址 Port_from 源端口 Port_to 目標端口 Priority，此屬性允許定義關聯指令的優先級。 Type，該屬性定義規則類型。僅有兩種類型的規則。 Detector，使用檢測部件信息的規則，其包含于服務器數據庫。 Reliability(可靠性，也叫可信度)，此參數越大(接近10)，表明報警越真實。此參數在關聯過程中至關重要。實際上，隨著規則的陸續匹配，本組報警誤報的概率會降低。所以有可能在每個標記規則中修改高級報警的可靠性。其后的規則會以相對(例如：+3，意味著相對于前面的規則，全局可靠性提高了3個等級)或者絕對(例如：7，表明現在的可靠性等級是7)的方式估計其等級。 Occrrence ，出現頻率 Plugin_id，此屬性定義由規則預計的報警的來源。實際上，每個插件有一個相關標識，此標識允許在相關性規則中引用該插件。 Plugin_sid，此參數定義了和插件相關聯的事件。實際上，所有被OSSIM恢復的事件都被索引(依照其插件)并且配置。通過在配置菜單的插件子菜單中點擊所需plugin_id便可以配置plugin_sid。例如，由plugin_id 1501和plugin_sid400提供的報警等同于：“apache：錯誤請求”有了這兩種屬性(plugin_id和plugin_sid)，就可以精確定義規則所預計的事件。 Time_out，超時設定，此屬性允許表明符合某個規則的事件的等待時間。如果此事件沒有在給定的時間(通過屬性以秒計算)內發生，相關性指令會結束并返回到前面規則計算的結果。此屬性可以確定由規則所預計的警報(事件)必須顯示的臨時窗口。 Protocol(協議)，此屬性允許配置由規則預計的網絡事件類型?？梢远x三種類型的協議：TCP、UDP、ICMP，此屬性允許絕對引用。此意味著有可能重新使用和前規則匹配的協議類型。所以，只需做如下表明：protocol=“1:PROTOCOL”，以此來明確表達此規則的協議和由一級規則相匹配的協議相同。如果要恢復二級規則匹配的協議，只需明確表達：protocol=“2:PROTOCOL” 。 From，此屬性允許明確表明預報警的IP源地址?？梢允褂?種不同的方法來表示： ①ANY，表明任意地址源和此屬性匹配。 ②x.x.x.x IP地址。 ③通過引用，和引用協議屬性原則一致。(例如：1：SCR_IP= 和一級相關指令匹配的報警的源地址，2：DST_IP= 和二級相關性指令的報警的目標地址)。 將規則導入OSSIM關聯分析引擎后顯示，如下圖所示。 準備工作就緒之后開始測試： 在攻擊機(Kali 2021，192.168.183.158)啟動medusa對，靶機開放的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平臺下的網絡日志關聯分析技術希望能給大家在日常網絡安全運維中提供一些幫助。
X 關閉
X 關閉