深度學(xué)習(xí)OSSIM關(guān)聯(lián)分析（附源碼注解）

從海量安全事件中挖掘有用的威脅信息與情報(bào)是當(dāng)今討論的熱門話題，同時(shí)這也是一個(gè)難點(diǎn)？怎么實(shí)現(xiàn)呢？這里用到一種技術(shù)叫做關(guān)聯(lián)分析，他也是SIEM（Security? Information Event Management安全信息和事件管理）系統(tǒng)中最常見的事件檢測(cè)手段，這并不是什么新鮮事物，20年前就已經(jīng)有人提出來了。通常基于時(shí)序來對(duì)相同數(shù)據(jù)源或來自不同數(shù)據(jù)源的安全事件，使用關(guān)聯(lián)規(guī)則來進(jìn)行綜合的關(guān)聯(lián)分析，下面介紹關(guān)聯(liá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ǔ)的，這些檢測(cè)規(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)行分類． 該算法較適合于本文檢測(cè)場(chǎng)景，通常 SIEM 系統(tǒng)中絕大多數(shù)的日志為正常事件，通過對(duì)正常事件訓(xùn)練建模，來檢測(cè)異常或Gong JI事件，這就是理論上說的One-Class SVM（單類支持向量機(jī)）。OSSIM系統(tǒng)中需要更多維度特征向量，才能準(zhǔn)確判斷Gong JI源，避免檢測(cè)精度低或過擬合情況． 算法輸入是經(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ī)則庫(kù)中抽取了幾個(gè)重要的字段 plugin_id_name，plu-gin_id_description，sid_name，并將所有字段拆分成關(guān)鍵詞標(biāo)簽，然后針對(duì)每一條檢測(cè)規(guī)則生成其關(guān)鍵詞標(biāo)簽統(tǒng)計(jì)模型，利用規(guī)則統(tǒng)計(jì)模型來代替原始的規(guī)則來檢測(cè)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地址來自于那些國(guó)家，它們信譽(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:單擊此按鈕，將檢測(cè)當(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)指令AvAttacks,Possible DDOS

● Username：事件中指定的用戶名

● Pass：???? 事件中指定的口令

● Userdata1~Userdata8:事件中指定的數(shù)據(jù)域。

圖5? 查看更對(duì)關(guān)聯(lián)規(guī)則屬性

注意，From、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 惡意軟件（包括檢測(cè)各種蠕蟲的規(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場(chǎng)景，在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場(chǎng)景，Event 代表在當(dāng)前已發(fā)生的Gong JI場(chǎng)景下，一個(gè)Gong JI場(chǎng)景由若干條規(guī)則組成，這些規(guī)則可能是“與”和“或”的關(guān)系。這樣表示的好處是，我們清楚的知道，如果一個(gè)Gong JI場(chǎng)景發(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場(chǎng)景的可靠性做修改，將結(jié)果存入New_Reliability中；規(guī)則部分的其它屬性代表了將和它做匹配的Event 的屬性值；而和數(shù)據(jù)庫(kù)的具體交互是通過Action 來表示。

下面我們看個(gè)實(shí)際的例子，下面這段指令主要是用來檢測(cè)公網(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: 探測(cè)器規(guī)則自動(dòng)收集從代理發(fā)來的記錄，包括Snort、Apache、Arpwatch等。

● Monitor：監(jiān)控器負(fù)責(zé)查詢Ntop服務(wù)發(fā)來的數(shù)據(jù)和會(huì)話。

● Name：事件數(shù)據(jù)庫(kù)中的規(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場(chǎng)景的策略文件，描述的結(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場(chǎng)景不同這個(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場(chǎng)景建立對(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場(chǎng)景中一條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檢測(cè)插件，產(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場(chǎng)景建立對(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)，檢測(cè)規(guī)則的編寫往往出現(xiàn)滯后的情況， 大家也許會(huì)考慮能否利用AI技術(shù)和數(shù)據(jù)融合技術(shù)進(jìn)行智能化的數(shù)據(jù)挖掘呢，這些剛高級(jí)的黑科技在實(shí)際應(yīng)用中往往生成的關(guān)聯(lián)規(guī)則檢測(cè)精度較低，檢測(cè)結(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è)指令克?。Ｆ渲忻總€(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 最 新 作 品

?

?

?

?

?

?