李磊 山東省煙臺市公安局交通警察支隊

引言

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

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

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

本文通過提出一個用于企業(yè)網(wǎng)絡(luò)入侵檢測與預(yù)防的系統(tǒng)架構(gòu)，解決了上述問題。本文方法的數(shù)據(jù)源包括DNS流量、HTTP流量、IP流記錄與蜜罐數(shù)據(jù)等。上述數(shù)據(jù)中的每一種都已經(jīng)被單獨(dú)應(yīng)用于入侵檢測并被證明是有效的[3-7]。然而，為了應(yīng)對各種新型攻擊手段和混合攻擊技術(shù)，安全防護(hù)系統(tǒng)必須利用所有可用的分析數(shù)據(jù)源。本文提出的系統(tǒng)在同一個分布式數(shù)據(jù)存儲和處理系統(tǒng)中集成了三個不同的數(shù)據(jù)存儲系統(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ù)存儲系統(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請求以獲取與域關(guān)聯(lián)的IP地址，然后查詢所需的資源。因此，對DNS進(jìn)行監(jiān)控以識別惡意域，是主動檢測和防止惡意通信的有效方式。在大規(guī)模網(wǎng)絡(luò)的具體實(shí)現(xiàn)中，需要在網(wǎng)絡(luò)中的遞歸DNS服務(wù)器上設(shè)置DNS探測器，用于收集所有相關(guān)的DNS請求和網(wǎng)絡(luò)回復(fù)。本文系統(tǒng)的DNS探測器捕獲發(fā)往遞歸DNS服務(wù)器的DNS回復(fù)，并從DNS數(shù)據(jù)包中提取信息。所有被觀察到的域及提取的信息都存儲在一個高可擴(kuò)展且可用的數(shù)據(jù)庫Apache Cassandra數(shù)據(jù)庫中。

在互聯(lián)網(wǎng)用戶流量中，HTTP流量占很大一部分，同時也是眾所周知的入侵媒介。對嵌入在HTTP數(shù)據(jù)包中的URI及其有效負(fù)載進(jìn)行研究，能夠有效地檢測與防止惡意網(wǎng)絡(luò)通信。因此，本文系統(tǒng)在網(wǎng)絡(luò)HTTP代理級別對HTTP流量實(shí)施監(jiān)視，網(wǎng)絡(luò)中的所有HTTP連接嘗試都通過該代理，并通過檢查分組的嵌入域和IP目的地，對連續(xù)參與相同通信的不同URI實(shí)施動態(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)端口、時間戳、使用的協(xié)議、交換的數(shù)據(jù)量等。這些流記錄信息對檢測入侵或發(fā)現(xiàn)僵尸網(wǎng)絡(luò)通信非常有價值。本文的系統(tǒng)通過從網(wǎng)絡(luò)中的核心路由導(dǎo)出NetFlow記錄，對從企業(yè)網(wǎng)絡(luò)與Internet之間的所有通信進(jìn)行了存儲。NetFlow記錄采用分布式存儲方式存儲在nfcapd二進(jìn)制文件中。

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

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

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

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

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

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

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

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

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

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

·根據(jù)DNS數(shù)據(jù)庫檢查與流量關(guān)聯(lián)的IP，以確定這些IP是否與我們認(rèn)為是惡意的域有關(guān)聯(lián)。將MDflow計算為對應(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)@過基于DNS的入侵檢測。

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

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

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

·針對有目標(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ù)載，以觀察其是否包含被動DNS數(shù)據(jù)庫中存在的域名。如果找到這些域，則PLdweb得 分等于相應(yīng)域的Domscore之和。

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

（三）應(yīng)用

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

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

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

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

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

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

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

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

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

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

三、性能評估

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

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

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

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

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

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

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

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

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

四、結(jié)語

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

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