從海量安全事件中挖掘有用的威脅信息與情報(bào)是當(dāng)今討論的熱門話題,同時(shí)這也是一個(gè)難點(diǎn)?怎么實(shí)現(xiàn)呢?這里用到一種技術(shù)叫做關(guān)聯(lián)分析,他也是SIEM(Security? Information Event Management安全信息和事件管理)系統(tǒng)中最常見的事件檢測手段,這并不是什么新鮮事物,20年前就已經(jīng)有人提出來了。通?;跁r(shí)序來對(duì)相同數(shù)據(jù)源或來自不同數(shù)據(jù)源的安全事件,使用關(guān)聯(lián)規(guī)則來進(jìn)行綜合的關(guān)聯(lián)分析,下面介紹關(guān)聯(lián)分析的具體功能。
專注于為中小企業(yè)提供成都網(wǎng)站制作、成都做網(wǎng)站、外貿(mào)營銷網(wǎng)站建設(shè)服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)安遠(yuǎn)免費(fèi)做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都,凝聚了一批互聯(lián)網(wǎng)行業(yè)人才,有力地推動(dòng)了上千余家企業(yè)的穩(wěn)健成長,幫助中小企業(yè)通過網(wǎng)站建設(shè)實(shí)現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。
??? 通常來說,一次惡意Gong JI會(huì)在多個(gè)安全設(shè)備或應(yīng)用程序(如網(wǎng)絡(luò)防火墻,交換機(jī),Web 應(yīng)用日志,SQL 日志,審核日志等)中留下痕跡. 然而,所有這些信息都是孤立隔絕的,被保存在不同的設(shè)備日志中,如果利用了關(guān)聯(lián)分析技術(shù)就可以快速定位故障。
關(guān)聯(lián)分析為什么有如此神通廣大呢?其實(shí)后臺(tái)有很多復(fù)雜的關(guān)聯(lián)規(guī)則最為基礎(chǔ)的,這些檢測規(guī)則可以識(shí)別?A t t a c k?事件,實(shí)際上這些規(guī)則是人工在大量實(shí)踐中總結(jié)出來生成對(duì)Gong JI事件的一種語言描述,并對(duì)其進(jìn)行了精確分類,分類越細(xì)描述越準(zhǔn)確,識(shí)別率就越高。
Tips:?下文中“Gong Ji”“**”代表銘感詞匯,你懂得。
?
一、關(guān)聯(lián)分析核心思想
關(guān)聯(lián)分析技術(shù)的核心思想是通過對(duì)某一類事件進(jìn)行訓(xùn)練建立行為基線,基線范圍外的事件視為異常事件來進(jìn)行分類. 該算法較適合于本文檢測場景,通常 SIEM 系統(tǒng)中絕大多數(shù)的日志為正常事件,通過對(duì)正常事件訓(xùn)練建模,來檢測異?;騁ong JI事件,這就是理論上說的One-Class SVM(單類支持向量機(jī))。OSSIM系統(tǒng)中需要更多維度特征向量,才能準(zhǔn)確判斷Gong JI源,避免檢測精度低或過擬合情況. 算法輸入是經(jīng)過 OSSIM 歸一化后具備相同數(shù)據(jù)結(jié)構(gòu)的安全事件,輸出則為帶有標(biāo)記的安全事件,標(biāo)記分為兩類:正常(Negative)與Gong JI(Positive). 而OSSIM關(guān)聯(lián)分析引擎的輸出就是 One-Class SVM分類算法輸出的帶標(biāo)記的正常與Gong JI事件。
通過深入分析 SIEM 系統(tǒng)的關(guān)聯(lián)規(guī)則,其中最常見的配置字段如:event_id,timestamp,plugin_id,plugin_sid,src_ip,src_port,des_ip,des_port,protocol 等。 為了使關(guān)聯(lián)分析規(guī)則不依賴于傳感器配置,本文從 OSSIM 的規(guī)則庫中抽取了幾個(gè)重要的字段 plugin_id_name,plu-gin_id_description,sid_name,并將所有字段拆分成關(guān)鍵詞標(biāo)簽,然后針對(duì)每一條檢測規(guī)則生成其關(guān)鍵詞標(biāo)簽統(tǒng)計(jì)模型,利用規(guī)則統(tǒng)計(jì)模型來代替原始的規(guī)則來檢測Gong JI。
關(guān)聯(lián)分析的核心通過一個(gè)或一組關(guān)聯(lián)指令來完成,下面用SSH**破解的例子加以說明,如圖1所示,SSH**破解(Brute Force)大約自UNIX誕生之后,就衍生出來的一種Gong JI行為,據(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ù)度如何等信息來綜合判定Gong JI以及作出響應(yīng)。
圖1
下面大家將親生經(jīng)歷關(guān)聯(lián)引擎的關(guān)聯(lián)指令的組成結(jié)構(gòu)。
?
二、關(guān)聯(lián)指令配置界面
? OSSIM中關(guān)聯(lián)指令的界面通過Configuration->Threat Intelligence->Directives打開,經(jīng)過前面幾節(jié)的內(nèi)容的學(xué)習(xí),大家或多或少的已經(jīng)接觸過關(guān)聯(lián)指令的界面,下面我們進(jìn)行一下歸納,如下圖2所示。
圖2? OSSIM? 關(guān)聯(lián)指令界面
關(guān)鍵功能解釋:
New Directive:單擊此選項(xiàng)以從頭開始創(chuàng)建一個(gè)新的指令。
Test Directives:單擊此按鈕,將檢測當(dāng)前新建/修改的指令是否正確。
Restart Server:單擊此按鈕,將重啟ossim-server進(jìn)程,凡是修改了任何一條關(guān)聯(lián)指令都需重新啟動(dòng)Server,按這個(gè)按鈕比你重啟整個(gè)USM服務(wù)器更明智。
需要注意的是,雖然重啟時(shí)間短暫,但重啟期間所有關(guān)聯(lián)數(shù)據(jù)會(huì)丟失。
圖3 一條完整指令
● Sensor:傳感器,用于收集各種事件信息。
● Protocol:協(xié)議,包括ANY、TCP、UDP、ICMP。
● Sticky different:
? ?還記得Linux基礎(chǔ)是指中,用于文件及目錄屬性設(shè)定的sticky位嗎?從OSSIM 4.3起在關(guān)聯(lián)指令中添加了新屬性,Sticky different(不同的粘粘位)域,規(guī)則中Sticky different為None。它是用來設(shè)定指令規(guī)則的屬性,
有關(guān)Sticky different的取值大家可參考/etc/ossim/server/directives.xsd文件
<xs:simpleType name="stickydifferenttype">
... ...略
</xs:simpleType>
? ?當(dāng)新收集的事件到達(dá)關(guān)聯(lián)引擎時(shí),它將和已有的事件相關(guān)聯(lián),如果事件屬性(如IP地址和端口號(hào))相同,但一個(gè)指令的屬性里可以設(shè)置不同的粘粘位,比如None、DST_PORT、SRC_IP、PLUGIN_ID等,用來區(qū)別收到的不同事件,以便進(jìn)行相互關(guān)聯(lián)。例如在端口掃描類Gong JI中,如果你設(shè)置目標(biāo)端口為Sticky different,那么只有來自不同目標(biāo)端口的事件被關(guān)聯(lián)。
三、在OSSIM的Web UI中查看效果
下面我們查看實(shí)際的例子,如圖4所示。
圖4? STICKY DIFF
打開/etc/ossim/server/alienvault-dos.xml查看關(guān)聯(lián)指令A(yù)vAttacks,Possible DDOS
● Username:事件中指定的用戶名
● Pass:???? 事件中指定的口令
● Userdata1~Userdata8:事件中指定的數(shù)據(jù)域。
圖5? 查看更對(duì)關(guān)聯(lián)規(guī)則屬性
注意,F(xiàn)rom、To、Data source 、Event Type 列下方的號(hào)表示可修改,Action下的號(hào)代表可添加規(guī)則 ,但系統(tǒng)默認(rèn)指令中的規(guī)則不允許修改。
四、深入關(guān)聯(lián)規(guī)則
1.基本操作
? ?在OSSIM利用預(yù)先定義的規(guī)則(/etc/ossim/server/*.xml)來進(jìn)行關(guān)聯(lián)分析。那么我們?nèi)绾尾僮髂?,首先,我們通過Web界面,新建一個(gè)Correlation Directives,新建兩個(gè)規(guī)則ssh和test,然后我們看看詳細(xì)文件內(nèi)容,路徑在/etc/ossim/server目錄,名為user.xml文件。其他默認(rèn)規(guī)則由/etc/ossim/server/directives.xml定義,如圖6所示。
圖6?自定義指令
當(dāng)系統(tǒng)調(diào)用Directive下的策略是,首先根據(jù)categories.xml配置文件讀取相應(yīng)的XML配置文件,這些文件功能如下:
策略文件存儲(chǔ)位置:/etc/ossim/server/及說明
??alienvault-attacks.xml?????? ??AlienVault Gong JI類策略
??alienvault-bruteforce.xml? ????AlienVault**破解類Gong JI
??alienvault-dos.xml???????????? Alienvault拒絕服務(wù)類
??alienvault-malware.xml???????? Alienvault 惡意軟件(包括檢測各種蠕蟲的規(guī)則)
??alienvault-misc.xml??????????? Alienvault各種失誤類(Miscellaneous)
??alienvault-network.xml???????? Alienvault網(wǎng)絡(luò)類 (開源版無此項(xiàng))
??alienvault-policy.xml??? ??????Alienvault策略
??alienvault-scan.xml??????????? Alienvault掃描
??user.xml?????????????????????? Alienvault用戶自定義
如果OSSIM關(guān)聯(lián)引擎讀不到這些策略配置文件,在Analysis→Alarm就不會(huì)生成報(bào)警。接下來我們?cè)敿?xì)看看一個(gè)xml的例子。
2.理解規(guī)則樹
關(guān)聯(lián)引擎通過規(guī)則來實(shí)現(xiàn)對(duì)安全事件的關(guān)聯(lián)分析,讀者需要能夠看懂OSSIM的規(guī)則,其中采用了特有的樹形規(guī)則,在規(guī)則樹中的每一個(gè)節(jié)點(diǎn)對(duì)應(yīng)一條關(guān)聯(lián)規(guī)則(rules)。在匹配時(shí)關(guān)聯(lián)引擎將某段時(shí)間內(nèi)收到的統(tǒng)一格式的報(bào)警,從根節(jié)點(diǎn)開始往葉子節(jié)點(diǎn)逐次匹配,系統(tǒng)根據(jù)匹配的結(jié)果可以進(jìn)行事件聚合和再次提升報(bào)警級(jí)別。下面看個(gè)實(shí)例:
圖7 自定義指令內(nèi)容
從上圖可以看出,這種基于事件序列的關(guān)聯(lián)方法中的每條指令相當(dāng)于一顆由規(guī)則組成的樹,所以可以把它叫做基于樹形指令(Directive)的關(guān)聯(lián)方法,其基本思想是根據(jù)相關(guān)事件序列創(chuàng)建一系列的規(guī)則來表示Gong JI場景,在OSSIM系統(tǒng)中采用了XML來定義關(guān)聯(lián)序列,關(guān)聯(lián)分析引擎啟動(dòng)時(shí)就將所有關(guān)聯(lián)導(dǎo)入每個(gè)關(guān)聯(lián)規(guī)則序列由下面標(biāo)簽組成將上面的實(shí)際xml提煉一下,得到如下模板:
<directive id="" name="" priority="">
<rule type="" name="" reliability="" occurence="” from="" to="" port_from="" port_to="" plugin_id=""plugin_sid="">
<rules>
?? <rules>
?? ......
</rules
??? ......
</rule>
</directive>
每個(gè)序列開頭包括兩個(gè)標(biāo)簽“directive_id”和“directive name”,而每個(gè)序列,又包括很多規(guī)則,規(guī)則之中又可以嵌套規(guī)則,即遞歸方法。
其中Rule 代表規(guī)則,規(guī)則后面代表一個(gè)可能發(fā)生的Gong JI場景,Event 代表在當(dāng)前已發(fā)生的Gong JI場景下,一個(gè)Gong JI場景由若干條規(guī)則組成,這些規(guī)則可能是“與”和“或”的關(guān)系。這樣表示的好處是,我們清楚的知道,如果一個(gè)Gong JI場景發(fā)生,那么只需要滿足哪些規(guī)則即可。
通過計(jì)算每個(gè)Rule 里的Reliability 來確認(rèn)這個(gè)Gong JI發(fā)生的可信度是多少。其中Scene 的id用directive_id來表示;前面講過Reliability 可以是0~10之間的數(shù),直接給可靠性賦值,也可以使一個(gè)修改量,表示當(dāng)這個(gè)規(guī)則滿足時(shí)將前一步Gong JI場景的可靠性做修改,將結(jié)果存入New_Reliability中;規(guī)則部分的其它屬性代表了將和它做匹配的Event 的屬性值;而和數(shù)據(jù)庫的具體交互是通過Action 來表示。
下面我們看個(gè)實(shí)際的例子,下面這段指令主要是用來檢測公網(wǎng)服務(wù)器是否可用,其中包含了兩個(gè)規(guī)則。
<directive id="500000" name="Public Web Server unavailable" priority="1">
? ???<rule type="detector" name="server unavailable" reliability="1"
??? occurrence="1" from="192.168.11.100" to="ANY" port_from="ANY" port_to="ANY"
??? plugin_id="1525" plugin_sid="1,7,9">
? ??<rules>
??? <rule type="monitor" name="Ping Baidu Server ?in order to check internet connection"
????? reliability="10" from="www.baidu.com" to="www.baidu.com" plugin_id="2009" plugin_sid="1" condition="gt" value="0" interval="20" time_out="120" />
? ??</rules>
</directive>
關(guān)鍵參數(shù)解釋:
● Detector: 探測器規(guī)則自動(dòng)收集從代理發(fā)來的記錄,包括Snort、Apache、Arpwatch等。
● Monitor:監(jiān)控器負(fù)責(zé)查詢Ntop服務(wù)發(fā)來的數(shù)據(jù)和會(huì)話。
● Name:事件數(shù)據(jù)庫中的規(guī)則名稱。
● Reliability:可靠性
● Plugin_id:插件ID,查看更多插件ID請(qǐng)參考《開源安全運(yùn)維平臺(tái)OSSIM最佳實(shí)踐》第一章內(nèi)容。
● Plugin_sid:插件子ID號(hào),分配給每個(gè)插件事件的子ID,比如Snort這個(gè)插件ID號(hào)為1001,而1501就是它的子ID號(hào),代表Apache事件的響應(yīng)代碼,當(dāng)然可不止這一件。
● Condition:條件參數(shù)和下面6個(gè)邏輯有關(guān)系,必須符合的邏輯條件匹配規(guī)則如下:
??eq – 等于(Equal)
??ne – 不等于(Not equal)
??lt – 小于(Lesser than)
??gt – 大于(Greater than)
??le – 小于等于(Lesser or equal)
??ge – 大于等于(Greater or equal)
●Interval:間隔,這個(gè)值類似于time_out,用于監(jiān)控類規(guī)則。
?
3.Alienvault-scan規(guī)則描述
再舉一個(gè)OSSIM自帶的例子,我們查看/etc/ossim/server/alienvault-scan.xml這個(gè)掃描Gong JI場景的策略文件,描述的結(jié)構(gòu)就像個(gè)邏輯樹,基本格式如下:
Gree:level 1
?? Yellow : level2
??? Orange:level3
??? Red: level 4
下面給出部分代碼內(nèi)容,如圖8所示
圖8 Gong JI掃描指令示例
● Occurrence,表示發(fā)生次數(shù),默認(rèn)為1,Gong JI場景不同這個(gè)值也不一樣。這個(gè)值越大,越要引起管理員的警覺。這里表示的發(fā)生次數(shù),也就是計(jì)算具有相同的 "from、to、port_from、port_to、plugin_id、plugin_sid" 發(fā)生次數(shù),用以進(jìn)行到關(guān)聯(lián)模式中的下一規(guī)則。
這個(gè)數(shù)值在基于規(guī)則的關(guān)聯(lián)分析中非常有用,例如當(dāng)目標(biāo)IP地址發(fā)生的異常行為事件數(shù)量的頻率達(dá)到了一定數(shù)值時(shí)(某人針對(duì)該系統(tǒng)發(fā)動(dòng)Gong JI),OSSIM會(huì)發(fā)出預(yù)警提示,管理員就可以有針對(duì)性開展深入調(diào)查。當(dāng)然對(duì)源IP也適用。
From表示來源,源地址有以下幾種形式:
①ANY,任意IP地址都可以匹配。
②小數(shù)點(diǎn)和數(shù)字的IPv4形式。
③以逗號(hào)隔開的IPv4地址,不帶掩碼。
④可以使用任意數(shù)目的IP地址,中間用逗號(hào)隔開。
⑤網(wǎng)絡(luò)名稱,可以使用網(wǎng)絡(luò)中事先定義好的網(wǎng)絡(luò)名稱。
⑥相對(duì)值,這種情況比較復(fù)雜,可以引用上條規(guī)則中的IP地址,例如:
l?1:SRC_IP 表示引用前一條規(guī)則的源地址
l?2:DST_IP 表示引用前第二條的目的地址作為源地址
⑦否定形式,可以使用地址的否定形式如 :"!192.168.150.200,HOME_NET"。
如果 HOME_NET = 192.168.150.0/24 將匹配一個(gè)C類子網(wǎng)排除192.168.150.200。
l?Time_out,表示超時(shí),其等待一定時(shí)間以匹配規(guī)則,時(shí)間超出則匹配失敗。
l?Port_from/Port_to,表示來自哪里/目的端口,Port_from可以是ANY,Port_to,可以是一個(gè)端口號(hào)或一個(gè)逗號(hào)分隔的端口序列,1:DST_PORT,也可以否定端口例如,port=“!22,25”。
注意:dst_ip表示目的ip地址,而dst_port則表示目的端口號(hào),ipaddr本地ip地址。
l?Protocol(協(xié)議),可以使用以下字符串:TCP、UDP、ANY。
l?Plugin_id(插件ID),參考plugin中的plugin_id。
l?Plugin_sid(插件SID),每個(gè)事件都是分配一個(gè)子ID。
圖9規(guī)則樹的嵌套
? ?在OSSIM系統(tǒng)運(yùn)行前,必須為已知的Gong JI場景建立對(duì)應(yīng)的樹形規(guī)則集,在啟動(dòng)時(shí),系統(tǒng)將預(yù)先定義好的指令讀入內(nèi)存,在接收到一個(gè)事件 (event)后,先將該event與之前已經(jīng)匹配,而還沒有匹配完的指令中的規(guī)則進(jìn)行匹配,然后在于其他規(guī)則匹配。那么在一個(gè)復(fù)雜的Gong JI場景中一條Event就會(huì)與多條規(guī)則匹配,如果此事件的風(fēng)險(xiǎn)值超過預(yù)先設(shè)定的閾值,則將其alarm屬性設(shè)為真,并在Alarm界面中顯示。
例如:plugin_id="1001" plugin_sid="2008609,2008641"。
在OSSIM 4.6系統(tǒng)中,有385個(gè)數(shù)據(jù)源,這里ID=1001,代表Snort檢測插件,產(chǎn)品類型屬于IDS,主要適用于Snort規(guī)則,其它插件ID還記得嗎?如果忘了請(qǐng)返回本書第1章,查看“插件&功能”對(duì)應(yīng)表。
實(shí)際上在OSSIM系統(tǒng)中,Snort插件ID范圍是1001~1145。在OSSIM 4.8 版中位于Configuration→Threat Intelligence→Data Source可以查看到所有數(shù)據(jù)源。如圖10所示。
圖10 數(shù)據(jù)源分類
在Ossim的關(guān)聯(lián)引擎運(yùn)行之前,必須為所有已知的Gong JI場景建立對(duì)應(yīng)的樹形指令(在開源系統(tǒng)中提供了84條,在OSSIM 4.15的商業(yè)版本提供了1800余條,OSSIM USM 5.x提供2100+條),這也是它的核心價(jià)值的體現(xiàn),在OSSIM啟動(dòng)時(shí),系統(tǒng)會(huì)將所有預(yù)先定義好的指令讀入內(nèi)存,在接收到一個(gè)directive_event后,先將該事件與之前已經(jīng)匹配,而還沒有匹配完的指令中的規(guī)則匹配,然后再與其它指令的規(guī)則匹配。注意一個(gè)事件可以與很多指令中的規(guī)則匹配。
五、 完善規(guī)則
OSSIM系統(tǒng)中的關(guān)聯(lián)規(guī)則生成主要通過安全專家人工編寫,這種方式效率低下,且人工成本難以承受. 對(duì)于新出現(xiàn)的Gong JI和漏洞無法及時(shí)作出響應(yīng),檢測規(guī)則的編寫往往出現(xiàn)滯后的情況, 大家也許會(huì)考慮能否利用AI技術(shù)和數(shù)據(jù)融合技術(shù)進(jìn)行智能化的數(shù)據(jù)挖掘呢,這些剛高級(jí)的黑科技在實(shí)際應(yīng)用中往往生成的關(guān)聯(lián)規(guī)則檢測精度較低,檢測結(jié)果不理想,實(shí)際應(yīng)用效果有限。利用人工神經(jīng)網(wǎng)絡(luò)來自動(dòng)生成關(guān)聯(lián)規(guī)則,是關(guān)聯(lián)分析研究領(lǐng)域今后發(fā)展的方向。
對(duì)于新手而言從一張白紙開始寫規(guī)則有些難了,但是對(duì)照系統(tǒng)給出的默認(rèn)規(guī)則,照葫蘆畫瓢還是可以實(shí)現(xiàn)的,不管這個(gè)模型是否完善,先用起來,然后逐步修改。在合適的時(shí)間,對(duì)自己進(jìn)行***,然后監(jiān)控SIEM的反應(yīng),觀察它是否產(chǎn)生正確的警報(bào),而警報(bào)是否提供足夠的信息來協(xié)助相應(yīng)這弄清楚發(fā)生了什么威脅,如果沒有那就需要修改規(guī)則,然后你需要不斷的優(yōu)化閾值,你是否發(fā)現(xiàn)SIEM報(bào)警過于頻繁,或者非常稀少,你需要調(diào)節(jié)閾值來解決,順便說一句,面對(duì)動(dòng)態(tài)的網(wǎng)絡(luò)Gong JI,這個(gè)調(diào)節(jié)的過程沒有終點(diǎn)如果讀者在學(xué)習(xí)關(guān)聯(lián)規(guī)則的過程中遇到各種問題也可以參考我的新書《開源安全運(yùn)維平臺(tái)OSSIM疑難解析:提高篇》。
?
?
?附件:
下面分享的是OSSIM關(guān)聯(lián)分析的一部分源代碼。
/* **?*?該指令是否與根節(jié)點(diǎn)指令匹配,這里只檢查根節(jié)點(diǎn),并不檢查指令的子節(jié)點(diǎn)** ?*/gboolean sim_directive_match_by_event?(SimDirective??*directive, ??????????????????????????????????????????????????????SimEvent??????*event) { ??SimRule?*rule; ??gboolean?match; ??g_return_val_if_fail?(directive,?FALSE); ??g_return_val_if_fail?(SIM_IS_DIRECTIVE?(directive),?FALSE); ??g_return_val_if_fail?(!directive->_priv->matched,?FALSE); ??g_return_val_if_fail?(directive->_priv->rule_root,?FALSE); ??g_return_val_if_fail?(directive->_priv->rule_root->data,?FALSE); ??g_return_val_if_fail?(SIM_IS_RULE?(directive->_priv->rule_root->data),?FALSE); ??g_return_val_if_fail?(event,?FALSE); ??g_return_val_if_fail?(SIM_IS_EVENT?(event),?FALSE); ??rule?=?SIM_RULE?(directive->_priv->rule_root->data); ??match?=?sim_rule_match_by_event?(rule,?event);? ??return?match; }/* **?*這將檢查事件是否可以與backlog中的某些數(shù)據(jù)匹配。backlog實(shí)際上是一個(gè)包含事件數(shù)據(jù)的指令。每個(gè)backlog條目都是一個(gè)樹,其中包含來自一個(gè)指令的所有規(guī)則(它相當(dāng)于是一個(gè)指令克?。F渲忻總€(gè)規(guī)則(simrule)還包含與規(guī)則匹配的事件的數(shù)據(jù)。** ?*? ?*/gboolean sim_directive_backlog_match_by_event?(SimDirective??*directive, ??????????????????????????????????????????????????????????????????????SimEvent????*event) { ??GNode??????*node?=?NULL; ??g_return_val_if_fail?(directive,?FALSE); ??g_return_val_if_fail?(SIM_IS_DIRECTIVE?(directive),?FALSE); ??g_return_val_if_fail?(!directive->_priv->matched,?FALSE); ??g_return_val_if_fail?(directive->_priv->rule_curr,?FALSE); ??g_return_val_if_fail?(directive->_priv->rule_curr->data,?FALSE); ??g_return_val_if_fail?(SIM_IS_RULE?(directive->_priv->rule_curr->data),?FALSE); ??g_return_val_if_fail?(event,?FALSE); ??g_return_val_if_fail?(SIM_IS_EVENT?(event),?FALSE); ??node?=?directive->_priv->rule_curr->children;??while?(node)??????//**我們必須對(duì)照backlog中的所有規(guī)則節(jié)點(diǎn)檢查事件,除了根節(jié)點(diǎn),因?yàn)樗炄肓藄im_directive_match_by_event是從sim_organizer_correlation調(diào)用的.** ??{ ????SimRule?*rule?=?(SimRule?*)?node->data;????if?(sim_rule_match_by_event?(rule,?event)) ????????{ ????????????g_log?(G_LOG_DOMAIN,?G_LOG_LEVEL_DEBUG,?"sim_directive_backlog_match_by_event;?sim_rule_match_by_event:?True"); ??????????time_t?time_last?=?time?(NULL); ????????????directive->_priv->rule_curr?=?node;?????//?每次事件匹配時(shí),該指令都下一級(jí)到匹配的節(jié)點(diǎn)。下次將根據(jù)此級(jí)別檢查事件。 ????????????????????????????????????????????????????????????????????????????????????????//FIXME:?父節(jié)點(diǎn)中可能存在內(nèi)存泄漏. ??????????directive->_priv->time_last?=?time_last; ??????????directive->_priv->time_out?=?sim_directive_get_rule_curr_time_out_max?(directive); ????????????sim_rule_set_event_data?(rule,?event);??????//這里我們將事件中的各個(gè)字段分配到規(guī)則中,所以每次我們進(jìn)入規(guī)則時(shí),我們可以看到匹配的事件. ??????????sim_rule_set_time_last?(rule,?time_last);??????????if?(!G_NODE_IS_LEAF?(node)) ????????{ ??????????GNode?*children?=?node->children;??????????while?(children) ????????????????{ ??????????????????SimRule?*rule_child?=?(SimRule?*)?children->data; ??????????????????sim_rule_set_time_last?(rule_child,?time_last); ??????????????????sim_directive_set_rule_vars?(directive,?children); ??????????????????children?=?children->next; ????????????????????g_log?(G_LOG_DOMAIN,?G_LOG_LEVEL_DEBUG,?"sim_directive_backlog_match_by_event:?There?are?childrens?in?%d?directive",?directive->_priv->id); ????????????????} ????????????}??????????else ??????????{ ??????????????directive->_priv->matched?=?TRUE; ????????????????g_log?(G_LOG_DOMAIN,?G_LOG_LEVEL_DEBUG,?"sim_directive_backlog_match_by_event:?The?directive?%d?has?matched",?directive->_priv->id); ??????????}??????????return?TRUE; ????????}????????else ????????{ ????????????g_log?(G_LOG_DOMAIN,?G_LOG_LEVEL_DEBUG,?"sim_directive_backlog_match_by_event:?sim_rule_match_by_event:?False"); ????????} ??????node?=?node->next; ????}??return?FALSE; }/* ?*?檢查指令中的所有節(jié)點(diǎn)規(guī)則,以查看....... ?*/gboolean sim_directive_backlog_match_by_not?(SimDirective??*directive) { ??GNode??????*node?=?NULL; ??GNode??????*children?=?NULL; ??g_return_val_if_fail?(directive,?FALSE); ??g_return_val_if_fail?(SIM_IS_DIRECTIVE?(directive),?FALSE); ??g_return_val_if_fail?(!directive->_priv->matched,?FALSE); ??g_return_val_if_fail?(directive->_priv->rule_curr,?FALSE); ??g_return_val_if_fail?(directive->_priv->rule_curr->data,?FALSE); ??g_return_val_if_fail?(SIM_IS_RULE?(directive->_priv->rule_curr->data),?FALSE); ??node?=?directive->_priv->rule_curr->children;??while?(node)? ??{ ????SimRule?*rule?=?(SimRule?*)?node->data;????????//如果規(guī)則已超時(shí)?&&??????? ????if?((sim_rule_is_time_out?(rule))?&&?(sim_rule_get_not?(rule))?&&?(!sim_rule_is_not_invalid?(rule)))? ????????{ ??????????time_t?time_last?=?time?(NULL); ????????directive->_priv->rule_curr?=?node; ??????????directive->_priv->time_last?=?time_last; ??????????directive->_priv->time_out?=?sim_directive_get_rule_curr_time_out_max?(directive); ????????sim_rule_set_not_data?(rule);??????????if?(!G_NODE_IS_LEAF?(node))?//這不是最后的節(jié)點(diǎn),他還有一些子節(jié)點(diǎn). ????????{ ??????????children?=?node->children;??????????while?(children) ????????????????{ ????????????????SimRule?*rule_child?=?(SimRule?*)?children->data; ??????????????????sim_rule_set_time_last?(rule_child,?time_last); ??????????????????sim_directive_set_rule_vars?(directive,?children); ??????????????????children?=?children->next; ????????????????} ????????}????????else?//last?node! ????????{ ??????????directive->_priv->matched?=?TRUE; ????????}????????return?TRUE; ????????} ????node?=?node->next; ??}??return?FALSE; }/* ?*?backlog&directives幾乎是相同的:backlog是存儲(chǔ)指令并填充事件數(shù)據(jù)的地方。 ?*“node”是子節(jié)點(diǎn)函數(shù)。我們需要從引用其級(jí)別的節(jié)點(diǎn)向該節(jié)點(diǎn)添加src_ip、port等。如果“node”參數(shù)是根節(jié)點(diǎn)->子節(jié)點(diǎn)1->子節(jié)點(diǎn)2中的children2,并且我們?cè)赾hildren2中有1:plugin-sid,那么我們必須將根節(jié)點(diǎn)中的plugin-sid添加到children2中。 ?*/void sim_directive_set_rule_vars?(SimDirective?????*directive, ?????????????????????????????????????????????????????GNode????????????*node) { ??SimRule????*rule; ??SimRule????*rule_up; ??GNode??????*node_up; ??GList??????*vars; ??GInetAddr??*ia; ??GInetAddr??*sensor; ??gint????????port; ??gint????????sid; ??SimProtocolType??protocol; ????gchar???????????????*aux?=?NULL; ??g_return_if_fail?(directive); ??g_return_if_fail?(SIM_IS_DIRECTIVE?(directive)); ??g_return_if_fail?(node); ??g_return_if_fail?(g_node_depth?(node)?>?1); ??rule?=?(SimRule?*)?node->data; ??vars?=?sim_rule_get_vars?(rule);
?
?2019 最 新 作 品
?
?
?
?
?
?
當(dāng)前文章:深度學(xué)習(xí)OSSIM關(guān)聯(lián)分析(附源碼注解)
網(wǎng)頁路徑:http://muchs.cn/article42/ihedhc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)網(wǎng)站制作、網(wǎng)站維護(hù)、做網(wǎng)站、全網(wǎng)營銷推廣、云服務(wù)器、建站公司
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)