基于蜜場的Openstack安全系統(tǒng)

焦宏宇，何利文，黃 俊

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

0 引 言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業(yè)務(wù)訪問中很可能會包含各種各樣的攻擊，對這些攻擊進行檢測的有效方式是采用入侵檢測技術(shù)，入侵檢測技術(shù)可以檢測出某些未知攻擊。在業(yè)務(wù)子網(wǎng)中部署基于支持向量機(SVM)的入侵檢測系統(tǒng)[7]，經(jīng)過模擬仿真實驗驗證選取最佳的SVM參數(shù)。當(dāng)入侵檢測系統(tǒng)檢測出異常流量后，對這股流量需要重定向到蜜場中。同時異常檢測系統(tǒng)會將攻擊信息記錄到事件數(shù)據(jù)庫中，其中包括最重要的信息是攻擊源的IP和Port，將該信息其存入黑名單列表中，并設(shè)置一個超時時間，在超時時間內(nèi)該IP:Port發(fā)來的流量都會被視為攻擊流量直接重定向到蜜場中，不再經(jīng)過異常檢測系統(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è)備進行轉(zhuǎn)發(fā)。而Openstack虛擬化網(wǎng)絡(luò)較為復(fù)雜，Openstack所有的外部網(wǎng)絡(luò)的流量和Openstack內(nèi)同租戶跨網(wǎng)段的流量都是要經(jīng)過neutron節(jié)點，通過不同租戶命名空間的router進行路由的。該組件會基于每個租戶虛擬化出基于不同命名空間(namespace)的路由器(router)，所有該租戶下的虛擬機去往外網(wǎng)的通信都會在該router上面做NAT，同租戶下的跨網(wǎng)段通信也由該router進行路由。由于Openstack網(wǎng)絡(luò)的特殊性，物理網(wǎng)絡(luò)的重定向設(shè)計不適合Openstack的網(wǎng)絡(luò)模式。

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

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

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

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

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

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

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

2 蜜場系統(tǒng)

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

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

當(dāng)蜜場內(nèi)的蜜罐機器被黑客攻陷后，為了防止黑客使用這些蜜罐作為跳板向外攻擊別的節(jié)點，造成二次危害，在蜜場內(nèi)做安全控制是非常有必要的[10]。蜜場的目的是吸引黑客的攻擊，所以進入蜜場的流量是不能限制的，只需要限制出向的流量即可。所有從蜜場中出去的流量都會被認(rèn)為是與黑客交互的流量，都需要進行限制。一般會將單位時間內(nèi)出向的流量大小以及出向的連接數(shù)限制到一個合理的值。這些參數(shù)可以直接在蜜場網(wǎng)關(guān)的iptables上進行統(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"#記錄單位，也可以是秒、分、小時等

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

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

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

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

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

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

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

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

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

2.3 動態(tài)蜜罐部署機制

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

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

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

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

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

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

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

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

4 實驗及結(jié)果分析

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

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

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

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

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

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

5 結(jié)束語

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