本文主要對OSSIM實(shí)現(xiàn)日志關(guān)聯(lián)技術(shù)進(jìn)行深入分析。

一、網(wǎng)絡(luò)安全管理中面臨的挑戰(zhàn)

目前很多組織都已經(jīng)擁有了防火墻、入侵檢測、防病毒系統(tǒng)、網(wǎng)管軟件，但是網(wǎng)絡(luò)管理者在安全追根溯源及安全管理面臨如下挑戰(zhàn)：

1 .安全設(shè)備和網(wǎng)絡(luò)應(yīng)用產(chǎn)生的安全事件數(shù)量巨大，誤報(bào)嚴(yán)重。一臺IDS系統(tǒng)一天產(chǎn)生的安全事件數(shù)量近成千上萬。通常99%的安全事件都是誤報(bào)。真正有威脅的安全事件淹沒于海量信息中難于識別。

2. 安全事件之間存在的橫向和縱向方面(如不同空間來源、時(shí)間序列等)的關(guān)系未能得到綜合分析，因此漏報(bào)嚴(yán)重，不能實(shí)現(xiàn)實(shí)時(shí)預(yù)測。一個(gè)攻擊活動之后常常接著另一個(gè)攻擊活動，前一個(gè)攻擊活動為后者提供基本條件;一個(gè)攻擊活動在多個(gè)安全設(shè)備上產(chǎn)生了安全事件;多個(gè)不同來源的安全事件其實(shí)是一次協(xié)作攻擊，這些都缺乏有效的綜合分析。

3.安全管理者缺乏對整個(gè)網(wǎng)絡(luò)安全態(tài)勢的全局實(shí)時(shí)感知能力，安全設(shè)備各自為政，設(shè)備所產(chǎn)生龐大的日志冗余，獨(dú)立而分散，真假難辯，顯然無法直接作為安全事件響應(yīng)的依據(jù)。

下面舉例一個(gè)擁有500臺電腦的中型企業(yè)，網(wǎng)絡(luò)安全產(chǎn)品每天產(chǎn)生的事件數(shù)量，如表1所示。

表1 典型企業(yè)日志產(chǎn)量分析

我們通過現(xiàn)有的日志采集技術(shù)收集這些日志難度并不大，然而安全人員很難在短時(shí)間內(nèi)識別出海量安全事件之間內(nèi)部端倪，分析日志相關(guān)性更是無從下手。此時(shí)我們需要一種技術(shù)能夠幫助我們實(shí)現(xiàn)從海量日志數(shù)據(jù)處理分析后能自動得到網(wǎng)絡(luò)異常報(bào)警，這樣才能提高安全團(tuán)隊(duì)發(fā)現(xiàn)網(wǎng)絡(luò)威脅的效率。

二、網(wǎng)絡(luò)關(guān)聯(lián)分析技術(shù)

面對上述問題，可以關(guān)聯(lián)分析平臺來解決問題，這種平臺可以為我們集中展示網(wǎng)絡(luò)安全各方面的概況，同時(shí)還提供有實(shí)時(shí)監(jiān)視和事件關(guān)聯(lián)、風(fēng)險(xiǎn)分析、報(bào)告、通知功能，可在企業(yè)范圍內(nèi)全面管理、審計(jì)安全事務(wù)，大大提高了網(wǎng)絡(luò)安全風(fēng)險(xiǎn)識別能力。關(guān)聯(lián)分析平臺依托關(guān)聯(lián)分析核心技術(shù)集中在：日志收集、日志格式化(也叫做歸一化)、日志關(guān)聯(lián)分析3個(gè)方面。

1.日志收集：一個(gè)SIM產(chǎn)品是否有優(yōu)勢，就要看日志收集，能否支持更多的類型，能否容易擴(kuò)展，自動識別支持未知設(shè)備日志。例如需要支持的協(xié)議有syslog、snmp trap、windows log、database、file、xml、soap等。

2.日志格式化：日志收集之后，需要格式化統(tǒng)一標(biāo)準(zhǔn)，這些統(tǒng)一格式會在原有日志基礎(chǔ)上附加風(fēng)險(xiǎn)值、可靠性、優(yōu)先級等標(biāo)簽，為后面的關(guān)聯(lián)分析做準(zhǔn)備，如果格式化不夠標(biāo)準(zhǔn)，關(guān)聯(lián)分析無法實(shí)現(xiàn)。以下是歸一化格式：

下面以SSH原始日志和標(biāo)準(zhǔn)化日志的前后對比：

可以看出SSH暴力破解事件比原始日志多了許多元素，但這些增加項(xiàng)可以為今后日志關(guān)聯(lián)分析做好了準(zhǔn)備。

三、日志關(guān)聯(lián)分析

在日志格式化基礎(chǔ)之上通過一定算法(上下文關(guān)聯(lián)、攻擊場景關(guān)聯(lián)等)從多個(gè)數(shù)據(jù)源獲取事件進(jìn)行關(guān)聯(lián)分析，實(shí)現(xiàn)不同日志的風(fēng)險(xiǎn)值，并結(jié)合資產(chǎn)的漏洞信息以及進(jìn)出流量綜合計(jì)算出網(wǎng)絡(luò)資產(chǎn)受威脅程度，最后發(fā)出報(bào)警，以便提醒管理員。這就大大降低了管理員分析海量日志的難度。

為了達(dá)到安全事件關(guān)聯(lián)分析的目的，就要有好的事件處理機(jī)制，比如前面講的日志收集的歸一化處理，還得有好的關(guān)聯(lián)方法，而且不止一種關(guān)聯(lián)方法，將多種實(shí)時(shí)關(guān)聯(lián)方法結(jié)合到一起效果更佳。大量標(biāo)準(zhǔn)化處理的事件被送入關(guān)聯(lián)引擎處理后，它們會經(jīng)歷事件分類處理、聚合、交叉關(guān)聯(lián)、啟發(fā)式關(guān)聯(lián)等多種關(guān)聯(lián)方法，系統(tǒng)會根據(jù)數(shù)據(jù)庫中的安全事件進(jìn)行統(tǒng)計(jì)分類。

下面我們再看個(gè)關(guān)聯(lián)分析場景：

(1)比如在VPN服務(wù)器日志顯示張三3:00點(diǎn)鐘，從外網(wǎng)登錄到內(nèi)部網(wǎng)，3:05分登錄FTP服務(wù)器，并在FTP服務(wù)器上下載了某一文件。在門禁系統(tǒng)的日志顯示張三在不久前剛剛進(jìn)入辦公區(qū)域，這三個(gè)日志可以關(guān)聯(lián)出一個(gè)安全事件。

(2)某公司核心數(shù)據(jù)庫前端部署了防火墻系統(tǒng)，某日安全系統(tǒng)監(jiān)測發(fā)現(xiàn)張三登錄了MySQL數(shù)據(jù)庫服務(wù)器，但是在防火墻日志中并沒有發(fā)現(xiàn)張三的訪問日志，則說明張三很有可能繞過防火墻直接去登錄數(shù)據(jù)庫服務(wù)器。

3).網(wǎng)絡(luò)中OpenVas掃到某Linux主機(jī)存在Apache 2.2.x Scoreboard(本地安全限制繞過)漏洞，與此同時(shí)，NIDS檢測到了一個(gè)對該主機(jī)漏洞的嘗試攻擊事件，如果此時(shí)該Linux服務(wù)器打上了相應(yīng)補(bǔ)丁，則關(guān)聯(lián)分析結(jié)果就是低風(fēng)險(xiǎn)值，不會報(bào)警，如果沒有打補(bǔ)丁此時(shí)審計(jì)系統(tǒng)就會報(bào)警。

對于每套系統(tǒng)管理都有它的安全防護(hù)措施，只不過都是安全孤島而已，但是萬事萬物之間必然有它的聯(lián)系，將這些日志聯(lián)系到一起分析，就是我們上面介紹的關(guān)聯(lián)分析技術(shù)。

四.OSSIM關(guān)聯(lián)引擎

1.關(guān)聯(lián)引擎概述

OSSIM平臺下實(shí)現(xiàn)關(guān)聯(lián)分析技術(shù)核心是關(guān)聯(lián)引擎，在OSSIM傳感器將大量標(biāo)準(zhǔn)化處理的事件被送入關(guān)聯(lián)引擎處理后，它們會經(jīng)歷事件分類處理、聚合、交叉關(guān)聯(lián)、啟發(fā)式關(guān)聯(lián)等多種關(guān)聯(lián)方法，系統(tǒng)會根據(jù)數(shù)據(jù)庫中的安全事件進(jìn)行統(tǒng)計(jì)分類，找出經(jīng)常導(dǎo)致安全事件的發(fā)源地和經(jīng)常被攻擊的端口，在這些階段都會產(chǎn)生事件告警，其安全事件關(guān)聯(lián)過程模塊如下圖所示。

在管理引擎中的事件聚合模塊可以為后續(xù)關(guān)聯(lián)提供高質(zhì)量的安全事件，提高關(guān)聯(lián)引擎效率，而分類處理可將已知可信度高，受關(guān)注高的安全事件直接提升為報(bào)警。而且統(tǒng)計(jì)分類通過對報(bào)警數(shù)據(jù)庫、日志數(shù)據(jù)庫、知識庫綜合進(jìn)行分析統(tǒng)計(jì)，產(chǎn)生受控網(wǎng)段內(nèi)最常被攻擊的主機(jī)和應(yīng)用，統(tǒng)計(jì)相同數(shù)據(jù)源和相同目標(biāo)端口的安全事件的數(shù)量，這樣就可以客觀反映網(wǎng)絡(luò)異常情況。

在OSSIM系統(tǒng)中關(guān)聯(lián)分析功能同樣是由關(guān)聯(lián)引擎來實(shí)現(xiàn)，關(guān)聯(lián)引擎策略文件定義位于/etc/ossim/server/，分析的數(shù)據(jù)由探針來收集，Sensor(傳感器)每天要從網(wǎng)絡(luò)上收集到成千上萬的事件，如果對這些海量的事件信息不加任何處理就直接生成事件，這種做法是沒有意義的。而在報(bào)告之前通過關(guān)聯(lián)分析可以將這些成千上萬的事件進(jìn)行濃縮(類聚)，并確認(rèn)成數(shù)十個(gè)甚至數(shù)個(gè)事件，顯示在Web前端的SIEM中。簡單理解就是OSSIM的網(wǎng)絡(luò)安全事件關(guān)聯(lián)分析能將不同功能的開源網(wǎng)絡(luò)安全檢測工具產(chǎn)生的報(bào)警信息進(jìn)行去偽存真，從而挖掘出真正的網(wǎng)絡(luò)攻擊事件。

2.主要關(guān)鍵詞

OSSIM系統(tǒng)中的風(fēng)險(xiǎn)評估主要圍繞著攻擊威脅(Threat)、漏洞(Vulnerability)、響應(yīng)(Response,即安全措施)、資產(chǎn)(Asset)等來監(jiān)控。風(fēng)險(xiǎn)評估模型嵌入在 OSSIM 關(guān)聯(lián)引擎系統(tǒng)中，關(guān)聯(lián)引擎結(jié)合知識庫中的資產(chǎn)庫、漏洞庫、威脅庫將風(fēng)險(xiǎn)的資產(chǎn)、漏洞、威脅三要素綜合考慮。

3.資產(chǎn)風(fēng)險(xiǎn)計(jì)算

Risk=R(asset,vulnerability,threat)

將資產(chǎn)價(jià)值(Asset)、優(yōu)先級(Priority)、可靠性(Reliability)三個(gè)參數(shù)組合在一起進(jìn)行風(fēng)險(xiǎn)的計(jì)算是簡潔有效的，在OSSIM系統(tǒng)中使用以下公式：

Risk=asset*priority*reliability/25 (風(fēng)險(xiǎn)模型計(jì)算公式1)

其中Asset(資產(chǎn)， 取值范圍0~5)

Priority(優(yōu)先級， 取值范圍0~5)

Reliability(可信度，取值范圍0~10)

由公式(1)計(jì)算每個(gè)Alert事件的Risk值，其中

? Asset 的取值范圍為 0～5，asset默認(rèn)值為2;在OSSIM系統(tǒng)中將資產(chǎn)的關(guān)注程度分為5級，取值由低到高分別為1、2、3、4、5。從表面上理解，數(shù)字的大小決定了風(fēng)險(xiǎn)計(jì)算公式中Risk值的大小，但也有它深層次的含義，比如普通工作站資產(chǎn)等級為1，當(dāng)它遭受DOS攻擊時(shí)，我們只需要簡單端口網(wǎng)絡(luò)連接，如果是數(shù)據(jù)庫服務(wù)器，它的資產(chǎn)等級為5，數(shù)據(jù)庫服務(wù)需要實(shí)時(shí)在線，所以同樣遭受DOS攻擊我們就不能象工作站那樣處理，而應(yīng)自動啟用備用IP地址并將攻擊引向網(wǎng)絡(luò)蜜罐系統(tǒng)。

? 優(yōu)先級Priority 的取值范圍為 0～5，默認(rèn)值為 1，該參數(shù)描述一次成功攻擊所造成的危害程度，數(shù)值越大，則危害程度越高;

? 可信度或者叫可靠性Reliability 的取值范圍為 0～10，默認(rèn)值為 1，可靠性參數(shù)描述一次攻擊可能成功的概率，最高值是10，代表100%可能，所以其值越高，代表越不可靠，大家也可以將此理解為被攻擊的可能性。

大家在操作OSSIM時(shí)，打開Web UI中的SIEM控制臺，觀察每條Event時(shí)就能發(fā)現(xiàn)風(fēng)險(xiǎn)值由資產(chǎn)值優(yōu)先級和可信度來控制。而網(wǎng)絡(luò)中每個(gè)資產(chǎn)都是有價(jià)值的，這個(gè)價(jià)值的量化就通過資產(chǎn)值來實(shí)現(xiàn)，默認(rèn)每個(gè)資產(chǎn)為2(范圍1~5)，在風(fēng)險(xiǎn)計(jì)算公式可以分析出，風(fēng)險(xiǎn)計(jì)算不將資產(chǎn)值作為影響風(fēng)險(xiǎn)結(jié)果的主要因素，例如某些數(shù)據(jù)庫服務(wù)器資產(chǎn)值很高，則計(jì)算出的風(fēng)險(xiǎn)值也會很大，而那些資產(chǎn)值小的工作站，在遭受嚴(yán)重攻擊的節(jié)點(diǎn)風(fēng)險(xiǎn)值小，這樣很難被關(guān)注，從而失去原本的真實(shí)性，所以就讓資產(chǎn)值的范圍在1~5之間，影響風(fēng)險(xiǎn)值也就小。

場景舉例：

一個(gè)主機(jī)在一個(gè)VLAN連接到5個(gè)不同IP地址的445端口，這有可能是正常網(wǎng)絡(luò)通訊，如果連接了15臺機(jī)器的445端口這就比較可疑，如果有150個(gè)這樣的連接并且持續(xù)很長時(shí)間，那就很可能受到蠕蟲攻擊，需人工要進(jìn)一步核實(shí)。

4.Risk & Priority & Reliability的關(guān)系實(shí)例

根據(jù)公式計(jì)算，誰都會，上述公式1中各個(gè)參數(shù)之間有什么內(nèi)在聯(lián)系?

在我們收集到的事件中，重復(fù)事件占比多，其中主要是Risk=0的風(fēng)險(xiǎn)，例如以Cisco ASA的一個(gè)ICMP事件為例，其PRIO=1，REL=1，ASET=2，根據(jù)上面的風(fēng)險(xiǎn)模型計(jì)算公式計(jì)算出來約等于0。

分析上圖發(fā)現(xiàn)在關(guān)聯(lián)規(guī)則中Reliability(可信度)系統(tǒng)為它已經(jīng)設(shè)定好了一個(gè)初始值，試想如果是個(gè)常量，那在動態(tài)的網(wǎng)絡(luò)攻擊中將會產(chǎn)生大量誤報(bào)，那么在引入交叉關(guān)聯(lián)機(jī)制之后，就將網(wǎng)絡(luò)安全報(bào)警和具體網(wǎng)絡(luò)應(yīng)用服務(wù)、開放端口、開放端口的漏洞信息進(jìn)行空間上的關(guān)聯(lián)，以便確定攻擊是否可達(dá)到，這樣可信度值(reliability)就必定為變量，對于那些含有不可能存在端口安全事件直接丟棄(系統(tǒng)的KDB中有一張即時(shí)更行的列表)下圖展示了reliability參數(shù)在OSSIM關(guān)聯(lián)規(guī)則變化過程。

5.事件聚合

我們知道冗余報(bào)警會嚴(yán)重干擾管理員對故障的判斷，此時(shí)需要這些信息進(jìn)行聚合，通過從海量報(bào)警中，將一些相似的報(bào)警進(jìn)行聚合處理，把冗余部分去掉，減少了報(bào)警條數(shù)，大大減輕了關(guān)聯(lián)模塊做關(guān)聯(lián)分析的任務(wù)量。

合并冗余的報(bào)警信息主要是從3方面來考慮：

(1)合并基于主機(jī)的監(jiān)控 Ossec 產(chǎn)生的冗余報(bào)警事件。

(2)合并基于網(wǎng)絡(luò)的監(jiān)控 Snort/Suricata 產(chǎn)生的冗余報(bào)警事件。

(3)合并主機(jī)監(jiān)控 Ossec 和網(wǎng)絡(luò)監(jiān)控 Snort 對相同攻擊產(chǎn)生的報(bào)警信息。

Snort報(bào)警信息的屬性比較全面，特征明顯，對Snort產(chǎn)生出來的報(bào)警事件合并的過程可以采用基于屬性相似度的方法。而對于Ossec的報(bào)警事件的合并，OSSIM采用基于事件ID和報(bào)警類別信息相結(jié)合的方法。目前Ossec有900多條檢測規(guī)則，均以XML格式存儲。經(jīng)過統(tǒng)計(jì)分析以后可以按報(bào)警的行為來分類共分為80個(gè)報(bào)警大類，常見的包括：Syslog、Firewall、IDS、Web、Squid、Windows等。以O(shè)SSEC報(bào)警的事件ID為入口，從而進(jìn)行一級級的類與子類之間的匹配以達(dá)到匹配與合并的目的。

根據(jù)信息來源分析我們看到聚合的對象是基于網(wǎng)絡(luò)的 Snort /Suricata和基于主機(jī)的Ossec安全產(chǎn)品產(chǎn)生的報(bào)警數(shù)據(jù)，由于 Snort 的報(bào)警數(shù)據(jù)(包括IP 地址，攻擊內(nèi)容和端口等之類的要素)中含有協(xié)議屬性，可對其用基于規(guī)則的方式進(jìn)行聚合，在聚類過程中可以保證報(bào)警信息得到正確的歸類。

Snort支持多種協(xié)議，報(bào)警事件聚類后再合并能節(jié)省大量時(shí)間。而同樣由于其屬性明顯的特征，所以對冗余信息的合并基于其屬性的相似度的方式進(jìn)行，這樣合并誤差小。而對于 Ossec 產(chǎn)生的報(bào)警信息，其報(bào)警事件的 ID 為入口，逐步的按報(bào)警類別進(jìn)行聚合，合并出來的誤差低，以 ID 為入口按根類別進(jìn)行合并的方式，節(jié)省了遍歷報(bào)警信息進(jìn)行聚類與合并的時(shí)間。

OSSIM中使用了主機(jī)監(jiān)控軟件 Ossec 來實(shí)現(xiàn)對主機(jī)的審計(jì)記錄，系統(tǒng)日志和應(yīng)用程序的采集分析。它支持文件的完整性監(jiān)控、注冊表監(jiān)控、端口的監(jiān)控、Rootkit 檢測和部分進(jìn)程監(jiān)控。同時(shí)使用Snort 對網(wǎng)絡(luò)上的數(shù)據(jù)包進(jìn)行采集，完成實(shí)時(shí)流量分析和對網(wǎng)絡(luò)上的 IP 包進(jìn)行測試等功能，也可進(jìn)行協(xié)議分析，內(nèi)容查找和匹配，能用來探測多種攻擊和嗅探(如緩沖區(qū)溢出和 ShellCode攻擊等)。

對于兩條事件而言，如果它們的相似程度較高，那么就認(rèn)為它們是同一個(gè)攻擊而進(jìn)行合并，否則就認(rèn)為是互不相關(guān)的攻擊行為。

我們可以從計(jì)算兩條報(bào)警信息之間的相似度入手，首先要考慮的是這兩條報(bào)警的共有屬性。這些屬性包括攻擊源、目標(biāo)(主機(jī) IP 和端口)、攻擊類型、MAC 地址、時(shí)間信息和事件 ID 等。據(jù)此我們可以對報(bào)警事件的屬性進(jìn)行抽象形式化建模，把它們的屬性定義為一個(gè)事件屬性集。我們對冗余的報(bào)警事件所采用的合并方法的出發(fā)點(diǎn)就是對相同的攻擊行為的報(bào)警信息之間存在著很高的相似度，對不同的攻擊行為的報(bào)警相似度較低。我們對各個(gè)產(chǎn)品的冗余報(bào)警信息合并的同時(shí)也要考慮到這兩個(gè)安全產(chǎn)品產(chǎn)生出來的對同一個(gè)攻擊的報(bào)警信息，盡可能的把所有重復(fù)報(bào)警信息得到有效的壓縮。

如果Snort發(fā)現(xiàn)基于一個(gè)目標(biāo)IP的攻擊，則說明該目標(biāo)IP主機(jī)有漏洞，則其可靠性系數(shù)為10(即100%攻擊成功)。下圖中REL的值為10，即代表當(dāng)前時(shí)間可靠性系數(shù)為10，所以風(fēng)險(xiǎn)值為4。這個(gè)值也可以在數(shù)據(jù)源中修改。

從上可知，可靠性和優(yōu)先級的數(shù)值決定了風(fēng)險(xiǎn)大小，手動修改數(shù)據(jù)源REL/PRIO的方法如下圖所示。注意這樣修改后對全局有效 ，并不是對單條事件。通過傳感器將各個(gè)監(jiān)控節(jié)點(diǎn)數(shù)據(jù)關(guān)聯(lián)聯(lián)系起來，形成一個(gè)數(shù)據(jù)鏈，再由關(guān)聯(lián)分析引擎和規(guī)則一起協(xié)調(diào)工作就能對黑客攻擊行為進(jìn)行分析，追根溯源，并發(fā)出Alarm。下面分析一下它的產(chǎn)生原理。

Alarm Events由關(guān)聯(lián)指令(Correlation Directives)配合Rules所產(chǎn)生，在Alarm中展示的警告信息是通過關(guān)聯(lián)規(guī)則從大量的事件中匹配而得出，在OSSIM 5以后的系統(tǒng)采用了一種圖形化展示OSSIM系統(tǒng)Alarm報(bào)警的模式，這便于管理員重大量安全事件中篩選重要的部分。Alarm事件產(chǎn)生過程如圖所示。

具體Alarm生成步驟如下：

(1)日志收集到OSSIM;

(2)將日志統(tǒng)一進(jìn)行歸一化處理后生成事件;

(3)將這些事件導(dǎo)入關(guān)聯(lián)引擎;

(4)根據(jù)關(guān)聯(lián)規(guī)則匹配出新的事件。

通過上圖顯示的畫面，即使是一個(gè)安全小白也能輕松檢測到針對SSH服務(wù)的暴力破解行為。

在這張圖中僅以System Compromise→Worm infection →Internal Host scanning 告警為例，在系統(tǒng)危害中出現(xiàn)了內(nèi)部主機(jī)的掃描行為，這類行為疑似為網(wǎng)絡(luò)蠕蟲的掃描，我們知道掃描主機(jī)漏洞往往是蠕蟲傳播的前提，蠕蟲常常會通過ICMP Ping包、TCP SYN、FIN、RST以及ACK包探測，而且具有著隨機(jī)性，從圖中看出，系統(tǒng)定義出這類事件的風(fēng)險(xiǎn)值，掃描的持續(xù)時(shí)間，源地址、目的地址，源端口、目標(biāo)端口以及關(guān)聯(lián)等級，對于這種異常行為很容易被OSSIM發(fā)現(xiàn)。

五、關(guān)聯(lián)規(guī)則指令

關(guān)聯(lián)分析的核心通過一個(gè)或一組關(guān)聯(lián)指令來完成，下面用SSH暴力破解的例子加以說明，SSH暴力破解(Brute Force)大約自UNIX誕生之后，就衍生出來的一種攻擊行為，據(jù)統(tǒng)計(jì)發(fā)現(xiàn)大約有50%以上的用戶名是root。一個(gè)低可靠性(low reliability)的SSH 服務(wù)器，在經(jīng)過100登錄嘗試之后成功登錄，而高可靠性(high reliability)的SSH服務(wù)器，則經(jīng)過10000次登錄才成功，那么關(guān)聯(lián)引擎可通過在一定時(shí)間內(nèi)，登錄的次數(shù)，以及這些時(shí)間的不同源地址和相同目標(biāo)IP地址，以及這些IP地址來自于那些國家，它們信譽(yù)度如何等信息來綜合判定攻擊以及作出響應(yīng)。

檢測SSH暴力攻擊的關(guān)聯(lián)指令規(guī)則源碼用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>

參數(shù)解釋：

這些指令常用XML來描述，如果不理解其含義，如果自己寫腳本或修改腳本時(shí)就無從下手。整個(gè)關(guān)聯(lián)規(guī)則系統(tǒng)有個(gè)完整的規(guī)則屬性，含義如下：

Id，該屬性允許定義相關(guān)聯(lián)指令的唯一標(biāo)識。這種編號必須遵循由OSSIM發(fā)布的指令。以便在框架中(關(guān)聯(lián)菜單的子指令菜單)實(shí)現(xiàn)的分類顯示得到準(zhǔn)確實(shí)現(xiàn)。編號指令在此子菜單中可用。

Name，此屬性允許定義指令的名稱。(當(dāng)指令匹配時(shí)顯示)

SRC , 源IP地址

DST，目標(biāo)IP地址

Port_from 源端口

Port_to 目標(biāo)端口

Priority，此屬性允許定義關(guān)聯(lián)指令的優(yōu)先級。

Type，該屬性定義規(guī)則類型。僅有兩種類型的規(guī)則。

Detector，使用檢測部件信息的規(guī)則，其包含于服務(wù)器數(shù)據(jù)庫。

Reliability(可靠性，也叫可信度)，此參數(shù)越大(接近10)，表明報(bào)警越真實(shí)。此參數(shù)在關(guān)聯(lián)過程中至關(guān)重要。實(shí)際上，隨著規(guī)則的陸續(xù)匹配，本組報(bào)警誤報(bào)的概率會降低。所以有可能在每個(gè)標(biāo)記規(guī)則中修改高級報(bào)警的可靠性。其后的規(guī)則會以相對(例如：+3，意味著相對于前面的規(guī)則，全局可靠性提高了3個(gè)等級)或者絕對(例如：7，表明現(xiàn)在的可靠性等級是7)的方式估計(jì)其等級。

Occrrence ，出現(xiàn)頻率

Plugin_id，此屬性定義由規(guī)則預(yù)計(jì)的報(bào)警的來源。實(shí)際上，每個(gè)插件有一個(gè)相關(guān)標(biāo)識，此標(biāo)識允許在相關(guān)性規(guī)則中引用該插件。

Plugin_sid，此參數(shù)定義了和插件相關(guān)聯(lián)的事件。實(shí)際上，所有被OSSIM恢復(fù)的事件都被索引(依照其插件)并且配置。通過在配置菜單的插件子菜單中點(diǎn)擊所需plugin_id便可以配置plugin_sid。例如，由plugin_id 1501和plugin_sid400提供的報(bào)警等同于：“apache：錯誤請求”有了這兩種屬性(plugin_id和plugin_sid)，就可以精確定義規(guī)則所預(yù)計(jì)的事件。

Time_out，超時(shí)設(shè)定，此屬性允許表明符合某個(gè)規(guī)則的事件的等待時(shí)間。如果此事件沒有在給定的時(shí)間(通過屬性以秒計(jì)算)內(nèi)發(fā)生，相關(guān)性指令會結(jié)束并返回到前面規(guī)則計(jì)算的結(jié)果。此屬性可以確定由規(guī)則所預(yù)計(jì)的警報(bào)(事件)必須顯示的臨時(shí)窗口。

Protocol(協(xié)議)，此屬性允許配置由規(guī)則預(yù)計(jì)的網(wǎng)絡(luò)事件類型?？梢远x三種類型的協(xié)議：TCP、UDP、ICMP，此屬性允許絕對引用。此意味著有可能重新使用和前規(guī)則匹配的協(xié)議類型。所以，只需做如下表明：protocol=“1:PROTOCOL”，以此來明確表達(dá)此規(guī)則的協(xié)議和由一級規(guī)則相匹配的協(xié)議相同。如果要恢復(fù)二級規(guī)則匹配的協(xié)議，只需明確表達(dá)：protocol=“2:PROTOCOL” 。

From，此屬性允許明確表明預(yù)報(bào)警的IP源地址?？梢允褂?種不同的方法來表示：

①ANY，表明任意地址源和此屬性匹配。

②x.x.x.x IP地址。

③通過引用，和引用協(xié)議屬性原則一致。(例如：1：SCR_IP= 和一級相關(guān)指令匹配的報(bào)警的源地址，2：DST_IP= 和二級相關(guān)性指令的報(bào)警的目標(biāo)地址)。

六、關(guān)聯(lián)規(guī)則實(shí)戰(zhàn)

將規(guī)則導(dǎo)入OSSIM關(guān)聯(lián)分析引擎后顯示，如下圖所示。

準(zhǔn)備工作就緒之后開始測試：

在攻擊機(jī)(Kali 2021，192.168.183.158)啟動medusa對，靶機(jī)開放的ssh端口進(jìn)行測試(命令從略)。隨后在登錄靶機(jī)(192.168.183.139)查看SSH日志：

傳統(tǒng)方式分析這些日志費(fèi)時(shí)費(fèi)力而且往往不能及時(shí)判定故障，下面我沒看以下OSSIM的歸一化事件，如下圖所示。

關(guān)聯(lián)分析結(jié)果：

從上圖看出風(fēng)險(xiǎn)值為3，很顯然可以定性為針對SSH服務(wù)的暴力攻擊。這一過程是自動化完成，規(guī)則寫對了，無需人工干預(yù)，自動實(shí)現(xiàn)報(bào)警。

千言萬語不如一段視頻表達(dá)的清晰：下面這段視頻是日志關(guān)聯(lián)分析實(shí)戰(zhàn)片段。

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

七、總結(jié)

對于新手而言從一張白紙開始寫規(guī)則有些難了，但是對照系統(tǒng)給出的默認(rèn)規(guī)則，照葫蘆畫瓢還是可以實(shí)現(xiàn)的，不管這個(gè)模型是否完善，先用起來，然后逐步修改。在合適的時(shí)間，對系統(tǒng)進(jìn)行滲透測試，然后監(jiān)控SIEM的反應(yīng)，觀察它是否產(chǎn)生正確的警報(bào)，而警報(bào)是否提供足夠的信息來協(xié)助相應(yīng)這弄清楚發(fā)生了什么威脅，如果沒有那就需要修改規(guī)則，然后你需要不斷的優(yōu)化閾值。本文簡要為大家介紹了OSSIM平臺下的網(wǎng)絡(luò)日志關(guān)聯(lián)分析技術(shù)希望能給大家在日常網(wǎng)絡(luò)安全運(yùn)維中提供一些幫助。