吳若豪，董 平，鄭 濤

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

0 引言

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

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

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

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

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

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

1 CRDM方案設計

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

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

圖1 CRDM設計思路流程

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

圖2 程序結構

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ù)：

URLConnection connection=url.openConnection();

//ODL的Web的ID驗證

connection.setRequestProperty("Content-Type",

"application/xml");

//設置文件類型

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

connection.connect();

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

2.2 XML解析

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

DataInputStream in=new DataInputStream(connection.

getInputStream());

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

DataOutputStream out=

new DataOutputStream(new FileOutputStream(fileName));

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

//fileName的文檔當中

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本地文檔重構成功");

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

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

圖3 讀取XML流程

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

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

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

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

2.4 惡意掃描端口判別

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

首先編寫一個類(結構體)用以記錄所需要比較的節(jié)點號和相應的節(jié)點端口：

class JudgeObj

{

String PortName=null;

int Number=0;

JudgeObj(String InPort){PortName=InPort;}

}

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

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

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

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

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

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

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

2.6 控制器再連接

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

3 CRDM系統(tǒng)測試

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

圖4 虛擬網(wǎng)絡拓撲

在圖4所示網(wǎng)絡拓撲當中，將HOST8用于模擬惡意掃描的端口主機，用它去ping其他的相應主機模擬惡意掃描，驗證文中所述的程序是否能夠達到防護該網(wǎng)絡的作用，效果如圖5所示。

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

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

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

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

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

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

從表2中可以看出：在相同的模擬攻擊和網(wǎng)絡環(huán)境中，Snort、PortSentry和CRDM的漏報率都大體相同，在14%左右，而Watcher則表現(xiàn)較差，為21.4%；但在誤報率的比較上，CRDM的性能遠比其他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個百分點。

表2 CRDM與Snort、Watcher、PortSentry準確度比較 %

4 結語

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

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

References)

[1] 左青云,陳鳴,趙廣松,等.基于OpenFlow的SDN技術研究[J].軟件學報,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)絡架構下的安全問題綜述[J].現(xiàn)代計算機(專業(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)絡控制器OpenDaylight的研究與分析[J].計算機科學,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北向接口技術及其應用[J].指揮信息系統(tǒng)與技術,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構建[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.