云環(huán)境下SDN 的流量異常檢測性能分析

馬 超，程 力，孔玲玲

(1.中國科學(xué)院新疆理化技術(shù)研究所，新疆 烏魯木齊 830011;2.中國科學(xué)院大學(xué)，北京 100049;3.核工業(yè)理化工程研究院，天津 300180)

0 引言

大規(guī)模的用戶與虛擬化部署催生了復(fù)雜的云計算網(wǎng)絡(luò)，尤其是數(shù)據(jù)中心，需要更加靈活敏捷的網(wǎng)絡(luò)響應(yīng)和面向工作負(fù)載的網(wǎng)絡(luò)資源調(diào)度，傳統(tǒng)的分布式網(wǎng)絡(luò)架構(gòu)已經(jīng)很難應(yīng)對這些挑戰(zhàn)。一個解決方案是在云中引入軟件定義網(wǎng)絡(luò)(Software-Defined Network)。SDN 是開放網(wǎng)絡(luò)基金會(Open Networking Foundation)提出的新型網(wǎng)絡(luò)構(gòu)架，將控制層和數(shù)據(jù)層分離是SDN 的基本思想，這使得網(wǎng)絡(luò)設(shè)備成為簡單的數(shù)據(jù)發(fā)送設(shè)備，而控制邏輯則被部署到邏輯集中控制器中進(jìn)行統(tǒng)一管理。通過對集中控制器進(jìn)行編程不僅可以方便地修改網(wǎng)絡(luò)策略和配置，還能及時地對網(wǎng)絡(luò)狀態(tài)做出響應(yīng)，為控制網(wǎng)絡(luò)提供更大的靈活性［1］。

正因為有了虛擬網(wǎng)絡(luò)，云才可以將計算/存儲等資源抽象、封裝成便于調(diào)度管理的邏輯單元，因此，虛擬網(wǎng)絡(luò)的安全對整個云服務(wù)有著至關(guān)重要的影響。傳統(tǒng)的來自外部的網(wǎng)絡(luò)攻擊，如拒絕服務(wù)攻擊(DoS)和端口掃描等依然是云計算網(wǎng)絡(luò)的重要威脅［2-3］。但在云計算規(guī)模越來越大的形勢下，虛擬機(jī)很可能會被攻擊者利用從內(nèi)網(wǎng)發(fā)起網(wǎng)絡(luò)攻擊，攻擊目標(biāo)可以是云中心內(nèi)的其他主機(jī)，也可以是Internet 上的主機(jī)。這種流量通常只經(jīng)過本地交換機(jī)或Hypervisors 而不會通過安全設(shè)備［4］。因此，能夠快速、準(zhǔn)確地檢測到內(nèi)部網(wǎng)絡(luò)流量的異常并做出合理響應(yīng)，是保證網(wǎng)絡(luò)服務(wù)正常運(yùn)行的重要前提。云計算經(jīng)過多年的發(fā)展研究，在網(wǎng)絡(luò)異常流量檢測方面已經(jīng)有了一定的積累［5］，SDN 在這方面的研究雖然才剛剛起步，但其自身的優(yōu)勢必將會為網(wǎng)絡(luò)安全的實現(xiàn)提供更有力的支撐。

云計算與SDN 相融合是一個重要發(fā)展趨勢。到目前為止，已經(jīng)有一些工作專注于在SDN 上構(gòu)建流量檢測應(yīng)用［6-9］，但云環(huán)境下的SDN 在檢測內(nèi)部網(wǎng)絡(luò)攻擊時的表現(xiàn)仍不得而知。在云環(huán)境中構(gòu)建SDN 并部署流量異常檢測，將其性能、效率與標(biāo)準(zhǔn)云環(huán)境進(jìn)行比較，能夠使人們對SDN 的特點和優(yōu)勢有進(jìn)一步的認(rèn)識。

1 相關(guān)工作

1.1 SDN

為了滿足高層次網(wǎng)絡(luò)策略的需求，網(wǎng)絡(luò)管理員必須使用廠商規(guī)定的、低級的命令分別配置每一個獨立的網(wǎng)絡(luò)設(shè)備，比如路由和交換機(jī)。除此之外，配置的復(fù)雜性、網(wǎng)絡(luò)的動態(tài)性、較少的網(wǎng)絡(luò)事件響應(yīng)機(jī)制都增加了管理員工作的復(fù)雜性。

2008 年，軟件定義網(wǎng)絡(luò)(Software-Defined Network，SDN)概念被提出。SDN 的實現(xiàn)基于OpenFlow規(guī)范，由基礎(chǔ)設(shè)施層、控制層和應(yīng)用層組成［10］。其中基礎(chǔ)設(shè)施層主要由網(wǎng)絡(luò)設(shè)備即支持OpenFlow 協(xié)議的SDN 交換機(jī)組成，它們是保留了傳統(tǒng)網(wǎng)絡(luò)設(shè)備數(shù)據(jù)面能力的硬件，負(fù)責(zé)基于流表的數(shù)據(jù)處理、轉(zhuǎn)發(fā)和狀態(tài)收集。控制層主要包含OpenFlow 控制器及網(wǎng)絡(luò)操作系統(tǒng)，負(fù)責(zé)處理數(shù)據(jù)平面資源的編排、維護(hù)網(wǎng)絡(luò)拓?fù)?、狀態(tài)信息等;控制器是一個平臺，該平臺向下可以直接與使用OpenFlow 協(xié)議的交換機(jī)(以下簡稱SDN交換機(jī))進(jìn)行會話;向上，為應(yīng)用層軟件提供開放接口，用于應(yīng)用程序檢測網(wǎng)絡(luò)狀態(tài)、下發(fā)控制策略。位于頂層的應(yīng)用層由眾多應(yīng)用軟件構(gòu)成，這些軟件能夠根據(jù)控制器提供的網(wǎng)絡(luò)信息執(zhí)行特定控制算法，并將結(jié)果通過控制器轉(zhuǎn)化為流量控制命令，下發(fā)到基礎(chǔ)設(shè)施層的實際設(shè)備中。

SDN 的特殊性吸引了越來越多的學(xué)者進(jìn)行研究。Gelberger［10］分析比較了ProGFE、OpenFlow 這2種SDN 構(gòu)架與傳統(tǒng)網(wǎng)絡(luò)的性能表現(xiàn)，證明了SDN 的靈活性是以犧牲一部分性能為前提的。Tsugawa 等人［11］討論了SDN 對云計算的影響及其面臨的眾多新的安全問題，并認(rèn)為SDN 對網(wǎng)絡(luò)的彈性控制會促進(jìn)產(chǎn)生新的思路來應(yīng)對網(wǎng)絡(luò)威脅。

1.2 OpenFlow

OpenFlow 是一種符合SDN 定義的通用標(biāo)準(zhǔn)。OpenFlow 交換機(jī)具有高度可編程的特征，利用軟件根據(jù)需要計算出最優(yōu)流量路由決定。對于OpenFlow交換機(jī)，數(shù)據(jù)層是可編程的，它包含了一個流表(Flow Table)，流表中有流量規(guī)則集，定義了數(shù)據(jù)層應(yīng)當(dāng)如何處理動態(tài)網(wǎng)絡(luò)流量［12］。流量規(guī)則提供了基本的指令用來管理如何發(fā)送、修改和丟棄經(jīng)過交換機(jī)的包。交換機(jī)的控制層只需要支持OpenFlow 協(xié)議，通過協(xié)議交換機(jī)與OpenFlow 網(wǎng)絡(luò)外的控制器通信，以便發(fā)送統(tǒng)計信息、新流量請求和更新規(guī)則集等。

OpenFlow 控制器在所有交換機(jī)之上，協(xié)調(diào)整個網(wǎng)絡(luò)的流量規(guī)則，為交換機(jī)提供必要的流量規(guī)則升級。在條件改變時，OpenFlow 控制器對交換機(jī)進(jìn)行重編程。同時，控制器還提供開放的API，使管理員和研究人員開發(fā)自己的控制軟件和新的重要功能［13］，進(jìn)行邏輯部署以制定新流量規(guī)則。常用的控制器包括OpenDaylight、NOX 等，其中Floodlight 和Ryu 控制器提供了OpenStack 插件，利用Neutron API在OpenStack 中實現(xiàn)獨立的網(wǎng)絡(luò)控制。

1.3 相關(guān)攻擊

1.3.1 DoS

DoS 旨在對目標(biāo)主機(jī)發(fā)起攻擊，使其網(wǎng)絡(luò)資源或系統(tǒng)資源耗盡，從而無法向合法用戶提供正常服務(wù)。DoS 可以分為2 種類型［14］，第1 種攻擊通過向目標(biāo)系統(tǒng)發(fā)送精心準(zhǔn)備的數(shù)據(jù)包而使系統(tǒng)崩潰，比如Ping of Death 和TearDrop，前者通過發(fā)送超過IP 協(xié)定能容忍的分組數(shù)使對方系統(tǒng)宕機(jī)，后者則在每個數(shù)據(jù)要傳送前對分組切割的位移信息進(jìn)行捏造，造成重組時發(fā)生錯誤。第2 種攻擊通過產(chǎn)生大量無用流量占據(jù)正常服務(wù)所需資源，其中最常見的是Flood 攻擊，又分為2 種攻擊方式［15］:直接攻擊通過直接向目標(biāo)發(fā)送大量SYN 請求，使對方系統(tǒng)中的處理器和內(nèi)存資源耗盡，無法再有效地處理合法請求;反射攻擊則通過大量中間節(jié)點向目標(biāo)發(fā)送SYN-ACK 或RST 數(shù)據(jù)包，使目標(biāo)服務(wù)中斷。

在網(wǎng)絡(luò)安全中，拒絕服務(wù)攻擊以其危害巨大，難以防御等特點成為惡意攻擊的常用手段，Darwish 等人［16］集中討論了幾種傳統(tǒng)DDoS(Distributed Denial of Service)攻擊對云計算的威脅，并指出這些攻擊不僅可以從外部發(fā)起，還可以基于云環(huán)境在內(nèi)部進(jìn)行，單一的防御策略已經(jīng)難以長期有效地阻斷攻擊。此外，云計算網(wǎng)絡(luò)構(gòu)架的大規(guī)模、復(fù)雜性也給攻擊者帶來新的攻擊思路，Liu 等人［17］提出了一種在云內(nèi)部發(fā)起的新型DoS 攻擊，該攻擊通過不完全阻塞云網(wǎng)絡(luò)中的上傳鏈路達(dá)到大幅降低服務(wù)性能的目標(biāo)，證實了在云中進(jìn)行“小規(guī)模DoS 攻擊”的可行性。

1.3.2 端口掃描

端口掃描首先會向目標(biāo)主機(jī)的特定端口發(fā)送消息，通過收到的應(yīng)答分析出端口的狀態(tài)，甚至確定其操作系統(tǒng)和漏洞信息。端口掃描通常分為秘密掃描、FTP 反彈攻擊、套接字端口探測、TCP 掃描和UDP 掃描等［18］。

攻擊者通過對主機(jī)進(jìn)行端口分析而收集主機(jī)的相關(guān)信息，這通常是網(wǎng)絡(luò)攻擊的第1 個階段，也是蠕蟲傳播的基本手段之一。因此，非常有必要檢測從云內(nèi)部發(fā)起的端口掃描［19］。同樣，攻擊者可以利用這些主機(jī)發(fā)動分布式端口掃描，實驗證明［20］，利用至少32 臺主機(jī)進(jìn)行分布式的端口掃描可以避免傳統(tǒng)入侵檢測系統(tǒng)的檢測。

2 研究方法

2.1 流量異常檢測

異常流量，就是不屬于正常網(wǎng)絡(luò)服務(wù)范圍內(nèi)的流量，包括網(wǎng)絡(luò)攻擊流量、網(wǎng)絡(luò)病毒流量、非法服務(wù)流量等。網(wǎng)絡(luò)異常流量通常會對網(wǎng)絡(luò)服務(wù)的提供和使用造成影響，甚至導(dǎo)致服務(wù)中斷，產(chǎn)生不可挽回的損失。部署合適的異常流量檢測系統(tǒng)不僅是網(wǎng)絡(luò)正常運(yùn)營的保證，也是網(wǎng)絡(luò)日常管理維護(hù)的內(nèi)容之一。

正常情況下，網(wǎng)絡(luò)連接通常會局限于某些固定的主機(jī)集合，而且這些伴有明確目的的連接(比如瀏覽網(wǎng)頁)成功率很高。但SYN Flood 和端口掃描的行為卻不同，它們會不斷嘗試與主機(jī)建立新連接，從而惡意消耗目標(biāo)主機(jī)資源或探索開放的端口，這些特殊連接的直接表現(xiàn)就是具有很高的失敗率。針對這個特點，本文選擇的2 種流量異常檢測算法只對新建立的網(wǎng)絡(luò)連接請求進(jìn)行檢查，算法檢測原理如下。

2.1.1 Threshold Random Walk with Credit Based Rate Limiting

TRW-CB［21］分為2 部分:

1)TRW-CB 建立一個“主機(jī)連接歷史”集，用以記錄一定數(shù)量的曾經(jīng)連接過的目的主機(jī);同時建立一個“首次連接”隊列，記錄這些“歷史連接主機(jī)”的信息，包括地址、連接狀態(tài)等。當(dāng)本地主機(jī)要發(fā)出一個連接請求時，先根據(jù)“主機(jī)連接歷史”集判斷該目的主機(jī)是否被連接過，如果沒有，則在“主機(jī)連接歷史”集中添加該主機(jī)，并在“首次連接”隊列中追加該主機(jī)地址，連接狀態(tài)為“Pending”。如果目的主機(jī)允許連接，則更改狀態(tài)為“Success”，如果收到拒絕連接的響應(yīng)(TCP RST)或無響應(yīng)(超時)，則更改狀態(tài)為“Fail”。每次連接狀態(tài)的更改(“Success”或“Fail”)都會發(fā)出一次計算，計算的值將與閾值進(jìn)行比較，判斷本地主機(jī)是否正常。

2)由于第1 部分的計算需要一定時間，為了防止這段時間內(nèi)產(chǎn)生大量連接請求，算法引入了信用值。每臺主機(jī)有1 個初始信用值，每產(chǎn)生1 個新的連接請求，信用值-1，當(dāng)新連接成功時，信用值+2;一定時間周期內(nèi)，超過初始值的信用值會產(chǎn)生折損，防止信用值無限膨脹;同時，對于信用值消耗完的主機(jī)，每隔一定時間會獲得一個信用值，避免了主機(jī)“徹底斷網(wǎng)”引發(fā)的不良后果。

2.1.2 Rate-Limiting

Rate-Limiting［22］通過維持一個“工作集”，限制主機(jī)建立的連接數(shù)目。當(dāng)主機(jī)發(fā)出一個連接請求時，首先會檢查這個連接是否在“工作集”中，如果“工作集”沒有滿載或存在此連接記錄，則可以正常進(jìn)行連接;否則，此連接請求會被轉(zhuǎn)存到“延遲隊列”中，每隔一段時間，“延遲隊列”中的連接請求會被取出并發(fā)送，同時更新“工作集”。當(dāng)“延遲隊列”也達(dá)到一定長度，Rate-Limiting 將不再接受任何連接請求。

本文對這種算法進(jìn)行了部分修改，使其能夠針對Flood 攻擊進(jìn)行檢測。修改如下:

1)主機(jī)發(fā)出的連接請求，如果目的地址不在“工作集”中，就直接轉(zhuǎn)存至“延遲隊列”。

2)工作集的每個目的地址都帶有一個狀態(tài)。新添加的地址狀態(tài)為“Pending”;如果目的地址對連接請求有積極反饋，則將狀態(tài)改為“Ready”;如果主機(jī)對反饋進(jìn)行了確認(rèn)，則狀態(tài)更新為“Success”。

3)主機(jī)可以與工作集中狀態(tài)為“Success”的目的地址通信。

4)連接建立后的ACK 數(shù)據(jù)包不會被檢測過濾。

2.2 數(shù)據(jù)集

為了實現(xiàn)對TCP 端口掃描和SYN Flood 攻擊的模擬，本文使用文獻(xiàn)［23］中實驗收集的流量集。該流量集包含普通網(wǎng)絡(luò)流量和攻擊網(wǎng)絡(luò)流量，其中，普通流量數(shù)據(jù)分別在家庭網(wǎng)絡(luò)、SOHO 網(wǎng)絡(luò)和ISP 網(wǎng)絡(luò)等3 個規(guī)模的節(jié)點上收集，攻擊流量則包含若干種攻擊在不同攻擊速率下的數(shù)據(jù)包。

考慮到云環(huán)境下的流量規(guī)模和實驗條件限制，本文選取SOHO 網(wǎng)絡(luò)流量集，包含34 臺活動主機(jī)，在2小時8 分內(nèi)產(chǎn)生6 369 925 個數(shù)據(jù)包，共418 MB;攻擊流量部分，包含TCP 端口掃描和SYN Flood 攻擊分別在低速率(0.1、1、10 pkts/sec)和高速率(100、1 000 pkts/sec)下的流量集，詳細(xì)信息見表1。利用Wireshark 將攻擊流量隨機(jī)地融合到普通流量中，也就意味著34 臺主機(jī)中有8 臺主機(jī)受到了感染而產(chǎn)生攻擊行為。

表1 攻擊流量數(shù)據(jù)

3 實驗內(nèi)容

3.1 實驗環(huán)境

所有實驗內(nèi)容均在2 臺運(yùn)行Ubuntu 13.10 系統(tǒng)的服務(wù)器上進(jìn)行，每臺服務(wù)器均配有雙Intel(R)Xeon(R)E5620 處理器和16 GB 內(nèi)存。利用這些服務(wù)器搭建完成多節(jié)點OpenStack Havana 環(huán)境，包括控制節(jié)點和計算節(jié)點。SDN 的實現(xiàn)依賴于控制器和支持OpenFlow 協(xié)議的交換機(jī)，因此，在網(wǎng)絡(luò)節(jié)點上部署控制器Ryu 3.7，并利用Neutron-Plugin-ryu 等插件實現(xiàn)控制器與OpenStack 的關(guān)聯(lián);在控制節(jié)點和計算節(jié)點上，部署了OpenvSwitch，通過OpenvSwitch 可以方便地實現(xiàn)網(wǎng)絡(luò)虛擬化，包括對OpenFlow 協(xié)議的支持。

2 種異常檢測算法用Python 實現(xiàn)并分別部署在Ryu 控制器和OpenStack 環(huán)境上。同時，實驗中專門建立一臺虛擬主機(jī)，通過TCPReplay 工具重放普通流量集和經(jīng)過整合過的攻擊流量集，實現(xiàn)對整個網(wǎng)絡(luò)流量的模擬。在OpenStack 環(huán)境下，還需要在網(wǎng)橋上增加相應(yīng)的規(guī)則，將流量集的數(shù)據(jù)包重定向至虛擬安全設(shè)備，這意味著整個中心所有VM 的改動(增加、刪除、遷移)都需要重新配置相應(yīng)的規(guī)則。而SDN 下則由交換機(jī)和控制器智能處理流量。

3.1.1 SDN 環(huán)境

在SDN 中，如果一個數(shù)據(jù)包不與任何流規(guī)則匹配，則該數(shù)據(jù)包會被轉(zhuǎn)發(fā)至控制器，控制器按照策略對該數(shù)據(jù)包進(jìn)行處理。根據(jù)本文所選2 種算法和SDN 的特點，Ryu 控制器沒有必要檢查主機(jī)發(fā)送的每一個數(shù)據(jù)包，只需要處理新的TCP 連接建立時的幾個相關(guān)數(shù)據(jù)報。主要流程如下:

1)當(dāng)源主機(jī)產(chǎn)生一個新連接請求時(SYN)，由于交換機(jī)上沒有匹配規(guī)則，該請求會被轉(zhuǎn)發(fā)至控制器，控制器正常地發(fā)送該請求。

2)如果目的主機(jī)對連接做出積極響應(yīng)(SYN +ACK)，該數(shù)據(jù)報同樣會被轉(zhuǎn)發(fā)給控制器，由控制器轉(zhuǎn)發(fā)給源主機(jī);控制器上的異常檢測算法判斷該連接正常，會在交換機(jī)上設(shè)置2 條流規(guī)則，允許目的主機(jī)和源主機(jī)間進(jìn)行通信，之后2 臺主機(jī)間產(chǎn)生的數(shù)據(jù)包將依據(jù)規(guī)則由交換機(jī)直接進(jìn)行轉(zhuǎn)發(fā)，無需再經(jīng)過控制器。

3)如果目的主機(jī)沒有響應(yīng)(TIMEOUT)或重置連接(RST)，控制器不會在交換機(jī)上設(shè)置任何新的規(guī)則，此后2 臺主機(jī)間嘗試通信的行為仍然被視為建立新連接。

4)如果源主機(jī)被異常檢測算法判斷為具有惡意行為，控制器撤銷交換機(jī)上所有與源主機(jī)相關(guān)的流規(guī)則，并設(shè)置新的流規(guī)則，放棄所有與源主機(jī)相關(guān)的數(shù)據(jù)包。

3.1.2 標(biāo)準(zhǔn)OpenStack 環(huán)境

在標(biāo)準(zhǔn)OpenStack 環(huán)境里，建立一臺特殊的主機(jī)來模擬安全設(shè)備，稱為檢測主機(jī)。檢測主機(jī)配有4 核心和8 GB 內(nèi)存，負(fù)責(zé)處理所有其他實例產(chǎn)生的網(wǎng)絡(luò)流量，檢測會覆蓋到每一個數(shù)據(jù)包。如果相關(guān)主機(jī)被異常檢測算法判斷為惡意主機(jī)，則放棄所有相關(guān)數(shù)據(jù)包，否則轉(zhuǎn)發(fā)數(shù)據(jù)包至交換機(jī)，由交換機(jī)正常處理。

3.2 實驗?zāi)康?/h3>

對采集到的數(shù)據(jù)進(jìn)行以下幾個方面的分析:

1)精確度，即檢測準(zhǔn)確率和誤報率。ROC(Receiver Operating Characteristic)曲線可以準(zhǔn)確刻畫入侵檢測系統(tǒng)的準(zhǔn)確率與誤報率之間的變化關(guān)系，被廣泛用于輸入不確定系統(tǒng)的評估［24］。因此，在SDN 和OpenStack 環(huán)境下，分別做出2 種算法對不同攻擊、速率的ROC 曲線，可以直觀反映出檢測算法的精確度。

2)效率。在SDN 環(huán)境下，分析通過控制器的數(shù)據(jù)包占全部數(shù)量的比率、控制器上數(shù)據(jù)包的平均通過率、交換機(jī)流表中流的數(shù)量和交換機(jī)流表中流的峰值數(shù)量。

3)CPU 和物理內(nèi)存使用情況，比較分析2 種環(huán)境下的資源使用差異。

4 實驗分析

4.1 精確度

在SDN 和OpenStack 環(huán)境下，TRW_CB 和Rate-Limiting 這2 種算法都對端口掃描攻擊進(jìn)行了檢測。從圖1 的ROC 曲線可以看出，SDN 下的TRW_CB 在檢測端口掃描攻擊時具有更低的誤報率，但準(zhǔn)確度不及OpenStack 環(huán)境下的檢測。Rate-Limiting 對高速端口掃描攻擊的檢測有更高的精確度，SDN 下更是達(dá)到了100%的準(zhǔn)確率和零誤報，見圖2。

圖1 TRW_CB 對端口掃描的檢測

圖2 Rate-Limiting 對端口掃描的檢測

對TCP Flood 的檢測只涉及Rate-Limiting 算法。由圖3 可以看出，該算法在SDN 下對高速攻擊較敏感，而在OpenStack 下則對低速攻擊更敏感。

圖3 Rate-Limiting 對Flood 的檢測

總的來說，流量異常檢測算法在SDN 和OpenStack這2 種環(huán)境下的表現(xiàn)各有優(yōu)劣，沒有太大的差距。

4.2 效率

表2 列出了SDN 特有的一些統(tǒng)計信息。整個檢測過程中，通過控制器的數(shù)據(jù)包占到全部流量16%左右，即每秒約有130 個數(shù)據(jù)包通過控制器，相比OpenStack 傳統(tǒng)網(wǎng)絡(luò)下所有的流量都需要流經(jīng)檢測主機(jī)的方式更為高效。

表2 SDN 下2 種算法處理的效率

流量異常檢測是面向連接的，控制器針對每臺正常主機(jī)的已有連接和所有感染主機(jī)都在相應(yīng)交換機(jī)上自動部署了流規(guī)則，平均會下發(fā)900 條規(guī)則，最大峰值達(dá)到1 200 條。這些規(guī)則都由控制器智能下發(fā)，無需人工干預(yù)，減少了人工成本。而在傳統(tǒng)的網(wǎng)絡(luò)下，則需要對每臺虛擬機(jī)相關(guān)的交換機(jī)進(jìn)行部署，才能將流量導(dǎo)入檢測主機(jī)，是一項龐大的任務(wù)。

4.3 CPU 和內(nèi)存

SDN 控制器和OpenStack 下檢測主機(jī)的CPU 使用情況見表3。雖然控制器處理的數(shù)據(jù)量只有全部數(shù)據(jù)的16%左右，但消耗的CPU 時間片卻稍微高出檢測主機(jī)，除去對網(wǎng)絡(luò)流量的分析外，控制器還要對OpenFlow 協(xié)議進(jìn)行解析、對交換機(jī)進(jìn)行定期查詢獲取統(tǒng)計和狀態(tài)信息等，這些是控制器占用CPU 時間片較高的重要原因。

物理內(nèi)存的使用上，控制器有絕對優(yōu)勢，平均使用了34 MB 物理內(nèi)存，約為檢測主機(jī)的8%左右，后者平均占用415 MB 物理內(nèi)存。

表3 檢測不同速率攻擊所需CPU 時間片

5 結(jié)束語

本文在OpenStack 下構(gòu)建了SDN，并對其在流量異常檢測方面的性能進(jìn)行了測試分析，結(jié)果表明，SDN 上的安全應(yīng)用在對安全檢測的準(zhǔn)確率沒有太大影響的情況下，能極大地減少人員配置的成本和失誤，同時有效降低資源的消耗。

直接在SDN 控制器上部署安全應(yīng)用，尤其是面向連接的安全檢查，雖然能充分與軟件定義的思想相融合，但這種結(jié)構(gòu)對控制平面和數(shù)據(jù)平面都會產(chǎn)生一定影響:

1)使大約16%左右的網(wǎng)絡(luò)流量經(jīng)過控制器直接到達(dá)安全應(yīng)用，而控制器要處理來自很多應(yīng)用的數(shù)據(jù)，它的性能對整個網(wǎng)絡(luò)有非常重要的影響。

2)在交換機(jī)上部署了數(shù)量龐大的規(guī)則，但正如文獻(xiàn)［25-26］中描述的，SDN 交換機(jī)上存儲規(guī)則的空間有限，因此，連接面向狀態(tài)的安全檢測會影響數(shù)據(jù)平面的性能。

在大型數(shù)據(jù)中心里，動態(tài)、復(fù)雜的大規(guī)模流量會為上述不足帶來放大效應(yīng)，對控制器和交換機(jī)產(chǎn)生巨大壓力，影響正常業(yè)務(wù)的工作，甚至使整個網(wǎng)絡(luò)完全崩潰。因此，必須采用新的安全架構(gòu)，使得在充分利用SDN 優(yōu)勢的同時，能夠有效減少SDN 控制器和交換機(jī)的壓力，不影響普通業(yè)務(wù)的正常工作，這將是未來的主要工作。

［1］Kreutz D，Ramos F M V，Verissimo P.Towards secure and dependable software-defined networks［C］// Proceedings of the 2nd ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking.2013:55-60.

［2］Modi C，Patel D，Borisaniya B，et al.A survey on security issues and solutions at different layers of cloud computing［J］.The Journal of Supercomputing，2013，63(2):561-592.

［3］Deshpande P，Aggarwal A，Sharma S C，et al.Distributed port-scan attack in cloud environment［C］// Proceedings of the 5th International Conference on Computational Aspects of Social Networks (CASoN).2013:27-31.

［4］Wang Bing，Zheng Yao，Lou Wenjing，et al.DDoS attack protection in the era of cloud computing and software-defined networking［C］// Proceedings of the 22nd IEEE International Conference on Network Protocols (ICNP).2014:624-629.

［5］Modi C，Patel D，Borisaniya B，et al.A survey of intrusion detection techniques in cloud［J］.Journal of Network and Computer Applications，2013，36(1):42-57.

［6］Dotcenko S，Vladyko A，Letenko I.A fuzzy logic-based information security management for software-defined networks［C］// Proceedings of the 16th International Conference on Advanced Communication Technology (ICACT).2014:167-171.

［7］Lim S，Ha J，Kim H，et al.A SDN-oriented DDoS blocking scheme for botnet-based attacks［C］// Proceedings of the 6th International Conference on Ubiquitous and Future Networks (ICUFN).2014:63-68.

［8］Collings J，Liu Jun.An openFlow-based prototype of SDNoriented stateful hardware firewalls［C］// Proceedings of the 22nd IEEE International Conference on Network Protocols (ICNP).2014:525-528.

［9］Suh M，Park S H，Lee B，et al.Building firewall over the software-defined network controller［C］// Proceedings of the 16th International Conference on Advanced Communication Technology (ICACT).2014:744-748.

［10］Gelberger A，Yemini N，Giladi R.Performance analysis of software-defined networking (SDN)［C］// Proceedings of the 21st IEEE International Symposium on Modeling，Analysis ＆ Simulation of Computer and Telecommunication Systems (MASCOTS).2013:389-393.

［11］Tsugawa M，Matsunaga A，F(xiàn)ortes J A B.Cloud computing security:What changes with software-defined networking?［M］// Secure Cloud Computing.New York:Springer，2014:77-93.

［12］McKeown N，Anderson T，Balakrishnan H，et al.Open-Flow:Enabling innovation in campus networks［J］.Computer Communication Review，2008，38(2):69-74.

［13］Vaughan-Nichols S J.OpenFlow:The next generation of the network?［J］.Computer，2011，44(8):13-15.

［14］Chang R K C.Defending against flooding-based distributed denial-of-service attacks:A tutorial［J］.IEEE Communications Magazine，2002，40(10):42-51.

［15］Peng Tao，Leckie C，Ramamohanarao K.Survey of network-based defense mechanisms countering the DoS and DDoS problems［J］.ACM Computing Surveys，2007，39(1):Article 3.

［16］Darwish M，Ouda A，Capretz L F.Cloud-based DDoS attacks and defenses［C］// Proceedings of the 2013 International Conference on Information Society (i-Society).2013:67-71.

［17］Liu Huan.A new form of DOS attack in a cloud and its avoidance mechanism［C］// Proceedings of the 2nd ACM Workshop on Cloud Computing Security.2010:65-76.

［18］Bhuyan M H，Bhattacharyya D K，Kalita J K.Surveying port scans and their detection methodologies［J］.The Computer Journal，2011，54(10):1565-1581.

［19］Akbarabadi A，Zamani M，F(xiàn)arahmandian S，et al.An Overview on Methods to Detect Port Scanning Attacks in Cloud Computing［DB/OL］.http://www.wseas.us/e-library/conferences/2013/CambridgeUK/AISE/AISE-30.pdf，2013-12-22.

［20］Riquet D，Grimaud G，Hauspie M.Large-scale coordinated attacks:Impact on the cloud security［C］// Proceedings of the 6th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing(IMIS).2012:558-563.

［21］Schechter S E，Jung J，Berger A W.Fast detection of scanning worm infections［C］// Proceedings of the 7th International Symposium on Recent Advances in Intrusion Detection.2004:59-81.

［22］Twycross J，Williamson M M.Implementing and testing a virus throttle［C］// Proceedings of the 12th USENIX Security Symposium.2003:285-294.

［23］Mehdi S A，Khalid J，Khayam S A.Revisiting traffic anomaly detection using software defined networking［C］//Proceedings of the 14th International Symposium on Recent Advances in Intrusion Detection.2011:161-180.

［24］McHugh J.The 1998 Lincoln laboratory IDS evaluation［C］// Proceedings of the 3rd International Workshop on Recent Advances in Intrusion Detection.2000:145-161.

［25］Curtis A R，Mogul J C，Tourrilhes J，et al.DevoFlow:Scaling flow management for high-performance networks［C］// Proceedings of the 2011 ACM SIGCOMM Conference on Applications，Technologies，Architectures，and Protocols for Computer Communications.2011:254-265.

［26］Sekar V，Egi N，Ratnasamy S，et al.Design and implementation of a consolidated middlebox architecture［C］//Proceedings of the 9th USENIX Symposium on Networked Systems Design and Implementation.2012:323-336.