張舟遠 吳承榮 葉家煒

(復旦大學計算機科學技術(shù)學院 上海 200433)(教育部網(wǎng)絡信息安全審計與監(jiān)控工程研究中心 上海 200433)

0 引 言

隨著云計算技術(shù)應用規(guī)模的不斷擴大，對數(shù)據(jù)中心網(wǎng)絡的要求也逐漸提高。由于傳統(tǒng)網(wǎng)絡在拓撲和IP地址空間等方面存在著固有缺陷[1]，為了克服這些缺陷，就產(chǎn)生了網(wǎng)絡虛擬化的基本需求。

網(wǎng)絡虛擬化技術(shù)[2]可以將一個物理網(wǎng)絡劃分為多個完整而又彼此隔離的邏輯網(wǎng)絡，即虛擬網(wǎng)絡。這些虛擬網(wǎng)絡通過同一套物理設(shè)備提供給云平臺中不同的租戶。租戶可以通過自定義的方式向云管理人員申請并獲得具備自己所需要的拓撲結(jié)構(gòu)和IP地址空間的網(wǎng)絡，從而滿足了新型數(shù)據(jù)中心的需求。對于租戶而言，除了上述需求外，虛擬網(wǎng)絡的安全問題也是非常需要關(guān)注的問題。與傳統(tǒng)物理網(wǎng)絡不同，虛擬網(wǎng)絡中的網(wǎng)絡設(shè)備既包括了傳統(tǒng)的物理網(wǎng)絡設(shè)備，又包括了部署在物理服務器上的虛擬網(wǎng)絡設(shè)備。因此虛擬網(wǎng)絡除了需要應對傳統(tǒng)的網(wǎng)絡安全問題以外，還需要有應對新的網(wǎng)絡安全的能力。

當前的主流云平臺，尤其是以O(shè)penStack為代表的開源云平臺，其整體架構(gòu)大多都是松耦合的。在這樣的整體架構(gòu)下，云平臺中的各層次，每個層次中的各模塊都可以獨立進行設(shè)計開發(fā)和維護，帶來極大的便利。但與這種便利相對應的，則是層次和層次之間的依賴性降低，缺乏良好的反饋機制。當?shù)讓映霈F(xiàn)狀況的時候，上層往往難以及時發(fā)現(xiàn)這些問題，從而給整個系統(tǒng)帶來安全隱患。虛擬網(wǎng)絡異常實體問題就是其中的一種安全問題。所謂虛擬網(wǎng)絡異常實體，指的是云平臺中沒有正常地在云管理平臺以認證和發(fā)出請求的方式，而是以直接調(diào)用底層的相關(guān)管理工具或者是API的方式直接添加、刪除或者是改變配置的虛擬網(wǎng)絡端口以及連接在該端口上的虛擬機。

本文對松耦合云環(huán)境下出現(xiàn)虛擬網(wǎng)絡異常實體問題的原因進行了探討，提出一種能夠及時發(fā)現(xiàn)虛擬網(wǎng)絡異常實體的方案，并通過實驗對該方案的有效性加以驗證。

1 相關(guān)工作

網(wǎng)絡安全歷來是一個非常重要的問題，而隨著虛擬網(wǎng)絡的出現(xiàn)和發(fā)展，網(wǎng)絡安全問題也迎來了新的挑戰(zhàn)。一般認為，虛擬網(wǎng)絡由于可以使用更為細粒度的訪問控制，因此安全性要高于傳統(tǒng)網(wǎng)絡。早在2008年和2009年，文獻[3-4]就指出了虛擬環(huán)境下存在通過攻擊Hypervisor獲取整個系統(tǒng)控制權(quán)，進而實施其他攻擊手段的安全問題。盡管當時主要把研究重點放在了虛擬機安全管理上，但隨著網(wǎng)絡虛擬化技術(shù)在云計算中的大量應用，無論是學術(shù)界還是工業(yè)界也都已經(jīng)開始對虛擬網(wǎng)絡的安全問題進行了相關(guān)研究，提出各自的解決方案。

學術(shù)界的主要研究思路是基于開源軟件來提出并開發(fā)相應的解決方案。例如，文獻[6]將處于同一虛擬網(wǎng)絡的虛擬機放置于同一臺物理機中，并將物理網(wǎng)卡配成多IP模式作為地址池，物理網(wǎng)卡與支持網(wǎng)絡虛擬化的物理交換機相連，物理機與物理交換機之間通過部署防火墻來實現(xiàn)網(wǎng)絡安全。文獻[7]則在每臺物理機的Hypervisor上部署了沙盒，并基于安全策略來保證虛擬機的網(wǎng)絡安全。文獻[12]探討了軟件定義網(wǎng)絡(SDN)環(huán)境下的虛擬網(wǎng)絡安全問題。文獻[13]進一步將SDN和NFV(網(wǎng)絡功能虛擬化)集成到OpenStack中，提高其網(wǎng)絡安全性。文獻[14]通過將入侵檢測系統(tǒng)(IDS)和蜜罐網(wǎng)絡集成到云環(huán)境中的方法實現(xiàn)減輕已知和未知的攻擊。此外，還有部分研究將重點放在了虛擬網(wǎng)絡中傳輸數(shù)據(jù)本身的安全上，例如文獻[11]設(shè)計了一種基于加密傳輸?shù)木W(wǎng)絡虛擬化系統(tǒng)來保證網(wǎng)絡中數(shù)據(jù)的安全。

工業(yè)界根據(jù)搭建虛擬網(wǎng)絡的解決方案的不同，有著不同的虛擬網(wǎng)絡安全機制。主要分為兩種：(1) 以VMWare和Cisco(思科)為代表的商用虛擬網(wǎng)絡解決方案；(2) 以O(shè)penStack為代表的開源虛擬網(wǎng)絡解決方案。

商用解決方案包括了以VMware為代表的軟件解決方案和以Cisco為代表的硬件解決方案。其中：VMware提出了一種名為NSX[8]的虛擬網(wǎng)絡解決方案和產(chǎn)品，該產(chǎn)品底層使用了VMware自己開發(fā)的VDS虛擬交換機，上層則和VMware vSphere相結(jié)合，各層次之間耦合度很高，具備非常良好的交互與反饋機制，管理人員可以很好地掌握整個系統(tǒng)的運行情況；Cisco則提出了一套名為ACI[9]的虛擬網(wǎng)絡解決方案，該方案的特點在于其仍將硬件作為虛擬網(wǎng)絡的核心，所有對網(wǎng)絡的操作都是基于硬件設(shè)備能力來實現(xiàn)的，并且采用了新的網(wǎng)絡協(xié)議，使得其相比較于使用樂高積木式組建網(wǎng)絡的軟件方案的功能更為強大。

以O(shè)penStack[5]為代表的開源云平臺則采用了輪詢的方式來檢測虛擬機的網(wǎng)絡連接，一旦發(fā)現(xiàn)虛擬機沒有連接到虛擬網(wǎng)橋上就會通過管理工具在對應的網(wǎng)橋上重新創(chuàng)建虛擬端口。但由于設(shè)計這一機制的目的是為了解決虛擬交換機運行時自身出現(xiàn)故障的問題。因此只能判斷虛擬機所對應的虛擬端口是否存在，既無法保證虛擬端口是否被正確配置，也無法感知不受OpenStack管控的虛擬端口。其各不同層次的組件通常分屬不同的開源產(chǎn)品，雖然每個產(chǎn)品都能夠提供一定程度的安全管理機制，但由于層次間的耦合程度低，尚未出現(xiàn)一個系統(tǒng)的統(tǒng)一安全管理方案，也沒有專門針對虛擬網(wǎng)絡異常實體問題進行過相關(guān)設(shè)計。本文主要針對松耦合架構(gòu)的開源云平臺下存在的虛擬網(wǎng)絡異常實體問題進行研究。

2 虛擬網(wǎng)絡異常實體問題分析和檢測

2.1 松耦合云環(huán)境下的虛擬網(wǎng)絡異常實體問題

圖1以O(shè)penStack為例，展示了松耦合云環(huán)境下虛擬網(wǎng)絡的典型結(jié)構(gòu)。租戶或管理員通過云平臺Portal提供的圖形化界面進行配置，云平臺通過分別調(diào)用Nova和Neutron的相關(guān)API對底層設(shè)備進行操作。

圖1 OpenStack環(huán)境下虛擬網(wǎng)絡典型結(jié)構(gòu)

在這樣的結(jié)構(gòu)下，各層次之間缺乏良好的反饋機制，只有在上層調(diào)用下層提供的服務時，下層才會將執(zhí)行結(jié)果返回上層，下層本身不會主動向上層報告自身的運行情況。這是因為在OpenStack環(huán)境下，云平臺的下層，即資源調(diào)度層和資源層，大量使用了第三方軟件，而這些第三方軟件本身不具備主動對上層反饋的機制。在正常情況下，租戶或管理員經(jīng)過云平臺Portal的認證，自上而下一層一層地對虛擬交換機進行操作，每一層都會將調(diào)用結(jié)果反饋給上層并且在日志中留下記錄，因此這樣的設(shè)計不存在問題。然而在非正常情況下，例如沒有經(jīng)過云平臺的認證而是直接調(diào)用底層虛擬交換機提供的管理工具進行操作時，由于底層設(shè)備不會主動向上層報告，因此上層的云管理平臺無法及時獲取相關(guān)的信息并加以處理，從而導致虛擬網(wǎng)絡異常實體的出現(xiàn)。這些異常實體或者成為垃圾資源無法正常使用，從而影響租戶的正常業(yè)務，或者成為攻擊者的“肉機”或跳板，從而危害整個系統(tǒng)安全。

根據(jù)對虛擬交換機的不同操作，虛擬網(wǎng)絡異常實體可以分為兩類：(1) 不受OpenStack管控的虛擬網(wǎng)絡端口及相關(guān)聯(lián)的虛擬機；(2) 被篡改網(wǎng)絡配置的虛擬網(wǎng)絡端口及相關(guān)聯(lián)的虛擬機。下面分別介紹這兩類虛擬網(wǎng)絡異常實體及其形成原因。

第一類虛擬網(wǎng)絡異常實體，即不受OpenStack管控的虛擬網(wǎng)絡端口及相關(guān)聯(lián)的虛擬機，指的是攻擊者繞過云管理平臺的認證機制，直接調(diào)用Open vSwitch等虛擬交換機提供的管理工具，將不屬于OpenStack管控的虛擬機接入OpenStack網(wǎng)絡中。這些虛擬機無法通過OpenStack進行管理，但是可以作為內(nèi)部網(wǎng)絡成員和所接入網(wǎng)絡內(nèi)的虛擬機正常通信，且不受部署在虛擬網(wǎng)絡邊界的網(wǎng)絡安全系統(tǒng)如防火墻等的影響。同時，由于將虛擬機接入OpenStack網(wǎng)絡的操作沒有經(jīng)過OpenStack的任何一個模塊，因此OpenStack既無法感知這些虛擬機，也無法發(fā)現(xiàn)虛擬機接入網(wǎng)絡的任何操作，于是就會產(chǎn)生第一類虛擬網(wǎng)絡異常實體。

第二類虛擬網(wǎng)絡異常實體，即被篡改網(wǎng)絡配置的虛擬網(wǎng)絡端口及相關(guān)聯(lián)的虛擬機，包括兩種情況：(1) 通過篡改虛擬網(wǎng)絡端口的配置使虛擬機接入其他網(wǎng)絡；(2) 通過篡改虛擬網(wǎng)絡端口的配置將虛擬機從虛擬網(wǎng)絡中刪除。在這兩種情況下，虛擬機的網(wǎng)絡配置都和云管理平臺中所記錄的網(wǎng)絡配置不同，從而形成異常實體。由于OpenStack的架構(gòu)是松耦合的，其主要模塊無法通過底層的主動報告來獲取其運行情況，而只能采用定時輪詢的方式檢測虛擬網(wǎng)絡端口的配置是否正確。如果輪詢的時間間隔設(shè)置得合適，并且能夠?qū)l(fā)現(xiàn)的異常實體及時報告給安全管理人員的話，這也不失為松耦合架構(gòu)下的一種可行的安全措施。然而OpenStack的定時輪詢機制并不是作為一種安全機制而設(shè)計的，而僅僅是為了防止底層的虛擬交換機自身在運行時出現(xiàn)錯誤，從而保證云管理平臺下發(fā)的各種指令能夠正確執(zhí)行。正是出于這一目的，OpenStack在發(fā)現(xiàn)虛擬網(wǎng)絡端口的配置與自身數(shù)據(jù)庫中記錄的不同時，只會根據(jù)自己記錄的信息重新配置虛擬網(wǎng)絡端口，而不會向安全管理人員報告，也不會留下任何日志信息供安全管理人員查看。

為了驗證上文所論述的異常實體的存在和危害，本文繞過OpenStack平臺，直接對虛擬交換機Open vSwitch進行了以下操作：

操作1：使用ovs-vsctl add port命令，將不受OpenStack管控的虛擬機接入OpenStack網(wǎng)絡中。

操作2：使用ovs-vsctl set port命令，改變虛擬網(wǎng)絡端口配置，從而將相關(guān)聯(lián)的虛擬機接入另外的網(wǎng)絡中。

操作3：使用ovs-vsctl del port命令，刪除虛擬網(wǎng)絡端口，從而將相關(guān)聯(lián)的虛擬機從網(wǎng)絡中刪除。

每次操作前都先將OpenStack恢復原狀，通過這些操作并分別查詢Dashboard界面、Neutron日志以及虛擬機本身情況，結(jié)果如表1所示。

表1 異常實體問題驗證結(jié)果

由此可見，OpenStack中出現(xiàn)的兩類虛擬網(wǎng)絡異常實體既不能通過Dashboard界面進行監(jiān)控，也不能通過查詢Neutron日志進行事后排查，這一點必須引起安全管理人員的重視。

2.2 虛擬網(wǎng)絡異常實體檢測方案

2.2.1 基本原理

上文曾經(jīng)提到，定時輪詢方案可以作為一種可行的虛擬網(wǎng)絡異常實體的檢測方案，而OpenStack現(xiàn)有的定時輪詢方案還存在著一些問題。本文基于OpenStack的定時輪詢思想，并作出一些改進，在不對云平臺本身進行改動的前提下提出一種針對虛擬網(wǎng)絡異常實體的檢測方案。本方案的基本原理是對Open vSwitch和OpenStack中分別記錄的虛擬網(wǎng)絡信息進行比對，如果發(fā)現(xiàn)記錄不一致，則存在虛擬網(wǎng)絡異常實體。其中：Open vSwitch中記錄的是虛擬機的實際網(wǎng)絡配置信息，而OpenStack中記錄的則是虛擬機應當具備的網(wǎng)絡配置信息。本方案的工作流程如圖2所示。

圖2 虛擬網(wǎng)絡異常實體檢測流程

根據(jù)本方案編寫的虛擬網(wǎng)絡異常實體檢測程序利用Linux提供的cron服務定時啟動，并且按照以下步驟工作：

(1) 參數(shù)收集 首先需要收集兩部分重要參數(shù)作為輸入。一部分是Open vSwitch的所有連有虛擬機的端口以及這些端口上所連接的虛擬機信息。另一部分是OpenStack上所存儲的虛擬機相應的信息以及這些虛擬機的相應網(wǎng)絡信息。

(2) 異常檢測 用步驟1中所獲取的兩部分虛擬機信息以及虛擬網(wǎng)絡端口信息進行比對，從而發(fā)現(xiàn)網(wǎng)絡中不受OpenStack管控的第一類虛擬網(wǎng)絡異常實體以及OpenStack中實際網(wǎng)絡配置和云管理平臺中記錄的配置不同的第二類虛擬網(wǎng)絡異常實體。

(3) 安全告警 如果在異常檢測這一步驟中發(fā)現(xiàn)了虛擬網(wǎng)絡異常實體，那么會在數(shù)據(jù)庫中生成一條告警記錄。這條告警記錄的信息會及時通過有效的反饋機制告知安全管理人員。

2.2.2 具體實現(xiàn)

根據(jù)上文的工作流程具體描述虛擬網(wǎng)絡異常實體的檢測實現(xiàn)細節(jié)。

(1) 參數(shù)收集的實現(xiàn) 在檢測開始前，需要分別對Open vSwitch上的信息集合(記為Ov)和OpenStack上的信息集合(記為Op)進行信息收集。其中，Ov中的每一項都對應了Open vSwitch中的一個連有虛擬機的虛擬網(wǎng)絡端口信息，對于每一個端口可以收集到的信息包括端口名、端口UUID、端口VLAN tag、對應VxLAN的標識VNI、虛擬機UUID、虛擬機MAC地址等。這部分信息中，VNI信息需要從Open vSwitch的流規(guī)則中提取，其余所有信息都可以從Open vSwitch的數(shù)據(jù)庫，即ovsdb中獲取。Open vSwitch分別提供了ovs-ofctl和ovsdb-client兩個管理工具來獲取這一部分信息。這里需要特別指出的是，虛擬機的UUID信息和MAC地址信息有可能因為攻擊而無法從ovsdb中提取，這時需要調(diào)用Libvirt API來獲取這些信息。

而Ov中的每一項對應OpenStack中的一臺虛擬機及其網(wǎng)絡的配置信息，包括虛擬機UUID、虛擬機MAC地址、虛擬機IP地址、VxLAN標識VNI和虛擬網(wǎng)絡UUID等。這一部分信息可以分別從Neutron數(shù)據(jù)庫中的ports表、ml2_network表和ipallocations表中提取。為此，可以建立一張視圖匯總這方面的信息，如圖3所示，圖中的device_id、mac_address、ip_address、segmentation_id和network_id字段分別對應了上述信息。

(2) 異常檢測的實現(xiàn) 在完成參數(shù)收集的工作后，首先開始遍歷Ov中的每一項，檢查Ov中的每一項(記為Ovi)所記錄的虛擬機UUID是否都包含在Op中，如果不在Op中，則可以判定系統(tǒng)中有存在第一類虛擬網(wǎng)絡異常實體；如果虛擬機UUID包含在Op中，那么繼續(xù)比對這臺虛擬機在Ov和Op的記錄中是否在同一網(wǎng)絡中；如果不在同一網(wǎng)絡中，那么可以判定系統(tǒng)中存在第二類虛擬網(wǎng)絡異常實體且屬于第一種情況；在完成對Ov的遍歷后，繼續(xù)遍歷Op中的每一項(記為Opi)，檢查是否每臺虛擬機都在Ov中有記錄，如果沒有，那么可以判定系統(tǒng)中存在第二類虛擬網(wǎng)絡異常實體且屬于第二種情況。這一過程可以用圖4所示的流程圖來表示。

(3) 安全告警的實現(xiàn) 虛擬網(wǎng)絡異常實體的告警記錄包含的內(nèi)容如表2所示。告警信息應當及時通知安全管理人員處理，本文使用網(wǎng)頁展示的方式進行通知。實際應用中也可以使用電子郵件、短信通知等其他有效的方式。

表2 異常實體數(shù)據(jù)庫表格式

續(xù)表2

3 實驗驗證

3.1 實驗環(huán)境

本文的實驗環(huán)境部署在3臺硬件配置相同的物理服務器上，詳細配置見表3。我們使用這3臺服務器搭建了一套小型的OpenStack環(huán)境。物理服務器操作系統(tǒng)為CentOS 7，其中一臺作為控制節(jié)點，安裝了MariaDB數(shù)據(jù)庫，其余兩臺作為計算節(jié)點，并使用Open vSwitch作為虛擬交換機來搭建虛擬網(wǎng)絡。

表3 物理服務器配置

我們用Python語言編寫了用于檢測虛擬網(wǎng)絡異常實體的腳本程序，并如圖5所示部署在計算節(jié)點的操作系統(tǒng)上。然后開啟Linux提供的cron服務，使用crontab命令配置任務，將該腳本程序設(shè)置為每分鐘執(zhí)行一次。控制節(jié)點上部署了Java運行環(huán)境，使用Java Web技術(shù)開發(fā)安全告警事件的展示頁面，用于展示檢測程序?qū)懭霐?shù)據(jù)庫的安全告警事件。

圖5 異常實體檢測程序物理部署

3.2 實驗設(shè)計和結(jié)果

為了驗證本文提出的虛擬網(wǎng)絡異常實體檢測方案的有效性，本文通過模擬產(chǎn)生虛擬網(wǎng)絡異常實體進行測試實驗。通過比較OpenStack的Dashboard頁面和虛擬網(wǎng)絡異常實體展示頁面中是否能夠?qū)⑦@些模擬產(chǎn)生的異常實體正確顯示來進行功能驗證。其中：對于OpenStack，主要查看虛擬網(wǎng)絡拓撲信息和相關(guān)操作日志；對于展示頁面，主要查看是否正確列出了告警事件。在開始實驗之前，首先查看原始的OpenStack網(wǎng)絡拓撲信息，如圖6所示。

圖6 OpenStack原始虛擬網(wǎng)絡拓撲

本次模擬實驗將利用Open vSwitch提供的管理工具ovs-vsctl命令，繞過OpenStack的認證和請求機制，直接把圖6中的一臺名為demo的虛擬機以篡改虛擬網(wǎng)絡端口配置的形式從admin-net2網(wǎng)絡移動至admin-net網(wǎng)絡。

首先登錄demo虛擬機所在的計算節(jié)點Compute1，并查看確認Open vSwitch中現(xiàn)有虛擬網(wǎng)絡的配置情況，如圖7所示。通過OpenStack的Nova模塊可以查出，虛擬機demo連接在Open vSwitch上的虛擬端口是qvo44f28f88-20。通過Neutron模塊和ovs-db可以查出，admin-net對應在Compute1上的Open vSwitch虛擬網(wǎng)絡VLAN tag是1，admin-net2對應的VLAN tag是3。于是使用ovs-vsctl set port qvo44f28f88-20 tag=1命令就實現(xiàn)了把虛擬機demo從原本所在的admin-net2網(wǎng)絡篡改到了admin-net網(wǎng)絡，從而成功模擬出來第二類虛擬網(wǎng)絡異常實體。成功模擬攻擊后，分別查看OpenStack的Dashboard界面上的網(wǎng)絡拓撲以及虛擬網(wǎng)絡異常實體展示頁面，結(jié)果是OpenStack上顯示的網(wǎng)絡拓撲與改變網(wǎng)絡以前完全一致，并未發(fā)現(xiàn)系統(tǒng)中出現(xiàn)了異常實體。而在異常實體展示頁面上，則可以看到詳細的告警信息，告知管理人員虛擬網(wǎng)絡異常實體所在的主機、異常實體的類型、被檢測出的時間、相關(guān)聯(lián)的Open vSwitch虛擬端口名稱、虛擬機的UUID、MAC地址以及攻擊前后端VLAN tag等，并提示安全管理人員進行處理。

圖7 Open vSwitch端口信息

實驗表明，本文設(shè)計的虛擬網(wǎng)絡異常實體檢測方案確有實效，其他類型的虛擬網(wǎng)絡異常實體可以通過類似的實驗加以證明。

4 結(jié) 語

本文探討了當前以O(shè)penStack為代表的松耦合架構(gòu)的云平臺中存在的虛擬網(wǎng)絡異常實體問題，并提出了一種檢測方案。該方案可以及時有效地發(fā)現(xiàn)系統(tǒng)中存在的虛擬網(wǎng)絡異常實體，并通過實驗驗證了這一點。在接下來的工作中，我們準備結(jié)合操作日志，引入日志關(guān)聯(lián)分析的有關(guān)技術(shù)來還原這些異常實體產(chǎn)生的操作現(xiàn)場，使得安全管理人員不僅能夠及時發(fā)現(xiàn)問題，還能查明問題產(chǎn)生的原因，從而能夠更加全面地掌握系統(tǒng)的運行情況，最終可以更加高效地處理這些安全問題。