基于蜜場的Openstack安全系統

焦宏宇，何利文，黃 俊

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

0 引 言

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

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

1 網絡攻擊流量重定向

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

1.1 網絡攻擊檢測系統

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

所以，針對子網的網絡攻擊流，不僅包含非業務流量，也包含業務流量。因此網絡攻擊檢測機制包含了對于非業務流量以及業務流量的檢測機制。

1.1.1 非業務訪問監聽模塊

非業務訪問監聽，需要確定哪些是非業務的流量，一般體現為未使用的IP+Port，需要去探測業務子網中哪些地址和端口是未使用的。這兩個參數主要體現在虛擬機是不是運行狀態以及運行狀態的虛擬機上開啟的端口有哪些。

對于虛擬機的狀態，在傳統網絡中或使用Ping進行存活狀態檢測，而在Openstack中所有虛擬機的狀態都會由系統檢測記錄到相應的數據庫中，可以直接拉取子網內虛擬機狀態信息，分析出哪些IP地址是運行中主機使用的。

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

以上兩個機制可以獲取到子網業務地址與端口，根據這些信息建立虛擬機開放服務信息庫。非業務監聽模塊如圖1所示。

圖1 非業務監聽模塊

1.1.2 針對業務訪問的異常檢測模塊

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

1.2 網絡流量重定向系統

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

文中采用重定向器作為中間設備，橋接業務系統租戶命名空間router和蜜場網絡租戶命名空間router，進行重定向以及相關的路由。當一個新的租戶網絡被創建時，Openstack在該租戶網絡所在neutron節點上，創建相應命名空間的router，同時會新建一個redirect橋接到該新建租戶的router和蜜場租戶的router上。redirect會對不同類型的數據包進行相關修改，不同租戶命名空間的router負責相關數據包的路由，具體流程如圖2所示。

圖2 網絡流量重定向系統

1.當外部流量進來之后會到達業務系統租戶(service_tenant)命名空間下的service_router，service_router會將所有流量都轉發到redirect上；

2.redirect根據流量分類進行相關操作，如果是非業務流量直接DNAT發給honeyfarm_router；如果是針對業務系統的攻擊流量會進行DNAT發給honeyfarm_router；如果是業務系統的正常流量，會直接轉發給service_router，不做任何操作；

3.同時redirect會給非正常業務流量打上相應標記[8]，標記該流量是針對Openstack業務系統中的哪臺虛擬機的流量。因為VM的UUID可以唯一標識一臺虛擬機，所以采用UUID來標識該流量，以便針對業務系統的攻擊流量轉發到蜜場網關，蜜場網關可以結合這個標記和自身的相關數據庫進行轉發；

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

5.所有正常的業務流量，直接由service_router路由給業務系統，回包也是由service_router進行路由。

2 蜜場系統

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

2.1 數據控制安全策略

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

##set the connection outbound limits for different protocols

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

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

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

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

OTHERRATE="15"#每記時單位中允許的其他IP新協議連接數

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

通過此規則設置，可以較好地限制對外連接數量。

2.2 數據捕獲機制

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

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

2.3 動態蜜罐部署機制

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

2.3.1 如何探測網絡環境

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

2.3.2 蜜罐系統模板

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

3 基于蜜場的Openstack安全系統設計

將蜜場和Openstack進行有機結合，設置出一個基于虛擬化網絡的新型蜜場系統。其中，網絡攻擊檢測系統中的非業務流量監聽模塊負責監聽非業務流量，異常檢測模塊負責對業務流量進行異常分析；網絡流量重定向系統中的重定向模塊負責對于非業務流量監聽模塊監聽到的流量和異常檢測模塊檢測出的異常流量進行重定向，將流量重定向到蜜場中進行交互，路由模塊負責正常流量和重定向后的攻擊流量的路由；蜜場系統中的動態蜜罐部署機制根據業務系統的虛擬機狀態動態地配置蜜罐以及根據虛擬機的快照進行蜜罐的創建。基于蜜場的Openstack安全系統設計框架如圖3所示。

系統的工作流程如下：網絡攻擊檢測系統進行流量分析，將流量分類；由重定向系統將分類后的流量進行重定向，正常流量路由到業務系統，攻擊流量路由到蜜場；蜜場中的蜜罐負責和外部攻擊進行交互；根據虛擬機狀態和快照，動態地部署蜜罐系統。

4 實驗及結果分析

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

重定向的網絡流正確地到達了蜜場環境。經過對比，在重定向網關的流信息庫中，被重定向的流(非業務流量、異常流量)在蜜場網關的流記錄中都能找到，反之亦然，說明重定向系統是正常工作的。

蜜場中的蜜罐以及honeypot_vm數據記錄均正確。經過對比，在honeypot_vm數據庫的記錄和相關的蜜罐均能正確匹配，并且蜜罐的系統模板與服務系統的快照一樣，說明動態蜜罐部署的機制是正常的。

根據蜜場網關以及蜜罐上監測系統的日志記錄得到一些攻擊數據。圖4展示了24小時內被重定向經過蜜場網關的網絡流量統計圖，圖5是24小時內Openstack虛擬化網絡內的各類型網絡流量統計對比圖。可以看到：有較大比例的網絡流量為非業務訪問被重定向到蜜場；小部分流量為未知源的攻擊流；少部分流量為已知源攻擊流，也被重定向到蜜場；還有高度可疑的蜜罐對Internet訪問流，說明攻擊者對蜜罐攻擊成功。

圖5 24小時內各類型網絡流量統計對比圖

系統潛在問題：時間延遲。當未知攻擊源實施對業務系統的首次攻擊，依次經過異常檢測系統檢測，重定向和蜜場網關分發流量到蜜罐，這些動作均有短時間延遲。

5 結束語

對面向虛擬化環境的蜜場進行了研究，結合Openstack虛擬網絡和Openstack對虛擬機狀態的記錄，設計出了針對虛擬化環境中的重定向實現機制以及動態蜜罐部署機制。實驗結果表明，該新型蜜場系統很好地解決了虛擬化環境的安全問題。下一步的工作將是在蜜場環境中對重定向的攻擊流進行取證分析，這涉及到跟蹤攻擊行為和攻擊取證等一系列技術，在這些技術研究的基礎上，最終將實現虛擬化環境中基于蜜場的網絡主動安全防護系統。