王禛鵬 扈紅超 程國振
(國家數(shù)字交換系統(tǒng)工程技術(shù)研究中心 鄭州 450003) (whuwzp@whu.edu.cn)
2017-06-11;
2017-08-01
國家自然科學(xué)基金項目(61309020,61602509);國家自然科學(xué)基金創(chuàng)新群體項目(61521003);國家重點研發(fā)計劃項目(2016YFB0800100,2016YFB0800101);河南省科技攻關(guān)項目(172102210615,172102210441) This work was supported by the National Natural Science Foundation of China (61309020, 61602509), the Foundation for Innovative Research Groups of the National Natural Science Foundation of China (61521003), the National Key Research and Development Program of China (2016YFB0800100, 2016YFB0800101), and the Key Technologies Research and Development Program of Henan Province of China (172102210615, 172102210441).
扈紅超(13633833568@139.com)
MNOS:擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)設(shè)計與實現(xiàn)
王禛鵬 扈紅超 程國振
(國家數(shù)字交換系統(tǒng)工程技術(shù)研究中心 鄭州 450003) (whuwzp@whu.edu.cn)
控制層的漏洞利用攻擊,如惡意APP、流表篡改等是軟件定義網(wǎng)絡(luò)(software defined networking, SDN)面臨的主要威脅之一,而傳統(tǒng)基于漏洞修復(fù)技術(shù)的防御策略無法應(yīng)對未知漏洞或后門.提出一種基于擬態(tài)防御思想的網(wǎng)絡(luò)操作系統(tǒng)安全架構(gòu)——擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)(mimic network operating system, MNOS)——保障SDN控制層安全.該架構(gòu)采用異構(gòu)冗余的網(wǎng)絡(luò)操作系統(tǒng)(network operating system, NOS),并在傳統(tǒng)的SDN數(shù)據(jù)層和控制層間增設(shè)了擬態(tài)層,實現(xiàn)動態(tài)調(diào)度功能.首先擬態(tài)層動態(tài)選取若干NOS作為激活態(tài)并行提供服務(wù),然后根據(jù)各NOS的處理結(jié)果決定最終的有效響應(yīng)返回底層交換機.實驗評估表明:在增加有限的時延開銷下,MNOS可以有效降低SDN控制層被成功攻擊的概率,并具備良好的容錯容侵能力;在此基礎(chǔ)上,提出的選調(diào)策略和判決機制,可以有效提升系統(tǒng)的異構(gòu)度和判決的準(zhǔn)確性,進一步提升安全性能.
軟件定義網(wǎng)絡(luò);主動防御;擬態(tài)安全防御;動態(tài)異構(gòu)冗余;網(wǎng)絡(luò)操作系統(tǒng)
軟件定義網(wǎng)絡(luò)(software defined networking, SDN)將傳統(tǒng)數(shù)據(jù)平面和控制平面解耦,在邏輯上實現(xiàn)了網(wǎng)絡(luò)的集中控制,使得網(wǎng)絡(luò)配置、網(wǎng)絡(luò)服務(wù)部署等都在網(wǎng)絡(luò)操作系統(tǒng)(network operating system, NOS, 也稱SDN控制器)之上實現(xiàn),有利于簡化網(wǎng)絡(luò)管理.然而,SDN應(yīng)用實際生產(chǎn)環(huán)境時仍面臨嚴峻的安全問題.首先,SDN控制器集中管理著其覆蓋網(wǎng)絡(luò)的所有視圖信息,因此,極易成為攻擊的首選目標(biāo),帶來額外的安全風(fēng)險.其次,SDN的重要特性是開放性,主要體現(xiàn)在可編程協(xié)議以及網(wǎng)絡(luò)操作系統(tǒng)的開源社區(qū),而這種開放性極易導(dǎo)致未知的安全漏洞等問題,例如已經(jīng)曝出的OpenDaylight的NetDump漏洞、XML eXternal Entity (XXE)漏洞*Security:Advisories, https://wiki.opendaylight.org/view/Security_Advisories#.5BImportant.5D_CVE-2014-5035_netconf:_XML_eXternal_Entity_.28XXE.29_vulnerability、ONOS的DoS漏洞*Denial-of-Service (DoS) due to exceptions in application packet processors, https://gerrit.onosproject.org/#/c/6137/,以及SDN中的Know Your Enemy (KYE)攻擊[1]等.最后,SDN控制層呈現(xiàn)的單一、靜態(tài)特性有利于攻擊者對其進行探測和分析.作為SDN的核心組件,控制器掌握著整個網(wǎng)絡(luò)的視圖,將上層策略轉(zhuǎn)譯為數(shù)據(jù)平面的轉(zhuǎn)發(fā)規(guī)則,一旦被攻擊或劫持,可導(dǎo)致信息泄漏,甚至網(wǎng)絡(luò)癱瘓.
一般地,針對SDN控制層的攻擊主要出于2個目的:操縱網(wǎng)絡(luò)流量或癱瘓網(wǎng)絡(luò).操縱網(wǎng)絡(luò)流量的攻擊,一般利用控制器的漏洞,如控制器缺少對上層APP權(quán)限管理的漏洞,導(dǎo)致帶毒APP下發(fā)惡意流表規(guī)則[2-3],以及控制器對LLDP(link layer discovery protocol)包缺少安全認證(或者如Floodlight,雖然提供鑒別碼認證,但是鑒別碼一直保持不變)的漏洞造成的拓撲偽造攻擊和中間人流表篡改攻擊[4]等.癱瘓網(wǎng)絡(luò)的攻擊,如存在惡意管理員[5],使用一個簡單的exit命令致使Floodlight宕機造成網(wǎng)絡(luò)癱瘓,或者通過發(fā)送探測報文推斷控制器類型、消息處理邏輯和負載狀態(tài)等信息和發(fā)動DoS攻擊等[6].總之,利用控制器的漏洞發(fā)動攻擊是控制器面臨的主要威脅之一[7].
為應(yīng)對上述安全問題,已有大量研究給出了防御方法.有研究者提出了為控制器增設(shè)北向接口的分級調(diào)用[8]和南向接口的限制訪問[9]以解決上述北向APP權(quán)限和南向探測等漏洞問題,然而這類方法具有侵入性,需修改控制器南北向接口(甚至內(nèi)核),并且這種“打補丁式”的防御手段無法根本上解決漏洞、后門等問題.因此,有研究者從架構(gòu)上提出了分布式控制器[10-13]和彈性控制平面[14-15],這些結(jié)構(gòu)可以有效解決SDN控制層呈現(xiàn)的靜態(tài)特性問題和單點失效造成的網(wǎng)絡(luò)癱瘓等攻擊問題,然而目前主流的分布式架構(gòu)中控制器仍是同構(gòu)的,同一漏洞[16-17]即可能導(dǎo)致所有實例陷入癱瘓,另外,同基于拜占庭容錯(Byzantine fault tolerance, BFT)機制的控制平面一樣[18-19],上述方法控制器間都不可避免地相互通信,增大了攻擊表面,易導(dǎo)致攻擊感染.
本文將鄔江興院士提出的擬態(tài)安全防御思想[20]引入到SDN控制層,提出了擬態(tài)網(wǎng)絡(luò)操作系統(tǒng) (mimic network operating system, MNOS),一種具有動態(tài)異構(gòu)冗余特性[21]的SDN安全架構(gòu),該架構(gòu)在數(shù)據(jù)層和控制層間增加擬態(tài)層,動態(tài)調(diào)度若干異構(gòu)控制器提供網(wǎng)絡(luò)服務(wù),并對其并行輸出進行一致性判決,從中選取最可信的結(jié)果.本文的主要貢獻有3個方面:
1) 基于擬態(tài)防御思想,設(shè)計了擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)架構(gòu),并對Floodlight,Ryu,ONOS這3種主流開源SDN控制器進行開發(fā),實現(xiàn)了原型驗證機POC(proof of concept).實驗評估證明,在增加一定的時延開銷下,MNOS可以有效保障SDN控制層安全;
2) 提出了一種基于異構(gòu)度增益的選調(diào)策略,通過增加選調(diào)前后系統(tǒng)的異構(gòu)程度,進一步提升MNOS的安全性能;
3) 優(yōu)化MNOS的判決機制,在考慮先驗知識的情況下,提升判決的準(zhǔn)確性.
SDN在提供便于管理的控制層的同時,也使其極易遭受攻擊,目前,針對控制層安全防御的研究,可以分為2個方向.
1.1改進型方案
改進型安全控制器的防御思路是在現(xiàn)有開源控制器的基礎(chǔ)上,改進已有的安全服務(wù)或開發(fā)部署新的安全模塊.目前,已有諸多研究者對NOX, Floodlight等控制器進行了安全功能的拓展,如FortNOX[22], SE-Floodlight[23]等.
FortNOX架構(gòu)是Porras等人[22]針對NOX控制器設(shè)計的一種安全內(nèi)核,為其提供基于角色的數(shù)據(jù)源認證、狀態(tài)表管理、流表規(guī)則沖突分析、流表規(guī)則超時回調(diào)等安全功能,提升NOX控制器在流規(guī)則沖突檢測方面的安全性能.在NOX基礎(chǔ)上,Porras等人又對Floodlight進行了類似安全拓展,設(shè)計了其安全增強版本SE-Floodlight[23],增加了應(yīng)用程序證書管理模塊、權(quán)限管理等新的安全模塊.
通過附加安全機制或修補安全漏洞的方式,使得研究者和開發(fā)人員比較被動,很難在短時間內(nèi)有效提升控制器的安全性,并且這些“打補丁式”的改進型也無法從根本上解決控制層的安全漏洞問題.
Fig. 1 The overview of MNOS圖1 MNOS整體架構(gòu)
1.2革新型方案
針對1.1節(jié)的問題,一些研究者提倡在SDN控制器的設(shè)計和開發(fā)之初,便將安全性作為其核心問題之一進行考慮,從而突破已有控制器在系統(tǒng)架構(gòu)、編程語言和預(yù)留接口等方面的限制,開發(fā)出全新的、內(nèi)嵌安全機制的SDN控制器.
Shin等人[24]提出了Rosemary架構(gòu),為實現(xiàn)對上層APP的管理,將其所有應(yīng)用程序運行在一個封閉的應(yīng)用程序區(qū)內(nèi),實時監(jiān)控各個應(yīng)用程序的行為,并通過檢查各個應(yīng)用程序的簽名信息判定其是否為合法應(yīng)用程序.然而,由于Rosemary系統(tǒng)對應(yīng)用程序的簽名方式是基于角色的簽名機制,并將整個應(yīng)用程序作為一個整體對其進行簽名,因而無法較好地對應(yīng)用程序各個模塊的訪問權(quán)限進行細粒度控制.Ferguson等人[25]設(shè)計了內(nèi)嵌安全機制PANE用于解決SDN中不可信用戶訪問請求之間的沖突問題.此外,針對控制器的單點失效問題,有研究者提出了分布式控制器,如HyperFlow[10],作為應(yīng)用程序運行于安裝NOX的控制器之上,采用物理分布但邏輯集中的設(shè)計,因此可以在保證良好可拓展性的同時實現(xiàn)網(wǎng)絡(luò)的集中管控,并且被動同步網(wǎng)絡(luò)狀態(tài)視圖,賦予各個控制器決策權(quán)以降低數(shù)據(jù)層和控制層的時延.FlowVisor[11]則是在轉(zhuǎn)發(fā)平面與控制平面之間引入了一個軟件切片層實現(xiàn)控制消息切分.還有如文獻[18-19]提出了基于拜占庭容錯機制的控制層安全架構(gòu),通過拜占庭的一致性協(xié)議,檢查點協(xié)議以及視圖更換協(xié)議,實現(xiàn)多控制器間網(wǎng)絡(luò)狀態(tài)視圖的一致以及對控制層的容錯/容侵功能.在經(jīng)典拜占庭模型下,當(dāng)系統(tǒng)3f+1個控制器時,可以最多容忍f個錯誤;而改進的拜占庭,可以只需2f+1個即可實現(xiàn)容忍[26].
除此之外,在相關(guān)的防御手段上,如由美國網(wǎng)絡(luò)與信息技術(shù)研究與發(fā)展(networking and information technology research and development, NITRD)計劃近年來提出的移動目標(biāo)防御(moving target defense, MTD)模型[27],其主要通過構(gòu)建動態(tài)冗余網(wǎng)絡(luò)增加不確定性,從而增加攻擊難度.不同于擬態(tài)防御,MTD每個周期只選取1個執(zhí)行體提供服務(wù).
總的來說,上述分布式架構(gòu)雖然可以有效單點失效等問題,但由于采用同構(gòu)控制器,且控制器間相互通信,因此仍可能面臨攻擊感染等問題.
本文提出的擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)(MNOS)主要是將動態(tài)異構(gòu)冗余模型引入SDN控制層中,以實現(xiàn)控制層內(nèi)生安全性.如圖1所示為MNOS的整體框架,其中虛線框內(nèi)即為本文提出的擬態(tài)層部分,下面對MNOS各模塊分別進行介紹.
2.1擬態(tài)控制協(xié)議
本文設(shè)計的擬態(tài)控制協(xié)議格式如圖2所示:
Fig. 2 Mimic Protocol
圖2 擬態(tài)控制協(xié)議
擬態(tài)控制協(xié)議運行在擬態(tài)層部分,即圖1中虛線框內(nèi)(虛線框內(nèi)的虛線箭頭表示擬態(tài)控制協(xié)議報文,框外的實線箭頭表示OpenFlow協(xié)議報文).之所以設(shè)計自定義協(xié)議而不直接采用現(xiàn)有的OpenFlow協(xié)議,是因為其不能滿足本文的動態(tài)調(diào)度、判決(需要對NOS進行標(biāo)識)等模塊功能.擬態(tài)控制協(xié)議類型(type)目前主要分為2類:1) 控制報文,主要是NOS與擬態(tài)層的交互,如NOS注冊消息和?;钕ⅲ?) 數(shù)據(jù)報文,數(shù)據(jù)域data主要為OpenFlow等SDN南向協(xié)議報文.nos_id/app_id字段主要是NOS及其上運行APP的標(biāo)志,在NOS初始化注冊時,由擬態(tài)層分配,便于擬態(tài)層管理.role字段由擬態(tài)層標(biāo)明NOS的角色,主要為master或slave.xid為會話標(biāo)志,便于判決時比對.
2.2南、北向代理層
南、北向代理層主要都是擬態(tài)控制協(xié)議的封裝、解封裝,即進入擬態(tài)層的報文封裝為擬態(tài)控制協(xié)議,反之則解封裝出數(shù)據(jù)域OpenFlow報文.
1) 南向代理層.之所以增加南向代理層(實際上擬態(tài)核心層也可以完成其功能),主要是出于安全的考慮:擬態(tài)核心層功能復(fù)雜,涉及狀態(tài)信息等,若直接對外呈現(xiàn),則易受攻擊(攻擊面大).而增加了功能實現(xiàn)較為簡單的南向代理層后,從底層交換機的角度上看,南向代理層即為SDN控制器,從而實現(xiàn)擬態(tài)核心層對數(shù)據(jù)層的透明無感,從而保障MNOS的系統(tǒng)安全.
由上述分析,南向代理層可以采用專用硬件如NetFPGA實現(xiàn),降低其遭受攻擊的概率.
2) 北向代理層.同南向代理層類似,北向代理層主要面向SDN控制器及其上運行的APP應(yīng)用,因此從控制層的角度看,北向代理層被視為底層交換機.
由于本文采用異構(gòu)的SDN控制器,如Floodlight,Ryu,ONOS,具體實現(xiàn)不同,但實現(xiàn)方法和邏輯類似.本文針對不同控制器類型開發(fā)APP(模塊),運行在SDN控制器上實現(xiàn)北向代理功能,其主要包含2個接口:與SDN控制器(以及APP)間通信接口和與擬態(tài)核心層間通信接口.邏輯功能主要為SDN控制器消息的攔截、報文封裝和虛假交換機實現(xiàn).不同控制器“攔截”實現(xiàn)不同,如Ryu控制器,我們是通過重寫datapath中的send_msg函數(shù)(增加封裝、解封裝擬態(tài)控制協(xié)議部分)實現(xiàn)的;而虛假交換機主要是為了完成底層交換機的“模擬”,實現(xiàn)對控制器的透明無感.
2.3消息隊列
由于MNOS系統(tǒng)內(nèi)部需要協(xié)調(diào)異構(gòu)系統(tǒng)大量的通信,目前主流的異構(gòu)系統(tǒng)通信的方法有2種:1)RPC(遠程協(xié)議調(diào)用);2)消息隊列.鑒于目前開源社區(qū)有較成熟的消息隊列框架,本文選擇基于消息隊列的異構(gòu)子系統(tǒng)通信實現(xiàn).
就目前而言,主流的消息隊列框架包括:RabbitMQ,ActiveMQ,ZeroMQ.RabbitMQ是AMQP協(xié)議領(lǐng)先的一個實現(xiàn),它實現(xiàn)了代理(Broker)架構(gòu),意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點上排隊.此特性使得RabbitMQ易于使用和部署,適宜于很多場景如路由、負載均衡或消息持久化等.但是,這使得它的可擴展性差,速度較慢,因為中央節(jié)點增加了延遲,消息封裝后也較大.
ZeroMQ (ZMQ)是一個非常輕量級的消息系統(tǒng),專門為高吞吐量/低延遲的場景開發(fā),在金融界應(yīng)用廣泛,與RabbitMQ相比,ZMQ支持許多高級消息場景.更重要的是,由于本文需要在多個控制器間進行調(diào)度,同時涉及關(guān)閉某些控制器(進行清洗)后重新啟動等操作,而ZMQ對連續(xù)的斷開連接、重連接等都很友好,支持度高,適合本文應(yīng)用場景,因此采用ZMQ實現(xiàn).
2.4擬態(tài)核心層
擬態(tài)核心層是MNOS功能核心部分,主要負責(zé)NOS的管理、調(diào)度和判決等功能,相應(yīng)地,其邏輯架構(gòu)包含NOS管理器、選調(diào)器和判決器.
2.4.1 NOS管理器
NOS管理器主要負責(zé)NOS管理和NOS狀態(tài)維護2個功能,下面分別進行介紹:
1) NOS狀態(tài)維護.NOS管理器維護的控制器狀態(tài)信息如圖3中NOS類所示:
Fig. 3 Status information of NOS圖3 NOS的狀態(tài)信息
每個新加入的控制器都必須在初始化階段向NOS管理器注冊,由管理器分配其唯一標(biāo)識的nos_id, 并確定控制器類型nos_kind,如Floodlight,Ryu,ONOS等;app_id和app_kind同控制器注冊時類似,這2個變量是為了維護該控制器上運行的APP信息;state表示控制器的狀態(tài),主要有激活態(tài)(active)、空閑態(tài)(inactive)、初始態(tài)(initial)和可疑態(tài)(suspicious),狀態(tài)state的變換過程如圖4所示:
Fig. 4 State transforming of NOS圖4 NOS的狀態(tài)變換
其中變換①由NOS管理器負責(zé),主要工作是NOS初始化時的網(wǎng)絡(luò)狀態(tài)同步,由NOS管理器負責(zé);變換②~③由選調(diào)器負責(zé),確定控制器的工作狀態(tài)、角色,這部分在2.4.2節(jié)介紹;變換④~⑥由判決器負責(zé),主要發(fā)生在發(fā)現(xiàn)控制器可疑或者去可疑時,這部分在2.4.3節(jié)介紹.
2) NOS管理.得益于docker、NFV、云等虛擬化技術(shù),我們可以很方便地新增控制器(鏡像)進行拓展,如圖4所示,這里新增控制器也有可能是判決器發(fā)現(xiàn)可疑控制器,最后決定刪除而重新初始化的控制器(變換⑥).但新增控制器不能立即投入使用,因為涉及網(wǎng)絡(luò)狀態(tài)信息和APP狀態(tài)等問題,因此首先需要對其進行網(wǎng)絡(luò)狀態(tài)同步,完成圖4中變換①.
狀態(tài)同步的步驟如圖5所示:
Fig. 5 State synchronization圖5 狀態(tài)同步流程
其中Floodlight表示正常運行的控制器,ONOS為新增待同步的控制器,switch表示底層交換機(實際應(yīng)該分別為南、北向代理層,這里是為描述簡便),core表示擬態(tài)核心層.以路由APP為例,具體步驟如下:
① 時刻t0擬態(tài)核心層收到ONOS的初始注冊消息,新建該控制器的狀態(tài)信息,即nos_id,nos_kind等,并將狀態(tài)設(shè)置為“初始態(tài)”;
② 擬態(tài)核心層向Floodlight發(fā)送獲取狀態(tài)的擬態(tài)控制協(xié)議報文,同時將時刻t0以后收到的switch報文進行緩存而不再發(fā)往Floodlight(如圖5中圓柱體);
③ 收到Floodlight發(fā)送的時刻t0的狀態(tài)(對于路由APP,狀態(tài)信息即為路由表,F(xiàn)loodlight的節(jié)點路由表狀態(tài)信息存放于TopologyInstance中的pathcache變量中)后,將其數(shù)據(jù)進行轉(zhuǎn)換(適用于ONOS的數(shù)據(jù))后發(fā)送給初始態(tài)的ONOS進行狀態(tài)同步(此時同步的是時刻t0的狀態(tài)),同時將緩存的報文發(fā)往Floodlight進行處理;
④ 在時刻t2,F(xiàn)loodlight正常處理報文,并將緩存的報文和后續(xù)到達的報文依次發(fā)往ONOS進行處理;
⑤ 在ONOS完成狀態(tài)同步(處理完緩存報文后)向擬態(tài)核心層確認后,將其狀態(tài)信息由“初始態(tài)”變換為“空閑態(tài)”,等待選調(diào)模塊的調(diào)用.
需要說明的是,若正常工作(激活態(tài)或空閑態(tài))的控制器中有相同類型的控制器,可直接用其進行同步,無需進行數(shù)據(jù)轉(zhuǎn)換的步驟.
2.4.2 選調(diào)器
選調(diào)器主要負責(zé)控制器的調(diào)度,實現(xiàn)動態(tài)性,即圖3中的變換②~③.為確??刂破鞯囊晥D一致,本文采用類似OpenFlow協(xié)議的slave/master方法實現(xiàn)選調(diào),不同的是OpenFlow協(xié)議中控制器集群只有一個master, slave只有在master無法正常工作時才修改為master(主要是應(yīng)對單點失效等故障),而本文是將多個控制器同時設(shè)為master.具體地,若北向代理層收到的擬態(tài)控制協(xié)議報文中role字段為master,則將其交付控制器處理并正常下發(fā)消息;反之,若為slave,則北向代理交付控制器處理后對其消息進行攔截而不下發(fā).
因此,首先選調(diào)器根據(jù)選調(diào)策略選取出m(m一般為不小于3的奇數(shù))個控制器后,將其狀態(tài)信息由空閑態(tài)設(shè)為激活態(tài),其余設(shè)為空閑態(tài),而后只需根據(jù)各控制器的狀態(tài),在分發(fā)消息給各控制器時,在role字段填入slave/master (0/1) 即可:對于空閑態(tài)和初始態(tài)的控制器,該字段設(shè)為slave(初始化的控制器不具備正常工作的能力);激活態(tài)和可疑態(tài)的,設(shè)為master(由于可疑的控制器需要進一步考察,因此需要其回復(fù)所有的消息請求,便于判決器與其他控制器的響應(yīng)進行比對,確認其可信與否).具體的選調(diào)策略將在第3節(jié)進行介紹.
2.4.3 判決器
判決器主要負責(zé)對多個控制器的響應(yīng)報文進行判決,判定最可靠的響應(yīng).判決機制在數(shù)據(jù)融合等領(lǐng)域有很多研究,以最簡單的大數(shù)判決為例.當(dāng)判決器收到m份響應(yīng)中(由2.4.2節(jié)可知,只有role字段為master的控制器才會響應(yīng))有大于或等于(m+1)/2份結(jié)果一致時,則判定該結(jié)果為有效響應(yīng),發(fā)往南向代理層(最終到交換機);而對于其余和該結(jié)果不一致的控制器,則判定為可疑,將其狀態(tài)由激活態(tài)改為可疑態(tài)(圖3中的變換④),然后著重對其進行考察,若后期仍多次出現(xiàn)不一致的情況,則向NOS管理器通告,將其刪除,并重新初始化新的控制器實例(圖3中變換⑥),反之,則重新設(shè)為空閑態(tài)(去可疑,圖3中變換⑤).
上述判決機制是基于一個假設(shè):多數(shù)控制器同時被攻擊且攻擊后輸出一致的錯誤響應(yīng)的概率極低.尤其是本文采用的異構(gòu)控制器,攻擊者需要對多種控制器進行漏洞挖掘,因此攻擊者成功實施攻擊的難度將會進一步增加[16-17].具體的判決機制將在第4節(jié)進行介紹.
第2節(jié)我們給出了選調(diào)器的工作原理,在本節(jié)中,我們詳細介紹本文選調(diào)器的選調(diào)策略.
多樣性,即異構(gòu)配置,是指對集合中冗余實例采用相同功能但軟件或硬件不同的配置,以增加系統(tǒng)的多樣性[16-17].通過引入多樣性增強網(wǎng)絡(luò)安全的方法已成為研究熱點并廣泛應(yīng)用,這種配置方法可以有效避免因同一種軟件或硬件的漏洞、后門等造成共模故障,使整個冗余系統(tǒng)遭受毀滅性攻擊[16-17].因此,本文提出一種基于異構(gòu)度增益的選調(diào)策略,即最大化MNOS系統(tǒng)中控制器異構(gòu)度.用到的符號、變量如表1所示:
Table 1 Definitions and Notations
我們的選調(diào)目標(biāo)是最大化系統(tǒng)選調(diào)前后的異構(gòu)度增益DG(由于每次選調(diào)的控制器數(shù)量受限,所以相當(dāng)于激活態(tài)和空閑態(tài)控制器的動態(tài)遷移),異構(gòu)度增益源于軟硬件2個方面,即DGH,DGK為最大化:
(1)
DGH,DGK的計算方法如式(2)所示,且由于選調(diào)后切換的時延等因素,所以需對遷移開銷(如遷移數(shù)量)進行限制:
(2)
顯然,若新選取的控制器軟件或硬件不同于當(dāng)前激活態(tài)控制器集中的,則其帶來的異構(gòu)度增益大于相同的情況,因此,式(2)中變量關(guān)系滿足ε1<ε2, ?12.
式(2)最優(yōu)模型是典型的NP難問題:當(dāng)前激活態(tài)控制器在選調(diào)后變?yōu)榭臻e態(tài),而空閑態(tài)被選取后變?yōu)榧せ顟B(tài),相當(dāng)于是一種映射算法.因此,本文給出如下啟發(fā)式算法:每一輪選調(diào)都分為若干次遷移步驟,每一步都先從當(dāng)前激活態(tài)集中選取出最破壞系統(tǒng)異構(gòu)度的控制器,然后對其進行考察,按照式(1)(2)的原則選取候選控制器.最破壞系統(tǒng)異構(gòu)度的控制器即某類型控制器數(shù)量最多的控制器.例如,某時刻激活態(tài)控制器集共有4種控制器,分別是3臺Ryu,一臺ONOS,一臺ODL和0臺Floodlight,那么在進行這一輪選調(diào)時,我們優(yōu)先選擇其中的一臺Ryu進行遷移(移出激活態(tài)集),并且由式(1)(2)可知,應(yīng)當(dāng)優(yōu)先選擇Floodlight加入候選控制器集中,以此類推.
算法1. 選調(diào)算法.
輸入:φc,Ccur;
輸出:Cnxt.
①Cnxt=φ;
② whileφc≠0 andCcur≠?
③ 從Ccur中選擇最破壞異構(gòu)度的控制器i;
④ forj∈CCcur
⑤ if (DGH+DGK)最大
⑥Ccur←j;
⑦ end if
⑧ end for
⑨Ccur←Ccur-i,φc←φc-1;
⑩ end while
假設(shè)控制器集共有|C|,則找到Cnxt的時間復(fù)雜度可近似為O(min(|Ccur|,φc)(|C|-|Ccur|)),所以復(fù)雜度最大為O(|Ccur|(|C|-|Ccur|))≤O(|C|24).
判決器的任務(wù)是從各激活態(tài)控制器的響應(yīng)報文中比對,抉擇出最可信的響應(yīng)回復(fù)給底層交換機,并記錄可疑控制器.主要涉及2個關(guān)鍵點:比對內(nèi)容和判決方法.在比對內(nèi)容(粒度)方面,顯然,若比對粒度為比特級,則計算量過大,因此,本文根據(jù)OpenFlow消息的格式進行字段級比對,著重考察2個關(guān)鍵字段:匹配(match)字段和行為(action)字段.如圖6所示,攻擊者通過劫持SDN控制器(NOS1)篡改下發(fā)的流表規(guī)則,將原合法的轉(zhuǎn)發(fā)邏輯match:in_port=2,actions:output=1,篡改為match:in_port=2,actions:output=3,企圖引導(dǎo)用戶流量到攻擊者事先部署的Web服務(wù)器上.此時,判決器只需比對各控制器的match字段和action字段,從中選取較可靠的響應(yīng)(output=1)下發(fā)給交換機.
Fig. 6 Modifying flow rule attack圖6 流表篡改攻擊
上述示例采用的判決方法是2.4.3節(jié)中簡單的大數(shù)裁決機制(majority-bases decision),實現(xiàn)容錯/容侵功能.但是這種方法多次判決之間相互獨立(每一次判決只和當(dāng)前接收的響應(yīng)有關(guān)),無法有效利用先驗知識,因此,本文優(yōu)化判決機制,在考慮先驗知識的情況下提升判決的準(zhǔn)確性.
4.1問題描述
假設(shè)有m個激活態(tài)控制器,存在若干拜占庭(惡意)控制器,每個控制器對同一OpenFlow消息(如packet in報文)進行處理后返回響應(yīng)報文,我們用f=(f1,f2,…,fl)′表示真正正確的響應(yīng)報文,共有l(wèi)個字段,其中fi為01位序列,表示待比對的第i字段(例如actions中output字段),fi,j為該字段的第j位(fi,j={0,1},j=1,2,…,hi),hi為第i字段所占位數(shù).如圖7所示,其中表示第k個控制器處理后的原始響應(yīng)報文中第i字段的第j位,而則表示為該控制器實際向判決器返回的報文.顯然,一般而言,正常情況下應(yīng)當(dāng)滿足但是若控制器被攻擊,變?yōu)閻阂饪刂破鳎敲纯赡芫陀屑僭O(shè)惡意控制器反轉(zhuǎn)該結(jié)果的概率為Pmal(Pmal=P(oi,j≠ri,j)).因此判決器的目標(biāo)就是在這些可能含有被篡改的報文中判決出最真實可靠的報文.
Fig. 7 Decision fusion scheme圖7 判決場景
4.2判決機制優(yōu)化
由4.1節(jié)可知,判決器的任務(wù)可以轉(zhuǎn)化為求解:
(3)
由貝葉斯定理和所有可能的響應(yīng)都是等概率發(fā)生可知,式(3)等價于:
(4)
我們用an=(a1,a2,…,am)的01序列表示控制器集的狀態(tài)(惡意或正常):若ak=1,則表示NOSk為惡意控制器;反之,則為正??刂破?而P(an)則表示當(dāng)前激活態(tài)控制器集狀態(tài)為該序列的概率,代入式(4)可得:
(5)
可以看出,由于乘法效應(yīng),式(5)求解較為復(fù)雜,我們采用類似OpenFlow多級流表的思想,將式(5)分解轉(zhuǎn)化為多級相加,即單獨求解各個字段的最優(yōu)解,可得:
(6)
于是由各個字段的解可以組合出最優(yōu)解f*.此外,我們考慮存在系統(tǒng)誤差概率ε,ε=p(oi,j≠fi,j)用于描述控制器的系統(tǒng)錯誤概率,于是正??刂破骱蛺阂饪刂破髯詈蠓祷亟o判決器的結(jié)果不同于真正正確的結(jié)果的概率可以分別表示為
(7)
(8)
因此,將式(7)(8)的結(jié)論代入,可將式(6)轉(zhuǎn)化為
(9)
我們假設(shè)攻擊者對每個控制器以相同的概率α成功實施攻擊,使其變?yōu)閻阂饪刂破鳎⑶矣捎诳刂破鏖g相互異構(gòu),所以可以認為各個控制器被攻擊的狀態(tài)相互獨立,因此:
(10)
其中,當(dāng)ak=1時,PA(ak)=α(一般假設(shè)α<0.5,否則,若半數(shù)以上為惡意控制器,則判決器就不可能做出正確的決策).將式(10)代入式(9),可得:
(11)
對于其他字段類似式(11)計算可得.由式(11)可知,判決器一次完整數(shù)據(jù)融合最大的計算復(fù)雜度與激活態(tài)控制器個數(shù)m和比對的字段數(shù)l呈線性關(guān)系,而與每個字段所占位數(shù)hi呈指數(shù)關(guān)系,因此hi不宜過大,而OpenFlow協(xié)議1.0版本中,actions中位數(shù)最大的為“modify Ethernet sourcedestination MAC address”(修改源、目的MAC地址)48 b,對此可以繼續(xù)采用分解的方法,將其劃為多個子字段,以降低每個子字段的位數(shù).
本節(jié)對MNOS性能、選調(diào)策略和判決機制進行實驗評估.我們采用3種開源控制器Ryu, Floodlight, ONOS,在9臺華為服務(wù)器(RH2288H V3)和1臺Pica8 (P3297)交換機上搭建實驗環(huán)境,具體地,3臺運行Floodlight、2臺運行ONOS、4臺服務(wù)器運行Ryu(其中1臺同時運行南向代理層、1臺同時運行擬態(tài)核心層).
5.1MNOS安全性能
5.1.1 攻擊成功概率仿真
首先對MNOS的安全性能進行評估對比.本文主要與移動目標(biāo)防御模型(MTD)[27]和基于拜占庭容錯(BFT)的SDN控制層[18-19]架構(gòu)進行對比.
由于MTD架構(gòu)下,每個周期只選取1個執(zhí)行體提供服務(wù),因此,可認為MTD是擬態(tài)防御在m=1時的特例.并且由于改進的BFT[26],可在2f+1冗余情況下實現(xiàn)f個錯誤容忍,因此改進BFT在最終效果上等同于進行了大數(shù)判決,可視為靜態(tài)MNOS,即沒有動態(tài)選調(diào)功能,只能一直由m個控制器提供服務(wù).
在具體的仿真設(shè)置上,假設(shè)共有N個異構(gòu)控制器,每個周期選取m個作為激活態(tài),攻擊者在一個周期的有效時間內(nèi)可同時對w個控制器發(fā)起攻擊(隨機選取w個).由于采用了異構(gòu)配置,因此可以假設(shè)攻擊不同控制器相互獨立,且假設(shè)對每個控制器的攻擊成功概率都為Pa.因此,MNOS架構(gòu)下若要攻擊成功必須滿足:1)有超過半數(shù)((m+1)2)的激活態(tài)控制器被選擇攻擊;2)成功攻擊.因此攻擊成功概率可表示為
(12)
其中,前項積分表示攻擊者選擇攻擊的w個控制器中有u個為激活態(tài)的概率,后項積分表示在u個激活態(tài)控制器中攻擊成功v個概率和,這里采用大數(shù)判決機制,因此只有當(dāng)u,v≥(m+1)2才可能攻擊成功.
而MTD架構(gòu)下,攻擊者選擇正確的攻擊目標(biāo)的概率為wN,因此攻擊成功概率可表示為(也可由式(12)取m=1得到):
(13)
而改進拜占庭架構(gòu)下,攻擊者需要成功攻擊半數(shù)以上控制器,可表示為(也可直接由式(12)取N=m得):
(14)
圖8所示為攻擊成功概率與Pa和每個時間間隔攻擊者可同時攻擊的控制器數(shù)量w的關(guān)系.可見,整體上,攻擊成功概率都隨攻擊能力w增加而增加;而MTD架構(gòu)下,攻擊成功概率呈線性增加,且遠高于MNOS和BFT模型;而BFT模型也要高于本文的MNOS架構(gòu),由式(12)和式(14)對比可知,這是由于MNOS的動態(tài)選調(diào)降低了攻擊者攻擊激活態(tài)控制器的概率導(dǎo)致的,而當(dāng)w≥5概率不再增加;而本文的MNOS安全性能明顯優(yōu)于其他2種架構(gòu)(本文MNOS在m=5,w=11時與BFT架構(gòu)結(jié)果一致,因為此時攻擊者可攻擊全部控制器),且性能隨m值的增加而增加,當(dāng)然,時延開銷等也會相應(yīng)增加,后文將就時延代價等問題進行分析.
Fig. 8 Successful attack probability圖8 攻擊成功概率
5.1.2 入侵容忍能力驗證
Fig. 9 Log file on decider圖9 判決器log文件信息
我們對MNOS的容錯/容侵能力進行了測試,驗證圖6所示場景.在擬態(tài)核心層判決器處收到3個控制器下發(fā)的OpenFlow的FLOW_MOD(規(guī)則下發(fā))報文如圖9所示,我們修改了其中一個控制器上的APP代碼(下發(fā)規(guī)則模塊),模擬惡意APP攻擊[28].可見,其中一個output字段由原1端口被篡改為3端口,此時判決器仍選擇1端口(大數(shù)判決),實現(xiàn)容錯/容侵.顯然,若激活態(tài)控制器數(shù)量為m,則若采用大數(shù)判決機制可容忍至多(m-1)/2個控制器故障,即攻擊者至少需成功攻擊(m+1)/2個控制器.并且由于采用了動態(tài)選調(diào)策略,限制了攻擊的連續(xù)有效時間(一個切換周期),進一步增加了攻擊難度.
5.1.3 時延開銷及壓力測試
最后由于引入了冗余控制器,并增設(shè)了擬態(tài)層,涉及選調(diào)、判決等模塊,因此本文對傳統(tǒng)單一控制器和MNOS的處理時延和吞吐量進行了對比分析評估.為了更好地描述和分析MNOS引入的額外時延開銷,給出本節(jié)涉及的相關(guān)符號和定義,如表2所示:
Table 2 Definitions and Notations
因此,傳統(tǒng)單一控制器的時延可以表示為(這里的傳輸時延(含傳播時延)為往返的時延):
Toriginal=Tt d_ds+Tp d_c,
(15)
而MNOS的時延可以表示為
(16)
因此,額外增加的時延可以表示為
(17)
考慮到南、北向代理的工作主要為報文封裝、解封裝,這部分處理時延較小,將其忽略,則式(14)可近似為
(18)
為分析上述各部分時延,下面給出MNOS的時延測試結(jié)果,我們采用圖5所示的拓撲,測試2個主機間的ping包時延(刪除了控制器中流表下發(fā)部分代碼,目的是讓所有數(shù)據(jù)包都經(jīng)由控制器處理,便于測試并統(tǒng)計時延).結(jié)果如圖10所示,其中Original(加粗點劃線)表示傳統(tǒng)單一控制器.
Fig. 10 Time delay test圖10 時延測試
1) 傳統(tǒng)單一控制器和無冗余MNOS對比.即圖9中加粗點劃線(Original)與三角劃線的第1點(單個控制器即無冗余下的MNOS)進行對比,可以體現(xiàn)由MNOS新增的多邏輯層傳輸時延,即Tt d_sm+Tt d_mn(由于只采用一個控制器,擬態(tài)層沒有選調(diào)、判決等處理,因此Tp d_m忽略不計,并且無max效應(yīng)),這部分時延增加約為43.8%.
然后我們采用Cbench(controller benchmarker)對MNOS系統(tǒng)進行壓力測試,測試不同交換機數(shù)量下的吞吐量,結(jié)果如圖11所示.
Fig. 11 Throughput test圖11 吞吐量測試
加粗點劃線為正常單個Ryu控制器架構(gòu)的測試結(jié)果(Floodlight和ONOS的吞吐量均為104~105級,遠大于Ryu,因此MNOS性能主要受Ryu的影響).可見,整體上吞吐量隨交換機數(shù)量變化不大,而激活態(tài)控制器數(shù)量越多,則吞吐量越小.同時,與單個Ryu的對比可見,MNOS架構(gòu)對網(wǎng)絡(luò)吞吐量損害較大,同時延分析類似,這主要是由于判決機制導(dǎo)致的,性能仍有待提升.
5.2選調(diào)策略評估
下面對選調(diào)策略進行仿真評估.我們的參數(shù)設(shè)置為:共有3臺主機、4種控制器類型,每種有3個,ε1, ?1為0.1,ε2, ?2為0.3, 每輪選調(diào)開銷φc=3.仿真結(jié)果如圖12所示,其中方形劃線(Random1)為完全隨機選調(diào);圓圈劃線(Random2)為考慮了異構(gòu)度增益,但是隨機選擇待遷移的控制器,即算法1中第3步為隨機選取而不是選擇最破壞異構(gòu)度的控制器優(yōu)先遷移;三角劃線(MNOS)即為本文提出的選調(diào)策略.
Fig. 12 Diversity gain圖12 異構(gòu)度增益
由仿真結(jié)果可以看出,本文提出的選調(diào)策略以及分步遷移算法可以增加激活態(tài)控制器集的異構(gòu)程度,從而有效避免同構(gòu)產(chǎn)生的攻擊感染問題,增加攻擊者攻擊難度.
5.3判決機制評估
下面對本文的判決機制進行仿真分析.其中參數(shù)設(shè)置為:m=21,hi=4(由4.2節(jié)分析,hi值不宜過大,且字段所占位數(shù)都為4的倍數(shù)),ε=0.1,惡意控制器和判決器采用的Pmal取值分別為0.5,0.6,0.7,0.8,0.9,1.0.我們進行10 000次重復(fù)試驗,最終得到的博弈雙方收益函數(shù)-錯誤率如表3所示:
Table 3 The Payoff (Pe)
SDN控制層作為軟件定義網(wǎng)絡(luò)中的核心管理模塊,對全網(wǎng)的正常運行起著關(guān)鍵性作用,因此其安全性和可靠性需求不言而喻.本文在分析已有的防御機制的基礎(chǔ)上,基于擬態(tài)防御思想,提出了動態(tài)異構(gòu)冗余模型的擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)MNOS架構(gòu).MNOS通過構(gòu)建異構(gòu)冗余的網(wǎng)絡(luò)操作系統(tǒng),實現(xiàn)控制層的動態(tài)調(diào)度,增加控制層的不確定性,從而降低攻擊成功概率.為增加控制層的異構(gòu)度,本文提出了基于異構(gòu)度增益的選調(diào)策略,進一步增加攻擊者的攻擊成本.最后,本文采用的判決機制,相比大數(shù)判決可以進一步提升判決的準(zhǔn)確性.
當(dāng)然,MNOS架構(gòu)也存在一定的不足,如實驗仿真中代價分析部分所述,MNOS由于采用冗余控制器共同決定最終結(jié)果,因此將會增加一定的時延,并對網(wǎng)絡(luò)吞吐量損害較大.對此,可以采用預(yù)判決機制進行改善.后續(xù)的可能研究思路主要包括優(yōu)化判決機制,降低計算復(fù)雜度;研究選調(diào)策略的優(yōu)化,如根據(jù)NOS安全狀態(tài)動態(tài)調(diào)整選調(diào)策略等.
[1] Conti M, Gaspari F D, Mancini L V. Know your enemy: Stealth configuration-information gathering in SDN[C] //Proc of the 12th Int Conf on Green, Pervasive, and Cloud Computing. Berlin: Springer, 2017: 386-401
[2] Scott-Hayward S, Natarajan S, Sezer S. A survey of security in software defined networks[J]. IEEE Communications Surveys & Tutorials, 2015, 18(1): 623-654
[3] Lee S, Yoon C, Shin S. The smaller, the shrewder: A simple malicious application can kill an entire SDN environment[C] //Proc of the 2016 ACM Int Workshop on Security in Software Defined Networks & Network Function Virtualization. New York: ACM, 2016: 23-28
[4] Hong Sungmin, Xu Lei, Wang Haopei, et al. Poisoning network visibility in software-defined networks: New attacks and countermeasures[C] //Proc of Network and Distributed System Security Symp. Reston, VA: ISOC, 2015: 8-11
[5] Matsumoto S, Hitz S, Perrig A. Fleet: Defending SDNs from malicious administrators[C] //Proc of the 2nd ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking. New York: ACM, 2014: 103-108
[6] Sonchack J, Aviv A J, Keller E. Timing SDN control planes to infer network configurations[C] //Proc of the 2016 ACM Int Workshop on Security in Software Defined Networks & Network Function Virtualization. New York: ACM, 2016: 19-22
[7] Lee S, Yoon C, Lee C, et al. DELTA: A security assessment framework for software-defined networks[C] //Proc of Network and Distributed System Security Symp 2017. Reston, VA: ISOC, 2017
[8] Lee C, Shin S. SHIELD: An automated framework for static analysis of SDN applications[C] //Proc of the ACM Int Workshop on Security in Software Defined Networks & Network Function Virtualization. New York: ACM, 2016: 29-34
[9] Wilczewski. Security considerations for equipment controllers and SDN[C] //Proc of IEEE Int Telecommunications Energy Conf. Piscataway, NJ: IEEE, 2016: 1-5
[10] Tootoonchian A, Ganjali Y. HyperFlow: A distributed control plane for OpenFlow[C] //Proc of the 2010 Internet Network Management Conf on Research on Enterprise Networking. Berkeley, CA: USENIX Associations, 2010
[11] Sherwood R, Gibb G, Yap K K, et al. FlowVisor: A network virtualization layer[EB/OL]. (2009-10-14) [2017-06-01]. http://archive.openflow.org/downloads/technicalreports/openflow-tr-2009-1-flowvisor.pdf
[12] Yeganeh S H, Ganjali Y. Kandoo: A framework for efficient and scalable offloading of control applications[C] //Proc of the 1st Workshop on Hot Topics in Software Defined Networks. New York: ACM, 2012: 19-24
[13] Koponen T, Casado M, Gude N, et al. Onix: A distributed control platform for large-scale production networks[C] //Proc of the 9th USENIX Symp on Operating Systems Design and Implementation. Berkeley, CA: USENIX Associations, 2010: 351-364
[14] Dixit A, Fang H, Mukherjee S, et al. Towards an elastic distributed SDN controller [C] //Proc of the 2nd Workshop on Hot Topics in Software Defined Networking. New York: ACM, 2013: 7-12
[15] Berde P, Hart J, et al. ONOS: Towards an open, distributed SDN OS[C] //Proc of the Workshop on Hot Topics in Software Defined Networking. New York: ACM, 2014: 1-6
[16] Voas J, Ghosh A, Charron F, et al. Reducing uncertainty about common-mode failures[C] //Proc of the 8th IEEE Symp Software Reliability Engineering. Piscataway, NJ: IEEE, 1997: 308-319
[17] Levitin G. Optimal structure of fault-tolerant software systems[J]. Reliability Engineering & System Safety, 2005, 89(3): 286-295
[18] Li He, Li Peng, Guo Song, et al. Byzantine-resilient secure software-defined networks with multiple controllers in cloud[J]. IEEE Trans on Cloud Computing, 2015, 2(4): 436-447
[19] Eldefrawy K, Kaczmarek T. Byzantine fault tolerant software-defined networking (SDN) controllers[C] //Proc of the 40th IEEE Computer Society Int Conf on Computers, Software & Applications. Piscataway, NJ: IEEE, 2016: 208-213
[20] Wu Jiangxing. Research on cyber mimic defense [J]. Journal of Cyber Security, 2016, 1(4): 1-10 (in Chinese)
(鄔江興. 網(wǎng)絡(luò)空間擬態(tài)防御研究[J]. 信息安全學(xué)報, 2016, 1(4): 1-10)
[21] Hu Hongchao, Chen Fucai, Wang Zhenpeng. Performance evaluations on DHR for cyberspace mimic defense [J]. Journal of Cyber Security, 2016, 1(4): 40-51 (in Chinese)
(扈紅超, 陳福才, 王禛鵬. 擬態(tài)防御DHR模型若干問題探討和性能評估[J]. 信息安全學(xué)報, 2016, 1(4): 40-51)
[22] Porras P, Shin S, Yegneswaran V, et al. A security enforcement kernel for OpenFlow networks[C] //Proc of the 1st Workshop on Hot Topics in Software Defined Networks. New York: ACM, 2012: 121-126
[23] Porras P, Cheung S, Fong M, et al. Securing the software defined network control layer[C] //Proc of Network and Distributed System Security Symp 2010. Reston, VA: ISOC, 2010
[24] Shin S, Song Y, Lee T, et al. Rosemary: A robust, secure, and high-performance network operating system[C] //Proc of the 21st ACM Conf on Computer and Communications Security. New York: ACM, 2014: 78-89
[25] Ferguson A D, Guha A, Liang C, et al. Participatory networking: An API for application control of SDNs[C] //Proc of the ACM SIGCOMM 2013. New York: ACM, 2013: 327-338
[26] Veronese G S, Correia M, Bessani A N, et al. Efficient Byzantine Fault-Tolerance[J]. IEEE Trans on Computers, 2013, 62(1): 16-30
[27] Baker S. Trustworthy cyberspace: Strategic plan for the federal cybersecurity research and development program[EB/OL]. (2011-12) [2017-09-06]. https://www.nitrd.gov/SUBCOMMITTEE/csia/Fed_Cybersecurity_RD_Strategic_Plan_2011.pdf
[28] Lee S, Yoon C, Shin S. The smaller, the shrewder: A simple malicious application can kill an entire SDN environment[C] //Proc of ACM Int Workshop on Security in Software Defined Networks & Network Function Virtualization. New York: ACM, 2016: 23-28
DesignandImplementationofMimicNetworkOperatingSystem
Wang Zhenpeng, Hu Hongchao, and Cheng Guozhen
(NationalDigitalSwitchingSystemEngineering&TechnologicalResearchCenter,Zhengzhou450003)
As a mission-critical network component in software defined networking (SDN), SDN control plane is suffering from the vulnerabilities exploited to launch malicious attacks, such as malicious applications attack, modifying flow rule attack, and so on. In this paper, we design and implement mimic network operating system (MNOS), an active defense architecture based on mimic security defense to deal with it. In addition to the SDN data plane and control plane, a mimic plane is introduced between them to manage and dynamically schedule heterogeneous SDN controllers. First, MNOS dynamically selectsmcontrollers to be active to provide network service in parallel according to a certain scheduling strategy, and then judges whether controllers are in benign conditions via comparing themresponses from the controllers, and decides a most trusted response to send to switches so that the minority of malicious controllers will be tolerated. Theoretical analysis and experimental results demonstrate that MNOS can reduce the successful attack probability and significantly improve network security, and these benefits come at only modest cost: the latency is only about 9.47% lower. And simulation results prove that the scheduling strategy and decision fusion method proposed can increase system diversity and the accuracy of decisions respectively, which will enhance the security performance further.
software defined networking (SDN); active defense; mimic security defense; dynamic heterogeneous redundancy; network operating system (NOS)
TP393
WangZhenpeng, born in 1993. Bachelor. His main research interests include software defined networking and mimic security defense.
HuHongchao, born in 1982. PhD and associate professor.. His main research interests include network security and software defined networking.
ChengGuozhen, born in 1986. PhD and research assistant. His main research interests include software defined networking and active defense.