国产日韩欧美一区二区三区三州_亚洲少妇熟女av_久久久久亚洲av国产精品_波多野结衣网站一区二区_亚洲欧美色片在线91_国产亚洲精品精品国产优播av_日本一区二区三区波多野结衣 _久久国产av不卡

?

UDM:基于NFV的防止DDoS攻擊SDN控制器的機制

2019-03-28 11:50錢紅燕薛昊陳鳴
通信學報 2019年3期
關鍵詞:交換機報文時延

錢紅燕,薛昊,陳鳴

?

UDM:基于NFV的防止DDoS攻擊SDN控制器的機制

錢紅燕,薛昊,陳鳴

(南京航空航天大學計算機科學與技術學院,江蘇 南京 211106)

廣泛存在的分布式拒絕服務(DDoS)攻擊對于軟件定義網(wǎng)絡(SDN)的控制器形成了致命威脅,至今還沒有一種安全機制能夠防御。將SDN和網(wǎng)絡功能虛擬化(NFV)結合,提出了一種新穎的防范DDoS攻擊SDN控制器的前置檢測中間盒(UDM)機制,在SDN交換機端口與用戶主機之間分布式部署UDM以檢測并拒止DDoS攻擊報文。此外,還提出了一種基于NFV的前置中間盒的實現(xiàn)方法,使這種UDM機制更為經(jīng)濟和有效,實現(xiàn)了基于該機制的原型系統(tǒng),并對其進行大量測試。實驗結果表明,基于NFV的UDM機制能夠實時有效地檢測和防止對控制器的DDoS攻擊。

DDoS攻擊;控制器安全;軟件定義網(wǎng)絡與網(wǎng)絡功能虛擬化;前置檢測中間盒

1 引言

軟件定義網(wǎng)絡(SDN, software defined networking)[1]是一種將控制和轉發(fā)功能相分離的網(wǎng)絡體系結構,它的集中控制方式使網(wǎng)絡管理與應用業(yè)務配置更加靈活和便捷,也便于部署網(wǎng)絡新技術、新協(xié)議,促進了網(wǎng)絡創(chuàng)新。然而,在SDN獲得了空前發(fā)展的同時,SDN的安全性也引起了越來越多的關注。特別是SDN控制器作為SDN的核心,保障其安全性成為科研人員研究的焦點之一。這是因為SDN的運轉完全依賴控制器執(zhí)行集中式的決策,如果控制器因為某種原因而無法正常工作甚至癱瘓,整個網(wǎng)絡都將隨之崩潰。

過去幾十年,分布式拒絕服務(DDoS, distributed denial of service)攻擊一直是互聯(lián)網(wǎng)中的一種重大的安全威脅,學術界和工業(yè)界的研究人員對此進行了大量研究工作。由于SDN集中控制的特點,DDoS針對SDN的攻擊危害性也更大。根據(jù)SDN工作原理,當某新流到達某SDN,進入一個OpenFlow交換機時,該OpenFlow交換機沒有與該流相匹配的流表項,此時交換機就會將該報文封裝成Packet_In報文轉發(fā)至SDN控制器,由控制器處理,而交換機與控制器之間的鏈路常常會成為DDoS攻擊的目標??刂破魇盏浇粨Q機傳來的Packet_In報文后就會處理這些報文,當報文數(shù)量過多時,會大量消耗控制器的資源,降低網(wǎng)絡性能,因此控制器資源的瓶頸也成為DDoS攻擊的目標??刂破魈幚硗攴纸M請求后會下發(fā)流表到相應的OpenFlow交換機,而交換機所能保存的流表項數(shù)量有限,當下發(fā)的流表數(shù)量大于交換機流表容量時,流表就會溢出,這一點也成為DDoS攻擊的目標。由于SDN受到攻擊后會對整個網(wǎng)絡造成巨大影響,特別是SDN控制器受到攻擊之后,很可能會使整個網(wǎng)絡癱瘓。因此,設計一種針對SDN控制器的防御機制來處理DDoS攻擊是研究者們追求的目標。

目前,解決SDN中DDoS攻擊的方法大體包括以下2種:一種是為SDN中的交換機和控制器增加更多的緩存隊列,使遇到DDoS時可以有更多的資源來應對,然而這種方法只是在遇到DDoS攻擊時起緩解作用,并不能從根本上解決DDoS攻擊,當DDoS攻擊流量過大時,依然會耗盡所有的緩存資源;另一種是在SDN的控制平面建立完整的DDoS檢測和防御機制,通過DDoS檢測方法來判斷攻擊的類型,然后報警或采用相應的方式進行DDoS防御,但是DDoS攻擊通常是在很短時間內(nèi)進行的很大流量的攻擊,這種方法需要定時收集流量數(shù)據(jù),并對其進行分析之后再進行防御,實時性不高,往往分析完攻擊類型進行防御時,整個網(wǎng)絡已經(jīng)受到影響甚至癱瘓。

近年來,隨著網(wǎng)絡功能虛擬化(NFV, network function virtualization)[2]的發(fā)展,其具有的優(yōu)點如不依賴底層硬件、極高的可擴展性、部署和遷移的靈活性以及設備的低成本性都為研究人員所關注。面對DDoS對SDN的攻擊,本文希望可以借助NFV多方面的優(yōu)勢來解決2個問題:1) 如何創(chuàng)新設計一種實時性較高的DDoS檢測防御控制機制;2) 如何提高這種機制的靈活性、實用性。

本文的主要貢獻如下:通過分析SDN控制器的工作過程,提出了一種新型分布式防范SDN中DDoS攻擊的機制;根據(jù)NFV和SDN的特征,提出了一種基于NFV實現(xiàn)上述機制的技術,并通過SDN和NFV結合的技術給出了防范DDoS攻擊的方案;原型系統(tǒng)的實驗表明了該機制和技術的有效性。

2 相關工作

在SDN中,控制器集中式控制決策方式需要分析所有新流并為其安裝流表。當受到DDoS攻擊時,控制器可能會由于負載過大而處于低效或者癱瘓狀態(tài)。文獻[3]提出,當網(wǎng)絡中的流量大于10 Gbit/s時,SDN控制器就很難對網(wǎng)絡中產(chǎn)生的大量新流進行合理和及時的處理。文獻[4]提出,針對控制器資源的各種攻擊行為需要提高可擴展性,避免遇到攻擊時對SDN的危害更為嚴重。

為了減少DDoS攻擊對控制器性能的影響,文獻[5]提出了多層公平隊列(MLFQ, multi-layer fair queueing),在控制器端為每個交換機創(chuàng)建多層次的緩沖隊列。MLFQ實施SDN控制器資源與多層隊列的公平共享,可根據(jù)控制器負載動態(tài)擴展和聚合,是一種簡單而有效的DDoS緩解方法。文獻[6-7]針對控制器資源飽和威脅提出了解決方案,但是需要對交換機進行修改。文獻[8]提出了一種主動防御DDoS攻擊的體系結構安全覆蓋服務,該機制能夠有效緩解攻擊的影響。

近年來,NFV和相關技術在很多新興應用領域都展現(xiàn)出獨特的魅力和良好的應用前景[2]。NFV將網(wǎng)絡功能的上層軟件與底層硬件解耦,并支持靈活動態(tài)的配置、啟動網(wǎng)絡功能及高效合理的分配基礎設施的資源,降低了網(wǎng)絡中的設備投資成本和運營成本,提高了網(wǎng)絡的靈活性和可擴展性,加快了網(wǎng)絡的創(chuàng)新和新技術的部署應用。應用NFV可以更好地運用分布式協(xié)調(diào)方法來緩解DDoS攻擊。文獻[9]提出了一種基于NFV和SDN的DDoS緩解框架,利用中心控制和全局網(wǎng)絡視圖的SDN特性在控制平面對網(wǎng)絡流量進行監(jiān)控分析,檢測出異常流量后將觸發(fā)相應對策計算的動作,防范資源虛擬化、實例化、部署和互聯(lián)。文獻[10-12]提出了通過應用NFV來考慮功能靈活性的DDoS攻擊檢測和預防機制。文獻[13]提出了一種在OpenFlow邊緣交換機中運行的基于熵的輕量級DDoS洪泛攻擊檢測模型,計算目的IP地址的熵,如果低于閾值,則檢測到攻擊,該方案實現(xiàn)了SDN中的分布式異常檢測,并減少了控制器上的流量采集過載。

綜上所述,目前的所有防御機制都僅能緩解DDoS攻擊的危害,而無法防止DDoS對SDN控制器的攻擊。此外,有些防御機制的實現(xiàn)開銷較大,難以實際部署。

3 防范攻擊的分布式機制

3.1 防范攻擊的難點

為了便于分析,圖1給出一個典型的OpenFlow網(wǎng)絡實例。其中,OpenFlow交換機(S1、S2、S3)相互連通,并與周圍的臺式主機(pc1、pc2、pc3)、手提電腦(user1、user2)以及服務器相連,它們構成了SDN的數(shù)據(jù)平面;而控制平面的SDN控制器與3個交換機相連,其中的SDN控制器負責處理來自交換機的報文并下發(fā)路徑流表,使SDN中的各個主機之間可以相互通信。

圖1 一個典型的OpenFlow網(wǎng)絡實例

圖2給出了在上述SDN中處理數(shù)據(jù)流時流表下發(fā)工作過程的主要步驟:1) 當用戶發(fā)送的報文進入OpenFlow交換機后,首先會與交換機中的流表進行匹配,若無相應的流表項則會觸發(fā)table_miss事件,交換機將報文封裝成Packet_In報文后發(fā)送給SDN控制器,請求控制器處理;2) SDN控制器根據(jù)已知的網(wǎng)絡拓撲情況為新的數(shù)據(jù)流請求計算路徑,將流表以Packet_Out報文發(fā)送至路徑上所有的OpenFlow交換機上;3) OpenFlow交換機收到Packet_Out報文后為報文安裝相應的流表項,流表安裝完畢之后,報文即可按照流表在OpenFlow交換機之間轉發(fā)。在步驟1)中,如果交換機收到發(fā)送的Packet_In報文數(shù)量過大,超過鏈路的容量,會導致正常的分組報文無法順利到達SDN控制器,OpenFlow交換機無法正常工作,與該交換機相連的主機、服務器等也都會受到影響。在步驟2)中,如果控制器受到攻擊,接收到過多的請求,導致控制器資源消耗過度,控制器癱瘓以至無法處理來自交換機的正常請求,與該控制器相連的所有交換機以及與交換機相連的主機、服務器等都會受到影響,整個SDN都無法正常工作。在步驟3)中,如果控制器下發(fā)的流表項過多,超出OpenFlow交換機中流表的容量,會導致一些流表項被丟棄,致使一些數(shù)據(jù)流需要重新傳入SDN控制器處理,增加控制器的負擔,影響SDN控制器以及與交換機相連的主機、服務器等的正常工作。

圖2 流表下發(fā)工作過程

3.2 防范攻擊的優(yōu)勢位置

本文將檢測和防御DDoS攻擊的相關設備稱為DDoS檢測中間盒,從前面分析可知,DDoS攻擊可能會攻擊SDN中的各個位置,而且無論攻擊什么位置都會對SDN產(chǎn)生危害。DDoS檢測中間盒在SDN中部署的位置也會對防御的效果產(chǎn)生影響。目前,比較常見的檢測和防御位置有3種。第一種是將檢測與防御放置在控制平面。由于SDN集中式管理的特點,在控制平面進行檢測和防御可以一次性監(jiān)控網(wǎng)絡中的所有流量,但是隨之而來的問題是會導致控制平面的數(shù)據(jù)流過大,在受到攻擊時,報文會大量進入控制平面,對交換機控制器之間的鏈路以及控制器造成影響。第二種是將檢測程序放在控制平面,而將防御程序放在數(shù)據(jù)平面。將防御程序放在數(shù)據(jù)平面確實會減輕很多控制平面的負載,在檢測到DDoS攻擊之后,DDoS的后續(xù)攻擊流都不會對SDN造成影響,不過由于DDoS快而多的特點,往往在DDoS攻擊被檢測到的時候,網(wǎng)絡已經(jīng)受到很大影響甚至癱瘓。第三種是將檢測中間盒部署在數(shù)據(jù)平面。目前常見的方案是通過修改OpenFlow交換機的代碼,將檢測中間盒部署在OpenFlow交換機之中;另一種方案是在數(shù)據(jù)傳輸路徑中增加檢測中間盒,通過分析進入流的分組,檢測DDoS攻擊并進行處理。前一種方案要修改交換機硬件和軟件,使交換機不再符合標準規(guī)范;后一種方案檢測和防御的效果好,但是實現(xiàn)成本有可能很高。

綜上所述,將檢測和防御功能放在控制平面的優(yōu)缺點是:控制平面監(jiān)控數(shù)據(jù)更全面,軟件實現(xiàn)更加方便,成本低,但是集中式處理大流量會使控制器處理能力成為瓶頸,難以應對DDoS攻擊。將檢測和防御功能分別放在控制平面和數(shù)據(jù)平面的優(yōu)缺點是:SDN控制器的負載較低,但是處理DDoS攻擊的實時性不好。而將檢測和防御功能放在數(shù)據(jù)平面的優(yōu)缺點是:利用數(shù)據(jù)平面?zhèn)鬏斈芰?、處理時效性好的特點,以分布式方式分散DDoS攻擊的影響,避免使控制器成為性能瓶頸,但是成本相對較高。為避免高成本使機制難以實施的缺點,需要找到降低實現(xiàn)防御機制成本的方法,詳情參見第4節(jié)的討論。

3.3 熵值計算

文獻[14]提出的基于熵值的檢測方法可以較好地檢測出是否存在DDoS攻擊報文。由于檢測實時性和準確性的要求,在將上述熵值檢測方法引入本文檢測機制的過程中,對其進行調(diào)整,通過滑動窗口調(diào)整數(shù)據(jù)集大小,使該方法可以更好地適用于本文的分布式實時檢測機制。

信息熵能夠很好地表現(xiàn)出數(shù)據(jù)集的特征,熵值越高,數(shù)據(jù)集的隨機性越大;熵值越低,數(shù)據(jù)集的隨機性越小。Shannon熵定義如下。

數(shù)據(jù)集中共有個數(shù)據(jù),包含個不同的取值,即{1,2,…,x},各個值出現(xiàn)的概率為,即{1,2,…,p},其中,p可由式(1)計算得到。

那么數(shù)據(jù)集的熵為

當數(shù)據(jù)集中所有元素相同時,熵值為0;而當數(shù)據(jù)集中所有元素都不相同時,熵值為最大。在所有情況下,數(shù)據(jù)集的熵值都在[0,max]區(qū)間內(nèi)。為了使熵值不受數(shù)據(jù)集大小的影響,通過式(3)將數(shù)據(jù)集的熵值標準化到[0,1]區(qū)間內(nèi)。

通常情況下,網(wǎng)絡中普通流量的源IP地址在一個連續(xù)采集的數(shù)據(jù)集中相對穩(wěn)定,但是當遇到偽造地址的DDoS攻擊時,源IP地址的隨機性會增加,熵值會顯著變大。因此在得到網(wǎng)絡中正常流量的源IP地址熵值區(qū)間之后,即可根據(jù)該熵值區(qū)間來設置本文的DDoS檢測閾值。

數(shù)據(jù)集大?。椿瑒哟翱诖笮。┦且粋€可調(diào)性很高的參數(shù)。DDoS攻擊報文在網(wǎng)絡中的速率為v,采集到攻擊報文的時長為t,而正常報文在網(wǎng)絡中的速率為v,采集到正常報文的時長為t。DDoS攻擊報文在數(shù)據(jù)集中占的比例P

由于DDoS攻擊突發(fā)性的特點,滑動窗口采集數(shù)據(jù)集的時間不宜過長。由式(4)可知,若采集時間過長,可能會導致t>>t,DDoS攻擊報文在數(shù)據(jù)集中的占比會減小,導致熵值檢測的準確性降低。在熵值檢測中,數(shù)據(jù)集中的各個值出現(xiàn)的概率p至關重要,由于滑動窗口采集數(shù)據(jù)集的不穩(wěn)定性,不同數(shù)值在不同數(shù)據(jù)集中出現(xiàn)的次數(shù)會有一定的偏差,由式(1)可知,越大,計算得到的p偏差越小,最后得到的熵值越逼近于該時間段內(nèi)中間盒轉發(fā)的報文的熵值。綜上所述,在保證合理的數(shù)據(jù)采集時間的前提下,進行DDoS熵值檢測算法的數(shù)據(jù)集越大,檢測的準確性越高。

然而增大同樣帶來了一個問題,先進入樣本集的報文需要等待后續(xù)的報文進入樣本集后才能進行分析處理,這樣會增加報文在網(wǎng)絡中的傳播時延。若網(wǎng)絡中時間內(nèi)發(fā)送報文的總數(shù)量為,檢測算法中設置的數(shù)據(jù)集容量為,那么樣本集中第個報文因等待其他報文進入數(shù)據(jù)集額外增加的傳播時延為

3.4 前置檢測中間盒機制

前置檢測中間盒(UDM, upfront detection middlebox)機制定義為:1)檢測中間盒靠前部署在用戶設備與相連的OpenFlow交換機某端口之間,而不是放在交換機甚至控制器之前;2)檢測中間盒具有檢測DDoS攻擊流的功能;3)檢測中間盒對檢測到的DDoS攻擊流具有拒止的功能。

SDN所有的用戶流量直接進入前置的檢測中間盒,中間盒的檢測算法分析是否存在DDoS攻擊。如果存在DDoS攻擊流則丟棄相關報文,交換機乃至控制器就不可能收到這些攻擊報文。如果是正常的流量則將其轉發(fā)給交換機進行后續(xù)處理。為了降低處理成本,可以區(qū)分用戶的可信度,將可信度高的用戶的流量直接轉交給交換機處理,而只處理可信度較低的那部分用戶的流量。使用傳統(tǒng)方法采用專用硬件和軟件來設計實現(xiàn)檢測中間盒,將存在嚴重的性價比問題,部署系統(tǒng)需要大量的檢測中間盒將提高系統(tǒng)的造價,但如果檢測中間盒的成本變得很低時,系統(tǒng)的性價比將不再是主要問題。本文將在第4節(jié)研究解決該問題的具體技術方案。

前置檢測中間盒的流處理流程如算法1所示。該算法首先需要為Packet_View設置一個具有一定容量的緩存區(qū),本文將該緩存區(qū)稱為滑動窗口。對于持續(xù)進入中間盒的流分組,先短暫緩存在Packet_View中,依次提取分組的源IP地址信息。每當Packet_View中存儲的信息量達到一定數(shù)量時,就開始計算這些報文的目的地址的熵值。若該熵值在正常范圍以內(nèi),則判斷這些報文不存在DDoS攻擊,將緩存Packet_View中所有的報文轉發(fā)到交換機;若該熵值異常,則判斷其中具有大量的DDoS攻擊流分組,向系統(tǒng)報警并將緩存中的所有報文丟棄,這些DDoS攻擊報文就根本沒有機會進入SDN中,也不可能形成對控制器的攻擊。與此同時,系統(tǒng)將在一定時間內(nèi)封閉與該用戶連接的端口,要求該用戶或網(wǎng)絡管理員解決DDoS攻擊來源問題。盡管這種處理策略可能會對正常應用流產(chǎn)生影響,但由于每個檢測中間盒只面對一個用戶,因此對系統(tǒng)中的其他用戶不會產(chǎn)生任何影響,并且要求用戶在正常使用網(wǎng)絡之前,先解決自身存在DDoS攻擊流的問題也是合理的。

當用戶流分組較少時,緩存Packet_View中的報文數(shù)量在一定時間間隔內(nèi)仍未填滿,為了保證應用流的實時性,此時系統(tǒng)將其判斷為無DDoS攻擊,并將轉發(fā)緩存中的所有報文。這是因為此時用戶到達的報文量很少,它們不會對控制器性能造成大的影響。

算法1 前置檢測中間盒的流處理

輸入 流的報文,視圖容量

輸出 對流中報文放行或者阻斷

1) 設置Packet_View容量為

2) for 每一條新到的報文do;

3) 在報文中提取源IP地址的信息;

4) 將保存到Packet_View中;

5) if (Packet_View飽和)then

6) 通過式(3)計算熵值;

7) if (超出正常范圍)then

8) 判斷為DDoS攻擊,將Packet_View中數(shù)據(jù)相關的報文丟棄,報警,關閉端口;

9) else

10) 將Packet_View中數(shù)據(jù)相關的報文全部放行,轉發(fā);

11) end if

12) end if

13) end for

14) if (無后續(xù)報文 && Packet_View未飽和)then

15) 窗口中報文全部放行,轉發(fā);

16) end if

算法1中如何使用緩存區(qū)還有一些值得研究的問題,例如,緩存區(qū)應當設置的大小,檢測中間盒對流報文產(chǎn)生的時延的影響,本文將在第5節(jié)進行深入研究。

4 前置檢測中間盒機制及其實現(xiàn)

DDoS檢測中間盒的實現(xiàn)技術是本文研究的另一個重要問題。近年來快速發(fā)展的NFV技術為本文采用虛擬化技術實現(xiàn)檢測中間盒功能提供了一個很好的思路。一方面,NFV是一種在標準服務器硬件上以特定軟件來實現(xiàn)網(wǎng)絡功能的技術,在特定的條件下能夠以很低的成本提供所需的各種虛擬網(wǎng)絡功能(VNF, virtualized network function),而且NFV技術的靈活性和可擴展性能夠為實現(xiàn)分布式檢測防御提供便利;另一方面,用一個檢測中間盒來處理一個用戶的流量,VNF通常是有能力來應對的。因此,本節(jié)設計了一種基于NFV與SDN綜合的技術,以分布式方式部署DDoS檢測中間盒的方案。首先,設計了一種基于NFV與SDN綜合的分布式網(wǎng)絡環(huán)境;然后,設計實現(xiàn)了一種檢測和防御DDoS攻擊的中間盒。

4.1 NFV/SDN環(huán)境

在NFV與SDN綜合的環(huán)境中,存在下列情況:一種是基于專用設備的SDN與基于虛擬化的NFV的綜合,主要是虛擬設備和真實設備的交互互聯(lián),將虛擬化的NFV作為專用設備SDN中的一部分;另一種是基于虛擬化的NFV和SDN之間的綜合,主要是將SDN的專用設備也用虛擬設備替換使用。其實兩者從邏輯交互方式上看并無太多不同,并且現(xiàn)有的虛擬化技術都具有虛擬設備與實體設備交互的能力。為簡化討論,本文僅討論在虛擬化環(huán)境下的情況。

首先,選用硬件適宜的服務器作為承載大型虛擬計算環(huán)境的宿主機。在其上運行Linux操作系統(tǒng)以提供虛擬化計算環(huán)境,提供構建虛擬網(wǎng)絡功能和虛擬SDN環(huán)境的硬件條件。

其次,生成配置網(wǎng)絡虛擬機。優(yōu)選高效低耗的虛擬機如Linux容器(LXC[15]),通過為虛擬機配置IP地址、路由選擇協(xié)議、性能參數(shù)等,使其成為某種網(wǎng)絡功能的虛擬網(wǎng)絡設備,如虛擬路由器、虛擬主機等。

第三,生成配置網(wǎng)絡中間盒。在上述虛擬網(wǎng)絡設備上安裝特定網(wǎng)絡功能軟件,使其成為具有特定網(wǎng)絡功能的虛擬網(wǎng)絡中間盒,例如防火墻、入侵檢測系統(tǒng)或本文所需DDoS檢測中間盒等。

第四,部署SDN互聯(lián)網(wǎng)絡虛擬設備和網(wǎng)絡中間盒。根據(jù)應用需求,通過在虛擬計算環(huán)境部署虛擬OpenFlow交換機,將所有虛擬網(wǎng)絡設備與相應的OpenFlow交換機相連;安裝SDN控制器,設置OpenFlow交換機到SDN控制器的通信鏈路,使SDN控制器與OpenFlow交換機保持連接,形成NFV與SDN綜合的網(wǎng)絡環(huán)境。注意到,SDN控制器既能安裝在實體主機上,也能安裝在虛擬主機上。

由于NFV的靈活性,本文不僅可以將網(wǎng)絡中間盒部署在虛擬網(wǎng)絡的各個部分,也可以將網(wǎng)絡中間盒與真實網(wǎng)絡進行虛實互連。將運行虛擬網(wǎng)絡功能中間盒的服務器與真實的OpenFlow交換機、服務器、PC主機等網(wǎng)絡設備用網(wǎng)線連接起來,并將網(wǎng)絡功能中間盒的虛擬網(wǎng)卡配置為與服務器實際網(wǎng)絡端口相連,這樣就能實現(xiàn)外部實際網(wǎng)絡設備與服務器中的虛擬網(wǎng)絡功能中間盒的連接。在NFV網(wǎng)絡中的虛實互連使得虛擬網(wǎng)絡功能能夠與真實網(wǎng)絡融為一體,提高了它的實用價值。

4.2 檢測中間盒實現(xiàn)

用軟件實現(xiàn)檢測中間盒的虛擬網(wǎng)絡功能也是本文研究的要點之一。本文以LXC作為檢測中間盒的運行環(huán)境,基于Netfilter框架[16]和HOOK技術設計了檢測功能的程序。眾所周知,常用的HOOK點有5種,分別是PRE_ROUTING、LOCAL_IN、FORWARD、LOCAL_OUT和POST_ROUTING。其中的FORWARD是所有中間盒轉發(fā)報文所必經(jīng)的HOOK點,本文選用它作為設計檢測中間盒的基礎。

libnetfilter_queue是一個用戶態(tài)庫,本文設計的用戶態(tài)程序使用它來處理NF_QUEUE隊列傳輸來的分組。檢測中間盒程序使用libnetfilter_queue依次處理NF_QUEUE中的報文,讓報文依次進入緩存區(qū),通過DDoS檢測算法進行數(shù)據(jù)檢測,如果檢測到DDoS攻擊,則將它們丟棄,若檢測到正常流量則進行轉發(fā)。

圖3給出了檢測中間盒功能模塊及其工作過程。當某UDP流進入檢測中間盒后,Linux的iptables指令使所有經(jīng)過FORWARD點的報文進入NF_QUEUE隊列中。接著,中間盒調(diào)用libnetfilter_queue用戶態(tài)庫函數(shù)來處理所有NF_QUEUE中的報文,依次采集報文的特征信息,檢測程序分析報文中特征信息的熵值,判斷其是否為DDoS攻擊數(shù)據(jù)流。如果是,將其全部丟棄;如果不是,將其轉發(fā)至OpenFlow交換機。

圖3 檢測中間盒功能模塊及其工作過程

5 實驗與性能評價

本節(jié)結合了第3節(jié)防范DDoS攻擊的模型以及第4節(jié)基于NFV的實現(xiàn)技術,在Linux LXC環(huán)境下使用NFV與SDN綜合的方法,在數(shù)據(jù)平面按分布式方式在每個用戶主機與SDN交換機之間部署了一個檢測中間盒,實現(xiàn)了一種防范DDoS攻擊SDN控制器的原型系統(tǒng)。通過對該原型系統(tǒng)進行實驗測試,驗證該系統(tǒng)的可行性,并對實驗結果進行分析,評價系統(tǒng)的性能指標。

5.1 原型系統(tǒng)實現(xiàn)

原型系統(tǒng)以一臺Intel(R) Xeon(R) X5647服務器作為宿主機,其主頻為2.93 GHz,內(nèi)存為32 GB,安裝Ubuntu 16.04 server版系統(tǒng)。以LXC作為虛擬機,構建3臺由Open vSwitch[17]生成的OpenFlow交換機S1、S2和S3,系統(tǒng)的SDN控制器采用運行在LXC中的ONOS控制器,控制器分別與S1、S2、S3相連并控制它們的運行?;贚XC生成虛擬主機,其中U1、U2、U3、U4、U5和U6為可信用戶,A1、A2、A3和A4為不可信用戶,并且A1、A2、A3可能生成DDoS流。生成DDoS流的攻擊工具是目前流行的TFN2K[18]。在所有虛擬主機上安裝iperf軟件產(chǎn)生TCP或UDP流。在LXC中安裝DDoS檢測中間盒軟件作為前置中間盒如D1、D2、D3和D4等,并將它們部署在不可信用戶與SDN交換機之間。圖4顯示了一個基于NFV的防范DDoS攻擊SDN控制器的原型系統(tǒng)的實例。

圖4 一個基于NFV的防范DDoS攻擊SDN控制器的原型系統(tǒng)的實例

5.2 實驗結果與分析

1) 滑動窗口大小對正常流時延的影響

設置整個實驗網(wǎng)絡各個端口普通情況下的報文傳輸速率約為100 Mbit/s,每秒發(fā)送的報文數(shù)大約為8 000~9 000個。由于期望中間盒產(chǎn)生的平均網(wǎng)絡時延大致為6 ms,利用式(5)估算出檢測中間盒的滑動窗口的大小約為100個報文。

實驗過程:使用A4向U4發(fā)送約100 Mbit/s的UDP報文,每秒發(fā)送的報文數(shù)約8 500個,D4中間盒的滑動窗口大小在[50,150]區(qū)間內(nèi)變動,統(tǒng)計不同大小的滑動窗口采集、分析處理報文的時長。實驗重復10次,取平均值作為實驗結果,如圖5所示。

圖5 窗口大小對窗口處理時延的影響

從圖5可知,隨著滑動窗口的增大,處理滑動窗口中報文時延也會隨之增加。當滑動窗口大小為50時,滑動窗口的處理時延不足6 ms;而當滑動窗口大小為100時,時延增加到11.56 ms;當滑動窗口大小為150時,處理時延已經(jīng)接近18 ms,實驗表明,時延與窗口大小大致為線性關系。因此,根據(jù)網(wǎng)絡應用的需求選擇合適的滑動窗口大小是十分重要的。

根據(jù)本文實驗環(huán)境的要求,需要將報文的平均網(wǎng)絡時延控制在6 ms左右,所有報文時延區(qū)間為0~12 ms,因此,本文實驗中間盒的滑動窗口大小設置為100。

2) DDoS攻擊流對控制器的影響

實驗過程:在0=0 s時刻,使A1、A2、A3和A4向SDN中發(fā)送約100 Mbit/s的TCP或UDP報文,在1=10 s時刻,A1、A2、A3啟動典型DDoS攻擊應用TFN2K進行源IP地址隨機變換的DDoS攻擊。在2=20 s時刻實驗結束。為了方便對實驗數(shù)據(jù)進行分析對比,分別在啟動和不啟動DDoS檢測中間盒功能的2種情況下,統(tǒng)計各個DDoS檢測中間盒端口轉發(fā)報文到SDN中的報文數(shù)量。實驗重復了10次,取平均值作為實驗結果,如圖6所示。

圖6 檢測中間盒對轉發(fā)報文數(shù)量的影響

由圖6(a)可知,在0~10 s,4個主機由于都在使用相對比較穩(wěn)定的iperf發(fā)送報文,因此各個中間盒轉發(fā)的報文的速率比較穩(wěn)定,都保持在8 000~ 9 000個/秒。而1時刻,A1、A2和A3都啟動TFN2K進行攻擊,每個攻擊源發(fā)送報文的速率大大提升,達到近60 000個/秒,大量攻擊報文進入檢測中間盒,由于此時檢測功能并未打開,因此沒有對攻擊的報文進行檢測防御,所有的攻擊報文進入OpenFlow交換機和SDN控制器。由于SDN控制器集中式的控制,最終SDN控制器接收到的DDoS攻擊報文的總量為所有攻擊源攻擊報文之和,約為170 000個/秒。由圖6(b)可知,在其他條件完全相同的情況下,當1時刻DDoS攻擊報文大量涌入中間盒后,DDoS檢測中間盒D1、D2、D3能夠迅速地檢測到DDoS攻擊,并對后續(xù)所有報文進行丟棄,切斷攻擊源,使幾乎所有的DDoS攻擊報文都無法進入OpenFlow交換機和SDN控制器,SDN得到了很好的保護。另外,檢測中間盒D4由于沒有檢測到攻擊,因此可以繼續(xù)轉發(fā)主機A4發(fā)送的正常報文,不會影響正常端口的數(shù)據(jù)傳輸。

該實驗表明,在數(shù)據(jù)平面部署分布式前置檢測中間盒可以有效地檢測和預防DDoS攻擊,將DDoS攻擊報文阻擋在整個SDN的外部,使它們無法對SDN控制器甚至OpenFlow交換機造成危害。另一方面,分布式的前置檢測防御不會因為DDoS攻擊源的增加而造成SDN控制器的報文冗余,這種工作方式大大提高了網(wǎng)絡系統(tǒng)的安全性和頑健性。

3) DDoS攻擊流對正常用戶的影響

在上述實驗2)的過程中,使可信用戶U5不斷嘗試與可信用戶U6建立TCP連接,獲取不同時刻TCP建立連接的時延,以此來反映SDN控制器在不同時刻的性能狀況。實驗結果如圖7所示。

圖7 TCP連接建立時延

圖7給出了2種情況下TCP連接建立的時延。由于SDN中TCP在建立連接的時候需要SDN控制器下發(fā)流表這一重要步驟,因此,TCP建立連接的時延大小與SDN控制器的運行狀態(tài)有著緊密的聯(lián)系。從圖7可知,在1時刻前,由于網(wǎng)絡環(huán)境沒有受到DDoS攻擊,2種情況下的時延基本相同。而在1時刻,DDoS攻擊到來,若未使用檢測中間盒功能,TCP建立連接的時延大大增加,甚至會出現(xiàn)連接建立失敗的情況;而在使用了檢測中間盒情況下,DDoS攻擊報文被中間盒完全阻擋在了SDN之外,SDN控制器完全沒有受到影響,因此TCP建立連接的時延完全沒有變化。

該實驗表明,在數(shù)據(jù)平面部署分布式前置檢測中間盒可以有效地保護SDN控制器,使其在遭遇DDoS攻擊時依然可以安全穩(wěn)定地工作,從而維持整個SDN的正常運營。

6 結束語

盡管SDN技術與應用已經(jīng)得到空前的發(fā)展,但SDN控制器受到DDoS攻擊威脅的問題一直沒有得到很好的解決。一旦DDoS攻擊報文進入SDN,就會消耗大量的控制器資源,使整個網(wǎng)絡效率降低甚至癱瘓。利用本文提出的防范DDoS攻擊SDN控制器的前置檢測中間盒機制(UDM),一方面將DDoS檢測和過濾功能分布式地設置在數(shù)據(jù)平面的前端,避免了大量攻擊報文進入SDN,從而有效地檢測和預防DDoS攻擊。另一方面,利用NFV虛擬網(wǎng)絡功能的實現(xiàn)成本低、部署靈活的特點,系統(tǒng)具有較高的性能價格比。原型系統(tǒng)的實驗結果表明,本文機制和方法具有可行性和有效性,能夠很好地保護SDN的核心控制器,提高網(wǎng)絡系統(tǒng)的安全性和頑健性。下一步,將思考如何更加靈活有效地部署檢測中間盒,提高檢測中間盒的工作效率,使其可以更好地服務于各種不同的網(wǎng)絡環(huán)境。

[1] MCKEOWN N, ANDERSON T, BALAKRISHNAN H, et al. OpenFlow: enabling innovation in campus networks[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(2): 69-74.

[2] MIJUMBI R, SERRAT J, GORRICHO J L, et al. Network function virtualization: state-of-the-art and research challenges[J]. IEEE Communications Surveys & Tutorials, 2017, 18(1): 236-262.

[3] TOOTOONCHIAN A, GORBUNOV S, SHERWOOD R, et al. On controller performance in software-defined networks[C]//Usenix Conference on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services. 2012: 10.

[4] JARSCHEL M, OECHSNER S, SCHLOSSER D, et al. Modeling and performance evaluation of an OpenFlow architecture[C]//Teletraffic Congress. 2011: 1-7.

[5] ZHANG P, WANG H, HU C, et al. On denial of service attacks in software defined networks[J]. IEEE Network, 2016, 30(6): 28-33.

[6] SHIN S, YEGNESWARAN V, PORRAS P, et al. AVANT-GUARD: scalable and vigilant switch flow management in software-defined networks[C]//ACM Sigsac Conference on Computer & Communications Security. 2013: 413-424.

[7] WANG H, XU L, GU G. FloodGuard: a DoS attack prevention extension in software-defined networks[C]//IEEE/IFIP International Conference on Dependable Systems and Networks. 2015: 239-250.

[8] KEROMYTIS A D, MISRA V, RUBENSTEIN D. SOS: secure overlay services[C]//ACM SIGCOMM ’02 Conference. 2002: 61-72.

[9] ZHOU L, GUO H. Applying NFV/SDN in mitigating DDoS attacks[C]//2017 IEEE Region 10 Conference. 2017: 2061-2066.

[10] FUNG C J, MCCORMICK B. VGuard: a distributed denial of service attack mitigation method using network function virtualization[C]//International Conference on Network and Service Management. 2015: 64-70.

[11] JAKARIA A H M, YANG W, RASHIDI B, et al. VFence: a defense against distributed denial of service attacks using network function virtualization[C]//Computer Software and Applications Conference. 2016: 431-436.

[12] FUTAMURA K, KARASARIDIS A, NOEL E, et al. vDNS closed-loop control: a framework for an elastic control plane service[C]//Network Function Virtualization and Software Defined Network. 2016: 170-176.

[13] WANG R, JIA Z, JU L. An entropy-based distributed DDoS detection mechanism in software-defined networking[C]//IEEE Trustcom/ bigdatase/ispa. 2015: 310-317.

[14] KUMAR K, JOSHI R C, SINGH K. A distributed approach using entropy to detect DDoS attacks in ISP domain[C]//International Conference on Signal Processing, Communications and Networking. 2007: 331-337.

[15] BERNSTEIN D. Containers and cloud: from LXC to docker to kubernetes[J]. IEEE Cloud Computing, 2015, 1(3): 81-84.

[16] YANG Y, WANG Y. A software implementation for a hybrid firewall using linux netfilter[C]//Software Engineering. 2011: 18-21.

[17] PFAFF B, PETTIT J, KOPONEN T. The design and implementation of open vSwitch[C]//USENIX Networked System Design and Implementation. 2015: 117-130.

[18] DOULIGERIS C, MITROKOTSA A. DDoS attacks and defense mechanisms: classification and state-of-the-art[J]. Computer Networks, 2004, 44(5): 643-666.

UDM: NFV-based prevention mechanism against DDoS attack on SDN controller

QIAN Hongyan, XUE Hao, CHEN Ming

College of Computer Science and Technology, Nanjing University of Aeronautics and Astronautics, Nanjing 211106, China

DDoS attack extensively existed have been mortal threats for the software-defined networking (SDN) controllers and there is no any security mechanism which can prevent them yet. Combining SDN and network function virtualization (NFV), a novel preventing mechanism against DDoS attacks on SDN controller called upfront detection middlebox (UDM) was proposed. The upfront detection middlebox was deployed between SDN switch interfaces and user hosts distributed, and DDoS attack packets were detected and denied. An NFV-based method of implementing the upfront middlebox was put forward, which made the UDM mechanism be economical and effective. A prototype system based on this mechanism was implemented and lots experiments were tested. The experimental results show that the UDM mechanism based on NFV can real-time and effectively detect and prevent against DDoS attacks on SDN controllers.

DDoS attack, controller security, SDN and NFV, upfront detection middlebox

TP393

A

10.11959/j.issn.1000?436x.2019067

2018?06?13;

2019?01?03

陳鳴,mingchennj@163.com

國家自然科學基金資助項目(No.61772271, No.61379149)

The National Natural Science Foundation of China (No.61772271, No.61379149)

錢紅燕(1973? ),女,江蘇常州人,博士,南京航空航天大學副教授、碩士生導師,主要研究方向為計算機網(wǎng)絡、信息安全等。

薛昊(1991? ),男,安徽寧國人,南京航空航天大學碩士生,主要研究方向為計算機網(wǎng)絡、網(wǎng)絡安全。

陳鳴(1956? ),男,江蘇無錫人,博士,南京航空航天大學教授、博士生導師,主要研究方向為未來網(wǎng)絡、網(wǎng)絡功能虛擬化、無人機網(wǎng)絡、網(wǎng)絡安全等。

猜你喜歡
交換機報文時延
基于J1939 協(xié)議多包報文的時序研究及應用
面向未來網(wǎng)絡的白盒交換機體系綜述
低軌星座短報文通信中的擴頻信號二維快捕優(yōu)化與實現(xiàn)
局域網(wǎng)交換機管理IP的規(guī)劃與配置方案的探討
CTCS-2級報文數(shù)據(jù)管理需求分析和實現(xiàn)
5G承載網(wǎng)部署滿足uRLLC業(yè)務時延要求的研究
淺析反駁類報文要點
更換匯聚交換機遇到的問題
基于地鐵交換機電源設計思考
基于GCC-nearest時延估計的室內(nèi)聲源定位