焦宏宇，何利文，黃 俊

(南京郵電大學(xué) 計(jì)算機(jī)學(xué)院，江蘇 南京 210046)

0 引 言

近年來，云計(jì)算、大數(shù)據(jù)被社會(huì)各界廣泛關(guān)注并快速發(fā)展。作為提供ISSA服務(wù)的開源云平臺(tái)Openstack[1]也被很多公司作為構(gòu)建私有云的管理平臺(tái)。隨之而來，Openstack的安全問題也日益嚴(yán)峻。由于Openstack本身并沒有有效的安全機(jī)制防止網(wǎng)絡(luò)上的攻擊，會(huì)造成很大的安全隱患。蜜場(chǎng)技術(shù)作為網(wǎng)絡(luò)安全領(lǐng)域的核心技術(shù)，結(jié)合了蜜罐技術(shù)[2]和異常檢測(cè)機(jī)制，在大型分布式網(wǎng)絡(luò)中集中部署蜜罐，對(duì)各個(gè)子網(wǎng)安全威脅進(jìn)行收集。但是蜜場(chǎng)系統(tǒng)受安全性、性能和保真度這三個(gè)因素的相互制約而無法廣泛應(yīng)用?；诿蹐?chǎng)技術(shù)的Openstack安全模塊研究就是在這種背景下進(jìn)行的，它不僅為私有云提供了更高的安全性，而且解決了蜜場(chǎng)系統(tǒng)搭建的安全性、保真度與性能這三個(gè)相互制約因素帶來的難題，讓蜜場(chǎng)系統(tǒng)具有了更高的實(shí)用價(jià)值。

但是目前很多的蜜場(chǎng)都是用于傳統(tǒng)物理網(wǎng)絡(luò)，對(duì)于虛擬化網(wǎng)絡(luò)中的應(yīng)用不是很成熟。文獻(xiàn)[3]介紹了通過構(gòu)建SDN蜜網(wǎng)，利用OpenDaylight控制器良好的可擴(kuò)展性和可控性，解決了傳統(tǒng)蜜網(wǎng)難以實(shí)現(xiàn)流量控制、部署不便、調(diào)整復(fù)雜等問題。文獻(xiàn)[4]建立了一個(gè)稱為Potemkin的原型蜂窩系統(tǒng)，利用虛擬機(jī)，激進(jìn)的內(nèi)存共享以及后期綁定資源來實(shí)現(xiàn)這一目標(biāo)。雖然還不成熟，但Potemkin在實(shí)際測(cè)試中模擬了超過64 000個(gè)互聯(lián)網(wǎng)蜜罐，僅僅是使用少量的物理服務(wù)器。

1 網(wǎng)絡(luò)攻擊流量重定向

重定向[5]是蜜場(chǎng)系統(tǒng)中的關(guān)鍵組成部分。它的作用是將進(jìn)入Openstack系統(tǒng)的所有流量進(jìn)行分類，并將不同的流量重定向到不同的系統(tǒng)中去。首先，監(jiān)聽非業(yè)務(wù)地址以及端口，非業(yè)務(wù)的流量會(huì)直接重定向到蜜場(chǎng)中；其次，業(yè)務(wù)流量會(huì)交由異常檢測(cè)系統(tǒng)進(jìn)行分析，檢測(cè)到的異常流量會(huì)直接重定向到蜜場(chǎng)中；最后，由異常檢測(cè)系統(tǒng)檢測(cè)出的正常流量才會(huì)轉(zhuǎn)發(fā)到業(yè)務(wù)系統(tǒng)中。但是現(xiàn)有的網(wǎng)絡(luò)攻擊檢測(cè)與網(wǎng)絡(luò)流量的重定向機(jī)制，存在較多不足，無法很好地滿足蜜場(chǎng)的需要。同時(shí)現(xiàn)有的重定向機(jī)制無法很好地工作在Openstack虛擬化的網(wǎng)絡(luò)環(huán)境中[6]。

1.1 網(wǎng)絡(luò)攻擊檢測(cè)系統(tǒng)

黑客進(jìn)行攻擊之前，一般都會(huì)進(jìn)行網(wǎng)絡(luò)掃描。網(wǎng)絡(luò)掃描通常掃描的是一個(gè)目的IP地址段，這些地址段中有些IP是未被使用的，端口掃描通常掃的是已有IP地址的主機(jī)上的大量端口，有些端口并未使用，即未開啟相應(yīng)服務(wù)。對(duì)于非活躍IP地址以及非開放端口的訪問，統(tǒng)稱為非業(yè)務(wù)訪問，這些訪問通常是攻擊流量。對(duì)于非業(yè)務(wù)流量的重定向，可以引誘攻擊這對(duì)蜜罐進(jìn)行攻擊。如果黑客通過某種方法得知業(yè)務(wù)系統(tǒng)地址，根據(jù)業(yè)務(wù)系統(tǒng)的漏洞對(duì)服務(wù)進(jìn)行攻擊，可達(dá)到一定的目的。對(duì)業(yè)務(wù)子網(wǎng)中活躍主機(jī)上開放服務(wù)的訪問，叫做業(yè)務(wù)訪問，也包含各種各樣的攻擊。

所以，針對(duì)子網(wǎng)的網(wǎng)絡(luò)攻擊流，不僅包含非業(yè)務(wù)流量，也包含業(yè)務(wù)流量。因此網(wǎng)絡(luò)攻擊檢測(cè)機(jī)制包含了對(duì)于非業(yè)務(wù)流量以及業(yè)務(wù)流量的檢測(cè)機(jī)制。

1.1.1 非業(yè)務(wù)訪問監(jiān)聽模塊

非業(yè)務(wù)訪問監(jiān)聽，需要確定哪些是非業(yè)務(wù)的流量，一般體現(xiàn)為未使用的IP+Port，需要去探測(cè)業(yè)務(wù)子網(wǎng)中哪些地址和端口是未使用的。這兩個(gè)參數(shù)主要體現(xiàn)在虛擬機(jī)是不是運(yùn)行狀態(tài)以及運(yùn)行狀態(tài)的虛擬機(jī)上開啟的端口有哪些。

對(duì)于虛擬機(jī)的狀態(tài)，在傳統(tǒng)網(wǎng)絡(luò)中或使用Ping進(jìn)行存活狀態(tài)檢測(cè)，而在Openstack中所有虛擬機(jī)的狀態(tài)都會(huì)由系統(tǒng)檢測(cè)記錄到相應(yīng)的數(shù)據(jù)庫中，可以直接拉取子網(wǎng)內(nèi)虛擬機(jī)狀態(tài)信息，分析出哪些IP地址是運(yùn)行中主機(jī)使用的。

對(duì)于運(yùn)行中虛擬機(jī)的端口是否開放，可以先拉取虛擬機(jī)安全組配置，將放行的端口取出，對(duì)應(yīng)運(yùn)行中主機(jī)放行的端口進(jìn)行主動(dòng)探測(cè)，將探測(cè)出來的運(yùn)行主機(jī)對(duì)應(yīng)的開放端口記錄下來。

以上兩個(gè)機(jī)制可以獲取到子網(wǎng)業(yè)務(wù)地址與端口，根據(jù)這些信息建立虛擬機(jī)開放服務(wù)信息庫。非業(yè)務(wù)監(jiān)聽模塊如圖1所示。

圖1 非業(yè)務(wù)監(jiān)聽模塊

1.1.2 針對(duì)業(yè)務(wù)訪問的異常檢測(cè)模塊

業(yè)務(wù)訪問中很可能會(huì)包含各種各樣的攻擊，對(duì)這些攻擊進(jìn)行檢測(cè)的有效方式是采用入侵檢測(cè)技術(shù)，入侵檢測(cè)技術(shù)可以檢測(cè)出某些未知攻擊。在業(yè)務(wù)子網(wǎng)中部署基于支持向量機(jī)(SVM)的入侵檢測(cè)系統(tǒng)[7]，經(jīng)過模擬仿真實(shí)驗(yàn)驗(yàn)證選取最佳的SVM參數(shù)。當(dāng)入侵檢測(cè)系統(tǒng)檢測(cè)出異常流量后，對(duì)這股流量需要重定向到蜜場(chǎng)中。同時(shí)異常檢測(cè)系統(tǒng)會(huì)將攻擊信息記錄到事件數(shù)據(jù)庫中，其中包括最重要的信息是攻擊源的IP和Port，將該信息其存入黑名單列表中，并設(shè)置一個(gè)超時(shí)時(shí)間，在超時(shí)時(shí)間內(nèi)該IP:Port發(fā)來的流量都會(huì)被視為攻擊流量直接重定向到蜜場(chǎng)中，不再經(jīng)過異常檢測(cè)系統(tǒng)，減輕了系統(tǒng)壓力。

1.2 網(wǎng)絡(luò)流量重定向系統(tǒng)

Openstack虛擬化網(wǎng)絡(luò)與物理網(wǎng)絡(luò)存在很多不同之處。物理網(wǎng)絡(luò)是由傳統(tǒng)物理網(wǎng)絡(luò)設(shè)備和物理服務(wù)器組成，數(shù)據(jù)包由網(wǎng)絡(luò)設(shè)備進(jìn)行轉(zhuǎn)發(fā)。而Openstack虛擬化網(wǎng)絡(luò)較為復(fù)雜，Openstack所有的外部網(wǎng)絡(luò)的流量和Openstack內(nèi)同租戶跨網(wǎng)段的流量都是要經(jīng)過neutron節(jié)點(diǎn)，通過不同租戶命名空間的router進(jìn)行路由的。該組件會(huì)基于每個(gè)租戶虛擬化出基于不同命名空間(namespace)的路由器(router)，所有該租戶下的虛擬機(jī)去往外網(wǎng)的通信都會(huì)在該router上面做NAT，同租戶下的跨網(wǎng)段通信也由該router進(jìn)行路由。由于Openstack網(wǎng)絡(luò)的特殊性，物理網(wǎng)絡(luò)的重定向設(shè)計(jì)不適合Openstack的網(wǎng)絡(luò)模式。

文中采用重定向器作為中間設(shè)備，橋接業(yè)務(wù)系統(tǒng)租戶命名空間router和蜜場(chǎng)網(wǎng)絡(luò)租戶命名空間router，進(jìn)行重定向以及相關(guān)的路由。當(dāng)一個(gè)新的租戶網(wǎng)絡(luò)被創(chuàng)建時(shí)，Openstack在該租戶網(wǎng)絡(luò)所在neutron節(jié)點(diǎn)上，創(chuàng)建相應(yīng)命名空間的router，同時(shí)會(huì)新建一個(gè)redirect橋接到該新建租戶的router和蜜場(chǎng)租戶的router上。redirect會(huì)對(duì)不同類型的數(shù)據(jù)包進(jìn)行相關(guān)修改，不同租戶命名空間的router負(fù)責(zé)相關(guān)數(shù)據(jù)包的路由，具體流程如圖2所示。

圖2 網(wǎng)絡(luò)流量重定向系統(tǒng)

1.當(dāng)外部流量進(jìn)來之后會(huì)到達(dá)業(yè)務(wù)系統(tǒng)租戶(service_tenant)命名空間下的service_router，service_router會(huì)將所有流量都轉(zhuǎn)發(fā)到redirect上；

2.redirect根據(jù)流量分類進(jìn)行相關(guān)操作，如果是非業(yè)務(wù)流量直接DNAT發(fā)給honeyfarm_router；如果是針對(duì)業(yè)務(wù)系統(tǒng)的攻擊流量會(huì)進(jìn)行DNAT發(fā)給honeyfarm_router；如果是業(yè)務(wù)系統(tǒng)的正常流量，會(huì)直接轉(zhuǎn)發(fā)給service_router，不做任何操作；

3.同時(shí)redirect會(huì)給非正常業(yè)務(wù)流量打上相應(yīng)標(biāo)記[8]，標(biāo)記該流量是針對(duì)Openstack業(yè)務(wù)系統(tǒng)中的哪臺(tái)虛擬機(jī)的流量。因?yàn)閂M的UUID可以唯一標(biāo)識(shí)一臺(tái)虛擬機(jī)，所以采用UUID來標(biāo)識(shí)該流量，以便針對(duì)業(yè)務(wù)系統(tǒng)的攻擊流量轉(zhuǎn)發(fā)到蜜場(chǎng)網(wǎng)關(guān)，蜜場(chǎng)網(wǎng)關(guān)可以結(jié)合這個(gè)標(biāo)記和自身的相關(guān)數(shù)據(jù)庫進(jìn)行轉(zhuǎn)發(fā)；

4.所有進(jìn)入蜜場(chǎng)的流量回包會(huì)經(jīng)過蜜場(chǎng)系統(tǒng)租戶(honeyfarm_tenant)命名空間下的honeyfarm_router，該router將流量發(fā)給redirect，redirect對(duì)流量進(jìn)行SNAT，發(fā)給service_router進(jìn)行路由；

5.所有正常的業(yè)務(wù)流量，直接由service_router路由給業(yè)務(wù)系統(tǒng)，回包也是由service_router進(jìn)行路由。

2 蜜場(chǎng)系統(tǒng)

利用Openstack中每個(gè)租戶隔離的特性，將蜜場(chǎng)單獨(dú)放入一個(gè)租戶中，使它邏輯上與其他業(yè)務(wù)系統(tǒng)所在的租戶隔離。蜜場(chǎng)系統(tǒng)應(yīng)該具備數(shù)據(jù)安全控制的機(jī)制、數(shù)據(jù)捕獲機(jī)制以及動(dòng)態(tài)部署蜜罐的機(jī)制[9]。

2.1 數(shù)據(jù)控制安全策略

當(dāng)蜜場(chǎng)內(nèi)的蜜罐機(jī)器被黑客攻陷后，為了防止黑客使用這些蜜罐作為跳板向外攻擊別的節(jié)點(diǎn)，造成二次危害，在蜜場(chǎng)內(nèi)做安全控制是非常有必要的[10]。蜜場(chǎng)的目的是吸引黑客的攻擊，所以進(jìn)入蜜場(chǎng)的流量是不能限制的，只需要限制出向的流量即可。所有從蜜場(chǎng)中出去的流量都會(huì)被認(rèn)為是與黑客交互的流量，都需要進(jìn)行限制。一般會(huì)將單位時(shí)間內(nèi)出向的流量大小以及出向的連接數(shù)限制到一個(gè)合理的值。這些參數(shù)可以直接在蜜場(chǎng)網(wǎng)關(guān)的iptables上進(jìn)行統(tǒng)一配置，其可以限制多種協(xié)議的連接數(shù)以及流量大小，比如TCP、UDP、ICMP等。數(shù)據(jù)控制安全策略的配置文件為rc.firewall，如在rc.firewall設(shè)置規(guī)則：

##set the connection outbound limits for different protocols

SCALE="day"#記錄單位，也可以是秒、分、小時(shí)等

TCPRATE="15"#每記時(shí)單位中允許的TCP連接數(shù)

UDPRATE="20"#每記時(shí)單位中允許的UDP連接數(shù)

ICMPRATE="50"#每記時(shí)單位中允許的ICMP連接數(shù)

OTHERRATE="15"#每記時(shí)單位中允許的其他IP新協(xié)議連接數(shù)

STOP_OUT="no"#如果不想允許任何向外連接，可以將這個(gè)參數(shù)設(shè)為"yes"

通過此規(guī)則設(shè)置，可以較好地限制對(duì)外連接數(shù)量。

2.2 數(shù)據(jù)捕獲機(jī)制

部署蜜場(chǎng)最主要的目的是記錄攻擊者的相關(guān)數(shù)據(jù)，比如攻擊行為、攻擊數(shù)據(jù)包，然后用收集到的這些數(shù)據(jù)進(jìn)行分析和反向追蹤。所以如何收集這些數(shù)據(jù)也至關(guān)重要。

數(shù)據(jù)捕獲機(jī)制是在蜜場(chǎng)網(wǎng)關(guān)和蜜罐上捕獲數(shù)據(jù)的。蜜場(chǎng)網(wǎng)關(guān)是所有數(shù)據(jù)出入蜜場(chǎng)的必經(jīng)之地，所以蜜場(chǎng)網(wǎng)關(guān)上捕獲的數(shù)據(jù)是最全面的。在蜜場(chǎng)網(wǎng)關(guān)利用iptables可以記錄所有經(jīng)過蜜場(chǎng)網(wǎng)關(guān)的連接，同時(shí)給不同的流量打上不同的標(biāo)記，使用tcpdump抓包工具抓取相應(yīng)標(biāo)記的數(shù)據(jù)包，以便后續(xù)分類和分析[11]。在蜜罐上通過運(yùn)行sebek來記錄攻擊者的攻擊行為，比如擊鍵記錄、所讀取的數(shù)據(jù)以及運(yùn)行了哪些程序。

2.3 動(dòng)態(tài)蜜罐部署機(jī)制

動(dòng)態(tài)部署蜜罐最關(guān)鍵的一點(diǎn)是怎樣學(xué)習(xí)周圍的網(wǎng)絡(luò)環(huán)境。傳統(tǒng)的方法[12]有兩種，方法一是積極主動(dòng)地進(jìn)行探測(cè)，從而確定周圍存在一些什么樣的操作系統(tǒng)。然而這種方法存在一些不足。首先，它引入了額外的網(wǎng)絡(luò)活動(dòng)，不可避免會(huì)影響到網(wǎng)絡(luò)帶寬；其次，為能夠了解網(wǎng)絡(luò)的變化情況，必須持續(xù)對(duì)網(wǎng)絡(luò)進(jìn)行掃描，這可能使得系統(tǒng)中的某些服務(wù)甚至整個(gè)服務(wù)被關(guān)閉。方法二是采用被動(dòng)采集的方法獲取周圍的網(wǎng)絡(luò)環(huán)境。這種方法基于每種操作系統(tǒng)的IP協(xié)議棧不同的特點(diǎn)，缺點(diǎn)在于不能精確判斷出網(wǎng)絡(luò)環(huán)境，操作系統(tǒng)眾多，有些操作系統(tǒng)僅通過數(shù)據(jù)包內(nèi)的某些字段是判斷不出來的。而且上述兩種方法都是針對(duì)物理網(wǎng)絡(luò)的，對(duì)于Openstack這種多租戶隔離的網(wǎng)絡(luò)是不行的。所以采用直接從Openstack虛擬機(jī)狀態(tài)數(shù)據(jù)庫中獲取虛擬機(jī)鏡像信息的方法較為合適。

2.3.1 如何探測(cè)網(wǎng)絡(luò)環(huán)境

根據(jù)Openstack的特點(diǎn)，它作為一個(gè)對(duì)虛擬機(jī)、虛擬網(wǎng)絡(luò)等的管理平臺(tái)，會(huì)記錄下很多虛擬機(jī)相關(guān)的數(shù)據(jù)到數(shù)據(jù)庫中，比如虛擬機(jī)的狀態(tài)信息、創(chuàng)建虛擬機(jī)的鏡像等。在蜜場(chǎng)網(wǎng)關(guān)上監(jiān)聽虛擬機(jī)相關(guān)操作的nova-api接口，根據(jù)不同的調(diào)用參數(shù)做出相應(yīng)的操作。如果是新建虛擬機(jī)的調(diào)用，一旦有新建虛擬機(jī)的操作，就會(huì)立即根據(jù)新建虛擬機(jī)使用的鏡像，在蜜場(chǎng)中創(chuàng)建相同的操作系統(tǒng)的虛擬機(jī)作為honeypot，該honeypot的UUID與業(yè)務(wù)虛擬機(jī)的UUID的對(duì)應(yīng)關(guān)系會(huì)存到honeypot_vm的數(shù)據(jù)庫中；如果有刪除的操作，會(huì)立即刪除相應(yīng)的honeypot同時(shí)更新honey_vm數(shù)據(jù)庫；如果有關(guān)機(jī)、掛起或者掃描到vm狀態(tài)不為運(yùn)行中，這時(shí)會(huì)在數(shù)據(jù)庫中給該vm對(duì)應(yīng)的條目設(shè)置一個(gè)計(jì)時(shí)器，如果該計(jì)時(shí)器到期之前vm狀態(tài)還不是運(yùn)行中，就會(huì)刪除該vm對(duì)應(yīng)的honeypot以及數(shù)據(jù)庫條目。同時(shí)，蜜場(chǎng)網(wǎng)關(guān)會(huì)定期對(duì)Openstack的虛擬機(jī)狀態(tài)信息數(shù)據(jù)庫進(jìn)行掃描，如果有些業(yè)務(wù)虛擬機(jī)的UUID在honey_vm的數(shù)據(jù)庫中不存在，就會(huì)根據(jù)該虛擬機(jī)的鏡像在honeyfarm中創(chuàng)建相應(yīng)的蜜罐。這是針對(duì)同一時(shí)間有大量的虛擬機(jī)新建操作，可能無法及時(shí)創(chuàng)建相應(yīng)的蜜罐的問題，采用定期掃描的方法進(jìn)行補(bǔ)充。

2.3.2 蜜罐系統(tǒng)模板

根據(jù)Openstack相關(guān)的狀態(tài)信息去創(chuàng)建honeypot，相對(duì)于去探測(cè)或者抓取虛擬機(jī)發(fā)送的數(shù)據(jù)包判斷更為準(zhǔn)確快速[13]，同時(shí)不會(huì)占用大量的網(wǎng)絡(luò)帶寬，也不需要耗費(fèi)抓取數(shù)據(jù)的資源。但是根據(jù)系統(tǒng)鏡像創(chuàng)建的honeypot有個(gè)缺點(diǎn)，就是其上沒有業(yè)務(wù)服務(wù)，不能很好地吸引和留住黑客。所以，采用虛擬機(jī)快照的方式去創(chuàng)建honeypot，當(dāng)虛擬機(jī)創(chuàng)建之后定期對(duì)虛擬機(jī)進(jìn)行快照，利用快照去創(chuàng)建蜜罐，這樣可以復(fù)制虛擬機(jī)的部分業(yè)務(wù)服務(wù)，使得蜜罐更像真實(shí)業(yè)務(wù)系統(tǒng)，更為真實(shí)，提高與黑客的交互度。

3 基于蜜場(chǎng)的Openstack安全系統(tǒng)設(shè)計(jì)

將蜜場(chǎng)和Openstack進(jìn)行有機(jī)結(jié)合，設(shè)置出一個(gè)基于虛擬化網(wǎng)絡(luò)的新型蜜場(chǎng)系統(tǒng)。其中，網(wǎng)絡(luò)攻擊檢測(cè)系統(tǒng)中的非業(yè)務(wù)流量監(jiān)聽模塊負(fù)責(zé)監(jiān)聽非業(yè)務(wù)流量，異常檢測(cè)模塊負(fù)責(zé)對(duì)業(yè)務(wù)流量進(jìn)行異常分析；網(wǎng)絡(luò)流量重定向系統(tǒng)中的重定向模塊負(fù)責(zé)對(duì)于非業(yè)務(wù)流量監(jiān)聽模塊監(jiān)聽到的流量和異常檢測(cè)模塊檢測(cè)出的異常流量進(jìn)行重定向，將流量重定向到蜜場(chǎng)中進(jìn)行交互，路由模塊負(fù)責(zé)正常流量和重定向后的攻擊流量的路由；蜜場(chǎng)系統(tǒng)中的動(dòng)態(tài)蜜罐部署機(jī)制根據(jù)業(yè)務(wù)系統(tǒng)的虛擬機(jī)狀態(tài)動(dòng)態(tài)地配置蜜罐以及根據(jù)虛擬機(jī)的快照進(jìn)行蜜罐的創(chuàng)建?；诿蹐?chǎng)的Openstack安全系統(tǒng)設(shè)計(jì)框架如圖3所示。

系統(tǒng)的工作流程如下：網(wǎng)絡(luò)攻擊檢測(cè)系統(tǒng)進(jìn)行流量分析，將流量分類；由重定向系統(tǒng)將分類后的流量進(jìn)行重定向，正常流量路由到業(yè)務(wù)系統(tǒng)，攻擊流量路由到蜜場(chǎng)；蜜場(chǎng)中的蜜罐負(fù)責(zé)和外部攻擊進(jìn)行交互；根據(jù)虛擬機(jī)狀態(tài)和快照，動(dòng)態(tài)地部署蜜罐系統(tǒng)。

4 實(shí)驗(yàn)及結(jié)果分析

在Openstack上部署改進(jìn)的蜜場(chǎng)環(huán)境[14]，創(chuàng)建一個(gè)小型業(yè)務(wù)租戶與子網(wǎng)作為實(shí)驗(yàn)平臺(tái)。蜜場(chǎng)環(huán)境由一個(gè)蜜場(chǎng)網(wǎng)關(guān)以及蜜罐系統(tǒng)組成；業(yè)務(wù)子網(wǎng)由重定向和若干業(yè)務(wù)主機(jī)組成，每個(gè)業(yè)務(wù)主機(jī)上有若干對(duì)外開放的服務(wù)，可通過Internet訪問。在重定向上允許非業(yè)務(wù)探測(cè)、網(wǎng)絡(luò)入侵檢測(cè)、網(wǎng)絡(luò)流量重定向和日志記錄系統(tǒng)，在蜜場(chǎng)網(wǎng)關(guān)上啟動(dòng)動(dòng)態(tài)蜜罐部署的服務(wù)、Firewall以及流記錄器。經(jīng)過一段時(shí)間的運(yùn)行，各子系統(tǒng)工作正常，實(shí)驗(yàn)結(jié)果及分析如下：

重定向的網(wǎng)絡(luò)流正確地到達(dá)了蜜場(chǎng)環(huán)境。經(jīng)過對(duì)比，在重定向網(wǎng)關(guān)的流信息庫中，被重定向的流(非業(yè)務(wù)流量、異常流量)在蜜場(chǎng)網(wǎng)關(guān)的流記錄中都能找到，反之亦然，說明重定向系統(tǒng)是正常工作的。

蜜場(chǎng)中的蜜罐以及honeypot_vm數(shù)據(jù)記錄均正確。經(jīng)過對(duì)比，在honeypot_vm數(shù)據(jù)庫的記錄和相關(guān)的蜜罐均能正確匹配，并且蜜罐的系統(tǒng)模板與服務(wù)系統(tǒng)的快照一樣，說明動(dòng)態(tài)蜜罐部署的機(jī)制是正常的。

根據(jù)蜜場(chǎng)網(wǎng)關(guān)以及蜜罐上監(jiān)測(cè)系統(tǒng)的日志記錄得到一些攻擊數(shù)據(jù)。圖4展示了24小時(shí)內(nèi)被重定向經(jīng)過蜜場(chǎng)網(wǎng)關(guān)的網(wǎng)絡(luò)流量統(tǒng)計(jì)圖，圖5是24小時(shí)內(nèi)Openstack虛擬化網(wǎng)絡(luò)內(nèi)的各類型網(wǎng)絡(luò)流量統(tǒng)計(jì)對(duì)比圖。可以看到：有較大比例的網(wǎng)絡(luò)流量為非業(yè)務(wù)訪問被重定向到蜜場(chǎng)；小部分流量為未知源的攻擊流；少部分流量為已知源攻擊流，也被重定向到蜜場(chǎng)；還有高度可疑的蜜罐對(duì)Internet訪問流，說明攻擊者對(duì)蜜罐攻擊成功。

圖5 24小時(shí)內(nèi)各類型網(wǎng)絡(luò)流量統(tǒng)計(jì)對(duì)比圖

系統(tǒng)潛在問題：時(shí)間延遲。當(dāng)未知攻擊源實(shí)施對(duì)業(yè)務(wù)系統(tǒng)的首次攻擊，依次經(jīng)過異常檢測(cè)系統(tǒng)檢測(cè)，重定向和蜜場(chǎng)網(wǎng)關(guān)分發(fā)流量到蜜罐，這些動(dòng)作均有短時(shí)間延遲。

5 結(jié)束語

對(duì)面向虛擬化環(huán)境的蜜場(chǎng)進(jìn)行了研究，結(jié)合Openstack虛擬網(wǎng)絡(luò)和Openstack對(duì)虛擬機(jī)狀態(tài)的記錄，設(shè)計(jì)出了針對(duì)虛擬化環(huán)境中的重定向?qū)崿F(xiàn)機(jī)制以及動(dòng)態(tài)蜜罐部署機(jī)制。實(shí)驗(yàn)結(jié)果表明，該新型蜜場(chǎng)系統(tǒng)很好地解決了虛擬化環(huán)境的安全問題。下一步的工作將是在蜜場(chǎng)環(huán)境中對(duì)重定向的攻擊流進(jìn)行取證分析，這涉及到跟蹤攻擊行為和攻擊取證等一系列技術(shù)，在這些技術(shù)研究的基礎(chǔ)上，最終將實(shí)現(xiàn)虛擬化環(huán)境中基于蜜場(chǎng)的網(wǎng)絡(luò)主動(dòng)安全防護(hù)系統(tǒng)。