王洋，湯光明，王碩，楚江

（1.信息工程大學(xué)，河南 鄭州 450001；2.中國西安衛(wèi)星測控中心，陜西 西安 710043）

0 引言

軟件定義網(wǎng)絡(luò)（SDN，software defined network）及其相關(guān)技術(shù)已經(jīng)成為未來網(wǎng)絡(luò)發(fā)展的重要方向之一[1-3]。然而，隨著軟件定義網(wǎng)絡(luò)的不斷發(fā)展和實(shí)踐應(yīng)用，SDN面臨諸多安全問題，極大地影響了其發(fā)展進(jìn)程[4]。事實(shí)上，由于SDN架構(gòu)的核心在于將網(wǎng)絡(luò)控制任務(wù)交給控制器處理，控制器自然而然成為整個網(wǎng)絡(luò)架構(gòu)的大腦，但這同時導(dǎo)致控制器成為網(wǎng)絡(luò)攻擊的焦點(diǎn)。特別地，攻擊者往往會發(fā)動針對控制器的分布式拒絕服務(wù)（DDoS，distributed denial-of-service）攻擊，從而使控制器資源耗盡，最終導(dǎo)致整個網(wǎng)絡(luò)癱瘓。因此，研究抵抗面向SDN的DDoS攻擊及檢測技術(shù)成為當(dāng)前SDN安全問題的研究熱點(diǎn)[5]。

分析現(xiàn)有研究可知，針對SDN的DDoS攻擊及檢測技術(shù)集中于數(shù)據(jù)層和控制層，其發(fā)動攻擊的原理在于利用OpenFlow協(xié)議中的漏洞，通過持續(xù)發(fā)送特定數(shù)據(jù)包使交換機(jī)流表溢出或控制器資源耗盡。具體地，在數(shù)據(jù)層，攻擊者通過增加僵尸節(jié)點(diǎn)個數(shù)等手段使交換機(jī)流表空間溢出而無法正常工作[6]。在控制層，攻擊者通過向控制器持續(xù)發(fā)送packet-in數(shù)據(jù)包，導(dǎo)致控制器資源耗盡而拒絕服務(wù)[7]。針對該類型的DDoS檢測方法可分為三類（基于規(guī)則的檢測方法、基于統(tǒng)計(jì)信息的檢測方法和基于機(jī)器學(xué)習(xí)的檢測方法）[8]，其本質(zhì)是對SDN中的流量進(jìn)行約束和測量。近年來，隨著深度學(xué)習(xí)技術(shù)的不斷發(fā)展，其相關(guān)技術(shù)廣泛應(yīng)用于DDoS攻擊檢測[9-12]。而針對該種類型的防御機(jī)制，主要依托于限速和遷移。Kandoi等[13]提出利用一種通過限制數(shù)據(jù)傳輸速率來緩解數(shù)據(jù)層或控制層DDoS攻擊的方法。喬思祎等[14]對OpenFlow交換機(jī)流表溢出問題的緩解機(jī)制進(jìn)行了深入研究，提出流表共享（FTS，flow table sharing）方法，完善了流表溢出處理機(jī)制。武澤慧等[15]提出基于OpenFlow交換機(jī)洗牌的DDoS攻擊動態(tài)防御方法，來緩解交換機(jī)遭遇的DDoS攻擊。

事實(shí)上，SDN控制層北向接口（NBI，northbound interface）的安全性同樣對SDN的正常運(yùn)行起關(guān)鍵作用。北向接口，作為控制層與應(yīng)用層的通道，隨著SDN應(yīng)用的廣泛普及，必然會受到越來越多攻擊者的關(guān)注。然而，針對北向接口的防御研究還比較少，主要集中在利用訪問控制來隔離攻擊者。Wen等[16]將控制器上的應(yīng)用程序和控制器內(nèi)核進(jìn)行隔離，提出一個應(yīng)用程序訪問權(quán)限管理系統(tǒng)，實(shí)現(xiàn)對應(yīng)用程序權(quán)限的細(xì)粒度訪問控制。與之類似的，還有Klaedtke等[17]的工作。然而，一些攻擊者會通過研究訪問控制規(guī)則，設(shè)計(jì)相應(yīng)的繞過機(jī)制，從而使該類型的防御機(jī)制失效。鑒于此，本文研究主要針對SDN應(yīng)用層DDoS攻擊的防御，結(jié)合北向接口發(fā)展特點(diǎn)[18-20]，提出一種基于應(yīng)用程序接口（API，application programming interface）惡意調(diào)用的SDN應(yīng)用層DDoS攻擊場景。進(jìn)一步地，為了防御該種類型攻擊，提出基于API調(diào)用管理的SDN應(yīng)用層DDoS防御機(jī)制，該機(jī)制通過在SDN應(yīng)用層和控制層之間增加一層App管理層，進(jìn)而通過對App的信譽(yù)管理、初始審查、映射分配、異常檢測和識別遷移，來抵抗惡意App對SDN的攻擊。

1 SDN架構(gòu)及應(yīng)用層DDoS攻擊場景

SDN架構(gòu)的核心思想是通過分離網(wǎng)絡(luò)控制與數(shù)據(jù)處理，賦予網(wǎng)絡(luò)可編程性，提高網(wǎng)絡(luò)的智能化與靈活性，最終提高網(wǎng)絡(luò)的整體運(yùn)行效率。當(dāng)前，SDN的經(jīng)典架構(gòu)分為應(yīng)用層、控制層和數(shù)據(jù)層。

應(yīng)用層主要指實(shí)現(xiàn)特定功能的SDN應(yīng)用程序。從當(dāng)前發(fā)展來看，SDN應(yīng)用程序大多是為了實(shí)現(xiàn)網(wǎng)絡(luò)的負(fù)載均衡、拓?fù)錁?gòu)建以及安全管理等功能?？刂茖幼鳛镾DN的核心，其主要依據(jù)SDN應(yīng)用需求，通過生成能夠用來控制細(xì)粒度網(wǎng)絡(luò)流量編排的流表，進(jìn)而實(shí)現(xiàn)對網(wǎng)絡(luò)的控制。數(shù)據(jù)層主要負(fù)責(zé)基于控制層下發(fā)流表的數(shù)據(jù)轉(zhuǎn)發(fā)。上述三層由兩個接口連接，北向接口用于連接應(yīng)用層與控制層，而南向接口（SBI，southbound interface）用于連接控制層與數(shù)據(jù)層。

事實(shí)上，OpenFlow已成為當(dāng)前南向接口的標(biāo)準(zhǔn)，針對南向接口的研究相對成熟，其安全性也得到很多學(xué)者的關(guān)注。然而，學(xué)者對北向接口的研究較少，目前還沒有形成得到廣泛認(rèn)可的標(biāo)準(zhǔn)，其安全威脅更令人擔(dān)憂。隨著SDN技術(shù)的不斷發(fā)展，其應(yīng)用必定會更加豐富多樣，而北向接口作為開放給用戶的端口，是用戶通過可編程來實(shí)現(xiàn)自定義功能的重要通道。依據(jù)當(dāng)前SDN技術(shù)的發(fā)展潮流，靈活性將是SDN技術(shù)的靈魂。因此，設(shè)計(jì)北向接口的關(guān)鍵在于接口的可編程性與調(diào)用管理的便捷性。表征狀態(tài)轉(zhuǎn)移（REST，representational state transfer）作為設(shè)計(jì)開放靈活接口的約束準(zhǔn)則，受到研究者的普遍關(guān)注。越來越多的學(xué)者傾向于利用REST架構(gòu)來定義SDN應(yīng)用所需的各種API，進(jìn)而使SDN應(yīng)用層的應(yīng)用程序能夠直接調(diào)用API來實(shí)現(xiàn)應(yīng)用程序的高效開發(fā)，最終推動SDN技術(shù)的快速普及?；谠摲N技術(shù)，SDN應(yīng)用層可事先實(shí)現(xiàn)安全狀態(tài)信息收集、鏈路流量信息收集、流量規(guī)則沖突分析、流規(guī)則超時回調(diào)、流規(guī)則修改、交換機(jī)配置信息獲取、控制器配置信息獲取、IP地址跳變等API，進(jìn)一步以這些API為接口提供給SDN應(yīng)用調(diào)用。軟件定義網(wǎng)絡(luò)中應(yīng)用層工作時API調(diào)用時間序列示例如圖1所示。

圖1 軟件定義網(wǎng)絡(luò)中應(yīng)用層工作時API調(diào)用時間序列示例 Figure 1 Example of API call time sequence when SDN application layer works

由以上分析可知，SDN北向接口的安全性直接關(guān)系到整個SDN正常運(yùn)行。當(dāng)前，針對SDN北向接口安全性的研究還比較少，缺乏嚴(yán)格的訪問控制、身份認(rèn)證及異常調(diào)用檢測等機(jī)制，這可能導(dǎo)致一些攻擊者故意開發(fā)惡意的應(yīng)用程序，造成北向接口API的濫用，以此實(shí)現(xiàn)對SDN的攻擊。鑒于此，本文研究主要針對SDN應(yīng)用層DDoS攻擊的防御。結(jié)合SDN網(wǎng)絡(luò)架構(gòu)，模擬兩種攻擊者利用惡意的API調(diào)用實(shí)現(xiàn)SDN應(yīng)用層的DDoS攻擊場景，如圖2所示。

圖2 軟件定義網(wǎng)絡(luò)中應(yīng)用層DDoS攻擊場景 Figure 2 DDoS attack scenario in SDN application layer

攻擊場景1：在該攻擊場景下，攻擊者設(shè)計(jì)惡意App，繞過北向接口的安全審查，對某些API進(jìn)行短時間大量調(diào)用，進(jìn)而導(dǎo)致控制器崩潰，使整個網(wǎng)絡(luò)癱瘓。

攻擊場景2：在該攻擊場景下，攻擊者以某個合法SDN應(yīng)用程序作為攻擊目標(biāo)，對該應(yīng)用程序所需用的特定API進(jìn)行短時間大量調(diào)用，使該合法App無法正常調(diào)用API，進(jìn)而使該合法App無法正常工作。與場景1相比，該種攻擊相對比較隱蔽。

2 API可信調(diào)用機(jī)制

由上文可知，為抵抗攻擊者利用惡意的API調(diào)用實(shí)現(xiàn)SDN應(yīng)用層的DDoS攻擊，對北向接口的安全管理成為防御的關(guān)鍵。鑒于此，本文提出一種基于API調(diào)用管理的SDN應(yīng)用層DDoS防御機(jī)制，該機(jī)制通過在SDN應(yīng)用層和控制層之間增加一層App管理層，進(jìn)而通過對App的信譽(yù)管理、初始審查、映射分配、異常檢測和識別遷移，來抵抗惡意App對SDN的攻擊，整個架構(gòu)如圖3所示。App管理層各個模塊之間的協(xié)同關(guān)系如圖4所示。

由圖3和圖4可知，為了實(shí)現(xiàn)對SDN北向接口的安全調(diào)用，提出的App管理層主要分為App運(yùn)行前的合法審查、App與控制器映射分配、App運(yùn)行時實(shí)時的異常檢測、非法App的識別遷移以及App信譽(yù)度評分5個主要模塊。其中，App運(yùn)行前的合法審查、App與控制器映射分配、App運(yùn)行時實(shí)時的異常檢測與惡意App的識別遷移是按App能夠正常運(yùn)行在SDN中的邏輯先后順序劃分的：只有通過合法審查的App才能運(yùn)行在SDN中；運(yùn)行之前，需要App與控制器映射分配，以實(shí)現(xiàn)運(yùn)行效率的最大化；運(yùn)行過程中，需要對其進(jìn)行實(shí)時的異常檢測；一旦發(fā)現(xiàn)異常，則需要惡意App的識別遷移，以保證網(wǎng)絡(luò)重新正常運(yùn)行。App信譽(yù)度評分則能夠?yàn)锳pp運(yùn)行前的合法審查以及App與控制器映射分配提供依據(jù)。

圖3 軟件定義網(wǎng)絡(luò)中應(yīng)用層DDoS防御架構(gòu) Figure 3 DDoS defense architecture of SDN application layer

圖4 App管理層各個模塊之間的協(xié)同關(guān)系 Figure 4 Synergy between modules of App management layer

（1）App運(yùn)行前的合法審查

對于SDN應(yīng)用層中的每一個App，在其運(yùn)行之前，均需要對其的API調(diào)用序列進(jìn)行合法性檢測，檢測結(jié)果判定為合法或不合法。經(jīng)判定不合法的App無法在應(yīng)用層運(yùn)行。

（2）App與控制器映射分配

隨著SDN的不斷發(fā)展，SDN應(yīng)用不斷豐富，單一的控制器網(wǎng)絡(luò)架構(gòu)往往無法滿足網(wǎng)絡(luò)實(shí)際需求，而多個控制器協(xié)同工作是SDN控制層發(fā)展的必然趨勢。在此情況下，SDN的應(yīng)用層存在App與控制器映射分配的問題，即通過將當(dāng)前網(wǎng)絡(luò)所有運(yùn)行的App合理分配給不同的控制器，實(shí)現(xiàn)控制器資源的最大化利用。

（3）App運(yùn)行時實(shí)時的異常檢測

盡管每一個App在SDN應(yīng)用層運(yùn)行之前均需進(jìn)行合法性審查，然而事實(shí)上，任何審查均存在一定的漏報(bào)率和誤報(bào)率。此外，由上文描述的攻擊場景2可知，一些攻擊者會精心設(shè)計(jì)惡意App，使它們能夠通過合法性審查而依然可對SDN實(shí)施攻擊。鑒于此，SDN需要實(shí)時對App運(yùn)行狀況進(jìn)行異常檢測。進(jìn)一步分析可知，SDN的應(yīng)用層DDoS攻擊最終均會導(dǎo)致控制器資源耗盡，從而使合法用戶無法正常調(diào)用API。因此，通過對控制器運(yùn)行狀態(tài)的監(jiān)視，能夠及時發(fā)現(xiàn)當(dāng)前SDN狀態(tài)的異常。

（4）惡意App的識別遷移

由合法審查和異常檢測模型可知，當(dāng)惡意App繞過審查而運(yùn)行在SDN應(yīng)用層時，最終會導(dǎo)致控制器運(yùn)行異常。本文僅考慮SDN應(yīng)用層的攻擊，即假定SND的控制層以及數(shù)據(jù)層不再遭遇其他類型的攻擊。由映射分配模塊可知，運(yùn)行在同一個控制器上的App可能有多個，當(dāng)該控制器異常時，反映出連接在該控制器上的App存在惡意App，則非法App的識別遷移模塊對這些App進(jìn)行識別，即判斷出哪些App是合法的而哪些App是惡意的，在此基礎(chǔ)上，進(jìn)一步暫停惡意App運(yùn)行而保證合法App的正常運(yùn)行。

（5）App信譽(yù)度評分

通過對上述模塊分析可知，增加App管理層的目的是對惡意App的識別封禁，以保證合法App在SDN應(yīng)用層的正常運(yùn)行。在此過程中，防御者可對所有App進(jìn)行統(tǒng)一的信譽(yù)度評分，對惡意App的來源進(jìn)行標(biāo)記，通過信譽(yù)度評分來提高對惡意App的檢測效率。

通過以上分析可知，App運(yùn)行時的異常檢測可通過對控制器運(yùn)行狀態(tài)的監(jiān)視來實(shí)現(xiàn)，而當(dāng)前針對SDN控制器異常檢測的研究很多，本文不做重點(diǎn)研究。此外，針對App信譽(yù)度評分的研究，可參考類似的信譽(yù)度評價相關(guān)模型[21-23]，與SDN特性關(guān)聯(lián)性不強(qiáng)。本文將App信譽(yù)度評分設(shè)定為0到10分，且將小于5分的App設(shè)為惡意App，在此基礎(chǔ)上，分別提出基于滑動時間窗口的API調(diào)用合法性審查、基于信譽(yù)度排序的SDN應(yīng)用映射分配和惡意App清洗分離，以此實(shí)現(xiàn)完整的App管理層模塊。針對多控制器之間的管理與通信研究較多[3,24]，這里不做深入探討。

需要注意的是，軟件定義網(wǎng)絡(luò)應(yīng)用層DDoS攻擊與軟件定義網(wǎng)絡(luò)中SDN控制器是否是分布式的沒有任何關(guān)系。即無論軟件定義網(wǎng)絡(luò)中SDN控制器是單個還是多個，攻擊者均可對其發(fā)動應(yīng)用層DDoS攻擊。而本文強(qiáng)調(diào)的多控制器的目的是防御該種DDoS攻擊的需要：當(dāng)軟件定義網(wǎng)絡(luò)中的控制器僅有一個時，一旦攻擊者對其發(fā)動應(yīng)用層DDoS攻擊，整個網(wǎng)絡(luò)便會癱瘓；而當(dāng)軟件定義網(wǎng)絡(luò)中的控制器有多個時，防御者可通過對惡意App清洗分離來保證整個網(wǎng)絡(luò)的正常運(yùn)行。

2.1 基于滑動時間窗口的API調(diào)用合法性審查

由上文可知，SDN應(yīng)用通過北向接口調(diào)用豐富的API以實(shí)現(xiàn)不同特定的功能。而針對SDN應(yīng)用層的DDoS攻擊，往往會開發(fā)惡意的App，進(jìn)而對某些API進(jìn)行短時間大量調(diào)用，以此耗盡控制器資源，使整個網(wǎng)絡(luò)崩潰。通過深入分析攻擊過程可知，為了避免API被惡意調(diào)用而導(dǎo)致SDN的崩潰，需要使所有App在調(diào)用API時滿足以下兩個約束條件。

（1）同一個API之間的調(diào)用周期約束Tapix≥不妨假設(shè)北向接口中共有n個可供調(diào)用的API，API={api1,api2,api3,…,apin}。為了使SDN正常運(yùn)行，每個API設(shè)定一個最小調(diào)用周期限制，以保證應(yīng)用的正常運(yùn)行，即apix的最小調(diào)用周期為，如對于“IP地址跳變”API來說，當(dāng)過于頻繁調(diào)用該API時，SDN中的節(jié)點(diǎn)地址跳變過于頻繁，不能保證正常業(yè)務(wù)的運(yùn)行。

（2）不同API之間的調(diào)用資源約束R(T)≤Rmax(T)

在SDN中，由于控制器的高度集中性，特別對于單控制器SDN，控制器具有一定的資源上限，若時間間隔T內(nèi)，調(diào)用的API所需資源高于控制器資源上限，則控制器將無法正常運(yùn)行，即R(T)≥Rmax(T)。不妨對每個API調(diào)用時所需資源進(jìn)行量化，設(shè)調(diào)用apix時所需資源為。進(jìn)一步假設(shè)SDN正常運(yùn)行時，某一T時間內(nèi)調(diào)用的API序列為API(T)={api1,api2,api3,…,apim}，則易知

以上兩個約束條件從API本身特性及其對資源需求角度對其正常調(diào)用進(jìn)行了規(guī)定。顯然，符合兩個約束條件的App為合法App，不符合的則為惡意App。

進(jìn)一步，本文以上述兩個約束條件為依據(jù)，提出了基于滑動時間窗口的API調(diào)用合法性審查算法，如算法1所示。

算法1基于滑動時間窗口的API調(diào)用合法性審查算法

輸入某個Appm的API調(diào)用時間序列，各個API的最小調(diào)用周期，控制器調(diào)用資源約束Rmax(T)

輸出 Result=Yes or No—Appm是否合法

2.2 基于信譽(yù)度排序的SDN應(yīng)用映射分配

為滿足日益增長的SDN應(yīng)用層需要，SDN控制平面往往會采取多個控制器協(xié)同工作的方式，且多個控制器實(shí)現(xiàn)負(fù)載均衡[25-26]。在此情況下，需要將所有SDN應(yīng)用映射分配到不同的控制器，使整個SDN負(fù)載均衡，最終實(shí)現(xiàn)網(wǎng)絡(luò)資源利用的最優(yōu)化，SDN應(yīng)用映射分配示例如圖5所示。

由圖5可知，同一個控制器上往往分配有多個App，顯然，這些App同時運(yùn)行時需要滿足算法1的兩個約束條件，才能保證控制器的正常運(yùn)行。事實(shí)上，對App的合法性審查本質(zhì)上是對其調(diào)用的API時間序列進(jìn)行審查。由圖1可知，將多個App的API調(diào)用時間序列進(jìn)行合并，并依據(jù)API調(diào)用時間由小到大排列，可形成多個App共同運(yùn)行時的API調(diào)用時間序列。由此可知，利用算法1能夠?qū)崿F(xiàn)對多個App能否共同運(yùn)行做出判斷。此外，為了使整個控制平面實(shí)現(xiàn)負(fù)載均衡，從資源利用的角度，各個控制器映射分配過程需要考慮控制器負(fù)載。鑒于此，本文提出基于信譽(yù)度排序的SDN應(yīng)用層映射分配算法。

圖5 SDN應(yīng)用映射分配示例 Figure 5 Example of SDN application mapping allocation

算法2基于信譽(yù)度排序的SDN應(yīng)用層映射分配算法

輸入目前待映射分配的SDN應(yīng)用集合APP={app1,app2,app3,… ,appm}，控 制 器 集 合C= {c1, c2,c3,…, cn}，控制器調(diào)用資源約束Rmax(T)。

輸出SDN應(yīng)用集合與控制器集合間的映射分配關(guān)系A(chǔ)pp →C

1) 將待映射分配的SDN應(yīng)用集合中的app按信譽(yù)度排序

2) for每一個appl∈ APP //令Seq(appl)表示應(yīng)用appl的API調(diào)用時間序列

3) for每一個ci∈C//假定將appl映射分配至控制器ci，此時控制器ci運(yùn)行的app集合記為 ci(app)，則其 API調(diào)用時間序列記為 Seq(ci)

在算法2中，整個SDN中的負(fù)載均衡用diff表示，其可從兩個方面進(jìn)行量化：一是同一個控制器中運(yùn)行的App構(gòu)成的API序列調(diào)用相對平滑；二是不同控制器間資源利用相對均衡。具體量化方法如下。

（1）設(shè)Rk為時間序列，用于表示控制器在不同時間間隔T所占用的資源，用 diff1(Rk)來量化該時間序列的平穩(wěn)度，其值越小，說明控制器運(yùn)行越平穩(wěn)，負(fù)載均衡越好。通過實(shí)際SDN運(yùn)行分析可知， diff1(Rk)的確定方法如下。

（2）用 diff2(C)表示不同控制器中負(fù)載均衡程度。為簡單起見，本文采用不同控制器的時間序列Rk中的元素均值之間方差來進(jìn)行量 化，即

（3）依據(jù)不同SDN實(shí)際需求，分別為上述兩個要素設(shè)定不同的權(quán)重，進(jìn)而利用權(quán)重和得到diff。

其中，α和β分別為上述兩要素的權(quán)重，滿足α+β=1。

2.3 惡意App清洗分離

當(dāng)一個SDN控制器上運(yùn)行有惡意App時，該SDN控制器由于資源耗盡而無法正常服務(wù)，該SDN控制器被稱為受攻擊控制器。在該種情況下，由于該控制器上運(yùn)行著多個App，防御者無法分辨哪些App是惡意的，哪些App是合法的。鑒于此，如何對受攻擊控制器上運(yùn)行的App進(jìn)行快速清洗以分離出惡意App，并進(jìn)一步對合法App重新分配控制器以保證其正常運(yùn)行，是一個值得研究的問題。SDN應(yīng)用層惡意App清洗分離過程示例如圖6所示。

圖6 SDN應(yīng)用層惡意App清洗分離過程示例 Figure 6 Example of cleaning and separating malicious App in SDN application layer

圖6中共有9個SDN應(yīng)用，其中包含兩個惡意的App，即app5和app7，控制平面有3個控制器。經(jīng)過初始的映射分配，app1、app2和app3分配到控制器c1，app4、app5和app6分配到控制器c2，app7、app8和app9分配到控制器c3。當(dāng)SDN運(yùn)行時，由于惡意App的存在，控制器c2和c3無法正常工作。而防御者無法識別連接到這兩個App上的應(yīng)用程序哪些是合法的，哪些是惡意的，如圖6(a)所示。在此情況下，防御者實(shí)施惡意App清洗分離過程，如圖6(b)所示，隨機(jī)將app5分配到控制器c3，而將app8分配到控制器c2。在此情況下，控制器c2將恢復(fù)正常運(yùn)行，而控制器c3將依然無法正常運(yùn)行。由此可知，在SDN遭遇攻擊時，惡意App清洗分離能有效分離出合法App和惡意App。為了最大化清洗分離效率，本文對此過程進(jìn)行如下建模。

設(shè)需要清洗分離的App集合為A，可供清洗分離的SDN控制器集合為C，控制器編號為1到|C|，其中|C|為控制器數(shù)量。每一輪的清洗分離可看作一個映射f。對于任一個控制器ci∈C，分配給該控制器的App集合記為Ai=f(ci)，顯然Ai∈A。由于每一個App只能分配給一個控制器，則

進(jìn)一步，設(shè)惡意App數(shù)量為Nv，設(shè)經(jīng)過一輪清洗分離操作后，仍有Na個合法的App無法正常運(yùn)行（被攻擊），而有Nu個合法App可以正常運(yùn)行，顯然，|A|=Na+Nu+Nv，其中|A|為所有待分配App數(shù)量。本文的目標(biāo)是設(shè)計(jì)最優(yōu)的清洗分離方法f，以使在各種條件下Nu的E(Nu)期望最大。如前文所述，對于任一個控制器ci∈C，分配給該控制器的App集合記為Ai=f(ci)，進(jìn)一步，不妨設(shè)。由于只有當(dāng)一個控制器上分配的所有App均為合法App時，該控制器才能正常工作。相反，只要一個控制器上分配有一個惡意App，該控制器便無法正常工作，則控制器ci能正常工作的概率記為

經(jīng)過Ai=f(ci)操作后，能夠分離出來的合法App數(shù)量的期望為pi?|Ai|。進(jìn)一步，易知

由于控制器資源的限制，當(dāng)將App集合Ai分配給該控制器ci時，存在即使所有Ai中的App均為合法App而控制器也無法正常工作的情況，即控制器ci無法滿足App集合Ai中所有App同時正常運(yùn)行。鑒于此，在清洗分離過程中，需要保證分配給控制器的App集合不能超出該控制器的資源限制。該條件可由算法1來判斷，即可表示為

綜上所述可知，對惡意App清洗分離問題可視為一個最優(yōu)化問題，其目標(biāo)函數(shù)為方程(8)，變量為分配方案f，約束條件為式(9)。直觀上，可供清洗分離的SDN控制器數(shù)量越多，則經(jīng)過每一輪清洗分離后合法App被分離出來的數(shù)量越多。若|C|≥|A|，則每一個App都能被分配到一個專有的 SDN 控制器上，在該種情況下，E(Nu)=|A| ?Nv，它意味著所有合法的App均能正常運(yùn)行，而所有惡意的App均被一輪清洗分離而分離出來。然而，在實(shí)際的SDN中，控制器的數(shù)量一般較少，甚至是一個控制器的情況，而App的個數(shù)一般遠(yuǎn)遠(yuǎn)多于控制器的個數(shù)?？紤]到此，如何設(shè)計(jì)清洗分離算法使盡快識別出惡意App是十分重要的。對于|C|≥1時，目標(biāo)函數(shù)是非線性的，且該類問題是NP難問題。對于該問題，本文利用貪心思想計(jì)算得出該方案的接近最優(yōu)解，其具有多項(xiàng)式時間。該惡意App清洗分離算法如下。

算法3惡意App清洗分離算法

輸入目前待清洗分離的SDN應(yīng)用集合A，可用的控制器集合C

輸出各個控制器上分配的SDN應(yīng)用集合，用f表示，即f(ci)表示控制器上分配的App集合

1) 將待映射分配的SDN應(yīng)用集合A中的所有app按信譽(yù)度排序形成Applist

2) if length(AppList)≤|C|

3) 為每一個App分配一個控制器

4) else

5) fori=1:|C|do //|C|表示集合C中的元素總個數(shù)

6)f(ci)=Appassign(ci, Applist)

7) AppList=AppListf(ci)//將當(dāng)前已分配完成的App從列表中刪除

8) end

1) Function Appassign(ControlID, AppList)//ControlID表示需要分配App的控制器，AppList表示當(dāng)前所有待清洗分離的App列表，該列表以App信譽(yù)度評分從高到低排列

由此，可依據(jù)每一輪分配后的控制器能否正常工作，來清洗分離出惡意App。經(jīng)過多輪的清洗分離操作，最終將會使所有惡意App均被分離識別。

此外，SDN中的惡意App數(shù)量越多，越要保證清洗分離盡快完成，則需要越多可供分配的控制器。因此，清洗之前，對SDN中的惡意App數(shù)量進(jìn)行評估，能夠?yàn)樵O(shè)定合適的控制器數(shù)量提供依據(jù)。需要注意的是，若一個控制器上所有的App均為合法App，則該控制器正常運(yùn)行，不參加惡意App的清理分離任務(wù)；若一個控制器上至少存在一個惡意App，則該控制器上的其他合法App也無法正常工作，而通過不斷的清洗分離，這些合法的App將被分配至其他的控制器，最終得以正常工作。由此可見，惡意App清洗分離過程可能會導(dǎo)致無法正常工作的合法App頻繁切換控制器，但不會對本身正常運(yùn)行的合法App造成影響。

不妨設(shè)appl的信譽(yù)度評分為 creditappl，則一個App為惡意的概率可記為

一個App為正常的概率為

于是

進(jìn)一步，利用最大似然估計(jì)原理，可得

其中，X*表示控制器ci上惡意App數(shù)量的估計(jì)值。

3 實(shí)驗(yàn)與驗(yàn)證

針對SDN應(yīng)用層的研究比較少，基于REST API調(diào)用的SDN應(yīng)用較缺乏。本文借鑒已被學(xué)者認(rèn)可的大規(guī)模網(wǎng)絡(luò)端地址跳變實(shí)現(xiàn)機(jī)理[27]，通過仿真實(shí)現(xiàn)了一個使目標(biāo)SDN所有終端地址跳變的API。具體地，借助Mininet創(chuàng)建SDN拓?fù)?，RYU作為控制器，如圖7所示。

圖7 實(shí)驗(yàn)網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu) Figure 7 Topology of experimental network

圖7所示實(shí)驗(yàn)網(wǎng)絡(luò)中的終端數(shù)量可動態(tài)調(diào)整，正常情況下，各終端之間能夠維持通信，從而保證正常的業(yè)務(wù)活動。當(dāng)SDN應(yīng)用程序調(diào)用跳變API時，該網(wǎng)絡(luò)中所有終端的IP地址會發(fā)生跳變，而后該SDN仍能正常工作。然而事實(shí)上，若攻擊者制作一個惡意App，該App短時間大量調(diào)用跳變API，顯然會造成網(wǎng)絡(luò)崩潰，這種情況相當(dāng)于攻擊者從SDN應(yīng)用層發(fā)起了DDoS攻擊。本文實(shí)驗(yàn)部分所配置的控制器個數(shù)是動態(tài)變化的，而圖7為了便于畫圖需要，又為體現(xiàn)多個物理控制器的邏輯集中，故用一個控制器代替。為了進(jìn)一步驗(yàn)證SDN應(yīng)用層攻擊會為網(wǎng)絡(luò)正常運(yùn)行造成影響，首先對網(wǎng)絡(luò)正常運(yùn)行的條件進(jìn)行定量表示：模擬SDN業(yè)務(wù)需求，設(shè)定兩臺主機(jī)維持運(yùn)行服務(wù)4 h，每隔10 min服務(wù)一次，每次服務(wù)需要維持一定的服務(wù)時間（ST，service time）。若網(wǎng)絡(luò)達(dá)到該要求，即可認(rèn)為網(wǎng)絡(luò)正常運(yùn)行。進(jìn)一步，通過仿真得到，不同條件下SDN服務(wù)正常運(yùn)行率與跳變API調(diào)用頻率(次數(shù)/小時)之間的關(guān)系如圖8所示。

圖8 不同條件下SDN服務(wù)正常運(yùn)行率與 跳變API調(diào)用頻率之間的關(guān)系 Figure 8 Relationship between normal operation rate of SDN service and call frequency of hopping API under different conditions

由圖8可知，對于不同的服務(wù)時間要求，SDN服務(wù)正常運(yùn)行率均隨跳變API調(diào)用頻率的增大而減小，且當(dāng)跳變API調(diào)用頻率達(dá)到一定值后，SDN服務(wù)正常運(yùn)行率會變得很小，即不能正常工作。由此可見，當(dāng)SDN應(yīng)用通過短時間內(nèi)高頻率的調(diào)用API能夠使SDN運(yùn)行的正常服務(wù)癱瘓，即造成SDN應(yīng)用層DDoS攻擊。由此，可通過對具體的SDN進(jìn)行實(shí)際運(yùn)行測試，以此來準(zhǔn)確設(shè)定參數(shù)和Rmax(T)的值。

通過對現(xiàn)有文獻(xiàn)進(jìn)行分析，針對SDN北向接口安全性的研究比較少，Oktian等[28]提出了一種針對SDN北向接口API身份認(rèn)證的方法。但其存在兩方面缺陷：一是認(rèn)證方法僅是理論上的且設(shè)計(jì)相對簡單，實(shí)際的應(yīng)用效果并不明確；二是對于前文提出的攻擊場景2中攻擊方法無效，一些攻擊者會采用分布式的攻擊方法，通過構(gòu)造多個看似合法的App（每個App都能通過身份認(rèn)證），并利用這些App同時調(diào)用同一個API，以實(shí)現(xiàn)對SDN應(yīng)用層的攻擊。事實(shí)上，本文提出的基于API調(diào)用管理的SDN應(yīng)用層DDoS攻擊防御機(jī)制，側(cè)重于在攻擊發(fā)生前對惡意App進(jìn)行事先審查，以避免攻擊的發(fā)生。其次，若攻擊發(fā)生，需要對合法App和惡意App進(jìn)行快速清洗分離。本文算法對上文提出的兩個攻擊場景均有較好的防御效果。此外，算法的運(yùn)行效率是驗(yàn)證該防御機(jī)制有效性的關(guān)鍵。鑒于此，對上一節(jié)所示3個算法運(yùn)行效率進(jìn)行了仿真測試。API序列長度對API調(diào)用合法性檢查所用時間的影響如圖9所示。

圖9 API序列長度對API調(diào)用合法性檢查所用時間的影響 Figure 9 The influence of API sequence length on the time for checking the validity of API calls

在本文實(shí)驗(yàn)中，App序列長度指的是SDN應(yīng)用程序所調(diào)用的API數(shù)量，如某一App的調(diào)用API序列為API={api1,api2,api3,…,apim}，則稱該App序列長度為m，即App序列長度可認(rèn)為是該App調(diào)用的API序列長度。顯然，App序列長度對算法運(yùn)行效率有較大的影響。由圖9實(shí)驗(yàn)結(jié)果知，當(dāng)API序列長度小于600時，API調(diào)用合法性檢查算法所需時間在100 s以內(nèi)。事實(shí)上，該審查算法一般在App運(yùn)行之前進(jìn)行，對實(shí)時性要求不高；其次，通過分析已有的SDN應(yīng)用，其API調(diào)用長度一般在100以內(nèi)。綜上可知，本文所提算法能夠滿足實(shí)用要求。

進(jìn)一步，當(dāng)設(shè)定App數(shù)量為100、SDN控制器數(shù)量為4時，API序列長度對映射分配所用時間的影響如圖10所示；當(dāng)設(shè)定App數(shù)量為100、App序列長度為10時，SDN控制器個數(shù)對映射分配所用時間的影響如圖11所示；當(dāng)設(shè)定App序列長度10、SDN控制器數(shù)量為4時，App個數(shù)對映射分配所用時間的影響如圖12所示。

圖10 API序列長度對映射分配所用時間的影響 Figure 10 Influence of API sequence length on mapping allocation time

圖11 SDN控制器個數(shù)對映射分配所用時間的影響 Figure 11 Influence of SDN controller number on mapping allocation time

圖12 App個數(shù)對映射分配所用時間的影響 Figure 12 Influence of the number of Apps on the time of mapping and allocation

圖10～圖12中所示的API序列長度指的是所有App序列長度均保持一致。由圖10可知，當(dāng)API序列長度維持在300以內(nèi)時，映射分配所用時間維持在1 000 s以內(nèi)，而當(dāng)API序列長度繼續(xù)增長時，映射分配所用時間呈指數(shù)增加；由圖11可知，當(dāng)API序列長度、App數(shù)量一定時，映射分配所用時間隨SDN控制器數(shù)量近似呈線性增加；同樣地，由圖12可知，當(dāng)API序列長度、SDN控制器數(shù)量一定時，映射分配所用時間隨App數(shù)量近似呈線性增加。由上述3個圖可知，App序列長度對映射分配所用時間的影響最大。事實(shí)上，對于SDN來說，正常運(yùn)行時，App數(shù)量一般不會超過200，API序列長度不會超過100。在該種情況下，無論SDN控制器數(shù)量多少，映射分配所用時間均在可接受時間內(nèi)，能夠滿足實(shí)際網(wǎng)絡(luò)需求。

最后，本文對惡意App清洗分離算法進(jìn)行了仿真測試，設(shè)定正常App數(shù)量為100，惡意App數(shù)量為10，App序列長度為10，則得出SDN控制器個數(shù)對清洗分離次數(shù)的影響如圖13所示，SDN控制器個數(shù)對清洗分離所需時間的影響如圖14所示。

圖13 SDN控制器個數(shù)對清洗分離次數(shù)的影響 Figure 13 Influence of the number of SDN controllers on cleaning and separation times

由圖13和圖14可知，當(dāng)SDN中正常App數(shù)量、惡意App數(shù)量以及App序列長度一定時，清洗分離次數(shù)以及清洗分離所需時間均隨SDN控制器個數(shù)的增加而降低，且清洗分離所需時間低于1 000 s。由此可知，在SDN中，通過部署多個SDN控制器，能夠加快清洗分離所需時間，降低DDoS攻擊對目標(biāo)網(wǎng)絡(luò)的影響。

圖14 SDN控制器個數(shù)對清洗分離所需時間的影響 Figure 14 Influence of the number of SDN controllers on the time required for cleaning and separation

4 結(jié)束語

針對DDoS攻擊對北向接口造成的威脅日益擴(kuò)大的問題，本文模擬了對其可能的DDoS攻擊樣態(tài)，并據(jù)此建立了基于API調(diào)用管理的SDN應(yīng)用層DDoS防御機(jī)制。該機(jī)制通過在SDN應(yīng)用層和控制層之間增加一層App管理層，進(jìn)而通過對App的信譽(yù)管理、初始審查、映射分配、異常檢測和識別遷移，來抵抗惡意App對SDN的攻擊。實(shí)驗(yàn)結(jié)果表明，本文提出的安全防御方案能夠有效地對SDN應(yīng)用層的DDoS攻擊進(jìn)行防御。