一、背景

如果運維工程師手里沒有高效的管理工具支持，就很難快速處理故障。市面上有很多運維監控工具，例如商業版的 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欄目下的“

[[172742]]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主要插件分布情況

對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結構

l 40002/tcp： 監聽服務器的原始請求。

l Listener： 接收服務器連接請求。

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

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

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

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

l DB-Connect： 連接到本地/遠程OSSIM數據庫。

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

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

提示

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

表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

l y:顯示不匹配的行

l v: 顯示匹配的行

l q: 只顯示摘要

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

圖15 定義別名

為了方便插件內容的定義，插件中使用了經常用到的內容來定義別名，這樣做的好處是當今后在定義某一插件內容時，便可使用已定義的別名代替那個元素，比如用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+)

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

 

圖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 多傳感器詳情

查詢Server/Sensor使用操作系統版本號

#cat /etc/debian_version

在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來監控變化后的狀態，有關它的實際應用參考http://chenguang.blog.51cto.com/350944/1703458

十一、關聯引擎

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

圖20 關聯引擎的工作流程

OSSIM服務器的核心組件功能包含：事件關聯、風險評估和確定優先次序和身份管理、報警和調度、策略管理、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千多條，這一數量遠高于國內的IDS硬件設備，在OSSIM中它們采用XML編寫易于理解，維護簡單。

圖21 關聯引擎的結構

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

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

 

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

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

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

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

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

（5）Agent Connect:啟動Agent連接，Forwarding Server連接

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

 

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

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

關聯引擎啟動

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

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

關聯引擎+關聯規則能發揮多大作用，大家參考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 

 

十二、 數據庫

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的架構和組成的了解還意猶未盡，敬請參閱由清華大學出版的《開源安全運維平臺OSSIM最佳實踐》一書。

十三、安裝

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

參考文獻：

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

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

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

2.《Ossim應用指南》入門篇 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讓網絡攻擊無所遁形 http://chenguang.blog.51cto.com/350944/1718135

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

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

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

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