基于OpenDayLight的惡意掃描防護技術

吳若豪，董 平，鄭 濤

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

0 引言

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

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

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

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

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

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

1 CRDM方案設計

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

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

圖1 CRDM設計思路流程

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

圖2 程序結構

2 CRDM方案實現

2.1 連接控制器與REST API的調用

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

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

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

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

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

URLConnection connection=url.openConnection();

//ODL的Web的ID驗證

connection.setRequestProperty("Content-Type",

"application/xml");

//設置文件類型

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

connection.connect();

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

2.2 XML解析

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

DataInputStream in=new DataInputStream(connection.

getInputStream());

//實例化數據輸入流獲取connection返回的輸入流

DataOutputStream out=

new DataOutputStream(new FileOutputStream(fileName));

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

//fileName的文檔當中

byte[] buffer=new byte[4096];

//緩沖區(qū)

int count=0;

//計數

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

out.write(buffer,0,count);

//寫入

}

out.close();

in.close();

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

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

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

圖3 讀取XML流程

2.3 MySQL數據庫存儲模塊設計

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

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

表1 實驗中使用的記錄流表數據的表格結構

2.4 惡意掃描端口判別

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

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

class JudgeObj

{

String PortName=null;

int Number=0;

JudgeObj(String InPort){PortName=InPort;}

}

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

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

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

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

//雙功能——1表示返回其流表條數

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

//流表數

}

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("流表條數最多的是"+NameofMax);

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

System.out.println("");

if(MaxNumber==0){}

else{

TestResult=test1.MySQLSearchTest(obj[RecordNum].

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

DurationSeconds,Priority);

//調用功能2，掃描查找惡意流表

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

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

}

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

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

2.6 控制器再連接

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

3 CRDM系統(tǒng)測試

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

圖4 虛擬網絡拓撲

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

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

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

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

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

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

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

從表2中可以看出：在相同的模擬攻擊和網絡環(huán)境中，Snort、PortSentry和CRDM的漏報率都大體相同，在14%左右，而Watcher則表現較差，為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 結語

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

雖然基于軟件定義網絡的集中式框架有諸多優(yōu)點，對開發(fā)網絡防護技術十分便利，但也有其不足之處：軟件定義網絡的集中式控制框架，使得控制器占據十分重要的地位，攻擊者會想盡一切攻擊手段去獲取控制器的控制權。一旦處于網絡頂層的中央控制器的漏洞被攻擊者掌握，并且利用該漏洞對控制器進行攻擊，掌握了網絡當中控制器的控制權，則會使得所有基于軟件定義網絡的網絡防護手段崩潰瓦解，導致網絡淪陷，其損失將遠遠超出傳統(tǒ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] 郁峰.軟件定義網絡架構下的安全問題綜述[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] 許名廣,劉亞萍,鄧文平.網絡控制器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].無線互聯科技,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.