一、背景

如果運維工程師手里沒有高效的管理工具支持，就很難快速處理故障。市面上有很多運維監(jiān)控工具，例如商業(yè)版的 Solarwinds、ManageEngine以及WhatsUp等，開源的MRTG、Nagios、Cacti、Zabbix、OpenNMS、Ganglia等。

由于它們彼此之間所生成的數(shù)據(jù)沒有關(guān)聯(lián)，無法共享，即便部署了這些工具，很多運維人員并沒有從中真正解脫出來，成千上萬條警告信息堆積在一起，很難識別問題的根源，結(jié)果被海量日志所淹沒，無法解脫出來。

另外在傳統(tǒng)運維環(huán)境中，當(dāng)查看各種監(jiān)控系統(tǒng)時需要多次登錄，查看繁多的界面，更新管理絕大多數(shù)工作主要是手工操作，即使一個簡單的系統(tǒng)變更，需要運維人員逐一登錄系統(tǒng)，若遇到問題，管理員便會在各種平臺間來回查詢，或靠人肉方式搜索故障關(guān)鍵詞，不斷的重復(fù)著這種工作方式。企業(yè)需要一種集成安全的運維平臺，滿足專業(yè)化、標(biāo)準(zhǔn)化和流程化的需要來實現(xiàn)運維工作的自動化管理，通過關(guān)聯(lián)分析及時發(fā)現(xiàn)故障隱患，這種優(yōu)秀的開源平臺叫做OSSIM即開源安全信息管理系統(tǒng)(Open source Security Information Management)，下面讓我們認識一下OSSIM的基本結(jié)構(gòu)和組成

從架構(gòu)上來看，OSSIM系統(tǒng)是一個開放的框架，它的核心價值在于創(chuàng)新的集成各開源軟件之所長，它里面的模塊既有C/S架構(gòu)，又有B/S架構(gòu)，但作為最終用戶主要掌握OSSIM WebUI主要采用B/S架構(gòu)，Web服務(wù)器使用Apache。OSSIM系統(tǒng)結(jié)構(gòu)示意圖如圖1所示。

圖1 OSSIM系統(tǒng)結(jié)構(gòu)

第1層，屬于數(shù)據(jù)采集層，使用各種采集技術(shù)采集流量信息、日志、各種資產(chǎn)信息，經(jīng)過歸一化處理后傳入核心層。改層體現(xiàn)安全事件來源，入侵檢測、防火墻、重要主機發(fā)出的日志都是安全事件來源，它們按發(fā)出機制分為兩類：模式偵查器和異常監(jiān)控(兩者都采集警告信息，功能互補)由它們采集的安全事件，再被Agent轉(zhuǎn)換為統(tǒng)一的格式發(fā)到OSSIM服務(wù)器，這一層就是Sensor要完成的內(nèi)容。

第2層，屬于核心處理層，主要實現(xiàn)對各種數(shù)據(jù)的深入加工處理，包括運行監(jiān)控、安全分析、策略管理、風(fēng)險評估、關(guān)聯(lián)分析、安全對象管理、脆弱性管理、事件管理、報表管理等。該層中OSSIM Server是主角，OSSIM服務(wù)器，主要功能是安全事件的集中并對集中后的事件進行關(guān)聯(lián)分析、風(fēng)險評估及嚴重性標(biāo)注等。所謂的集中就是以一種統(tǒng)一格式組織所有系統(tǒng)產(chǎn)生的安全事件告警信息(Alarms)并將所有的網(wǎng)絡(luò)安全事件告警存儲到數(shù)據(jù)庫，這樣就完成了對網(wǎng)絡(luò)中所產(chǎn)生事件的一個龐大視圖。系統(tǒng)通過事件序列關(guān)聯(lián)和啟發(fā)式算法關(guān)聯(lián)來更好的識別誤報和偵查攻擊的能力。

OSSIM本質(zhì)上通過對各種探測器和監(jiān)控產(chǎn)生的告警進行格式化處理，再進行關(guān)聯(lián)分析，通過后期這些處理能提高檢測性能，即減少告警數(shù)量，減小關(guān)聯(lián)引擎的壓力，從整體上提高告警質(zhì)量。

第3層，屬于數(shù)據(jù)展現(xiàn)層，主要負責(zé)完成與用戶之間的交互，達到安全預(yù)警和事件監(jiān)控、安全運行監(jiān)控、綜合分析的統(tǒng)一展示，形式上以圖形化方式展示給用戶。Web框架(Framework)控制臺界面即OSSIM的Web UI(Web User Interface，Web用戶界面)，其實就是OSSIM系統(tǒng)對外的門戶站點，它主要由儀表盤、SIEM控制臺、Alarm控制臺、資產(chǎn)漏洞掃描管理、可靠性監(jiān)控、報表及系統(tǒng)策略等部分組成。

二、 主要模塊的關(guān)系

OSSIM系統(tǒng)主要使用了PHP、Python、Perl和C等四種編程語言，從軟件層面上看OSSIM框架系統(tǒng)包括五大模塊：Agent模塊、Server模塊、Database數(shù)據(jù)庫模塊、Frameworkd模塊以及Framework模塊，邏輯結(jié)構(gòu)圖見2所示。

圖2 Ossim系統(tǒng)邏輯結(jié)構(gòu)

五個模塊之間的數(shù)據(jù)流向如圖3所示：

圖3 五大模塊的數(shù)據(jù)流向

① Agent至Server：來自各個傳感器的安全事件被對應(yīng)Agent格式化后，以加密字符串傳給Server。

② Server至Agent：發(fā)送有關(guān)請求命令(request command)，以字符串方式向Agent傳送，主要是要求Agent完成插件的啟動停止及獲取信息等。

③ Server至Frameworkd:發(fā)送請求命令，要求Frameworkd針對Alarm采取相應(yīng)操作，例如執(zhí)行外部程序或發(fā)出Email來通知管理員。

④ Framework至Server：發(fā)送請求命令至Server。要求Server通知Agent對插件(Plugins)進行啟動、停止等操作。

⑤ Framework至Frameworkd:發(fā)送請求命令，要求Frameworkd啟動OpenVas掃描進程。

⑥ Frameworkd至Framework:傳送OpenVas掃描結(jié)果在前端頁面中顯示。

⑦ Database至Agent和Server：向Agent和Server提供數(shù)據(jù)。

⑧ Server至Database：Server需要將Events、Alarms等數(shù)據(jù)存入數(shù)據(jù)庫并索引或更新操作。

⑨ Database至Frameworkd:在Frameworkd中的Openvas掃描和動作需要用調(diào)用數(shù)據(jù)庫里的數(shù)據(jù)。

⑩ Frameworkd至Database：在Frameworkd執(zhí)行過程中將Openvas掃描結(jié)果存入數(shù)據(jù)庫。

⑾Database至Framework:PHP頁面顯示需要調(diào)用數(shù)據(jù)庫的告警事件。

⑿Framework至Database：用戶參數(shù)設(shè)置信息需要存入數(shù)據(jù)庫。

三、安全插件(Plugins)

OSSIM系統(tǒng)中插件繁多，超乎你的想象，大致可將它們分為采集(Collection)插件和監(jiān)視(Monitor)插件。每個插件都有又細分為ID和SID。采集插件主要通過SNMP、Syslog、WMI等協(xié)議進行采集，在Sensor中常見采集插件有ossec-single-line、ssh、syslog、wmi-system-logger等，其中SNMP與WMI協(xié)議需要Agent采集數(shù)據(jù)時主動進行所采集數(shù)據(jù)的抓取;Syslog協(xié)議則被動接收采集數(shù)據(jù)。具體如圖4所示。

圖4 查看插件

監(jiān)控插件包括malwaredomainlist、nessus、nmap、ntop、ocs、ossim等，如圖5所示。

圖5 設(shè)置監(jiān)控插件

當(dāng)這些插件加載完畢之后，我們可以到Web UI中Configuration→Deployment→Components→Sensors欄目下的“

[[172742]]Sensor Status”查看所添加的監(jiān)控插件的工作狀態(tài)，如圖6所示。

圖6 查看Sensor監(jiān)控插件工作狀態(tài)

注意：監(jiān)控器相當(dāng)于“督戰(zhàn)隊”，誰(關(guān)鍵服務(wù)進程)要是“罷工”了就會在設(shè)定的時間內(nèi)重啟進程，這樣可以保護關(guān)鍵進程。

UNIX/Linux環(huán)境下，大部分系統(tǒng)都安裝有SNMP與Syslog工具。如果采集數(shù)據(jù)的目標(biāo)系統(tǒng)為Windows，那么考慮使用WMI協(xié)議，此時只需要在Windows上進行相關(guān)配置，以便能夠遠程訪問，無需安裝額外的工具軟件。

四、 采集與監(jiān)控插件的區(qū)別

在OSSIM系統(tǒng)的Sensor端包含了采集(Collection)和監(jiān)控(Monitor)這兩類插件統(tǒng)稱為安全插件，它們都安裝在Sensor上。雖然都稱為插件可工作原理卻不同，檢測插件(Detector)是檢測器信息產(chǎn)生后，由代理自動向服務(wù)器發(fā)送，包括Snort、Apache等。而檢測器插件需要主動采集安全設(shè)備接口上的信息，這類插件可分為Snort、P0f、Prads、Arpwatch、Apache、SSH、Sudo等。

監(jiān)控(Monitor)插件，必須由服務(wù)器主動發(fā)起查詢請求。監(jiān)控插件中定義了需要主動采集的安全設(shè)備接口，該模塊接收控制中心發(fā)出的命令和查詢，在OSSIM系統(tǒng)中典型Monitor插件有Ntop、Nmap、Nessus等。讀者可在Alienvault控制臺的Sensor配置中(Configure Monitor Plugins)查看。OSSIM主要安全插件如表1所示。

表1 OSSIM主要插件分布情況

對OSSIM插件位置的說明：在安裝時系統(tǒng)將支持的插件，全部復(fù)制到目錄/etc/ossim/agent/plugins/目錄中，如Nagios插件的擴展名為“.cfg”的文本文件，可以用任何編輯器修改，在每個插件配置文件中最難理解的當(dāng)屬理解正則表達式(RegExp)。OSSIM下主要插件如圖7所示。

圖7 規(guī)則與插件路徑

在今后安裝過程中，選擇多少插件系統(tǒng)就在開機時加載多少(插件加載越多越占用內(nèi)存)。具體查看插件詳情，訪問/etc/ossim/agent/config.cfg配置文件，而且在系統(tǒng)/etc/ossim/ossim_setup.conf中的[sensor]項中也詳細列出了監(jiān)控插件(monitors)和檢測插件(detector)分別包含了哪些內(nèi)容。在插件這方面，OSSIM默認提供了上百個插件，涉及8個大類，在表1-2中僅列出了一小部分，從插件分布和數(shù)量來看，OSSIM系統(tǒng)幾乎包含了常用的插件類型。例如運維設(shè)備Cisco、CheckPoint、F5、Fortigate、Netscreen、Sonicwall、Symantec等，如果遇到無法識別設(shè)備的插件，只能自己編寫插件，后續(xù)內(nèi)容會詳細講到，已加載插件如圖8，圖9所示。

圖8 查看傳感器啟用的插件情況

從圖中看出，此Sensor系統(tǒng)中啟用了9個插件，如何在Web上展示出來呢?如圖所示總共184個插件在Plugins enabled中啟用了9個插件。

圖9 查看加載插件詳情

從圖10看出這里顯示9個插件，我們可打開/etc/ossim/ossim_setup.conf文件查看。

圖10 從Ossim配置文件中查看插件

五、 檢測器(Detector)

OSSIM下的檢測器起到收集資源信息及監(jiān)聽當(dāng)前網(wǎng)段數(shù)據(jù)包的作用，主要包括ntop、prads、suricata、ossec等，相關(guān)內(nèi)容在后續(xù)章節(jié)里會詳細介紹。

六、 代理(Agent)

代理進程(由于Agent采用Python語言編寫，所以無需編譯就能在Python Shell環(huán)境運行)將運行在多個主機上，負責(zé)從安全設(shè)備采集相關(guān)信息(比如報警日志等)，并將采集到的各類信息統(tǒng)一格式，最后將這些數(shù)據(jù)傳至Server。

從采集方式上看，Agent屬于主動采集，可以形象理解為由OSSIM Server安插在各個監(jiān)控網(wǎng)段的“耳目”，由它們收集數(shù)據(jù)，并主動推送到Collector中，然后Collector又連接著消息隊列系統(tǒng)、緩存系統(tǒng)及存儲系統(tǒng)。

OSSIM中的這些代理腳本位于/usr/share/alienvault/ossim-agent/目錄下，腳本經(jīng)過加密，以.pyo為擴展名。

列如OSSIM代理(ossim-agent)直接讀取存儲在/var/log/suricata/unified2.alert.1428975051日志。

suricata的報警輸出文件是/var/log/suricata/unified2.alert,這是由/etc/suricata/suricata.yaml配置文件在111行 # alert output for use with Barnyard2定義，所以ossim-agent直接讀取該文件就能顯示在SIEM控制臺中。

Agent的主要功能是接收或抓取Plugins發(fā)送過來或者生成的日志，經(jīng)過歸一化處理，然后有序地傳送到OSSIM的Server，它的功能很復(fù)雜，因為它的設(shè)計要考慮到如果Agent和Server之間的網(wǎng)絡(luò)中斷、擁堵、丟包等情況。

在免費版的OSSIM系統(tǒng)中，其日志處理大部分情況下不能達到實時，但可以達到準(zhǔn)實時(Firm Real-Time)，通常會在Agent端緩存一段時間才會發(fā)送到Server端去。Agent會主動連接兩個端口與外界通信，一個是連接Server的40001端口(在/etc/ossim/agent/config.cfg配置文件的選項[output-server]中端口設(shè)置能看出通訊端口為40001)，而另一個是連接數(shù)據(jù)庫的3306端口。如圖11所示：

圖11 日志歸一化處理、收集與存儲

原始日志被分成若干段填充到相應(yīng)的域中，這些字段如下：

l date、sensor、interface、plugin_id、plugin_sid、priority、protocol、src_ip、src_port、dst_ip、dst_port

l username、password、filename、userdata1、userdata2、userdata3、userdata4、userdata5、userdata6、userdata7、userdata8、userdata9

其實Sensor的輸出數(shù)據(jù)就是Ossim Server的輸入“原料”，我們可在WebUI中查看Sensor的output情況。如圖12所示。

圖12 Sensor輸出

七、報警格式的解碼

報警信息的接收過程中，為了應(yīng)對報警信息格式的變化，OSSIM采用基于正則表達式的方法對報警信息進行匹配，解析報警事件獲取關(guān)鍵信息。正則表達式是一串記錄文本規(guī)則的代碼組合，它的作用是用來進行文本匹配。例如對空白字符、數(shù)字字符、中英文字符、IP和 E-mail地址等匹配，簡單的說它就是一個普通的字符查找串。

例如，下面對一段Snort報警信息進行正則表達式的匹配。

5/26-01:02:17.670721 [**] [1:1419:9] SNMP trap udp [**] [Classification: Attempted 
Information Leak] [Priority: 2] {UDP} 20.20.13.17:162 -> 20.20.20.78:162 
<ids> 
<name>snort</name> 
<method>net_socket</method> 
<regex>^(\d+/\d+-\d+:\d+:\d+).\d+\s+[**] [\d:(\d+):\d+] \.+[Classification: (\.+)] 
[Priority: (\d)] {(\.+)} (\d+.\d+.\d+.\d+)\p*(\d*)->(\d+.\d+.\d+.\d+)\p*(\d*)</regex> 
<order>time,id,classtype,priority,protocol,srcip,srcport,dstip,dstport</order> 
<mapping>snort_classtype,snort_id</mapping> 
</ids> 

 

這樣通過正則表達式可以提取時間、id、分類、報警級別、協(xié)議、源IP、源端口、目的IP 和目標(biāo)端口等信息。接著再將這些字段逐個存儲為標(biāo)準(zhǔn)化的表中，最后通過Web界面展現(xiàn)。

八、OSSIM Agent

Agent運行在Sensor中，負責(zé)從各安全設(shè)備、安全工具的插件中采集相關(guān)信息(比如IIS服務(wù)日志、Snort報警日志等)，并將采集到的各類信息統(tǒng)一格式，再將這些數(shù)據(jù)傳至Server，例如將Snort系統(tǒng)產(chǎn)生的報警信息收集并存儲在OSSIM Server中。

OSSIM Agent中所有腳本采用Python編寫，相關(guān)目錄在/etc/ossim/agent/，代理插件目錄在/etc/ossim/agent/plugins/，配置文件路徑：/etc/ossim/agent/config.cfg，OSSIM系統(tǒng)的代理信息查看方法，通過Analysis→Detection下的HIDS標(biāo)簽中Agents查看。結(jié)構(gòu)如圖13所示。

圖13 Agent結(jié)構(gòu)

l 40002/tcp： 監(jiān)聽服務(wù)器的原始請求。

l Listener： 接收服務(wù)器連接請求。

l Active： 接收服務(wù)器輸入并且根據(jù)請求掃描主機。

l Engine： 管理線程，處理監(jiān)視器請求。

l Detector Plugin：讀取日志和進行歸一化處理。

l Monitor Plugin：請求監(jiān)視器數(shù)據(jù)。

l DB-Connect： 連接到本地/遠程OSSIM數(shù)據(jù)庫。

l Watchdog： 監(jiān)視進程啟動/停止進程，檢查各插件是否已經(jīng)開始運行，如遇意外，它會發(fā)現(xiàn)并重啟相關(guān)進程，它自動檢查時間為180秒，重啟進程時間為3600秒，其值可以在/etc/ossim/agent/config.cfg配置文件中修改。

注意：OSSIM系統(tǒng)中出了引入HIDS(通過OSSEC實現(xiàn))，還引入了NIDS(通過suricata實現(xiàn))，因為基于主機的入侵檢測系統(tǒng)還無法完全滿足網(wǎng)絡(luò)安全需要，NIDS可以捕捉和分析網(wǎng)絡(luò)數(shù)據(jù)包也分析協(xié)議。NIDS可以部署在各個網(wǎng)段，只對監(jiān)控網(wǎng)段進行監(jiān)聽，不會影響網(wǎng)絡(luò)的運行。但做為Sensor也有缺點，如果網(wǎng)絡(luò)流量一旦超過閾值，就會導(dǎo)致丟包。

提示

OSSIM中定義的大部分插件其日志都默認存放在/var/log/syslog中，所以自定義插件式往往需要修改日志的存放位置，在本書后面的例子中將詳細講解。

表2分析了目錄/etc/ossim/agent/plugin/中主要插件的日志輸出情況，通過該表我們能夠很容易的了解正則表達式的匹配情況。我們進入/etc/ossim/agent/plugings/目錄，其下有197個插件，如何能了解每個插件的日志的匹配情況呢?例如SSH插件對應(yīng)的文件為ssh.cfg，記錄的日志文件為/var/log/auth.log，匹配的詳情我們通過以下命令實現(xiàn)(在OSSIM 4.4之后的版本中已去除了regexp.py調(diào)試腳本，大家可以到作者博客下載該腳本 ，以便完成后續(xù)試驗)。

下面看個Apache訪問日志的例子，首先在/var/log/apache2/access.log中的兩條日志如下：

圖14 Apache日志實例

插件檢測格式：

./regexp.py log_filename regexp modifier

l y:顯示不匹配的行

l v: 顯示匹配的行

l q: 只顯示摘要

如同在Linux定義別名一樣，在regexp.py腳本中也定義了別名，區(qū)別是它采用aliases定義，詳情如下：

圖15 定義別名

為了方便插件內(nèi)容的定義，插件中使用了經(jīng)常用到的內(nèi)容來定義別名，這樣做的好處是當(dāng)今后在定義某一插件內(nèi)容時，便可使用已定義的別名代替那個元素，比如用IPV4代替\d{1,3{\.\d{1,3}\.\d{1,3}\d{1,3}的定義。由此可知，插件中定義的Apache訪問日志的正則表達式為：

regexp=(\IPV4) (\S+) (\S+) \[(?P(\d\d)\/(\w\w\w)\/(\d\d\d\d):(\d\d):(\d\d):(\d\d)).+"(?P.+)" (?P\d+) (\S+)

通過插件匹配的詳細結(jié)果如下：

 

圖16 Apache匹配結(jié)果

由此可見，經(jīng)過處理后的日志內(nèi)容并沒變，為了適應(yīng)SIEM事件顯示需要，實際日志中各項的排列順序發(fā)生了改變，目的是方便閱讀，方便更好的展示在SIEM控制臺上。再接著看SSH和Snare的日志。

 

#/usr/share/ossim/scripts/regexp.py /etc/ossim/agent/plugins/ssh.cfg /var/log/auth.log q 

 

圖17 SSH匹配結(jié)果

又例如：

#/usr/share/ossim/scripts/regexp.py /var/log/snare2.log /etc/ossim/agent/plugins/landesk.cfg q 
Multiple regexp mode used, parsing /etc/ossim/agent/plugins/landesk.cfg 
----------------------------------------------------------------------------- 
Rule: Landesk-sync-job-successed 
Matched 273 times 
Counted 274 lines. 
Matched 273 lines. 

了解OSSIM的其他插件

九、 代理與插件的區(qū)別

初學(xué)者?；煜砗筒寮母拍?，Sensor(傳感器)指軟件和硬件的傳感器被安裝在網(wǎng)絡(luò)中收集和發(fā)送數(shù)據(jù)，而代理是運行在傳感器上，用來收集和發(fā)送數(shù)據(jù)到服務(wù)器的一段腳本，一個插件需要了解特定系統(tǒng)的日志格式(例如防火墻、IDS)，并通過插件來采集數(shù)據(jù)。

系統(tǒng)中如果啟用插件越多，那么采集到網(wǎng)絡(luò)中各種數(shù)據(jù)就越全面，在Sensor中加載過多的插件，將會占有OSSIM Server的數(shù)據(jù)庫空間，下面的這條經(jīng)驗值需要讀者了解，OSSIM系統(tǒng)中每條事件，約占用1KB存儲空間，而1millions的事件量，大約占1.5GB空間。

十、 傳感器(Sensor)

傳感器(Sensor)俗稱探針，用來收集監(jiān)控網(wǎng)段內(nèi)主機的信息，它工作在網(wǎng)卡的嗅探模式。

傳感器工作在一臺Debian Linux主機上，通過ISO鏡像安裝，對于新手來講非常容易操作，他的目的是收集信息，發(fā)送給OSSIM Server。在一個分布式OSSIM系統(tǒng)平臺上，可以有十多個傳感器協(xié)同工作。傳感器可以收集來自多個數(shù)據(jù)源的數(shù)據(jù)包，包括來自主機的，也包括來自網(wǎng)絡(luò)的數(shù)據(jù)包，另外傳感器除了收集數(shù)據(jù)(比如SPAN，Agent)以提供分析之外，還具有過濾功能可以通過Agent里面的plugin實現(xiàn)過濾冗余和無效數(shù)據(jù)的功能，已達到減少OSSIM Server端數(shù)據(jù)量，提高數(shù)據(jù)速度的效果。舉個例子在對于來自同一個IP地址的數(shù)據(jù)，傳感器可以通過模式匹配的方法來判斷冗余數(shù)據(jù)，最終聚合成很少量的數(shù)據(jù)傳送給OSSIM Server。

另外要主機，傳感器能夠和本地代理(比如Ossec agent,Snare)，事件收發(fā)器通訊，但傳感器之間并不直接通訊。

OSSIM系統(tǒng)中，把Agent和插件構(gòu)成的一個具有網(wǎng)絡(luò)行為監(jiān)控功能的組合稱為一個傳感器，Sensor的功能范圍主要有：

• 入侵檢測(最新版已換成支持多線程的Suricata)
• 漏洞掃描(OpenVas、Nmap)
• 異常檢測(P0f、Prads、ARPWatch等)

Arpwatch主要監(jiān)視網(wǎng)絡(luò)中新出現(xiàn)的MAC地址，它包含1個監(jiān)視庫，名為arp.dat，在OSSIM中位于/var/lib/arpwatch/arp.dat，所以它同樣是AIDE監(jiān)控的對象。

提示

OSSIM具有強大的網(wǎng)絡(luò)威脅監(jiān)控，流量監(jiān)測的功能，但無法將威脅阻斷，所以不能將其串聯(lián)在防火墻鏈路，最佳方法是作為旁路鏈接使用,這一點就像部署審計設(shè)備一樣。

 

在OSSIM系統(tǒng)的傳感器的狀態(tài)可在Configuration→Deployment→Components→Sensors中查看詳情，如圖18所示。

圖18 多傳感器詳情

查詢Server/Sensor使用操作系統(tǒng)版本號

#cat /etc/debian_version

在OSSIM分布式應(yīng)用中有多個傳感器，這時在圖182中可以查看每個傳感器的工作狀態(tài)，包括IP地址、名稱、優(yōu)先級、工作狀態(tài)等信息。

OSSIM系統(tǒng)發(fā)展到4.3版本之后，傳感器查詢方式發(fā)生了變化，路徑為Configuration→Deployment→Alienvault Center→Sensor Configuration→Detection，而且啟動程序也發(fā)生些的變化，由Suritata代替了Snort，如圖1-23所示。OSSIM Server默認就啟動ntop、ossec、prads、suricata這4項，Snort為停止?fàn)顟B(tài)。這5個檢測器的狀態(tài)無法通過Web界面直接進行修改。

圖19 傳感器詳情

大家如果使用OSSIM4.1系統(tǒng)，查看系統(tǒng)檢測插件時，Snort為啟動狀態(tài)，但OSSIM 4.2后的系統(tǒng)Snort是關(guān)閉狀態(tài)，代替它的是性能更強大的Suricata系統(tǒng)，同一個系統(tǒng)中兩者只能任選其一。而Prads(Passive RealTime Asset Detection System)是OSSIM 4.2之后又一款被動實時資產(chǎn)探測系統(tǒng)，它的主要功能就是被判斷資產(chǎn)特征，如同一個指紋庫，保存了各種系統(tǒng)特征，可以識別資產(chǎn)的操作系統(tǒng)類型、由ARP發(fā)現(xiàn)新增資產(chǎn)，根據(jù)開放端口判斷打開的網(wǎng)絡(luò)應(yīng)用，因為各種設(shè)備和服務(wù)打開狀態(tài)并不是一成不變，所以需要用Prads來監(jiān)控變化后的狀態(tài)，有關(guān)它的實際應(yīng)用參考http://chenguang.blog.51cto.com/350944/1703458

十一、關(guān)聯(lián)引擎

關(guān)聯(lián)引擎(Server)是OSSIM安全集成管理系統(tǒng)的核心部分，它支持分布式運行，負責(zé)將Agents傳送來的歸一化安全事件進行關(guān)聯(lián)，并對網(wǎng)絡(luò)資產(chǎn)進行風(fēng)險評估。其工作流程見圖1-24所示。

圖20 關(guān)聯(lián)引擎的工作流程

OSSIM服務(wù)器的核心組件功能包含：事件關(guān)聯(lián)、風(fēng)險評估和確定優(yōu)先次序和身份管理、報警和調(diào)度、策略管理、IP信譽管理等，其配置文件在/etc/ossim/server目錄中，文件分別為：

l alienvault-attacks.xml

l alienvault-bruteforce.xml

l alienvault-dos.xml

l alienvault-malware.xml

l alienvault-network.xml

l alienvault-scan.xml

l alienvault-policy.xml

以上這些文件由開源OSSIM免費提供，策略為84條，在USM中則具有2千多條，這一數(shù)量遠高于國內(nèi)的IDS硬件設(shè)備，在OSSIM中它們采用XML編寫易于理解，維護簡單。

圖21 關(guān)聯(lián)引擎的結(jié)構(gòu)

關(guān)聯(lián)引擎結(jié)構(gòu)如圖21所示，其工作過程由下面6個步驟組成：

（1）40001/tcp:Server首先監(jiān)聽 40001/tcp 端口，接收Agent 連接和Framework請求。該端口大小由OSSIM系統(tǒng)在配置文件/etc/ossim/ossim_setup.conf中定義。

 

我們在OSSIM系統(tǒng)中通過以下命令可以清晰查看到其工作端口。

#lsof –Pnl +M –i4 |grep ossim-ser 

（2）Connect:當(dāng)連接到端口為40002指定的Agent時，連接到端口為40001的其他Server 對采集事件進行分配和傳遞。該端口大小在/etc/ossim/agent/config.cfg文件的[output-idm]項配置，不建議更改。

（3）Listener:接收各個Agent的連接數(shù)據(jù)，并細分為Forwarding Server連接、Framework連接。

（4）DB Connect:主要是OSSIM DB連接、Snort DB連接和OSSEC DB連接

（5）Agent Connect:啟動Agent連接，F(xiàn)orwarding Server連接

（6）Engine:事件的授權(quán)、關(guān)聯(lián)、分類。

 

在OSSIM系統(tǒng)關(guān)聯(lián)引擎的狀態(tài)可在Configuration→Deployment→Components→Servers中查看，如圖22所示。

圖22 關(guān)聯(lián)引擎模塊工作狀態(tài)

關(guān)聯(lián)引擎啟動

OSSIM系統(tǒng)會啟動關(guān)聯(lián)引擎，有時系統(tǒng)調(diào)試也需要用到手工啟動方式，命令如下：

#ossim-server -d -c /etc/ossim/server/config.xml 
OSSIM-Message: Entering daemon mode... 

關(guān)聯(lián)引擎+關(guān)聯(lián)規(guī)則能發(fā)揮多大作用，大家參考http://chenguang.blog.51cto.com/350944/1728514

查看Ossim Server框架版本號

 

#ossim-server -v 
Alienvault OSSIM Server Version : 5.1.1.free.commit:(1:5.1.1-31) 
  (c) 2007-2013 AlienVault 

 

十二、 數(shù)據(jù)庫

Ossim關(guān)聯(lián)引擎(簡稱OSSIM Server)將事件關(guān)聯(lián)結(jié)果寫入數(shù)據(jù)庫。系統(tǒng)用戶可通過Framework(Web前端控制臺)對Database進行訪問。數(shù)據(jù)庫中alienvault.event表是整個系統(tǒng)事件分析和策略調(diào)整的信息源。OSSIM從總體上將其劃分為事件數(shù)據(jù)庫(EDB)、知識數(shù)據(jù)庫(KDB)、用戶數(shù)據(jù)庫(UDB)。OSSIM數(shù)據(jù)庫用來記錄與安全事件關(guān)聯(lián)及配置等相關(guān)的信息，對應(yīng)于設(shè)計階段的KDB和EDB的關(guān)聯(lián)事件部分;在Framework中使用ACID/BASE來作為Snort數(shù)據(jù)庫的前端控制臺，對應(yīng)于設(shè)計階段的EDB。此外ACL數(shù)據(jù)庫相關(guān)表格可包含在OSSIM數(shù)據(jù)庫中，用來記錄用戶行為，對應(yīng)于設(shè)計階段的UDB庫。

Ossim數(shù)據(jù)庫分關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫。OSSIM系統(tǒng)默認使用的MySQL監(jiān)聽端口是3306，為增其其處理性能，在Alienvault USM中采用MongoDB作為非關(guān)系型數(shù)據(jù)庫。2013年將OSSIM 4.2發(fā)行版中用Percona_server5.5替換了原來的MySQL 5.1，由于使用了XtraDB存儲引擎，而且對MySQL進行了優(yōu)化和改進，使其在功能和性能上明顯提升。在2015年底的最新版本USM 5.2中將Percona_server升級為功能強大的5.6.25。

表3 OSSIM 主要版本數(shù)據(jù)庫變遷

如果大家對OSSIM的架構(gòu)和組成的了解還意猶未盡，敬請參閱由清華大學(xué)出版的《開源安全運維平臺OSSIM最佳實踐》一書。

十三、安裝

功能強大的系統(tǒng)，安裝過程卻非常簡單，如下圖所示

參考文獻：

1. 李晨光.開源安全運維平臺OSSIM最佳實踐【M】北京：清華大學(xué)出版社，2016.1

該書前言、目錄PDF下載地址：http://wenku.it168.com/d_001656004.shtml

查看3D圖書： http://mobile.pin3d.cn/p3d/show3d2?taskID=569c9f1c65747a5f4dde479b

2.《Ossim應(yīng)用指南》入門篇 http://chenguang.blog.51cto.com/350944/1332329

3.最新開源可視化安全管理平臺Ossim5.0使用

http://chenguang.blog.51cto.com/350944/1636741

4.詳解Ossim 4.3控制臺 http://chenguang.blog.51cto.com/350944/1332835

5.OSSIM讓網(wǎng)絡(luò)攻擊無所遁形 http://chenguang.blog.51cto.com/350944/1718135

6.OSSIM中主動與被動探測工具(arpwatch+p0f+pads)組合應(yīng)用http://chenguang.blog.51cto.com/350944/1703458

7.基于OSSIM平臺的漏洞掃描詳解 http://chenguang.blog.51cto.com/350944/1692490

全文PDF下載：http://wenku.it168.com/d_001665820.shtml

當(dāng)別人還在為一段腳本，自動化安裝上某個工具而高興時，你已經(jīng)學(xué)會了用一個ISO鏡像，一次輕松集成幾十個開源安全工具模塊的平臺，一下子甩出幾條街區(qū)。