吳若豪，董 平，鄭 濤

(北京交通大學(xué) 電子信息工程學(xué)院，北京 100044)(*通信作者電子郵箱15120159@bjtu.edu.cn)

0 引言

網(wǎng)絡(luò)安全問題一直是影響網(wǎng)絡(luò)技術(shù)發(fā)展的重要因素之一，隨著信息化的不斷加快，其重要性也不斷增加。傳統(tǒng)的網(wǎng)絡(luò)層安全防護(hù)技術(shù)普遍集成在防火墻設(shè)備當(dāng)中，這些設(shè)備隨著近年來各種網(wǎng)絡(luò)技術(shù)的興起已經(jīng)逐漸暴露出一些弊端，例如設(shè)備的二次部署和集中管理問題[1]。為了解決這類問題，研究人員提出了一體化防火墻、下一代防火墻[2]等概念，目前正處于深入研究階段。

相比之下，軟件定義網(wǎng)絡(luò)(Software Defined Network, SDN)采用集中式架構(gòu)，能夠在控制器端感知網(wǎng)絡(luò)整體的信息，并且控制器具有操作網(wǎng)絡(luò)轉(zhuǎn)發(fā)行為的能力[3]，這使得利用軟件定義網(wǎng)絡(luò)技術(shù)實現(xiàn)新型網(wǎng)絡(luò)層安全防護(hù)技術(shù)成為可能[4]。與傳統(tǒng)同類網(wǎng)絡(luò)安全技術(shù)相比，基于軟件定義網(wǎng)絡(luò)的網(wǎng)絡(luò)層安全防護(hù)技術(shù)最重要的優(yōu)勢在于其便于統(tǒng)一管理、靈活調(diào)用，因此具有較大的研究和應(yīng)用價值[5]。

且眾所周知，分布式拒絕服務(wù)(Distributed Denial of Service， DDoS)攻擊對當(dāng)前的網(wǎng)絡(luò)安全有著巨大的危害性。2015年12月31日，英國廣播公司(British Broadcasting Corporation， BBC)和Iplayer服務(wù)器由于遭到了分布式拒絕服務(wù)攻擊，網(wǎng)站癱瘓數(shù)個小時；2016年1月6日，知名互聯(lián)網(wǎng)金融門戶網(wǎng)貸天下發(fā)布公告，稱其遭到了DDoS攻擊，造成了嚴(yán)重的經(jīng)濟(jì)損失。類似的事情數(shù)數(shù)不勝數(shù)，可見分布式拒絕服務(wù)攻擊已經(jīng)成為了網(wǎng)絡(luò)安全的頭號公敵。而該攻擊過程大體可以分為以下幾步[6]：1)惡意的探測掃描大量主機(jī)以尋找可入侵的主機(jī)目標(biāo)；2)入侵有安全漏洞的主機(jī)并獲取控制權(quán)；3)在每一臺被入侵的主機(jī)當(dāng)中安裝控制程序；4)利用已經(jīng)被安裝控制程序的傀儡機(jī)繼續(xù)重復(fù)步驟1)～3)去擴(kuò)張傀儡機(jī)群的規(guī)模；5)利用已掌握的傀儡機(jī)群對目標(biāo)進(jìn)行具有嚴(yán)重破壞性的分布式拒絕服務(wù)攻擊。

以往傳統(tǒng)的防護(hù)手段，大多僅能在攻擊者已經(jīng)形成一定規(guī)模的傀儡機(jī)，并且對攻擊對象產(chǎn)生了一定破壞程度的攻擊危害之后，才能發(fā)現(xiàn)DDoS攻擊并且對其進(jìn)行檢測和防御，而不能在攻擊還沒開始之前就很好地預(yù)防[7]。而要想在攻擊還沒有產(chǎn)生破壞效果之前就預(yù)防DDoS攻擊，需要在攻擊者對網(wǎng)絡(luò)進(jìn)行惡意掃描發(fā)展傀儡機(jī)群的階段，就阻止傀儡機(jī)群規(guī)模的擴(kuò)張，攻擊者在沒有控制大量傀儡機(jī)的情況下，就無法對目標(biāo)發(fā)動有效的DDoS攻擊。但以往對于攻擊者在通過惡意掃描去發(fā)展傀儡機(jī)群數(shù)量的階段就可進(jìn)行反制的手段很少，即使有，大多也僅能從單機(jī)層面來進(jìn)行防御，即通過對每臺主機(jī)設(shè)置防火墻、為每一臺主機(jī)打上安全漏洞補(bǔ)丁、定期掃描每臺主機(jī)當(dāng)中是否存在惡意進(jìn)程來進(jìn)行，由于是從單機(jī)的層面，并且操作很復(fù)雜繁瑣，效果并不好，并不能從根本上阻止攻擊者擴(kuò)張傀儡機(jī)群；并且由于傳統(tǒng)網(wǎng)絡(luò)防護(hù)技術(shù)難以集中獲取整個網(wǎng)絡(luò)的狀態(tài)和對各節(jié)點(diǎn)進(jìn)行控制，所以對于攻擊者對網(wǎng)絡(luò)的惡意掃描的預(yù)防就十分困難，即使通過硬件防火墻對整體網(wǎng)絡(luò)進(jìn)行隔離，也需要提供額外的硬件成本，代價很高。

而基于軟件定義網(wǎng)絡(luò)(SDN)的網(wǎng)絡(luò)層防護(hù)技術(shù)具有能方便地對網(wǎng)絡(luò)統(tǒng)一管理、調(diào)用靈活的特性，打破了難以對網(wǎng)絡(luò)惡意掃描預(yù)防的現(xiàn)狀，使得對惡意掃描攻擊的預(yù)防簡便了許多[8]。利用SDN可對網(wǎng)絡(luò)通過控制器進(jìn)行統(tǒng)一管理的這一特性，不再從單機(jī)層面，而是從網(wǎng)絡(luò)層面，對攻擊者對網(wǎng)絡(luò)的惡意掃描進(jìn)行有效的檢測和防御[9]，從根本上阻止了攻擊者所掌控的傀儡機(jī)規(guī)模的擴(kuò)張，從而進(jìn)一步預(yù)防了如同分布式拒絕服務(wù)攻擊等破壞性極強(qiáng)的攻擊行為[10]。

基于軟件定義網(wǎng)絡(luò)對網(wǎng)絡(luò)便于統(tǒng)一管理和調(diào)用靈活的特性，本文提出了一種新的預(yù)防DDoS攻擊的防護(hù)手段，面向惡意掃描的控制層實時防護(hù)機(jī)制(Control Real-time Defense Mechanism, CRDM)。該方法具有如下特性：1)所創(chuàng)新設(shè)計的基于OpenDayLight(ODL)[11]實現(xiàn)的CRDM，不需要任何額外的硬件支持，僅通過ODL控制器即可達(dá)到對惡意掃描攻擊的檢測和防護(hù)的目的，節(jié)約了大量的硬件成本。2)基于表述性狀態(tài)傳遞(REpresentational State Transfer， REST) 應(yīng)用程序編程接口(Application Programming Interface， API)，不會對網(wǎng)絡(luò)造成負(fù)載，免去了大量的網(wǎng)絡(luò)開銷，并且可以簡便快捷地實現(xiàn)網(wǎng)絡(luò)層狀態(tài)的獲取和管理，且易拓展開發(fā)，具有很強(qiáng)的拓展性。3)利用SDN的特性，相比傳統(tǒng)的防護(hù)手段，創(chuàng)新性地提出了在網(wǎng)絡(luò)控制層面，利用控制器對攻擊者的惡意掃描網(wǎng)絡(luò)的行為進(jìn)行有效的反制，從網(wǎng)絡(luò)的層面而不是傳統(tǒng)的單機(jī)層面上阻止了攻擊者的惡意掃描攻擊網(wǎng)絡(luò)并發(fā)展傀儡機(jī)群的行為。4)運(yùn)用數(shù)據(jù)庫進(jìn)行數(shù)據(jù)的存儲和CRDM相應(yīng)參數(shù)的設(shè)置，更易對網(wǎng)絡(luò)狀態(tài)數(shù)據(jù)進(jìn)行分析、處理和判斷，以及對本身系統(tǒng)的調(diào)整和設(shè)置。該方案不僅解決了傳統(tǒng)網(wǎng)絡(luò)關(guān)于惡意掃描攻擊難以防護(hù)或防護(hù)代價過高的問題，基于軟件定義網(wǎng)絡(luò)的集中式架構(gòu)以及REST API的特點(diǎn)，無須額外的硬件支持和額外的網(wǎng)絡(luò)開銷，僅需要軟件編程開發(fā)即可，使得程序的設(shè)計思路變得十分清晰，方便了開發(fā)人員的開發(fā)和測試。

1 CRDM方案設(shè)計

本文將實現(xiàn)一個在軟件定義網(wǎng)絡(luò)架構(gòu)下，基于OpenDayLight控制器的面向惡意掃描的控制層實時防護(hù)機(jī)制。而一個完整的攻擊防護(hù)過程的設(shè)計工作應(yīng)當(dāng)分為兩個部分進(jìn)行：1)檢測部分的設(shè)計。在這一部分當(dāng)中，設(shè)計者首先要分析所需要防護(hù)的攻擊具有的特征和特性，針對這些特征和特性提出一系列的檢測方案。本文當(dāng)中需要防護(hù)的攻擊為惡意掃描，而惡意掃描攻擊的特性即為掃描速度快、范圍廣，且具有的一大特征便是其發(fā)動攻擊的端口會在攻擊時間內(nèi)于控制器當(dāng)中產(chǎn)生大量的冗余流表。針對這一特征，需要對控制器當(dāng)中的所有流表都進(jìn)行實時的檢測，檢測這些流表當(dāng)中是否符合上述特征，以檢測是否存在端口正在進(jìn)行惡意掃描攻擊[12]。2)防護(hù)部分的設(shè)計。在完成了檢測部分的設(shè)計之后，程序?qū)λ雷o(hù)的攻擊具有了檢測能力，則需要對程序檢測出來的目標(biāo)采取必要的防護(hù)措施。在本文當(dāng)中，當(dāng)程序檢測出某一端口正在進(jìn)行惡意掃描的行為時，程序會根據(jù)檢測部分檢測到的正在攻擊端口的具體參數(shù)，自動通過控制器生成一條對該端口進(jìn)行禁用的流表規(guī)則，禁用該攻擊端口，以達(dá)到對整體網(wǎng)絡(luò)的防護(hù)效果[13]。

其實現(xiàn)思路如下：首先，通過OpenDayLight所提供的部分北向的REST API[14]，讀取控制器里的功能數(shù)據(jù)，如流表數(shù)據(jù)等。其次將這些流表數(shù)據(jù)存入MySQL數(shù)據(jù)庫后，再對這些流表數(shù)據(jù)進(jìn)行實時監(jiān)測，其中還需制定監(jiān)測機(jī)制，判定是否存在正在進(jìn)行惡意掃描的端口以及確定惡意端口號。如存在端口正在進(jìn)行惡意掃描，則通過對控制器編程的方式，自動進(jìn)行一些流表的操作，如添加一些流表，用以禁用惡意掃描端口。CRDM設(shè)計思路流程如圖1所示。

圖1 CRDM設(shè)計思路流程

基于CRDM的設(shè)計思路，可設(shè)計如圖2所示的程序結(jié)構(gòu)編程實現(xiàn)該方案。首先，實現(xiàn)連接控制器的信息初始化以及相應(yīng)API調(diào)用的模塊，該模塊向控制器和網(wǎng)絡(luò)發(fā)送相應(yīng)請求，控制器收到請求后，反饋相應(yīng)請求所需信息，如發(fā)送對流的統(tǒng)計請求，則控制器反饋所有流表。接收到控制器反饋的所有流表信息后，由于它是以可擴(kuò)展標(biāo)記語言(eXtensible Markup Language， XML)形式傳輸，需要編寫代碼在本地生成相應(yīng)的XML文件為之后流的關(guān)鍵信息的讀取提供基礎(chǔ)。在本地生成相應(yīng)的XML后，對該XML文件進(jìn)行解析，獲取關(guān)鍵的流數(shù)據(jù)后，存入數(shù)據(jù)庫中，方便之后的數(shù)據(jù)庫數(shù)據(jù)的檢測。之后制定相應(yīng)的惡意端口判別標(biāo)準(zhǔn)，對數(shù)據(jù)庫內(nèi)的各個流信息進(jìn)行檢測，一旦發(fā)現(xiàn)符合判定規(guī)則的惡意端口，將該端口的參數(shù)傳輸?shù)搅鞅砜刂埔?guī)則的生成模塊，其中參數(shù)包括：惡意端口號、惡意端口所在的節(jié)點(diǎn)ID以及對該惡意節(jié)點(diǎn)的處理方法等。生成含流處理操作的參數(shù)的XML后，回傳到連接控制器與相應(yīng)API的調(diào)用模塊，發(fā)送下發(fā)流表請求，如下發(fā)流表成功，則控制器將反饋“success”信息，程序結(jié)構(gòu)如圖2。

圖2 程序結(jié)構(gòu)

2 CRDM方案實現(xiàn)

2.1 連接控制器與REST API的調(diào)用

連接控制器與REST API的調(diào)用模塊用于與控制器連接，首先定義一個特定的統(tǒng)一資源定位符(Uniform Resource Locator， URL)字符串用于記錄所需要訪問的URL接口地址：

String baseURL="http://localhost:8080/controller/nb/v2/statistics"

再將其以所需調(diào)用的API所要求特定的形式，實例化一個java.net.URL：

url=new java.net.URL(baseURL+"/"+containerName+"/flow");

之后將登錄信息利用Base64.encodeBase64解碼成比特流，再調(diào)用Connection對象的實例化方法和其他的配置屬性方法，如設(shè)置文件的類型、請求的類型等參數(shù)：

URLConnection connection=url.openConnection();

//ODL的Web的ID驗證

connection.setRequestProperty("Content-Type",

"application/xml");

//設(shè)置文件類型

connection.setRequestProperty("Accept","application/xml");

connection.connect();

即可向控制器發(fā)送請求，請求其反饋當(dāng)前網(wǎng)絡(luò)當(dāng)中的所有流表信息。

2.2 XML解析

當(dāng)利用Connection成功連接上指定的URL接口之后，利用文件流的操作將Connection對象返回的數(shù)據(jù)存入本地的指定路徑XML文件中，重構(gòu)含有控制器所有流表信息的XML文檔：

DataInputStream in=new DataInputStream(connection.

getInputStream());

//實例化數(shù)據(jù)輸入流獲取connection返回的輸入流

DataOutputStream out=

new DataOutputStream(new FileOutputStream(fileName));

//實例化數(shù)據(jù)輸出流，將其輸出地址設(shè)置到工程根目錄下的

//fileName的文檔當(dāng)中

byte[] buffer=new byte[4096];

//緩沖區(qū)

int count=0;

//計數(shù)

while ((count=in.read(buffer))>0){

out.write(buffer,0,count);

//寫入

}

out.close();

in.close();

System.out.println("XMl本地文檔重構(gòu)成功");

對于在本地緩存下來的XML文件，利用多層循環(huán)不停地挖掘其每一子層的內(nèi)容，對每一層的子層的節(jié)點(diǎn)數(shù)進(jìn)行判定，一旦發(fā)現(xiàn)其不為零，則繼續(xù)往里一層挖掘，如判定該層的子節(jié)點(diǎn)數(shù)為零，則打印該層節(jié)點(diǎn)名以及該節(jié)點(diǎn)的內(nèi)容，其判斷流程如圖3所示。

解析出XML中所有數(shù)據(jù)后，針對需要的一些特定的數(shù)據(jù)進(jìn)行挑選，如輸入節(jié)點(diǎn)端口、流目的地址、流處理方式、流字節(jié)數(shù)、流包數(shù)、流持續(xù)時間、流優(yōu)先級。普通格式的數(shù)據(jù)通過節(jié)點(diǎn)名匹配的方式讀取。一些特定格式的內(nèi)容，則采用標(biāo)示符與及節(jié)點(diǎn)名稱進(jìn)行聯(lián)合判定的方法讀取。

圖3 讀取XML流程

2.3 MySQL數(shù)據(jù)庫存儲模塊設(shè)計

由惡意掃描的特性可知，其一大特征就是特定流表的數(shù)量會大幅增長，后期的惡意端口判定工作一定程度上是基于流表數(shù)量上的判定，所以在編寫設(shè)計存入MySQL數(shù)據(jù)庫相關(guān)模塊時，必須考慮以下幾個問題：1)如何向數(shù)據(jù)庫內(nèi)插入固定格式的流數(shù)據(jù);2)如何防止同一時刻產(chǎn)生的同一流表信息重復(fù)存入數(shù)據(jù)庫;3)如何防止不同時刻的同一流表信息重復(fù)存入數(shù)據(jù)庫;4)如何在數(shù)據(jù)庫中讀取指定數(shù)據(jù)為后期判別提供基礎(chǔ)。

前3個問題都會導(dǎo)致存入數(shù)據(jù)庫內(nèi)的各個端口的流表數(shù)量與實際控制器內(nèi)的各個端口的流表數(shù)量不符，如果不妥善解決，將會導(dǎo)致后期的判定無法進(jìn)行。為解決這幾個問題，本文的思路為：每次更新數(shù)據(jù)庫前，都會將數(shù)據(jù)庫指定表內(nèi)的所有數(shù)據(jù)清空，然后再對ODL控制器反饋的XML文件解析出來的內(nèi)容進(jìn)行全掃描，完整地獲取一次ODL的所有流表，不僅可以防止同一時刻流表信息以及不同時刻同一流表信息的重復(fù)存儲，且還能更新同一流表不同時刻下的一些參數(shù)變化，如傳輸比特數(shù)、傳輸包數(shù)、流存在持續(xù)時間等。用于流表記錄的表格結(jié)構(gòu)設(shè)計如表1所示。

表1 實驗中使用的記錄流表數(shù)據(jù)的表格結(jié)構(gòu)

2.4 惡意掃描端口判別

由前文描述可知，惡意掃描的一大特征便是同一輸入端口(惡意端口)的流表會突然大幅增長，并且為了達(dá)到攻擊效果，要求其流表增長必須十分迅速，所以這些流表中傳輸?shù)谋忍財?shù)和包數(shù)一般都十分少，持續(xù)時間也很短。利用惡意掃描的這些特征，可以制定相應(yīng)的惡意端口判別標(biāo)準(zhǔn)：當(dāng)某一端口存在的流表數(shù)量在控制器中最多，每條流表的傳輸比特數(shù)都小于一個預(yù)設(shè)的門限，并且為了防止誤判，要求當(dāng)這些流表中的傳輸比特數(shù)小于判決門限的數(shù)量且大于這些流表數(shù)量的1/2時，則會判定該端口正在進(jìn)行惡意掃描。當(dāng)然，使用這套判決標(biāo)準(zhǔn)必須有一個大前提，那就是比較的對象端口必須只能是底層節(jié)點(diǎn)連接主機(jī)的端口，不能有中間節(jié)點(diǎn)的端口，因為特定形式的拓?fù)?，如以一個節(jié)點(diǎn)作為中心點(diǎn)的放射型拓?fù)?，則流表數(shù)最多的必須是越靠近中心節(jié)點(diǎn)的端口，這樣就會使上述判定標(biāo)準(zhǔn)失效。

首先編寫一個類(結(jié)構(gòu)體)用以記錄所需要比較的節(jié)點(diǎn)號和相應(yīng)的節(jié)點(diǎn)端口：

class JudgeObj

{

String PortName=null;

int Number=0;

JudgeObj(String InPort){PortName=InPort;}

}

通過一個類數(shù)組的形式，將該數(shù)組當(dāng)中的各個節(jié)點(diǎn)號和節(jié)點(diǎn)端口作為參數(shù)，調(diào)用前文中提到的數(shù)據(jù)庫中的查詢類，該類將返還所查詢的節(jié)點(diǎn)的端口在數(shù)據(jù)庫中所含的流表數(shù)，再利用一個比較算法，比較出當(dāng)中最多流表的端口號。記錄該端口號和該端口號的流表數(shù)量，再次調(diào)用數(shù)據(jù)庫，查詢該端口號的流表中，傳輸比特數(shù)小于門限閾值的流表數(shù)量，一旦該數(shù)量大于該端口號的總流表數(shù)量的1/2，再判定該端口正在進(jìn)行惡意掃描。

通過惡意掃描端口判別模塊，程序即可檢測當(dāng)前網(wǎng)絡(luò)當(dāng)中，是否存在惡意掃描端口，如存在惡意掃描端口，則可以將其節(jié)點(diǎn)信息存到指定的字符串當(dāng)中，為之后的防護(hù)工作提供了數(shù)據(jù)基礎(chǔ)。以下是惡意掃描端口判別模塊的部分核心功能代碼：

for(l=0;l<8;l++){

obj[l].Number=test1.MySQLSearchTest(obj[l].PortName,1,DLDst,Action,ByteCount,PacketCount,DurationSeconds,Priority);

//雙功能——1表示返回其流表條數(shù)

//雙功能——2表示匹配查詢這些流表當(dāng)中小于所定閾值的

//流表數(shù)

}

MaxNumber=obj[0].Number;

NameofMax=obj[0].PortName;

//if(obj[0].Number>obj[1].Number)System.out.println("test");

for(l=0;l<8;l++){

//比較算法，取最大值

if(MaxNumber<=obj[l].Number){

MaxNumber=obj[l].Number;

NameofMax=obj[l].PortName;

RecordNum=l;

}

}

System.out.println("");

System.out.print("流表條數(shù)最多的是"+NameofMax);

System.out.println("條數(shù)為"+MaxNumber);

System.out.println("");

if(MaxNumber==0){}

else{

TestResult=test1.MySQLSearchTest(obj[RecordNum].

PortName,2,DLDst,Action,ByteCount,PacketCount,

DurationSeconds,Priority);

//調(diào)用功能2，掃描查找惡意流表

if(TestResult>=MaxNumber/2)System.out.println("經(jīng)檢測"+

NameofMax+"為惡意掃描端口");

}

2.5 含流表控制規(guī)則XML文檔的生成

通過2.4節(jié)所描述的模塊，程序通過相應(yīng)的檢測機(jī)制以及判別標(biāo)準(zhǔn)，已經(jīng)檢測并獲取了當(dāng)前正在進(jìn)行惡意掃描的端口號和端口ID，僅需要代碼生成一份與控制器要求的格式相同，并且含有本文所需的指定數(shù)據(jù)，即惡意端口號和對該端口號的處理方式的XML即可，通過這份XML可以向控制器提供惡意掃描端口信息和對其處理的規(guī)則。

2.6 控制器再連接

控制器再連接模塊的主要作用大體與2.1節(jié)的連接控制器的模塊相似，但其不同的地方在于：在該模塊中不再是簡單地使用HTTP的Get請求來向控制器請求流表信息，而是必須以HttpURLConnection作為操作對象，通過HTTP當(dāng)中的Post請求，結(jié)合文件流的讀取操作，將2.5節(jié)當(dāng)中生成的本地含有惡意掃描端口信息和對其處理規(guī)則的XML回傳到控制器的指定URL后，控制器生成相應(yīng)的處理流表，對XML提供惡意掃描端口進(jìn)行指定方式的處理。

3 CRDM系統(tǒng)測試

依據(jù)第2章的程序結(jié)構(gòu)設(shè)計和實現(xiàn)思路，搭建好開發(fā)所需的平臺和環(huán)境之后，在Windows 7平臺下進(jìn)行測試。通過Mininet虛擬網(wǎng)絡(luò)連入控制器[15]，并且在Mininet端利用某一端口ping其他的各個端口模擬在該網(wǎng)絡(luò)中惡意掃描其他主機(jī)，通過已設(shè)計好的判決機(jī)制對數(shù)據(jù)庫當(dāng)中的所有端口(已產(chǎn)生流量的端口)的流表進(jìn)行判決，測試該算法是否能夠正確地判定出模擬惡意掃描的端口，并且當(dāng)正確判定出惡意掃描端口后，測試程序是否能夠自動地對該端口進(jìn)行處理，以達(dá)到防護(hù)作用。虛擬網(wǎng)絡(luò)拓?fù)淙鐖D4所示。

圖4 虛擬網(wǎng)絡(luò)拓?fù)?/p>

在圖4所示網(wǎng)絡(luò)拓?fù)洚?dāng)中，將HOST8用于模擬惡意掃描的端口主機(jī)，用它去ping其他的相應(yīng)主機(jī)模擬惡意掃描，驗證文中所述的程序是否能夠達(dá)到防護(hù)該網(wǎng)絡(luò)的作用，效果如圖5所示。

從圖5中可以看到，當(dāng)HOST8再次ping其他的主機(jī)時，顯示的都為100% packet loss，說明HOST8端口已經(jīng)被成功禁用，程序成功將惡意掃描的端口主機(jī)在網(wǎng)絡(luò)當(dāng)中進(jìn)行了隔離，達(dá)到了對網(wǎng)絡(luò)的防護(hù)作用。

圖5 CRDM系統(tǒng)測試效果

CRDM系統(tǒng)功能測試完成之后，對CRDM系統(tǒng)在不同大小規(guī)模的網(wǎng)絡(luò)下進(jìn)行了測試，針對其誤報率和漏報率進(jìn)行了統(tǒng)計。網(wǎng)絡(luò)規(guī)模主要體現(xiàn)于網(wǎng)絡(luò)當(dāng)中的主機(jī)數(shù)量，而網(wǎng)絡(luò)當(dāng)中模擬惡意掃描攻擊的主機(jī)數(shù)量設(shè)定為當(dāng)前網(wǎng)絡(luò)當(dāng)中總主機(jī)數(shù)量的20%，在這樣的條件下對CRDM系統(tǒng)進(jìn)行測試，其誤報率變化和漏報率變化如圖6所示。

圖6 CRDM系統(tǒng)誤報率和漏報率

從圖6當(dāng)中可以看出，隨著網(wǎng)絡(luò)規(guī)模的增大，其誤報率和漏報率都呈現(xiàn)上升趨勢，因為當(dāng)網(wǎng)絡(luò)規(guī)模變得較為龐大時，網(wǎng)絡(luò)當(dāng)中的主機(jī)之間的數(shù)據(jù)交互就會變得更為復(fù)雜，這給本文的系統(tǒng)帶來了挑戰(zhàn)，讓系統(tǒng)更容易出現(xiàn)誤報和漏報的情況。從圖中可以看到，雖其趨勢是上升的，但是并未出現(xiàn)在某一個規(guī)模之后，系統(tǒng)的性能急速惡化的現(xiàn)象，而是維持在一個相對緩慢的速度曲折上升，說明CRDM系統(tǒng)性能具有一定穩(wěn)定性。

除了對CRDM系統(tǒng)進(jìn)行了不同網(wǎng)絡(luò)規(guī)模的性能測試，本文還將CRDM系統(tǒng)與以往常用的網(wǎng)絡(luò)的入侵檢測系統(tǒng)Snort、Watcher、PortSentry三套系統(tǒng)在同一網(wǎng)絡(luò)和模擬攻擊的環(huán)境，即主機(jī)臺數(shù)70臺、模擬攻擊數(shù)為14的網(wǎng)絡(luò)規(guī)模當(dāng)中進(jìn)行了性能的測試比較，結(jié)果如表2。

從表2中可以看出：在相同的模擬攻擊和網(wǎng)絡(luò)環(huán)境中，Snort、PortSentry和CRDM的漏報率都大體相同，在14%左右，而Watcher則表現(xiàn)較差，為21.4%；但在誤報率的比較上，CRDM的性能遠(yuǎn)比其他3種系統(tǒng)的性能要好得多，CRDM的誤報率為3.6%，而Snort的誤報率為19.2%，Watcher的誤報率為20.1%，PortSentry的誤報率為15.4%，Snort、Watcher、PortSentry的誤報率分別比CRDM的誤報率高出了15.6、16.5、11.8個百分點(diǎn)。

表2 CRDM與Snort、Watcher、PortSentry準(zhǔn)確度比較 %

4 結(jié)語

本文在分析基于軟件定義網(wǎng)絡(luò)的網(wǎng)絡(luò)層的防護(hù)技術(shù)的基礎(chǔ)上，結(jié)合了軟件定義網(wǎng)絡(luò)的集中式架構(gòu)以及OpenDayLight控制器提供的REST API的開發(fā)特點(diǎn)，提出了一種可在DDoS攻擊具有破壞性的行為還未開始前，就可預(yù)防該攻擊的思路，即在攻擊者惡意掃描網(wǎng)絡(luò)的時候就對其進(jìn)行阻止；并且根據(jù)該思路，設(shè)計和實現(xiàn)了一整套可用于實時監(jiān)測網(wǎng)絡(luò)底層節(jié)點(diǎn)端口的防御機(jī)制(CRDM)。為了驗證CRDM的性能，利用Mininet搭建了虛擬網(wǎng)絡(luò)，并且通過模擬對網(wǎng)絡(luò)的惡意掃描攻擊，在不同規(guī)模的網(wǎng)絡(luò)集群當(dāng)中進(jìn)行了大量的模擬攻擊實驗。實驗結(jié)果表明：當(dāng)網(wǎng)絡(luò)規(guī)模較小，并且模擬攻擊數(shù)較少時，CRDM一旦檢測到網(wǎng)絡(luò)當(dāng)中有端口正在進(jìn)行惡意掃描攻擊，可及時地禁用該端口，阻止攻擊者對網(wǎng)絡(luò)的惡意掃描攻擊以及發(fā)展傀儡機(jī)規(guī)模的行為，使得攻擊者無法對目標(biāo)進(jìn)行有效的DDoS攻擊，從而防止了損害的產(chǎn)生。而隨著網(wǎng)絡(luò)規(guī)模的擴(kuò)大以及攻擊數(shù)量的增加，CRDM的誤報率和漏報率也會相應(yīng)增加，但性能還是趨于穩(wěn)定，不會急速惡化，具有一定的穩(wěn)定性。除此之外，還將CRDM與傳統(tǒng)的入侵檢測系統(tǒng)Snort、Watcher、PortSentry進(jìn)行了性能比較，雖然在漏報率方面與其他三套系統(tǒng)大體持平，但在誤報率方面CRDM遠(yuǎn)低于它們，可見CRDM性能優(yōu)于其他三套系統(tǒng)。

雖然基于軟件定義網(wǎng)絡(luò)的集中式框架有諸多優(yōu)點(diǎn)，對開發(fā)網(wǎng)絡(luò)防護(hù)技術(shù)十分便利，但也有其不足之處：軟件定義網(wǎng)絡(luò)的集中式控制框架，使得控制器占據(jù)十分重要的地位，攻擊者會想盡一切攻擊手段去獲取控制器的控制權(quán)。一旦處于網(wǎng)絡(luò)頂層的中央控制器的漏洞被攻擊者掌握，并且利用該漏洞對控制器進(jìn)行攻擊，掌握了網(wǎng)絡(luò)當(dāng)中控制器的控制權(quán)，則會使得所有基于軟件定義網(wǎng)絡(luò)的網(wǎng)絡(luò)防護(hù)手段崩潰瓦解，導(dǎo)致網(wǎng)絡(luò)淪陷，其損失將遠(yuǎn)遠(yuǎn)超出傳統(tǒng)的網(wǎng)絡(luò)防護(hù)技術(shù)。所以在使用軟件定義網(wǎng)絡(luò)架構(gòu)進(jìn)行網(wǎng)絡(luò)防護(hù)手段的研究和開發(fā)時，控制器安全的保護(hù)就顯得尤為重要，也將是今后的一個研究重點(diǎn)。

References)

[1] 左青云,陳鳴,趙廣松,等.基于OpenFlow的SDN技術(shù)研究[J].軟件學(xué)報,2013,24(5):1078-1097.(ZUO Q Y, CHEN M, ZHAO G S, et al. Research on OpenFlow-based SDN technologies [J]. Journal of Software, 2013, 24(5): 1078-1097.)

[2] 姜紅德.新IT時代:下一代防火墻崛起[J].中國信息化,2016(12):84-86.(JIANG H D. The new IT era: the rise of the NGFW [J]. Information China, 2016(12): 84-86.)

[3] SCOTT-HAYWARD S, O’CALLAGHAN G, SEZER S. SDN security: a survey [C]// SDN4FNS’13: Proceedings of 2013 IEEE Software Defined Networks for Future Networks and Services. Piscataway, NJ: IEEE, 2013: 1-7.

[4] ALI S T, SIVARAMAN V, RADFORD A, et al. A survey of securing networks using software defined networking [J]. IEEE Transactions on Reliability, 2015, 64(3): 1086-1097.

[5] 郁峰.軟件定義網(wǎng)絡(luò)架構(gòu)下的安全問題綜述[J].現(xiàn)代計算機(jī)(專業(yè)版),2014(16):13-20.(YU F. Overview of security issues in SDN architecture [J]. Modern Computer, 2014(16): 13-20.)

[6] MATTA V, MAURO M D, LONGO M. DDoS attacks with randomized traffic innovation botnet identification challenges and strategies [J]. IEEE Transactions on Information Forensics & Security, 2017, 12(8): 1844-1859.

[7] SOMANI G, GAUR M S, SANGHI D, et al. Combating DDoS attacks in the cloud: requirements, trends, and future directions [J]. IEEE Cloud Computing, 2017, 4(1): 22-32.

[8] YAN Q, GONG Q, YU F R. Effective software-defined networking controller scheduling method to mitigate DDoS attacks [J]. Electronics Letters, 2017, 53(7): 469-471.

[9] AMBROSIN M, CONTI M, GASPARI F D, et al. LineSwitch: tackling control plane saturation attacks in software-defined networking [J]. IEEE/ACM Transactions on Networking, 2017, 25(2): 1206-1219.

[10] BURAGOHAIN C, MEDHI N. FlowTrApp: an SDN based architecture for DDoS attack detection and mitigation in data centers [C]// Proceedings of the 2016 International Conference on Signal Processing and Integrated Networks. Piscataway, NJ: IEEE, 2016: 519-524.

[11] 許名廣,劉亞萍,鄧文平.網(wǎng)絡(luò)控制器OpenDaylight的研究與分析[J].計算機(jī)科學(xué),2015,42(z1):249-252.(XU M G, LIU Y P, DENG W P. Research and analysis of OpenDaylight controller [J]. Computer Science, 2015, 42(z1): 249-252.)

[12] KHATTAK Z K, AWAIS M, IQBAL A. Performance evaluation of OpenDaylight SDN controller [C]// Proceedings of the 2014 IEEE International Conference on Parallel and Distributed Systems. Piscataway, NJ: IEEE, 2014: 671-676.

[13] YUAN B, ZOU D, YU S, et al. Defending against flow table overloading attack in software-defined networks [J]. IEEE Transactions on Services Computing, 1939, PP(99): 1-1.

[14] 閆魯生.OpenDayLight北向接口技術(shù)及其應(yīng)用[J].指揮信息系統(tǒng)與技術(shù),2015,6(5):74-78.(YAN L S. Implementation of northbound interface technology on OpenDayLight platform [J]. Command Information System and Technology, 2015, 6(5): 74-78.)

[15] 張俊.基于Mininet和OpenDayLight的SDN構(gòu)建[J].無線互聯(lián)科技,2015(18):5-7.(ZHANG J. Construction of software defined network based on the Mininet and OpenDayLight [J]. Wireless Internet Technology, 2015(18): 5-7.)

This work is partially supported by the National Basic Research Program (973 Program) of China (2013CB329100), the National High Technology Research and Development Program (863 Program) of China (2015AA016103).

WURuohao, born in 1993, M. S. candidate. His research interests include next generation Internet, software defined networking, network security.

DONGPing, born in 1979, Ph. D., associate professor. His research interests include next generation Internet, information network, network security.

ZHENGTao, born in 1983, Ph. D., lecturer. His research interests include next generation Internet, information network, network security.