標籤：

OSSIM架構與組成綜述

04-15

OSSIM架構與組成綜述

一、背景

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

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

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

從架構上來看，OSSIM系統是一個開放的框架，它的核心價值在於創新的集成各開源軟體之所長，它裡面的模塊既有C/S架構，又有B/S架構，但作為最終用戶主要掌握OSSIM WebUI主要採用B/S架構，Web伺服器使用Apache。OSSIM系統結構示意圖如圖1所示。

圖1 OSSIM系統結構

第1層，屬於數據採集層，使用各種採集技術採集流量信息、日誌、各種資產信息，經過歸一化處理後傳入核心層。改層體現安全事件來源，入侵檢測、防火牆、重要主機發出的日誌都是安全事件來源，它們按發出機制分為兩類：模式偵查器和異常監控（兩者都採集警告信息，功能互補）由它們採集的安全事件，再被Agent轉換為統一的格式發到OSSIM伺服器，這一層就是Sensor要完成的內容。

第2層，屬於核心處理層，主要實現對各種數據的深入加工處理，包括運行監控、安全分析、策略管理、風險評估、關聯分析、安全對象管理、脆弱性管理、事件管理、報表管理等。該層中OSSIM Server是主角，OSSIM伺服器，主要功能是安全事件的集中並對集中後的事件進行關聯分析、風險評估及嚴重性標註等。所謂的集中就是以一種統一格式組織所有系統產生的安全事件告警信息（Alarms）並將所有的網路安全事件告警存儲到資料庫，這樣就完成了對網路中所產生事件的一個龐大視圖。系統通過事件序列關聯和啟發式演算法關聯來更好的識別誤報和偵查攻擊的能力。

OSSIM本質上通過對各種探測器和監控產生的告警進行格式化處理，再進行關聯分析，通過後期這些處理能提高檢測性能，即減少告警數量，減小關聯引擎的壓力，從整體上提高告警質量。

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

二、 主要模塊的關係

OSSIM系統主要使用了PHP、Python、Perl和C等四種編程語言，從軟體層面上看OSSIM框架系統包括五大模塊：Agent模塊、Server模塊、Database資料庫模塊、Frameworkd模塊以及Framework模塊，邏輯結構圖見2所示。

圖2 Ossim系統邏輯結構

五個模塊之間的數據流向如圖3所示：

圖3 五大模塊的數據流向

① Agent至Server：來自各個感測器的安全事件被對應Agent格式化後，以加密字元串傳給Server。

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

③ Server至Frameworkd:發送請求命令，要求Frameworkd針對Alarm採取相應操作，例如執行外部程序或發出Email來通知管理員。

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

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

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

⑦ Database至Agent和Server：向Agent和Server提供數據。

⑧ Server至Database：Server需要將Events、Alarms等數據存入資料庫並索引或更新操作。

⑨ Database至Frameworkd:在Frameworkd中的Openvas掃描和動作需要用調用資料庫里的數據。

⑩ Frameworkd至Database：在Frameworkd執行過程中將Openvas掃描結果存入資料庫。

⑾Database至Framework:PHP頁面顯示需要調用資料庫的告警事件。

⑿Framework至Database：用戶參數設置信息需要存入資料庫。

三、安全插件（Plugins）

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

圖4 查看插件

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

圖5 設置監控插件

當這些插件載入完畢之後，我們可以到Web UI中Configuration→Deployment→Components→Sensors欄目下的「Sensor Status」查看所添加的監控插件的工作狀態，如圖6所示。

圖6 查看Sensor監控插件工作狀態

注意：監控器相當於「督戰隊」，誰（關鍵服務進程）要是「罷工」了就會在設定的時間內重啟進程，這樣可以保護關鍵進程。

UNIX/Linux環境下，大部分系統都安裝有SNMP與Syslog工具。如果採集數據的目標系統為Windows，那麼考慮使用WMI協議，此時只需要在Windows上進行相關配置，以便能夠遠程訪問，無需安裝額外的工具軟體。

四、 採集與監控插件的區別

在OSSIM系統的Sensor端包含了採集（Collection）和監控（Monitor）這兩類插件統稱為安全插件，它們都安裝在Sensor上。雖然都稱為插件可工作原理卻不同，檢測插件（Detector）是檢測器信息產生後，由代理自動向伺服器發送，包括Snort、Apache等。而檢測器插件需要主動採集安全設備介面上的信息，這類插件可分為Snort、P0f、Prads、Arpwatch、Apache、SSH、Sudo等。

監控(Monitor)插件，必須由伺服器主動發起查詢請求。監控插件中定義了需要主動採集的安全設備介面，該模塊接收控制中心發出的命令和查詢，在OSSIM系統中典型Monitor插件有Ntop、Nmap、Nessus等。讀者可在Alienvault控制台的Sensor配置中（Configure Monitor Plugins）查看。OSSIM主要安全插件如表1所示。

表1 OSSIM主要插件分布情況

分類

功能

插件名稱

1

訪問控制

csico-acs、cisco-acs-idm、cisco-asa

2

防病毒

Avast、gfi security、mcafee、clamav

3

防火牆

fw1-alt、cisco-pix、ipfw、m0n0wall、netscreen-igs、Motorola-firewall、iptables、pf(openbsd項目)

4

HIDS

Ossec、ossec-single-line Osiris

5

負載均衡

Allot、cisco-ace、citrix-netscaler、f5、heartbeat

6

網路監控

ntop-monitor、p0f、prads、session-monitor、tcptrack-monitor

7

虛擬化

vmware-esxi、vmware-vcenter、vmware-vcenter-sql

8

漏洞掃描

Nessus、Nessus-detector、Nessus-monitor

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

圖7 規則與插件路徑

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

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

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

圖9 查看載入插件詳情

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

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

五、 檢測器（Detector）

OSSIM下的檢測器起到收集資源信息及監聽當前網段數據包的作用，主要包括ntop、prads、suricata、ossec等，相關內容在後續章節里會詳細介紹。

六、 代理（Agent）

代理進程（由於Agent採用Python語言編寫，所以無需編譯就能在Python Shell環境運行）將運行在多個主機上，負責從安全設備採集相關信息（比如報警日誌等），並將採集到的各類信息統一格式，最後將這些數據傳至Server。

從採集方式上看，Agent屬於主動採集，可以形象理解為由OSSIM Server安插在各個監控網段的「耳目」，由它們收集數據，並主動推送到Collector中，然後Collector又連接著消息隊列系統、緩存系統及存儲系統。

OSSIM中的這些代理腳本位於/usr/share/alienvault/ossim-agent/目錄下，腳本經過加密，以.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發送過來或者生成的日誌，經過歸一化處理，然後有序地傳送到OSSIM的Server，它的功能很複雜，因為它的設計要考慮到如果Agent和Server之間的網路中斷、擁堵、丟包等情況。

在免費版的OSSIM系統中，其日誌處理大部分情況下不能達到實時，但可以達到准實時（Firm Real-Time），通常會在Agent端緩存一段時間才會發送到Server端去。Agent會主動連接兩個埠與外界通信，一個是連接Server的40001埠（在/etc/ossim/agent/config.cfg配置文件的選項[output-server]中埠設置能看出通訊埠為40001），而另一個是連接資料庫的3306埠。如圖11所示。

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

原始日誌被分成若干段填充到相應的域中，這些欄位如下：

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的輸出數據就是Ossim Server的輸入「原料」，我們可在WebUI中查看Sensor的output情況。如圖12所示。

圖12 Sensor輸出

七、報警格式的解碼

報警信息的接收過程中，為了應對報警信息格式的變化，OSSIM採用基於正則表達式的方法對報警信息進行匹配，解析報警事件獲取關鍵信息。正則表達式是一串記錄文本規則的代碼組合，它的作用是用來進行文本匹配。例如對空白字元、數字字元、中英文字元、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、分類、報警級別、協議、源IP、源埠、目的IP 和目標埠等信息。接著再將這些欄位逐個存儲為標準化的表中，最後通過Web界面展現。

八、OSSIM Agent

Agent運行在Sensor中，負責從各安全設備、安全工具的插件中採集相關信息(比如IIS服務日誌、Snort報警日誌等)，並將採集到的各類信息統一格式，再將這些數據傳至Server，例如將Snort系統產生的報警信息收集並存儲在OSSIM Server中。

OSSIM Agent中所有腳本採用Python編寫，相關目錄在/etc/ossim/agent/，代理插件目錄在/etc/ossim/agent/plugins/，配置文件路徑：/etc/ossim/agent/config.cfg，OSSIM系統的代理信息查看方法，通過Analysis→Detection下的HIDS標籤中Agents查看。結構如圖13所示。

圖13 Agent結構

  • 40002/tcp： 監聽伺服器的原始請求。

  • Listener： 接收伺服器連接請求。

  • Active： 接收伺服器輸入並且根據請求掃描主機。

  • Engine： 管理線程，處理監視器請求。

  • Detector Plugin：讀取日誌和進行歸一化處理。

  • Monitor Plugin：請求監視器數據。

  • DB-Connect： 連接到本地/遠程OSSIM資料庫。

  • Watchdog： 監視進程啟動/停止進程，檢查各插件是否已經開始運行，如遇意外，它會發現並重啟相關進程，它自動檢查時間為180秒，重啟進程時間為3600秒，其值可以在/etc/ossim/agent/config.cfg配置文件中修改。

注意：OSSIM系統中出了引入HIDS（通過OSSEC實現），還引入了NIDS（通過suricata實現），因為基於主機的入侵檢測系統還無法完全滿足網路安全需要，NIDS可以捕捉和分析網路數據包也分析協議。NIDS可以部署在各個網段，只對監控網段進行監聽，不會影響網路的運行。但做為Sensor也有缺點，如果網路流量一旦超過閾值，就會導致丟包。

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

表2 插件的日誌路徑

OSSIM Agent插件

ID

日誌位置

Apache

1501

/var/log/apache2/access.log /var/log/apache2/error.log

Arpwatch

1512

/var/log/ossim/arpwatch-eth0.log

Avast

1567

/var/log/avast.log

bind

1577

/var/log/bind.log

bluecoat

1642

/var/log/bluecoat.log

Cisco-asa

1636

/var/log/cisco-asa.log

Cisco-pix

1514

/var/log/cisco-pix.log

cisco-route

1510

/var/log/syslog

cisco-vpn

1527

/var/log/syslog

Exchange

1603

/var/log/syslog

Extreme-switch

1672

/var/log/extreme-switch.log

F5

1614

/var/log/syslog

fortigate

1554

/var/log/fortigate.log

Fw1ngr60

1504

/var/log/ossim/fw1.log

gfi

1530

/var/log/syslog

heartbeat

1523

/var/log/ha-log

iis

1502

/var/log/iisweb.log

ipfw

1529

/var/log/messages

Iptables

1503

/var/log/syslog

Juniper-vpn

1609

/var/log/juniper-vpn.log

kismet

1596

/var/log/syslog

linuxdhcp

1607

/var/log/ossim/dhcp.log

M0n0wall

1559

/var/log/syslog

mcafee

1571

/var/log/mcafee.log

monit

1687

/var/log/ossim/monit.log

nagios

1525

/var/log/nagios3/Nagios.log

nessus

90003

/var/ossec/logs/archive/archive.log

Nessus-detector

3001

/var/log/ossim/nessus_jobs

netgear

1519

/var/log/syslog

Netscreen-firewall

1522

/var/log/netscreen.log

nfs

1631

/var/log/syslog

Nortel-switch

1557

/var/log/syslog

openldap

1586

/var/log/openldap/slapd.log

osiris

4001

/var/log/syslog

Ossec-idm

50003

/var/ossec/logs/alerts/alerts.log

Ossec-single-line

7007

OSSIM-agent

6001

/var/log/ossim/agent.log

P0f

1511

/var/log/ossim/p0f.log

Alienvault-dummy-server

1510

/var/log/ossim/sem.log

prads

1683

/var/log/prads-asset.log

Prads_eth0

1683

/var/log/ossim/prads-eth0.log

postfix

1521

/var/log/mail.log

snare

1518

/var/log/snare.log

Snort_syslog

1001

/var/log/snort/alert

snortunified

1001

/var/log/snort

sophos

1581

/var/log/ossim/sophos.log

suiqd

1553

/var/log/squid/access.log

ssh

4003

/var/log/auth.log

sudo

4005

Suricata-http

8001

/var/log/suricata/http.log

suricata

1001

/var/log/suricata/

Symantec-ams

1556

/var/log/syslog

Vmware-esxi

1686

/var/log/vmware-esxi.log

vsftpd

1576

/var/log/vsftpd.log

webmin

1580

/var/log/auth.log

websense

19004

/var/log/websense.log

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

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

圖14 Apache日誌實例

插件檢測格式：

./regexp.py log_filename regexp modifier

  • y:顯示不匹配的行

  • v: 顯示匹配的行

  • lq: 只顯示摘要

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

圖15 定義別名

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

regexp=(IPV4) (S+) (S+) [(?P<date>(dd)/(www)/(dddd):(dd):(dd):(dd)).+"(?P<info>.+)" (?P<sid>d+) (S+)

通過插件匹配的詳細結果如下：

圖16 Apache匹配結果

由此可見，經過處理後的日誌內容並沒變，為了適應SIEM事件顯示需要，實際日誌中各項的排列順序發生了改變，目的是方便閱讀，方便更好的展示在SIEM控制台上。再接著看SSH和Snare的日誌。

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

圖17 SSH匹配結果

又例如：

#/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的其他插件

九、 代理與插件的區別

初學者常混淆代理和插件的概念，Sensor（感測器）指軟體和硬體的感測器被安裝在網路中收集和發送數據，而代理是運行在感測器上，用來收集和發送數據到伺服器的一段腳本，一個插件需要了解特定系統的日誌格式（例如防火牆、IDS），並通過插件來採集數據。

系統中如果啟用插件越多，那麼採集到網路中各種數據就越全面，在Sensor中載入過多的插件，將會佔有OSSIM Server的資料庫空間，下面的這條經驗值需要讀者了解，OSSIM系統中每條事件，約佔用1KB存儲空間，而1millions的事件量，大約佔1.5GB空間。

十、 感測器（Sensor）

感測器（Sensor）俗稱探針，用來收集監控網段內主機的信息，它工作在網卡的嗅探模式。

感測器工作在一台Debian Linux主機上，通過ISO鏡像安裝，對於新手來講非常容易操作，他的目的是收集信息，發送給OSSIM Server。在一個分散式OSSIM系統平台上，可以有十多個感測器協同工作。感測器可以收集來自多個數據源的數據包，包括來自主機的，也包括來自網路的數據包，另外感測器除了收集數據（比如SPAN，Agent）以提供分析之外，還具有過濾功能可以通過Agent裡面的plugin實現過濾冗餘和無效數據的功能，已達到減少OSSIM Server端數據量，提高數據速度的效果。舉個例子在對於來自同一個IP地址的數據，感測器可以通過模式匹配的方法來判斷冗餘數據，最終聚合成很少量的數據傳送給OSSIM Server。

另外要主機，感測器能夠和本地代理（比如Ossec agent,Snare），事件收發器通訊，但感測器之間並不直接通訊。

OSSIM系統中，把Agent和插件構成的一個具有網路行為監控功能的組合稱為一個感測器，Sensor的功能範圍主要有：

  • 入侵檢測(最新版已換成支持多線程的Suricata)

  • 漏洞掃描(OpenVas、Nmap)

  • 異常檢測(P0f、Prads、ARPWatch等)

Arpwatch主要監視網路中新出現的MAC地址，它包含1個監視庫，名為arp.dat，在OSSIM中位於/var/lib/arpwatch/arp.dat，所以它同樣是AIDE監控的對象。

OSSIM具有強大的網路威脅監控，流量監測的功能，但無法將威脅阻斷，所以不能將其串聯在防火牆鏈路，最佳方法是作為旁路鏈接使用,這一點就像部署審計設備一樣。

在OSSIM系統的感測器的狀態可在Configuration→Deployment→Components→Sensors中查看詳情，如圖18所示。

圖18 多感測器詳情

在OSSIM分散式應用中有多個感測器，這時在圖182中可以查看每個感測器的工作狀態，包括IP地址、名稱、優先順序、工作狀態等信息。

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

圖19 感測器詳情

大家如果使用OSSIM4.1系統，查看系統檢測插件時，Snort為啟動狀態，但OSSIM 4.2後的系統Snort是關閉狀態，代替它的是性能更強大的Suricata系統，同一個系統中兩者只能任選其一。而Prads（Passive RealTime Asset Detection System）是OSSIM 4.2之後又一款被動實時資產探測系統，它的主要功能就是被判斷資產特徵，如同一個指紋庫，保存了各種系統特徵，可以識別資產的操作系統類型、由ARP發現新增資產，根據開放埠判斷打開的網路應用，因為各種設備和服務打開狀態並不是一成不變，所以需要用Prads來監控變化後的狀態，有關它的實際應用參考OSSIM中主動與被動探測工具（arpwatch+p0f+pads）組合應用

十一、關聯引擎

關聯引擎（Server）是OSSIM安全集成管理系統的核心部分，它支持分散式運行，負責將Agents傳送來的歸一化安全事件進行關聯，並對網路資產進行風險評估。其工作流程見圖1-24所示。

圖20 關聯引擎的工作流程

OSSIM伺服器的核心組件功能包含：事件關聯、風險評估和確定優先次序和身份管理、報警和調度、策略管理、IP信譽管理等，其配置文件在/etc/ossim/server目錄中，文件分別為：

  • alienvault-attacks.xml

  • alienvault-bruteforce.xml

  • alienvault-dos.xml

  • alienvault-malware.xml

  • alienvault-network.xml

  • alienvault-scan.xml

  • alienvault-policy.xml

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

圖21 關聯引擎的結構

關聯引擎結構如圖21所示，其工作過程由下面6個步驟組成：

40001/tcp:Server首先監聽 40001/tcp 埠，接收Agent 連接和Framework請求。該埠大小由OSSIM系統在配置文件/etc/ossim/ossim_setup.conf中定義。

我們在OSSIM系統中通過以下命令可以清晰查看到其工作埠。

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

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

Listener:接收各個Agent的連接數據，並細分為Forwarding Server連接、Framework連接。

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

Agent Connect:啟動Agent連接，Forwarding Server連接。

Engine:事件的授權、關聯、分類。

在OSSIM系統關聯引擎的狀態可在Configuration→Deployment→Components→Servers中查看，如圖22所示。

圖22 關聯引擎模塊工作狀態

關聯引擎啟動

OSSIM系統會啟動關聯引擎，有時系統調試也需要用到手工啟動方式，命令如下：

#ossim-server -d -c /etc/ossim/server/config.xml

OSSIM-Message: Entering daemon mode...

關聯引擎+關聯規則能發揮多大作用，大家參考日誌聚合與關聯分析技術實例視頻演示

查看Ossim Server版本

#ossim-server -v

Alienvault OSSIM Server Version : 5.1.1.free.commit:(1:5.1.1-31)

(c) 2007-2013 AlienVault

十二、 資料庫

Ossim關聯引擎（簡稱OSSIM Server）將事件關聯結果寫入資料庫。系統用戶可通過Framework(Web前端控制台)對Database進行訪問。資料庫中alienvault.event表是整個系統事件分析和策略調整的信息源。OSSIM從總體上將其劃分為事件資料庫(EDB)、知識資料庫(KDB)、用戶資料庫(UDB)。OSSIM資料庫用來記錄與安全事件關聯及配置等相關的信息，對應於設計階段的KDB和EDB的關聯事件部分；在Framework中使用ACID/BASE來作為Snort資料庫的前端控制台，對應於設計階段的EDB。此外ACL資料庫相關表格可包含在OSSIM資料庫中，用來記錄用戶行為，對應於設計階段的UDB庫。

Ossim資料庫分關係型資料庫和非關係型資料庫。OSSIM系統默認使用的MySQL監聽埠是3306，為增其其處理性能，在Alienvault USM中採用MongoDB作為非關係型資料庫。2013年將OSSIM 4.2發行版中用Percona_server5.5替換了原來的MySQL 5.1，由於使用了XtraDB存儲引擎，而且對MySQL進行了優化和改進，使其在功能和性能上明顯提升。在2015年底的最新版本USM 5.2中將Percona_server升級為功能強大的5.6.25。

表3 OSSIM 主要版本資料庫變遷

版本

資料庫

OSSIM 2.3

MySQL-server 5.1

OSSIM 3.1

MySQL-server 5.1

OSSIM 4.1

Percona-server-5.5.23

OSSIM 4.2

Percona-server-5.5.25

OSSIM 4.3

Percona-server-5.5.29

OSSIM 4.4

Percona-server-5.5.33

OSSIM 4.5

Percona-server-5.5.33

OSSIM 4.6~4.9

Percona-server-5.5.33-31

OSSIM 4.10~4.15

Percona-server-5.5.33-31.1

OSSIM USM 5.0

OSSIM USM 5.2

Percona-server-5.6.23-72.1

Percona-server-5.6.25-73.1

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

十三、安裝

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

參考文獻：

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

該書前言、目錄PDF下載地址：《開源安全運維平台-OSSIM最佳實踐》文前

查看3D圖書： OSSIM最佳實踐3D.zip

2.《Ossim應用指南》入門篇 《Ossim應用指南》入門篇

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

最新-開源可視化安全管理平台Ossim5.0使用「預覽」

4.詳解Ossim 4.3控制台 詳解Ossim 4.3控制台

5.OSSIM讓網路攻擊無所遁形 OSSIM讓網路攻擊無所遁形

6.OSSIM中主動與被動探測工具（arpwatch+p0f+pads）組合應用 OSSIM中主動與被動探測工具（arpwatch+p0f+pads）組合應用

7.基於OSSIM平台的漏洞掃描詳解 基於OSSIM平台的漏洞掃描詳解

全文PDF下載：OSSIM架構詳解


推薦閱讀：

TAG:開源系統 |