MNOS：擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

王禛鵬 扈紅超 程國振

(國家數(shù)字交換系統(tǒng)工程技術(shù)研究中心 鄭州 450003) (whuwzp@whu.edu.cn)

2017-06-11；

2017-08-01

國家自然科學(xué)基金項(xiàng)目(61309020,61602509)；國家自然科學(xué)基金創(chuàng)新群體項(xiàng)目(61521003)；國家重點(diǎn)研發(fā)計(jì)劃項(xiàng)目(2016YFB0800100,2016YFB0800101)；河南省科技攻關(guān)項(xiàng)目(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è)計(jì)與實(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)對(duì)未知漏洞或后門.提出一種基于擬態(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)層，實(shí)現(xiàn)動(dòng)態(tài)調(diào)度功能.首先擬態(tài)層動(dòng)態(tài)選取若干NOS作為激活態(tài)并行提供服務(wù)，然后根據(jù)各NOS的處理結(jié)果決定最終的有效響應(yīng)返回底層交換機(jī).實(shí)驗(yàn)評(píng)估表明：在增加有限的時(shí)延開銷下，MNOS可以有效降低SDN控制層被成功攻擊的概率，并具備良好的容錯(cuò)容侵能力；在此基礎(chǔ)上，提出的選調(diào)策略和判決機(jī)制，可以有效提升系統(tǒng)的異構(gòu)度和判決的準(zhǔn)確性，進(jìn)一步提升安全性能.

軟件定義網(wǎng)絡(luò)；主動(dòng)防御；擬態(tài)安全防御；動(dòng)態(tài)異構(gòu)冗余；網(wǎng)絡(luò)操作系統(tǒng)

軟件定義網(wǎng)絡(luò)(software defined networking, SDN)將傳統(tǒng)數(shù)據(jù)平面和控制平面解耦，在邏輯上實(shí)現(xiàn)了網(wǎng)絡(luò)的集中控制，使得網(wǎng)絡(luò)配置、網(wǎng)絡(luò)服務(wù)部署等都在網(wǎng)絡(luò)操作系統(tǒng)(network operating system, NOS, 也稱SDN控制器)之上實(shí)現(xiàn)，有利于簡化網(wǎng)絡(luò)管理.然而，SDN應(yīng)用實(shí)際生產(chǎn)環(huán)境時(shí)仍面臨嚴(yán)峻的安全問題.首先，SDN控制器集中管理著其覆蓋網(wǎng)絡(luò)的所有視圖信息，因此，極易成為攻擊的首選目標(biāo)，帶來額外的安全風(fēng)險(xiǎn).其次，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)特性有利于攻擊者對(duì)其進(jìn)行探測和分析.作為SDN的核心組件，控制器掌握著整個(gè)網(wǎng)絡(luò)的視圖，將上層策略轉(zhuǎn)譯為數(shù)據(jù)平面的轉(zhuǎn)發(fā)規(guī)則，一旦被攻擊或劫持，可導(dǎo)致信息泄漏，甚至網(wǎng)絡(luò)癱瘓.

一般地，針對(duì)SDN控制層的攻擊主要出于2個(gè)目的：操縱網(wǎng)絡(luò)流量或癱瘓網(wǎng)絡(luò).操縱網(wǎng)絡(luò)流量的攻擊，一般利用控制器的漏洞，如控制器缺少對(duì)上層APP權(quán)限管理的漏洞，導(dǎo)致帶毒APP下發(fā)惡意流表規(guī)則[2-3]，以及控制器對(duì)LLDP(link layer discovery protocol)包缺少安全認(rèn)證(或者如Floodlight，雖然提供鑒別碼認(rèn)證，但是鑒別碼一直保持不變)的漏洞造成的拓?fù)鋫卧旃艉椭虚g人流表篡改攻擊[4]等.癱瘓網(wǎng)絡(luò)的攻擊，如存在惡意管理員[5]，使用一個(gè)簡單的exit命令致使Floodlight宕機(jī)造成網(wǎng)絡(luò)癱瘓，或者通過發(fā)送探測報(bào)文推斷控制器類型、消息處理邏輯和負(fù)載狀態(tài)等信息和發(fā)動(dòng)DoS攻擊等[6].總之，利用控制器的漏洞發(fā)動(dòng)攻擊是控制器面臨的主要威脅之一[7].

為應(yīng)對(duì)上述安全問題，已有大量研究給出了防御方法.有研究者提出了為控制器增設(shè)北向接口的分級(jí)調(diào)用[8]和南向接口的限制訪問[9]以解決上述北向APP權(quán)限和南向探測等漏洞問題，然而這類方法具有侵入性，需修改控制器南北向接口(甚至內(nèi)核)，并且這種“打補(bǔ)丁式”的防御手段無法根本上解決漏洞、后門等問題.因此，有研究者從架構(gòu)上提出了分布式控制器[10-13]和彈性控制平面[14-15]，這些結(jié)構(gòu)可以有效解決SDN控制層呈現(xiàn)的靜態(tài)特性問題和單點(diǎn)失效造成的網(wǎng)絡(luò)癱瘓等攻擊問題，然而目前主流的分布式架構(gòu)中控制器仍是同構(gòu)的，同一漏洞[16-17]即可能導(dǎo)致所有實(shí)例陷入癱瘓，另外，同基于拜占庭容錯(cuò)(Byzantine fault tolerance, BFT)機(jī)制的控制平面一樣[18-19]，上述方法控制器間都不可避免地相互通信，增大了攻擊表面，易導(dǎo)致攻擊感染.

本文將鄔江興院士提出的擬態(tài)安全防御思想[20]引入到SDN控制層，提出了擬態(tài)網(wǎng)絡(luò)操作系統(tǒng) (mimic network operating system, MNOS)，一種具有動(dòng)態(tài)異構(gòu)冗余特性[21]的SDN安全架構(gòu)，該架構(gòu)在數(shù)據(jù)層和控制層間增加擬態(tài)層，動(dòng)態(tài)調(diào)度若干異構(gòu)控制器提供網(wǎng)絡(luò)服務(wù)，并對(duì)其并行輸出進(jìn)行一致性判決，從中選取最可信的結(jié)果.本文的主要貢獻(xiàn)有3個(gè)方面：

1) 基于擬態(tài)防御思想，設(shè)計(jì)了擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)架構(gòu)，并對(duì)Floodlight,Ryu,ONOS這3種主流開源SDN控制器進(jìn)行開發(fā)，實(shí)現(xiàn)了原型驗(yàn)證機(jī)POC(proof of concept).實(shí)驗(yàn)評(píng)估證明，在增加一定的時(shí)延開銷下，MNOS可以有效保障SDN控制層安全；

2) 提出了一種基于異構(gòu)度增益的選調(diào)策略，通過增加選調(diào)前后系統(tǒng)的異構(gòu)程度，進(jìn)一步提升MNOS的安全性能；

3) 優(yōu)化MNOS的判決機(jī)制，在考慮先驗(yàn)知識(shí)的情況下，提升判決的準(zhǔn)確性.

1 相關(guān)工作

SDN在提供便于管理的控制層的同時(shí)，也使其極易遭受攻擊，目前，針對(duì)控制層安全防御的研究，可以分為2個(gè)方向.

1.1改進(jìn)型方案

改進(jìn)型安全控制器的防御思路是在現(xiàn)有開源控制器的基礎(chǔ)上，改進(jìn)已有的安全服務(wù)或開發(fā)部署新的安全模塊.目前，已有諸多研究者對(duì)NOX, Floodlight等控制器進(jìn)行了安全功能的拓展，如FortNOX[22], SE-Floodlight[23]等.

FortNOX架構(gòu)是Porras等人[22]針對(duì)NOX控制器設(shè)計(jì)的一種安全內(nèi)核，為其提供基于角色的數(shù)據(jù)源認(rèn)證、狀態(tài)表管理、流表規(guī)則沖突分析、流表規(guī)則超時(shí)回調(diào)等安全功能，提升NOX控制器在流規(guī)則沖突檢測方面的安全性能.在NOX基礎(chǔ)上，Porras等人又對(duì)Floodlight進(jìn)行了類似安全拓展，設(shè)計(jì)了其安全增強(qiáng)版本SE-Floodlight[23]，增加了應(yīng)用程序證書管理模塊、權(quán)限管理等新的安全模塊.

通過附加安全機(jī)制或修補(bǔ)安全漏洞的方式，使得研究者和開發(fā)人員比較被動(dòng)，很難在短時(shí)間內(nèi)有效提升控制器的安全性，并且這些“打補(bǔ)丁式”的改進(jìn)型也無法從根本上解決控制層的安全漏洞問題.

Fig. 1 The overview of MNOS圖1 MNOS整體架構(gòu)

1.2革新型方案

針對(duì)1.1節(jié)的問題，一些研究者提倡在SDN控制器的設(shè)計(jì)和開發(fā)之初，便將安全性作為其核心問題之一進(jìn)行考慮，從而突破已有控制器在系統(tǒng)架構(gòu)、編程語言和預(yù)留接口等方面的限制，開發(fā)出全新的、內(nèi)嵌安全機(jī)制的SDN控制器.

Shin等人[24]提出了Rosemary架構(gòu)，為實(shí)現(xiàn)對(duì)上層APP的管理，將其所有應(yīng)用程序運(yùn)行在一個(gè)封閉的應(yīng)用程序區(qū)內(nèi)，實(shí)時(shí)監(jiān)控各個(gè)應(yīng)用程序的行為，并通過檢查各個(gè)應(yīng)用程序的簽名信息判定其是否為合法應(yīng)用程序.然而，由于Rosemary系統(tǒng)對(duì)應(yīng)用程序的簽名方式是基于角色的簽名機(jī)制，并將整個(gè)應(yīng)用程序作為一個(gè)整體對(duì)其進(jìn)行簽名，因而無法較好地對(duì)應(yīng)用程序各個(gè)模塊的訪問權(quán)限進(jìn)行細(xì)粒度控制.Ferguson等人[25]設(shè)計(jì)了內(nèi)嵌安全機(jī)制PANE用于解決SDN中不可信用戶訪問請(qǐng)求之間的沖突問題.此外，針對(duì)控制器的單點(diǎn)失效問題，有研究者提出了分布式控制器，如HyperFlow[10]，作為應(yīng)用程序運(yùn)行于安裝NOX的控制器之上，采用物理分布但邏輯集中的設(shè)計(jì)，因此可以在保證良好可拓展性的同時(shí)實(shí)現(xiàn)網(wǎng)絡(luò)的集中管控，并且被動(dòng)同步網(wǎng)絡(luò)狀態(tài)視圖，賦予各個(gè)控制器決策權(quán)以降低數(shù)據(jù)層和控制層的時(shí)延.FlowVisor[11]則是在轉(zhuǎn)發(fā)平面與控制平面之間引入了一個(gè)軟件切片層實(shí)現(xiàn)控制消息切分.還有如文獻(xiàn)[18-19]提出了基于拜占庭容錯(cuò)機(jī)制的控制層安全架構(gòu)，通過拜占庭的一致性協(xié)議，檢查點(diǎn)協(xié)議以及視圖更換協(xié)議，實(shí)現(xiàn)多控制器間網(wǎng)絡(luò)狀態(tài)視圖的一致以及對(duì)控制層的容錯(cuò)/容侵功能.在經(jīng)典拜占庭模型下，當(dāng)系統(tǒng)3f+1個(gè)控制器時(shí)，可以最多容忍f個(gè)錯(cuò)誤；而改進(jìn)的拜占庭，可以只需2f+1個(gè)即可實(shí)現(xiàn)容忍[26].

除此之外，在相關(guān)的防御手段上，如由美國網(wǎng)絡(luò)與信息技術(shù)研究與發(fā)展(networking and information technology research and development, NITRD)計(jì)劃近年來提出的移動(dòng)目標(biāo)防御(moving target defense, MTD)模型[27]，其主要通過構(gòu)建動(dòng)態(tài)冗余網(wǎng)絡(luò)增加不確定性，從而增加攻擊難度.不同于擬態(tài)防御，MTD每個(gè)周期只選取1個(gè)執(zhí)行體提供服務(wù).

總的來說，上述分布式架構(gòu)雖然可以有效單點(diǎn)失效等問題，但由于采用同構(gòu)控制器，且控制器間相互通信，因此仍可能面臨攻擊感染等問題.

2 MNOS架構(gòu)

本文提出的擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)(MNOS)主要是將動(dòng)態(tài)異構(gòu)冗余模型引入SDN控制層中，以實(shí)現(xiàn)控制層內(nèi)生安全性.如圖1所示為MNOS的整體框架，其中虛線框內(nèi)即為本文提出的擬態(tài)層部分，下面對(duì)MNOS各模塊分別進(jìn)行介紹.

2.1擬態(tài)控制協(xié)議

本文設(shè)計(jì)的擬態(tài)控制協(xié)議格式如圖2所示:

Fig. 2 Mimic Protocol
圖2 擬態(tài)控制協(xié)議

擬態(tài)控制協(xié)議運(yùn)行在擬態(tài)層部分，即圖1中虛線框內(nèi)(虛線框內(nèi)的虛線箭頭表示擬態(tài)控制協(xié)議報(bào)文，框外的實(shí)線箭頭表示OpenFlow協(xié)議報(bào)文).之所以設(shè)計(jì)自定義協(xié)議而不直接采用現(xiàn)有的OpenFlow協(xié)議，是因?yàn)槠洳荒軡M足本文的動(dòng)態(tài)調(diào)度、判決(需要對(duì)NOS進(jìn)行標(biāo)識(shí))等模塊功能.擬態(tài)控制協(xié)議類型(type)目前主要分為2類：1) 控制報(bào)文，主要是NOS與擬態(tài)層的交互，如NOS注冊(cè)消息和保活消息；2) 數(shù)據(jù)報(bào)文，數(shù)據(jù)域data主要為OpenFlow等SDN南向協(xié)議報(bào)文.nos_id/app_id字段主要是NOS及其上運(yùn)行APP的標(biāo)志，在NOS初始化注冊(cè)時(shí)，由擬態(tài)層分配，便于擬態(tài)層管理.role字段由擬態(tài)層標(biāo)明NOS的角色，主要為master或slave.xid為會(huì)話標(biāo)志，便于判決時(shí)比對(duì).

2.2南、北向代理層

南、北向代理層主要都是擬態(tài)控制協(xié)議的封裝、解封裝，即進(jìn)入擬態(tài)層的報(bào)文封裝為擬態(tài)控制協(xié)議，反之則解封裝出數(shù)據(jù)域OpenFlow報(bào)文.

1) 南向代理層.之所以增加南向代理層(實(shí)際上擬態(tài)核心層也可以完成其功能)，主要是出于安全的考慮：擬態(tài)核心層功能復(fù)雜，涉及狀態(tài)信息等，若直接對(duì)外呈現(xiàn)，則易受攻擊(攻擊面大).而增加了功能實(shí)現(xiàn)較為簡單的南向代理層后，從底層交換機(jī)的角度上看，南向代理層即為SDN控制器，從而實(shí)現(xiàn)擬態(tài)核心層對(duì)數(shù)據(jù)層的透明無感，從而保障MNOS的系統(tǒng)安全.

由上述分析，南向代理層可以采用專用硬件如NetFPGA實(shí)現(xiàn)，降低其遭受攻擊的概率.

2) 北向代理層.同南向代理層類似，北向代理層主要面向SDN控制器及其上運(yùn)行的APP應(yīng)用，因此從控制層的角度看，北向代理層被視為底層交換機(jī).

由于本文采用異構(gòu)的SDN控制器，如Floodlight,Ryu,ONOS，具體實(shí)現(xiàn)不同，但實(shí)現(xiàn)方法和邏輯類似.本文針對(duì)不同控制器類型開發(fā)APP(模塊)，運(yùn)行在SDN控制器上實(shí)現(xiàn)北向代理功能，其主要包含2個(gè)接口：與SDN控制器(以及APP)間通信接口和與擬態(tài)核心層間通信接口.邏輯功能主要為SDN控制器消息的攔截、報(bào)文封裝和虛假交換機(jī)實(shí)現(xiàn).不同控制器“攔截”實(shí)現(xiàn)不同，如Ryu控制器，我們是通過重寫datapath中的send_msg函數(shù)(增加封裝、解封裝擬態(tài)控制協(xié)議部分)實(shí)現(xiàn)的；而虛假交換機(jī)主要是為了完成底層交換機(jī)的“模擬”，實(shí)現(xiàn)對(duì)控制器的透明無感.

2.3消息隊(duì)列

由于MNOS系統(tǒng)內(nèi)部需要協(xié)調(diào)異構(gòu)系統(tǒng)大量的通信，目前主流的異構(gòu)系統(tǒng)通信的方法有2種：1)RPC(遠(yuǎn)程協(xié)議調(diào)用);2)消息隊(duì)列.鑒于目前開源社區(qū)有較成熟的消息隊(duì)列框架，本文選擇基于消息隊(duì)列的異構(gòu)子系統(tǒng)通信實(shí)現(xiàn).

就目前而言，主流的消息隊(duì)列框架包括：RabbitMQ,ActiveMQ，ZeroMQ.RabbitMQ是AMQP協(xié)議領(lǐng)先的一個(gè)實(shí)現(xiàn)，它實(shí)現(xiàn)了代理(Broker)架構(gòu)，意味著消息在發(fā)送到客戶端之前可以在中央節(jié)點(diǎn)上排隊(duì).此特性使得RabbitMQ易于使用和部署，適宜于很多場景如路由、負(fù)載均衡或消息持久化等.但是，這使得它的可擴(kuò)展性差，速度較慢，因?yàn)橹醒牍?jié)點(diǎn)增加了延遲，消息封裝后也較大.

ZeroMQ (ZMQ)是一個(gè)非常輕量級(jí)的消息系統(tǒng)，專門為高吞吐量/低延遲的場景開發(fā)，在金融界應(yīng)用廣泛，與RabbitMQ相比，ZMQ支持許多高級(jí)消息場景.更重要的是，由于本文需要在多個(gè)控制器間進(jìn)行調(diào)度，同時(shí)涉及關(guān)閉某些控制器(進(jìn)行清洗)后重新啟動(dòng)等操作，而ZMQ對(duì)連續(xù)的斷開連接、重連接等都很友好，支持度高，適合本文應(yīng)用場景，因此采用ZMQ實(shí)現(xiàn).

2.4擬態(tài)核心層

擬態(tài)核心層是MNOS功能核心部分，主要負(fù)責(zé)NOS的管理、調(diào)度和判決等功能，相應(yīng)地，其邏輯架構(gòu)包含NOS管理器、選調(diào)器和判決器.

2.4.1 NOS管理器

NOS管理器主要負(fù)責(zé)NOS管理和NOS狀態(tài)維護(hù)2個(gè)功能，下面分別進(jìn)行介紹：

1) NOS狀態(tài)維護(hù).NOS管理器維護(hù)的控制器狀態(tài)信息如圖3中NOS類所示：

Fig. 3 Status information of NOS圖3 NOS的狀態(tài)信息

每個(gè)新加入的控制器都必須在初始化階段向NOS管理器注冊(cè)，由管理器分配其唯一標(biāo)識(shí)的nos_id, 并確定控制器類型nos_kind，如Floodlight,Ryu,ONOS等；app_id和app_kind同控制器注冊(cè)時(shí)類似，這2個(gè)變量是為了維護(hù)該控制器上運(yùn)行的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管理器負(fù)責(zé)，主要工作是NOS初始化時(shí)的網(wǎng)絡(luò)狀態(tài)同步，由NOS管理器負(fù)責(zé)；變換②～③由選調(diào)器負(fù)責(zé)，確定控制器的工作狀態(tài)、角色，這部分在2.4.2節(jié)介紹；變換④～⑥由判決器負(fù)責(zé)，主要發(fā)生在發(fā)現(xiàn)控制器可疑或者去可疑時(shí)，這部分在2.4.3節(jié)介紹.

2) NOS管理.得益于docker、NFV、云等虛擬化技術(shù)，我們可以很方便地新增控制器(鏡像)進(jìn)行拓展，如圖4所示，這里新增控制器也有可能是判決器發(fā)現(xiàn)可疑控制器，最后決定刪除而重新初始化的控制器(變換⑥).但新增控制器不能立即投入使用，因?yàn)樯婕熬W(wǎng)絡(luò)狀態(tài)信息和APP狀態(tài)等問題，因此首先需要對(duì)其進(jìn)行網(wǎng)絡(luò)狀態(tài)同步，完成圖4中變換①.

狀態(tài)同步的步驟如圖5所示:

Fig. 5 State synchronization圖5 狀態(tài)同步流程

其中Floodlight表示正常運(yùn)行的控制器，ONOS為新增待同步的控制器，switch表示底層交換機(jī)(實(shí)際應(yīng)該分別為南、北向代理層，這里是為描述簡便)，core表示擬態(tài)核心層.以路由APP為例，具體步驟如下：

① 時(shí)刻t0擬態(tài)核心層收到ONOS的初始注冊(cè)消息，新建該控制器的狀態(tài)信息，即nos_id,nos_kind等，并將狀態(tài)設(shè)置為“初始態(tài)”；

② 擬態(tài)核心層向Floodlight發(fā)送獲取狀態(tài)的擬態(tài)控制協(xié)議報(bào)文，同時(shí)將時(shí)刻t0以后收到的switch報(bào)文進(jìn)行緩存而不再發(fā)往Floodlight(如圖5中圓柱體)；

③ 收到Floodlight發(fā)送的時(shí)刻t0的狀態(tài)(對(duì)于路由APP，狀態(tài)信息即為路由表，F(xiàn)loodlight的節(jié)點(diǎn)路由表狀態(tài)信息存放于TopologyInstance中的pathcache變量中)后，將其數(shù)據(jù)進(jìn)行轉(zhuǎn)換(適用于ONOS的數(shù)據(jù))后發(fā)送給初始態(tài)的ONOS進(jìn)行狀態(tài)同步(此時(shí)同步的是時(shí)刻t0的狀態(tài))，同時(shí)將緩存的報(bào)文發(fā)往Floodlight進(jìn)行處理；

④ 在時(shí)刻t2，F(xiàn)loodlight正常處理報(bào)文，并將緩存的報(bào)文和后續(xù)到達(dá)的報(bào)文依次發(fā)往ONOS進(jìn)行處理；

⑤ 在ONOS完成狀態(tài)同步(處理完緩存報(bào)文后)向擬態(tài)核心層確認(rèn)后，將其狀態(tài)信息由“初始態(tài)”變換為“空閑態(tài)”，等待選調(diào)模塊的調(diào)用.

需要說明的是，若正常工作(激活態(tài)或空閑態(tài))的控制器中有相同類型的控制器，可直接用其進(jìn)行同步，無需進(jìn)行數(shù)據(jù)轉(zhuǎn)換的步驟.

2.4.2 選調(diào)器

選調(diào)器主要負(fù)責(zé)控制器的調(diào)度，實(shí)現(xiàn)動(dòng)態(tài)性，即圖3中的變換②～③.為確保控制器的視圖一致，本文采用類似OpenFlow協(xié)議的slave/master方法實(shí)現(xiàn)選調(diào)，不同的是OpenFlow協(xié)議中控制器集群只有一個(gè)master, slave只有在master無法正常工作時(shí)才修改為master(主要是應(yīng)對(duì)單點(diǎn)失效等故障)，而本文是將多個(gè)控制器同時(shí)設(shè)為master.具體地，若北向代理層收到的擬態(tài)控制協(xié)議報(bào)文中role字段為master，則將其交付控制器處理并正常下發(fā)消息；反之，若為slave，則北向代理交付控制器處理后對(duì)其消息進(jìn)行攔截而不下發(fā).

因此，首先選調(diào)器根據(jù)選調(diào)策略選取出m(m一般為不小于3的奇數(shù))個(gè)控制器后，將其狀態(tài)信息由空閑態(tài)設(shè)為激活態(tài)，其余設(shè)為空閑態(tài)，而后只需根據(jù)各控制器的狀態(tài)，在分發(fā)消息給各控制器時(shí)，在role字段填入slave/master (0/1) 即可：對(duì)于空閑態(tài)和初始態(tài)的控制器，該字段設(shè)為slave(初始化的控制器不具備正常工作的能力)；激活態(tài)和可疑態(tài)的，設(shè)為master(由于可疑的控制器需要進(jìn)一步考察，因此需要其回復(fù)所有的消息請(qǐng)求，便于判決器與其他控制器的響應(yīng)進(jìn)行比對(duì)，確認(rèn)其可信與否).具體的選調(diào)策略將在第3節(jié)進(jìn)行介紹.

2.4.3 判決器

判決器主要負(fù)責(zé)對(duì)多個(gè)控制器的響應(yīng)報(bào)文進(jìn)行判決，判定最可靠的響應(yīng).判決機(jī)制在數(shù)據(jù)融合等領(lǐng)域有很多研究，以最簡單的大數(shù)判決為例.當(dāng)判決器收到m份響應(yīng)中(由2.4.2節(jié)可知，只有role字段為master的控制器才會(huì)響應(yīng))有大于或等于(m+1)/2份結(jié)果一致時(shí)，則判定該結(jié)果為有效響應(yīng)，發(fā)往南向代理層(最終到交換機(jī))；而對(duì)于其余和該結(jié)果不一致的控制器，則判定為可疑，將其狀態(tài)由激活態(tài)改為可疑態(tài)(圖3中的變換④)，然后著重對(duì)其進(jìn)行考察，若后期仍多次出現(xiàn)不一致的情況，則向NOS管理器通告，將其刪除，并重新初始化新的控制器實(shí)例(圖3中變換⑥)，反之，則重新設(shè)為空閑態(tài)(去可疑，圖3中變換⑤).

上述判決機(jī)制是基于一個(gè)假設(shè)：多數(shù)控制器同時(shí)被攻擊且攻擊后輸出一致的錯(cuò)誤響應(yīng)的概率極低.尤其是本文采用的異構(gòu)控制器，攻擊者需要對(duì)多種控制器進(jìn)行漏洞挖掘，因此攻擊者成功實(shí)施攻擊的難度將會(huì)進(jìn)一步增加[16-17].具體的判決機(jī)制將在第4節(jié)進(jìn)行介紹.

3 選調(diào)策略

第2節(jié)我們給出了選調(diào)器的工作原理，在本節(jié)中，我們?cè)敿?xì)介紹本文選調(diào)器的選調(diào)策略.

多樣性，即異構(gòu)配置，是指對(duì)集合中冗余實(shí)例采用相同功能但軟件或硬件不同的配置，以增加系統(tǒng)的多樣性[16-17].通過引入多樣性增強(qiáng)網(wǎng)絡(luò)安全的方法已成為研究熱點(diǎn)并廣泛應(yīng)用，這種配置方法可以有效避免因同一種軟件或硬件的漏洞、后門等造成共模故障，使整個(gè)冗余系統(tǒng)遭受毀滅性攻擊[16-17].因此，本文提出一種基于異構(gòu)度增益的選調(diào)策略，即最大化MNOS系統(tǒng)中控制器異構(gòu)度.用到的符號(hào)、變量如表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)控制器的動(dòng)態(tài)遷移)，異構(gòu)度增益源于軟硬件2個(gè)方面，即DGH,DGK為最大化:

(1)

DGH,DGK的計(jì)算方法如式(2)所示，且由于選調(diào)后切換的時(shí)延等因素，所以需對(duì)遷移開銷(如遷移數(shù)量)進(jìn)行限制：

(2)

顯然，若新選取的控制器軟件或硬件不同于當(dāng)前激活態(tài)控制器集中的，則其帶來的異構(gòu)度增益大于相同的情況，因此，式(2)中變量關(guān)系滿足ε1<ε2, ?1

式(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)度的控制器，然后對(duì)其進(jìn)行考察，按照式(1)(2)的原則選取候選控制器.最破壞系統(tǒng)異構(gòu)度的控制器即某類型控制器數(shù)量最多的控制器.例如，某時(shí)刻激活態(tài)控制器集共有4種控制器，分別是3臺(tái)Ryu,一臺(tái)ONOS,一臺(tái)ODL和0臺(tái)Floodlight，那么在進(jìn)行這一輪選調(diào)時(shí)，我們優(yōu)先選擇其中的一臺(tái)Ryu進(jìn)行遷移(移出激活態(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的時(shí)間復(fù)雜度可近似為O(min(|Ccur|,φc)(|C|-|Ccur|))，所以復(fù)雜度最大為O(|Ccur|(|C|-|Ccur|))≤O(|C|24).

4 判決機(jī)制

判決器的任務(wù)是從各激活態(tài)控制器的響應(yīng)報(bào)文中比對(duì)，抉擇出最可信的響應(yīng)回復(fù)給底層交換機(jī)，并記錄可疑控制器.主要涉及2個(gè)關(guān)鍵點(diǎn)：比對(duì)內(nèi)容和判決方法.在比對(duì)內(nèi)容(粒度)方面，顯然，若比對(duì)粒度為比特級(jí)，則計(jì)算量過大，因此，本文根據(jù)OpenFlow消息的格式進(jìn)行字段級(jí)比對(duì)，著重考察2個(gè)關(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ù)器上.此時(shí)，判決器只需比對(duì)各控制器的match字段和action字段，從中選取較可靠的響應(yīng)(output=1)下發(fā)給交換機(jī).

Fig. 6 Modifying flow rule attack圖6 流表篡改攻擊

上述示例采用的判決方法是2.4.3節(jié)中簡單的大數(shù)裁決機(jī)制(majority-bases decision)，實(shí)現(xiàn)容錯(cuò)/容侵功能.但是這種方法多次判決之間相互獨(dú)立(每一次判決只和當(dāng)前接收的響應(yīng)有關(guān))，無法有效利用先驗(yàn)知識(shí)，因此，本文優(yōu)化判決機(jī)制，在考慮先驗(yàn)知識(shí)的情況下提升判決的準(zhǔn)確性.

4.1問題描述

假設(shè)有m個(gè)激活態(tài)控制器，存在若干拜占庭(惡意)控制器，每個(gè)控制器對(duì)同一OpenFlow消息(如packet in報(bào)文)進(jìn)行處理后返回響應(yīng)報(bào)文，我們用f=(f1,f2,…,fl)′表示真正正確的響應(yīng)報(bào)文，共有l(wèi)個(gè)字段，其中fi為01位序列，表示待比對(duì)的第i字段(例如actions中output字段)，fi,j為該字段的第j位(fi,j={0,1},j=1,2,…,hi),hi為第i字段所占位數(shù).如圖7所示，其中表示第k個(gè)控制器處理后的原始響應(yīng)報(bào)文中第i字段的第j位，而則表示為該控制器實(shí)際向判決器返回的報(bào)文.顯然，一般而言，正常情況下應(yīng)當(dāng)滿足但是若控制器被攻擊，變?yōu)閻阂饪刂破鳎敲纯赡芫陀屑僭O(shè)惡意控制器反轉(zhuǎn)該結(jié)果的概率為Pmal(Pmal=P(oi,j≠ri,j)).因此判決器的目標(biāo)就是在這些可能含有被篡改的報(bào)文中判決出最真實(shí)可靠的報(bào)文.

Fig. 7 Decision fusion scheme圖7 判決場景

4.2判決機(jī)制優(yōu)化

由4.1節(jié)可知，判決器的任務(wù)可以轉(zhuǎn)化為求解：

(3)

由貝葉斯定理和所有可能的響應(yīng)都是等概率發(fā)生可知，式(3)等價(jià)于：

(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多級(jí)流表的思想，將式(5)分解轉(zhuǎn)化為多級(jí)相加，即單獨(dú)求解各個(gè)字段的最優(yōu)解，可得：

(6)

于是由各個(gè)字段的解可以組合出最優(yōu)解f*.此外，我們考慮存在系統(tǒng)誤差概率ε,ε=p(oi,j≠fi,j)用于描述控制器的系統(tǒng)錯(cuò)誤概率，于是正常控制器和惡意控制器最后返回給判決器的結(jié)果不同于真正正確的結(jié)果的概率可以分別表示為

(7)

(8)

因此，將式(7)(8)的結(jié)論代入，可將式(6)轉(zhuǎn)化為

(9)

我們假設(shè)攻擊者對(duì)每個(gè)控制器以相同的概率α成功實(shí)施攻擊，使其變?yōu)閻阂饪刂破鳎⑶矣捎诳刂破鏖g相互異構(gòu)，所以可以認(rèn)為各個(gè)控制器被攻擊的狀態(tài)相互獨(dú)立，因此：

(10)

其中，當(dāng)ak=1時(shí)，PA(ak)=α(一般假設(shè)α<0.5，否則，若半數(shù)以上為惡意控制器，則判決器就不可能做出正確的決策).將式(10)代入式(9)，可得：

(11)

對(duì)于其他字段類似式(11)計(jì)算可得.由式(11)可知，判決器一次完整數(shù)據(jù)融合最大的計(jì)算復(fù)雜度與激活態(tài)控制器個(gè)數(shù)m和比對(duì)的字段數(shù)l呈線性關(guān)系，而與每個(gè)字段所占位數(shù)hi呈指數(shù)關(guān)系，因此hi不宜過大，而OpenFlow協(xié)議1.0版本中，actions中位數(shù)最大的為“modify Ethernet sourcedestination MAC address”(修改源、目的MAC地址)48 b，對(duì)此可以繼續(xù)采用分解的方法，將其劃為多個(gè)子字段，以降低每個(gè)子字段的位數(shù).

5 實(shí)驗(yàn)仿真

本節(jié)對(duì)MNOS性能、選調(diào)策略和判決機(jī)制進(jìn)行實(shí)驗(yàn)評(píng)估.我們采用3種開源控制器Ryu, Floodlight, ONOS，在9臺(tái)華為服務(wù)器(RH2288H V3)和1臺(tái)Pica8 (P3297)交換機(jī)上搭建實(shí)驗(yàn)環(huán)境，具體地，3臺(tái)運(yùn)行Floodlight、2臺(tái)運(yùn)行ONOS、4臺(tái)服務(wù)器運(yùn)行Ryu(其中1臺(tái)同時(shí)運(yùn)行南向代理層、1臺(tái)同時(shí)運(yùn)行擬態(tài)核心層).

5.1MNOS安全性能

5.1.1 攻擊成功概率仿真

首先對(duì)MNOS的安全性能進(jìn)行評(píng)估對(duì)比.本文主要與移動(dòng)目標(biāo)防御模型(MTD)[27]和基于拜占庭容錯(cuò)(BFT)的SDN控制層[18-19]架構(gòu)進(jìn)行對(duì)比.

由于MTD架構(gòu)下，每個(gè)周期只選取1個(gè)執(zhí)行體提供服務(wù)，因此，可認(rèn)為MTD是擬態(tài)防御在m=1時(shí)的特例.并且由于改進(jìn)的BFT[26]，可在2f+1冗余情況下實(shí)現(xiàn)f個(gè)錯(cuò)誤容忍，因此改進(jìn)BFT在最終效果上等同于進(jìn)行了大數(shù)判決，可視為靜態(tài)MNOS，即沒有動(dòng)態(tài)選調(diào)功能，只能一直由m個(gè)控制器提供服務(wù).

在具體的仿真設(shè)置上，假設(shè)共有N個(gè)異構(gòu)控制器，每個(gè)周期選取m個(gè)作為激活態(tài)，攻擊者在一個(gè)周期的有效時(shí)間內(nèi)可同時(shí)對(duì)w個(gè)控制器發(fā)起攻擊(隨機(jī)選取w個(gè)).由于采用了異構(gòu)配置，因此可以假設(shè)攻擊不同控制器相互獨(dú)立，且假設(shè)對(duì)每個(gè)控制器的攻擊成功概率都為Pa.因此，MNOS架構(gòu)下若要攻擊成功必須滿足：1)有超過半數(shù)((m+1)2)的激活態(tài)控制器被選擇攻擊；2)成功攻擊.因此攻擊成功概率可表示為

(12)

其中，前項(xiàng)積分表示攻擊者選擇攻擊的w個(gè)控制器中有u個(gè)為激活態(tài)的概率，后項(xiàng)積分表示在u個(gè)激活態(tài)控制器中攻擊成功v個(gè)概率和，這里采用大數(shù)判決機(jī)制，因此只有當(dāng)u,v≥(m+1)2才可能攻擊成功.

而MTD架構(gòu)下，攻擊者選擇正確的攻擊目標(biāo)的概率為wN，因此攻擊成功概率可表示為(也可由式(12)取m=1得到)：

(13)

而改進(jìn)拜占庭架構(gòu)下，攻擊者需要成功攻擊半數(shù)以上控制器，可表示為(也可直接由式(12)取N=m得)：

(14)

圖8所示為攻擊成功概率與Pa和每個(gè)時(shí)間間隔攻擊者可同時(shí)攻擊的控制器數(shù)量w的關(guān)系.可見，整體上，攻擊成功概率都隨攻擊能力w增加而增加；而MTD架構(gòu)下，攻擊成功概率呈線性增加，且遠(yuǎn)高于MNOS和BFT模型；而BFT模型也要高于本文的MNOS架構(gòu)，由式(12)和式(14)對(duì)比可知，這是由于MNOS的動(dòng)態(tài)選調(diào)降低了攻擊者攻擊激活態(tài)控制器的概率導(dǎo)致的，而當(dāng)w≥5概率不再增加；而本文的MNOS安全性能明顯優(yōu)于其他2種架構(gòu)(本文MNOS在m=5,w=11時(shí)與BFT架構(gòu)結(jié)果一致，因?yàn)榇藭r(shí)攻擊者可攻擊全部控制器)，且性能隨m值的增加而增加，當(dāng)然，時(shí)延開銷等也會(huì)相應(yīng)增加，后文將就時(shí)延代價(jià)等問題進(jìn)行分析.

Fig. 8 Successful attack probability圖8 攻擊成功概率

5.1.2 入侵容忍能力驗(yàn)證

Fig. 9 Log file on decider圖9 判決器log文件信息

我們對(duì)MNOS的容錯(cuò)/容侵能力進(jìn)行了測試，驗(yàn)證圖6所示場景.在擬態(tài)核心層判決器處收到3個(gè)控制器下發(fā)的OpenFlow的FLOW_MOD(規(guī)則下發(fā))報(bào)文如圖9所示，我們修改了其中一個(gè)控制器上的APP代碼(下發(fā)規(guī)則模塊)，模擬惡意APP攻擊[28].可見，其中一個(gè)output字段由原1端口被篡改為3端口，此時(shí)判決器仍選擇1端口(大數(shù)判決)，實(shí)現(xiàn)容錯(cuò)/容侵.顯然，若激活態(tài)控制器數(shù)量為m，則若采用大數(shù)判決機(jī)制可容忍至多(m-1)/2個(gè)控制器故障，即攻擊者至少需成功攻擊(m+1)/2個(gè)控制器.并且由于采用了動(dòng)態(tài)選調(diào)策略，限制了攻擊的連續(xù)有效時(shí)間(一個(gè)切換周期)，進(jìn)一步增加了攻擊難度.

5.1.3 時(shí)延開銷及壓力測試

最后由于引入了冗余控制器，并增設(shè)了擬態(tài)層，涉及選調(diào)、判決等模塊，因此本文對(duì)傳統(tǒng)單一控制器和MNOS的處理時(shí)延和吞吐量進(jìn)行了對(duì)比分析評(píng)估.為了更好地描述和分析MNOS引入的額外時(shí)延開銷，給出本節(jié)涉及的相關(guān)符號(hào)和定義，如表2所示：

Table 2 Definitions and Notations

因此，傳統(tǒng)單一控制器的時(shí)延可以表示為(這里的傳輸時(shí)延(含傳播時(shí)延)為往返的時(shí)延)：

Toriginal=Tt d_ds+Tp d_c,

(15)

而MNOS的時(shí)延可以表示為

(16)

因此，額外增加的時(shí)延可以表示為

(17)

考慮到南、北向代理的工作主要為報(bào)文封裝、解封裝，這部分處理時(shí)延較小，將其忽略，則式(14)可近似為

(18)

為分析上述各部分時(shí)延，下面給出MNOS的時(shí)延測試結(jié)果，我們采用圖5所示的拓?fù)洌瑴y試2個(gè)主機(jī)間的ping包時(shí)延(刪除了控制器中流表下發(fā)部分代碼，目的是讓所有數(shù)據(jù)包都經(jīng)由控制器處理，便于測試并統(tǒng)計(jì)時(shí)延).結(jié)果如圖10所示，其中Original(加粗點(diǎn)劃線)表示傳統(tǒng)單一控制器.

Fig. 10 Time delay test圖10 時(shí)延測試

1) 傳統(tǒng)單一控制器和無冗余MNOS對(duì)比.即圖9中加粗點(diǎn)劃線(Original)與三角劃線的第1點(diǎn)(單個(gè)控制器即無冗余下的MNOS)進(jìn)行對(duì)比，可以體現(xiàn)由MNOS新增的多邏輯層傳輸時(shí)延，即Tt d_sm+Tt d_mn(由于只采用一個(gè)控制器，擬態(tài)層沒有選調(diào)、判決等處理，因此Tp d_m忽略不計(jì)，并且無max效應(yīng))，這部分時(shí)延增加約為43.8%.

然后我們采用Cbench(controller benchmarker)對(duì)MNOS系統(tǒng)進(jìn)行壓力測試，測試不同交換機(jī)數(shù)量下的吞吐量，結(jié)果如圖11所示.

Fig. 11 Throughput test圖11 吞吐量測試

加粗點(diǎn)劃線為正常單個(gè)Ryu控制器架構(gòu)的測試結(jié)果(Floodlight和ONOS的吞吐量均為104～105級(jí)，遠(yuǎn)大于Ryu，因此MNOS性能主要受Ryu的影響).可見，整體上吞吐量隨交換機(jī)數(shù)量變化不大，而激活態(tài)控制器數(shù)量越多，則吞吐量越小.同時(shí)，與單個(gè)Ryu的對(duì)比可見，MNOS架構(gòu)對(duì)網(wǎng)絡(luò)吞吐量損害較大，同時(shí)延分析類似，這主要是由于判決機(jī)制導(dǎo)致的，性能仍有待提升.

5.2選調(diào)策略評(píng)估

下面對(duì)選調(diào)策略進(jìn)行仿真評(píng)估.我們的參數(shù)設(shè)置為：共有3臺(tái)主機(jī)、4種控制器類型，每種有3個(gè)，ε1, ?1為0.1,ε2, ?2為0.3, 每輪選調(diào)開銷φc=3.仿真結(jié)果如圖12所示，其中方形劃線(Random1)為完全隨機(jī)選調(diào);圓圈劃線(Random2)為考慮了異構(gòu)度增益，但是隨機(jī)選擇待遷移的控制器，即算法1中第3步為隨機(jī)選取而不是選擇最破壞異構(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判決機(jī)制評(píng)估

下面對(duì)本文的判決機(jī)制進(jìn)行仿真分析.其中參數(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.我們進(jìn)行10 000次重復(fù)試驗(yàn)，最終得到的博弈雙方收益函數(shù)-錯(cuò)誤率如表3所示：

Table 3 The Payoff (Pe)

6 結(jié)束語

SDN控制層作為軟件定義網(wǎng)絡(luò)中的核心管理模塊，對(duì)全網(wǎng)的正常運(yùn)行起著關(guān)鍵性作用，因此其安全性和可靠性需求不言而喻.本文在分析已有的防御機(jī)制的基礎(chǔ)上，基于擬態(tài)防御思想，提出了動(dòng)態(tài)異構(gòu)冗余模型的擬態(tài)網(wǎng)絡(luò)操作系統(tǒng)MNOS架構(gòu).MNOS通過構(gòu)建異構(gòu)冗余的網(wǎng)絡(luò)操作系統(tǒng)，實(shí)現(xiàn)控制層的動(dòng)態(tài)調(diào)度，增加控制層的不確定性，從而降低攻擊成功概率.為增加控制層的異構(gòu)度，本文提出了基于異構(gòu)度增益的選調(diào)策略，進(jìn)一步增加攻擊者的攻擊成本.最后，本文采用的判決機(jī)制，相比大數(shù)判決可以進(jìn)一步提升判決的準(zhǔn)確性.

當(dāng)然，MNOS架構(gòu)也存在一定的不足，如實(shí)驗(yàn)仿真中代價(jià)分析部分所述，MNOS由于采用冗余控制器共同決定最終結(jié)果，因此將會(huì)增加一定的時(shí)延，并對(duì)網(wǎng)絡(luò)吞吐量損害較大.對(duì)此，可以采用預(yù)判決機(jī)制進(jìn)行改善.后續(xù)的可能研究思路主要包括優(yōu)化判決機(jī)制，降低計(jì)算復(fù)雜度；研究選調(diào)策略的優(yōu)化，如根據(jù)NOS安全狀態(tài)動(dòng)態(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é)報(bào), 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模型若干問題探討和性能評(píng)估[J]. 信息安全學(xué)報(bào), 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.