一種用于大規(guī)模網(wǎng)絡(luò)安全監(jiān)控的大數(shù)據(jù)架構(gòu)

李磊 山東省煙臺(tái)市公安局交通警察支隊(duì)

引言

作為一個(gè)傳統(tǒng)的網(wǎng)絡(luò)安全問題，入侵檢測(cè)與預(yù)防問題已經(jīng)被科研人員研究了三十多年[1]，第一個(gè)被提出的概念是入侵檢測(cè)系統(tǒng)（IDS），它于1987年被提出[2]。然而，由于要分析的數(shù)據(jù)類型不斷演變，對(duì)此問題的研究仍然一直在持續(xù)。另外，攻擊者針對(duì)新的防護(hù)手段與防火墻策略不斷調(diào)整其攻擊手段，也使得該研究領(lǐng)域不斷發(fā)展。此外，近年來，與入侵識(shí)別和檢測(cè)相關(guān)的異構(gòu)安全數(shù)據(jù)的處理方法研究，也是研究的熱點(diǎn)。

大多數(shù)傳統(tǒng)網(wǎng)絡(luò)入侵檢測(cè)系統(tǒng)（NIDS）的技術(shù)實(shí)現(xiàn)依賴于網(wǎng)絡(luò)流量分析，它們一般通過檢查來自多個(gè)協(xié)議（HTTP、SIP、DNS等）的網(wǎng)絡(luò)流量以發(fā)現(xiàn)異常行為，這些異常行為通常依賴于對(duì)異常行為的規(guī)則定義。一旦觀察到異常行為，系統(tǒng)就會(huì)發(fā)出報(bào)警（IDS）或停止通信（IP S）。目前的IDS還會(huì)分析多種協(xié)議，并將其觀察到的數(shù)據(jù)與事件由SIEM（安全信息和事件管理）相關(guān)聯(lián)以便檢測(cè)入侵行為。但是，一個(gè)缺點(diǎn)是，目前基于IDS實(shí)現(xiàn)的深度分組分析解決方案不可擴(kuò)展，并且無法適用于會(huì)產(chǎn)生大量數(shù)據(jù)的大型網(wǎng)絡(luò)。

在大型政府單位、運(yùn)營(yíng)商等網(wǎng)絡(luò)環(huán)境中，必須處理大量的流量數(shù)據(jù)。主IP流記錄中包含源及目標(biāo)IP與端口、IP協(xié)議版本、時(shí)間戳、字節(jié)數(shù)與數(shù)據(jù)包數(shù)等屬性，其數(shù)據(jù)量、數(shù)據(jù)生成速度、數(shù)據(jù)多樣性等均會(huì)成為數(shù)據(jù)收集與分析的挑戰(zhàn)。而數(shù)據(jù)來源的多樣性（蜜罐、DNS監(jiān)控、IDS、IPS等）更要求有一套統(tǒng)一的分析方法。

本文通過提出一個(gè)用于企業(yè)網(wǎng)絡(luò)入侵檢測(cè)與預(yù)防的系統(tǒng)架構(gòu)，解決了上述問題。本文方法的數(shù)據(jù)源包括DNS流量、HTTP流量、IP流記錄與蜜罐數(shù)據(jù)等。上述數(shù)據(jù)中的每一種都已經(jīng)被單獨(dú)應(yīng)用于入侵檢測(cè)并被證明是有效的[3-7]。然而，為了應(yīng)對(duì)各種新型攻擊手段和混合攻擊技術(shù)，安全防護(hù)系統(tǒng)必須利用所有可用的分析數(shù)據(jù)源。本文提出的系統(tǒng)在同一個(gè)分布式數(shù)據(jù)存儲(chǔ)和處理系統(tǒng)中集成了三個(gè)不同的數(shù)據(jù)存儲(chǔ)系統(tǒng)，數(shù)據(jù)被分布式數(shù)據(jù)關(guān)聯(lián)系統(tǒng)利用，從而能夠支持大規(guī)模網(wǎng)絡(luò)安全監(jiān)控。

一、系統(tǒng)架構(gòu)和應(yīng)用

本文提出的安全監(jiān)控系統(tǒng)的總體結(jié)構(gòu)如圖1所示，系統(tǒng)由異構(gòu)分布式數(shù)據(jù)存儲(chǔ)系統(tǒng)與其他分布式數(shù)據(jù)相關(guān)系統(tǒng)組成。

本文系統(tǒng)收集處理了四類用于網(wǎng)絡(luò)安全監(jiān)控的數(shù)據(jù)：

·DNS回復(fù)

·HTTP數(shù)據(jù)包

·IP流記錄

·蜜罐數(shù)據(jù)

（一）數(shù)據(jù)采集

作為互聯(lián)網(wǎng)的核心服務(wù)，幾乎所有的網(wǎng)絡(luò)通信都是通過DNS發(fā)起的。在網(wǎng)絡(luò)通信過程中，需要執(zhí)行DNS請(qǐng)求以獲取與域關(guān)聯(lián)的IP地址，然后查詢所需的資源。因此，對(duì)DNS進(jìn)行監(jiān)控以識(shí)別惡意域，是主動(dòng)檢測(cè)和防止惡意通信的有效方式。在大規(guī)模網(wǎng)絡(luò)的具體實(shí)現(xiàn)中，需要在網(wǎng)絡(luò)中的遞歸DNS服務(wù)器上設(shè)置DNS探測(cè)器，用于收集所有相關(guān)的DNS請(qǐng)求和網(wǎng)絡(luò)回復(fù)。本文系統(tǒng)的DNS探測(cè)器捕獲發(fā)往遞歸DNS服務(wù)器的DNS回復(fù)，并從DNS數(shù)據(jù)包中提取信息。所有被觀察到的域及提取的信息都存儲(chǔ)在一個(gè)高可擴(kuò)展且可用的數(shù)據(jù)庫Apache Cassandra數(shù)據(jù)庫中。

在互聯(lián)網(wǎng)用戶流量中，HTTP流量占很大一部分，同時(shí)也是眾所周知的入侵媒介。對(duì)嵌入在HTTP數(shù)據(jù)包中的URI及其有效負(fù)載進(jìn)行研究，能夠有效地檢測(cè)與防止惡意網(wǎng)絡(luò)通信。因此，本文系統(tǒng)在網(wǎng)絡(luò)HTTP代理級(jí)別對(duì)HTTP流量實(shí)施監(jiān)視，網(wǎng)絡(luò)中的所有HTTP連接嘗試都通過該代理，并通過檢查分組的嵌入域和IP目的地，對(duì)連續(xù)參與相同通信的不同URI實(shí)施動(dòng)態(tài)分析。相同的技術(shù)也可以應(yīng)用于任何包括IP地址和URI的協(xié)議分析，如SIP數(shù)據(jù)包。

Cisco NetFlow是一種應(yīng)用較廣的通過路由器實(shí)施IP流量監(jiān)控的監(jiān)控技術(shù)，它能夠記錄通過路由器轉(zhuǎn)發(fā)的所有通信，具體記錄內(nèi)容包括源和目標(biāo)IP、源和目標(biāo)端口、時(shí)間戳、使用的協(xié)議、交換的數(shù)據(jù)量等。這些流記錄信息對(duì)檢測(cè)入侵或發(fā)現(xiàn)僵尸網(wǎng)絡(luò)通信非常有價(jià)值。本文的系統(tǒng)通過從網(wǎng)絡(luò)中的核心路由導(dǎo)出NetFlow記錄，對(duì)從企業(yè)網(wǎng)絡(luò)與Internet之間的所有通信進(jìn)行了存儲(chǔ)。NetFlow記錄采用分布式存儲(chǔ)方式存儲(chǔ)在nfcapd二進(jìn)制文件中。

本文系統(tǒng)中使用的最后一種數(shù)據(jù)是蜜罐數(shù)據(jù)。蜜罐通常用于模擬易受攻擊的服務(wù)并包含虛假的生產(chǎn)網(wǎng)絡(luò)數(shù)據(jù)。它看上去就像一臺(tái)存在缺陷的計(jì)算機(jī)，其部署目的就是被攻擊。對(duì)蜜罐的連接嘗試通常是探測(cè)攻擊的表征，因此，記錄蜜罐信息可以了解針對(duì)特定網(wǎng)絡(luò)的攻擊者特征，如其使用的IP地址、協(xié)議、漏洞利用文件、掃描策略等。利用蜜罐數(shù)據(jù)可以調(diào)整安全策略，以防止攻擊者對(duì)生產(chǎn)機(jī)器發(fā)起真正的攻擊。本文系統(tǒng)架構(gòu)中選擇的蜜罐解決方案是Dionaea[]，這是一種低交互蜜罐，能夠模擬HTTP、FTP、MSSQL、SMB等多種易受攻擊的網(wǎng)絡(luò)服務(wù)，對(duì)Dionaea的所有連接嘗試都存儲(chǔ)在SQLite數(shù)據(jù)庫中。

（二）數(shù)據(jù)關(guān)聯(lián)

本節(jié)對(duì)分布式數(shù)據(jù)關(guān)聯(lián)系統(tǒng)的基本原理和數(shù)據(jù)處理方式進(jìn)行闡述。系統(tǒng)將來自四類數(shù)據(jù)源的數(shù)據(jù)進(jìn)行整合，從而計(jì)算描繪網(wǎng)絡(luò)的風(fēng)險(xiǎn)水平值。

在本文系統(tǒng)中，當(dāng)有客戶端查詢域名時(shí)，請(qǐng)求將被轉(zhuǎn)發(fā)到本地的遞歸DNS服務(wù)器。它通過向權(quán)威DNS服務(wù)器提出遞歸請(qǐng)求來解析域名。所有進(jìn)入遞歸DNS服務(wù)器的權(quán)威DNS回復(fù)都會(huì)被存儲(chǔ)在Cassandra數(shù)據(jù)庫中。收集DNS回復(fù)時(shí)，系統(tǒng)執(zhí)行了三個(gè)操作來推斷域名的惡意程度：

·根據(jù)三個(gè)公開的黑名單對(duì)域名實(shí)施檢查，三個(gè)黑名單的分值BLdom遞增。

·利用DNS數(shù)據(jù)自動(dòng)分類技術(shù)識(shí)別惡意域名[3,4]，此處采用機(jī)器學(xué)習(xí)算法計(jì)算所得的置信度Cdom作為風(fēng)險(xiǎn)值，數(shù)值越接近1，域名越可能是惡意的。

·根據(jù)蜜罐記錄的IP地址檢查DNS資源記錄中的每個(gè)IP。每出現(xiàn)一次匹配，則計(jì)數(shù)器Hdom遞增。假設(shè)某域名有5個(gè)A資源記錄，即5個(gè)IP地址相關(guān)聯(lián)，若其中3個(gè)被蜜罐記錄，則其Hdom得分為3。

根據(jù)上述三個(gè)數(shù)值，可以利用式（1）計(jì)算域名惡意程度值Domscore，并將該值與數(shù)據(jù)庫中的各個(gè)域名一起計(jì)算與存儲(chǔ)：

對(duì)于由核心路由導(dǎo)出的所有數(shù)據(jù)流量，本文系統(tǒng)用三個(gè)相關(guān)方案來推斷通信的惡意程度。這些關(guān)聯(lián)方案適用于不屬于企業(yè)網(wǎng)絡(luò)范圍的IP地址：

·根據(jù)蜜罐記錄的IP地址檢查與流量相關(guān)的IP地址。如果出現(xiàn)匹配，則檢查端口匹配情況。增加對(duì)應(yīng)于IP地址匹配和端口匹配的兩個(gè)布爾值，用于計(jì)算Hflow。如果首先匹配IP地址，則僅計(jì)算后者。

·根據(jù)DNS數(shù)據(jù)庫檢查與流量關(guān)聯(lián)的IP，以確定這些IP是否與我們認(rèn)為是惡意的域有關(guān)聯(lián)。將MDflow計(jì)算為對(duì)應(yīng)于與流量記錄的IP相關(guān)聯(lián)的所有域的Domscore數(shù)值總和。

·如果流記錄中出現(xiàn)的IP地址與DNS數(shù)據(jù)庫的任何域都無關(guān)，則此地址的分?jǐn)?shù)為NOflow=1。這表明可能出現(xiàn)了使用硬編碼IP的網(wǎng)絡(luò)通信，可能是可疑行為，因?yàn)楣粽呖赡軙?huì)嘗試?yán)@過基于DNS的入侵檢測(cè)。

根據(jù)上述三個(gè)數(shù)值，可以利用式（2）計(jì)算出根據(jù)流量記錄所確定的網(wǎng)絡(luò)風(fēng)險(xiǎn)值Flowscore：

在本文的系統(tǒng)中，HTTP流量是通過代理在線采集的，這些流量被轉(zhuǎn)發(fā)到本文的分析系統(tǒng)中進(jìn)行下述計(jì)算評(píng)估：

·檢查HTTP數(shù)據(jù)包的URI，以確定其是否嵌入DNS數(shù)據(jù)庫中存在的域。然后計(jì)算Dweb= Domscore以判斷URI是否是惡意的。

·針對(duì)有目標(biāo)或源IP地址的HTTP數(shù)據(jù)包，根據(jù)其是否登錄蜜罐，判斷用于表示其與潛在惡意來源通信的Hweb值（1或0）。

·由包括蜜罐在內(nèi)的仿真HTTP服務(wù)器接收的有效負(fù)載中的HTTP數(shù)據(jù)包，判斷PLhweb值（1或0），用于表示在HTTP數(shù)據(jù)包中公開注入代碼或shell腳本的痕跡。

·最后分析HTTP數(shù)據(jù)包的有效負(fù)載，以觀察其是否包含被動(dòng)DNS數(shù)據(jù)庫中存在的域名。如果找到這些域，則PLdweb得 分等于相應(yīng)域的Domscore之和。

根據(jù)上述四個(gè)數(shù)值，可以利用式（3）計(jì)算出描述HTTP數(shù)據(jù)包惡意程度的分值Webscore：

（三）應(yīng)用

前面提出了三個(gè)數(shù)據(jù)指標(biāo)Domscore，F(xiàn)lowscore和Webscore，用于評(píng)估域名、流量和HTTP數(shù)據(jù)包惡意的可能性。當(dāng)出現(xiàn)導(dǎo)致IDS發(fā)出警報(bào)或IPS出現(xiàn)阻止行為的通信時(shí)，可以分別利用上述指標(biāo)進(jìn)行具體判斷。

二、數(shù)據(jù)存儲(chǔ)和處理

上一節(jié)簡(jiǎn)要介紹了本文系統(tǒng)所利用的數(shù)據(jù)是在不同點(diǎn)收集并存儲(chǔ)在各種數(shù)據(jù)存儲(chǔ)系統(tǒng)中的（參見圖1）。系統(tǒng)實(shí)際運(yùn)行環(huán)境在包含近200臺(tái)計(jì)算機(jī)終端的行業(yè)辦公網(wǎng)絡(luò)環(huán)境中，在測(cè)試階段我們測(cè)量了下述數(shù)值：

·Dionaea蜜罐：每天從15個(gè)不同的主機(jī)嘗試大約1000次連接。

·NetFlow：平均日流量9600000，每分鐘出口一次（約450MB）。

·DNS：每天約1300萬次DNS回復(fù)（約1.5k MB）。

Dionaea蜜罐，連接由少量攻擊者發(fā)起，數(shù)據(jù)量不大，處理要求不高。另外，在測(cè)試期內(nèi)，發(fā)現(xiàn)部分IP可能隨著時(shí)間的推移創(chuàng)建冗余連接。對(duì)于數(shù)據(jù)量較小的此類數(shù)據(jù)，SQLite數(shù)據(jù)庫的查詢速度非?？?，因此本文系統(tǒng)選擇了SQLite數(shù)據(jù)庫存儲(chǔ)記錄信息（IP、端口、協(xié)議、有效負(fù)載等）。值得注意的是，即使監(jiān)控對(duì)象變成更大規(guī)模的網(wǎng)絡(luò)，如擁有500臺(tái)或10,000臺(tái)計(jì)算機(jī)的網(wǎng)絡(luò)，也不會(huì)影響部署在網(wǎng)絡(luò)中的單個(gè)蜜罐機(jī)器記錄的數(shù)據(jù)量，因此，此類數(shù)據(jù)總量也不會(huì)有太大變化。

網(wǎng)絡(luò)流量數(shù)據(jù)的存儲(chǔ)更具挑戰(zhàn)性，尤其是在本文的系統(tǒng)中需要的是一種可擴(kuò)展解決方案。在系統(tǒng)實(shí)現(xiàn)中，我們每分鐘用nfdump導(dǎo)出網(wǎng)絡(luò)流量，以實(shí)現(xiàn)近乎實(shí)時(shí)的網(wǎng)絡(luò)通信監(jiān)控。網(wǎng)絡(luò)流量記錄被存儲(chǔ)在幾個(gè)分布式服務(wù)器上的nfcapd二進(jìn)制文件中。在本文的實(shí)際案例實(shí)現(xiàn)中，多個(gè)服務(wù)器并非必需的，但由于路由器導(dǎo)出的流量會(huì)隨著網(wǎng)絡(luò)規(guī)模的變大而增長(zhǎng)，因此采用了多臺(tái)分布式服務(wù)器的方式，這種選擇能夠確保滿足任何規(guī)模網(wǎng)絡(luò)的可擴(kuò)展性存儲(chǔ)要求。然而，由于nfcapd文件是二進(jìn)制文件，它也導(dǎo)致了一些數(shù)據(jù)處理問題。大數(shù)據(jù)框架（如Hadoop）具有通?；谖谋镜腗apReduce任務(wù)輸入格式。雖然Hadoop支持二進(jìn)制輸入/輸出的內(nèi)置序列文件格式，但是，在上傳之前，必須先在HDFS（Hadoop分布式文件系統(tǒng)）序列文件中轉(zhuǎn)換nfcapd文件。此過程意味著較高的計(jì)算開銷，耗時(shí)且無法實(shí)現(xiàn)安全監(jiān)控的實(shí)時(shí)性。因此，另一種解決方式是開發(fā)一個(gè)新的API，直接讀取本機(jī)nfcapd格式的數(shù)據(jù)。該解決方案優(yōu)于本文系統(tǒng)中的解決方案，并且速度很快，文獻(xiàn)[9]中的實(shí)踐證明其對(duì)在200節(jié)點(diǎn)的測(cè)試平臺(tái)中能夠提供14Gbps的吞吐量。

與網(wǎng)絡(luò)流量類似，本文的實(shí)踐結(jié)果表明，DNS監(jiān)控也會(huì)產(chǎn)生較大的數(shù)據(jù)量。此外，該數(shù)據(jù)量也會(huì)隨著實(shí)施DNS查詢的用戶/機(jī)器數(shù)量（即網(wǎng)絡(luò)的大?。┒鲩L(zhǎng)。與網(wǎng)絡(luò)流量的全量存儲(chǔ)方式不同，對(duì)DNS監(jiān)控，不需要存儲(chǔ)所有相關(guān)數(shù)據(jù)，可以從DNS分組中提取部分信息以避免信息冗余，同時(shí)節(jié)省存儲(chǔ)空間。在本文系統(tǒng)中，存儲(chǔ)的信息包括域名、TTL、部分標(biāo)志符、首次訪問和末次訪問時(shí)間戳等。

為了滿足數(shù)據(jù)存儲(chǔ)和可用性的要求，DNS數(shù)據(jù)從數(shù)據(jù)包中提取并存儲(chǔ)在Apache Cassandra數(shù)據(jù)庫中。Cassandra是一種用于數(shù)據(jù)存儲(chǔ)的分布式數(shù)據(jù)庫，數(shù)據(jù)訪問方面的性能較為突出。此外，Apache Cassandra自0.6版本開始集成Hadoop管理，從而確保了與大數(shù)據(jù)處理的最新解決方案的便捷交互。本文系統(tǒng)采用此實(shí)現(xiàn)方式能夠確保系統(tǒng)的體系結(jié)構(gòu)適用于比測(cè)試網(wǎng)絡(luò)規(guī)模更大的網(wǎng)絡(luò)環(huán)境。

三、性能評(píng)估

針對(duì)本文提出的網(wǎng)絡(luò)安全監(jiān)控大數(shù)據(jù)架構(gòu)，本節(jié)針對(duì)Hadoop、Pig、Hive和Spark四個(gè)應(yīng)用最為廣泛的開源大數(shù)據(jù)框架的性能進(jìn)行了性能比較。在評(píng)估中，本節(jié)針對(duì)與技術(shù)指標(biāo)相關(guān)的三種不同任務(wù)，對(duì)上述四個(gè)大數(shù)據(jù)框架的執(zhí)行性能進(jìn)行了實(shí)驗(yàn)測(cè)試。實(shí)驗(yàn)環(huán)境為由8臺(tái)計(jì)算機(jī)（1個(gè)主節(jié)點(diǎn)、7個(gè)從節(jié)點(diǎn)）組成的集群環(huán)境，其中，所有計(jì)算機(jī)的性能配置均為：Intel(R) Core(TM) 2 Duo，Ubuntu 12.04.4操作系統(tǒng)，4GB內(nèi)存。實(shí)驗(yàn)中所采用的大數(shù)據(jù)框架版本分別為Hadoop-1.2.1、Hive-0.9.0、Pig-0.11.1和Spark-0.6.1。Spark框架的每個(gè)節(jié)點(diǎn)分配2GB內(nèi)存，共14GB工作內(nèi)存。針對(duì)所有框架和測(cè)試任務(wù)均做了10次測(cè)試。

三種測(cè)試任務(wù)分別為：

任務(wù)1：查找與給定源IP與源端口匹配的數(shù)據(jù)包；

任務(wù)2：在有效流量中查找包含給定字符串的數(shù)據(jù)包；

任務(wù)3：計(jì)算每個(gè)源IP的目標(biāo)IP數(shù)量并對(duì)結(jié)果進(jìn)行排序。

任務(wù)1的需求也就是計(jì)算Hdom要做的工作，即查找與域名相關(guān)的IP是否有被記錄。Hflow、Hweb和BLdom的計(jì)算也需要執(zhí)行同類型的操作。針對(duì)本文研究的四個(gè)框架，表1記錄了執(zhí)行該操作所需的時(shí)間，包括10次測(cè)試所花費(fèi)的平均時(shí)間、時(shí)間中位數(shù)，以及最小、最大持續(xù)時(shí)間。

從表1(a)的實(shí)驗(yàn)結(jié)果可以看出，針對(duì)任務(wù)1，Hadoop的Hive性能近似，均需約17.5秒執(zhí)行時(shí)間；Pig是所有測(cè)試框架中速度最慢的，平均需26.475秒執(zhí)行時(shí)間；Spark的執(zhí)行效率比其他框架高得多，且比較穩(wěn)定（平均時(shí)間、中位時(shí)間、最長(zhǎng)和最短執(zhí)行時(shí)間差別較?。?，是任務(wù)1下的最佳方案。

表1(b)和表1(c)也給出了針對(duì)任務(wù)2和任務(wù)3的實(shí)驗(yàn)結(jié)果記錄。其中，針對(duì)任務(wù)2，需要計(jì)算PLhweb和PLdweb，此項(xiàng)計(jì)算需要分析HTTP數(shù)據(jù)包的內(nèi)容以查找給定字符串和域名，該工作也可用于通過在URI中搜索惡意域來計(jì)算Dweb。針對(duì)任務(wù)3，能夠突顯出網(wǎng)絡(luò)環(huán)境中與Internet通信量最大的計(jì)算機(jī)，這也是網(wǎng)絡(luò)安全監(jiān)控中所需的重要信息。

針對(duì)這兩類任務(wù)的執(zhí)行測(cè)試情況，能夠觀察到與任務(wù)1幾乎相同的結(jié)果數(shù)據(jù)趨勢(shì)。Pig仍舊是最慢的解決方案，特別是對(duì)于任務(wù)3，需要82.744秒的任務(wù)執(zhí)行時(shí)間，是Hadoop用時(shí)的兩倍多、Spark用時(shí)的50倍。另外，除任務(wù)2之外，Hadoop和Hive的執(zhí)行時(shí)間幾乎相同，Hive的平均執(zhí)行時(shí)間快于Hadoop，但Hadoop比Hive更穩(wěn)定。Spark還是比其他三個(gè)方案執(zhí)行時(shí)間更短，每個(gè)任務(wù)的結(jié)果均約為1秒。對(duì)于任務(wù)2來說，Spark的表現(xiàn)較為穩(wěn)定，但對(duì)于任務(wù)3，Spark的穩(wěn)定性則較差，其最小與最大執(zhí)行時(shí)間之差高達(dá)6倍。

四、結(jié)語

本文提出了一種新的可擴(kuò)展網(wǎng)絡(luò)入侵檢測(cè)與防護(hù)技術(shù)架構(gòu)，并對(duì)該架構(gòu)的系統(tǒng)實(shí)現(xiàn)進(jìn)行了闡述。本文的系統(tǒng)實(shí)現(xiàn)以分布式方式收集和存儲(chǔ)蜜罐數(shù)據(jù)、DNS數(shù)據(jù)、HTTP流量與IP流量數(shù)據(jù)。介紹了基于這些數(shù)據(jù)的幾種入侵檢測(cè)與取證分析應(yīng)用方案，并在四種數(shù)據(jù)的存儲(chǔ)與處理方案中評(píng)估并提出了適合本文架構(gòu)的五種最先進(jìn)的大數(shù)據(jù)框架。

雖然本文的架構(gòu)在安全分值計(jì)算中延遲很少，但是仍然使用了Hadoop和Shark的離線分析工具。在未來的研究中，將使用在線分析大數(shù)據(jù)框架（如Spark Streaming 或Storm）實(shí)現(xiàn)相同的系統(tǒng)功能，并對(duì)兩類方案的優(yōu)劣進(jìn)行比較研究。