MNOS：擬態網絡操作系統設計與實現

王禛鵬 扈紅超 程國振

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

2017-06-11；

2017-08-01

國家自然科學基金項目(61309020,61602509)；國家自然科學基金創新群體項目(61521003)；國家重點研發計劃項目(2016YFB0800100,2016YFB0800101)；河南省科技攻關項目(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：擬態網絡操作系統設計與實現

王禛鵬 扈紅超 程國振

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

控制層的漏洞利用攻擊，如惡意APP、流表篡改等是軟件定義網絡(software defined networking, SDN)面臨的主要威脅之一，而傳統基于漏洞修復技術的防御策略無法應對未知漏洞或后門.提出一種基于擬態防御思想的網絡操作系統安全架構——擬態網絡操作系統(mimic network operating system, MNOS)——保障SDN控制層安全.該架構采用異構冗余的網絡操作系統(network operating system, NOS)，并在傳統的SDN數據層和控制層間增設了擬態層，實現動態調度功能.首先擬態層動態選取若干NOS作為激活態并行提供服務，然后根據各NOS的處理結果決定最終的有效響應返回底層交換機.實驗評估表明：在增加有限的時延開銷下，MNOS可以有效降低SDN控制層被成功攻擊的概率，并具備良好的容錯容侵能力；在此基礎上，提出的選調策略和判決機制，可以有效提升系統的異構度和判決的準確性，進一步提升安全性能.

軟件定義網絡；主動防御；擬態安全防御；動態異構冗余；網絡操作系統

軟件定義網絡(software defined networking, SDN)將傳統數據平面和控制平面解耦，在邏輯上實現了網絡的集中控制，使得網絡配置、網絡服務部署等都在網絡操作系統(network operating system, NOS, 也稱SDN控制器)之上實現，有利于簡化網絡管理.然而，SDN應用實際生產環境時仍面臨嚴峻的安全問題.首先，SDN控制器集中管理著其覆蓋網絡的所有視圖信息，因此，極易成為攻擊的首選目標，帶來額外的安全風險.其次，SDN的重要特性是開放性，主要體現在可編程協議以及網絡操作系統的開源社區，而這種開放性極易導致未知的安全漏洞等問題，例如已經曝出的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控制層呈現的單一、靜態特性有利于攻擊者對其進行探測和分析.作為SDN的核心組件，控制器掌握著整個網絡的視圖，將上層策略轉譯為數據平面的轉發規則，一旦被攻擊或劫持，可導致信息泄漏，甚至網絡癱瘓.

一般地，針對SDN控制層的攻擊主要出于2個目的：操縱網絡流量或癱瘓網絡.操縱網絡流量的攻擊，一般利用控制器的漏洞，如控制器缺少對上層APP權限管理的漏洞，導致帶毒APP下發惡意流表規則[2-3]，以及控制器對LLDP(link layer discovery protocol)包缺少安全認證(或者如Floodlight，雖然提供鑒別碼認證，但是鑒別碼一直保持不變)的漏洞造成的拓撲偽造攻擊和中間人流表篡改攻擊[4]等.癱瘓網絡的攻擊，如存在惡意管理員[5]，使用一個簡單的exit命令致使Floodlight宕機造成網絡癱瘓，或者通過發送探測報文推斷控制器類型、消息處理邏輯和負載狀態等信息和發動DoS攻擊等[6].總之，利用控制器的漏洞發動攻擊是控制器面臨的主要威脅之一[7].

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

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

1) 基于擬態防御思想，設計了擬態網絡操作系統架構，并對Floodlight,Ryu,ONOS這3種主流開源SDN控制器進行開發，實現了原型驗證機POC(proof of concept).實驗評估證明，在增加一定的時延開銷下，MNOS可以有效保障SDN控制層安全；

2) 提出了一種基于異構度增益的選調策略，通過增加選調前后系統的異構程度，進一步提升MNOS的安全性能；

3) 優化MNOS的判決機制，在考慮先驗知識的情況下，提升判決的準確性.

1 相關工作

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

1.1改進型方案

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

FortNOX架構是Porras等人[22]針對NOX控制器設計的一種安全內核，為其提供基于角色的數據源認證、狀態表管理、流表規則沖突分析、流表規則超時回調等安全功能，提升NOX控制器在流規則沖突檢測方面的安全性能.在NOX基礎上，Porras等人又對Floodlight進行了類似安全拓展，設計了其安全增強版本SE-Floodlight[23]，增加了應用程序證書管理模塊、權限管理等新的安全模塊.

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

Fig. 1 The overview of MNOS圖1 MNOS整體架構

1.2革新型方案

針對1.1節的問題，一些研究者提倡在SDN控制器的設計和開發之初，便將安全性作為其核心問題之一進行考慮，從而突破已有控制器在系統架構、編程語言和預留接口等方面的限制，開發出全新的、內嵌安全機制的SDN控制器.

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

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

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

2 MNOS架構

本文提出的擬態網絡操作系統(MNOS)主要是將動態異構冗余模型引入SDN控制層中，以實現控制層內生安全性.如圖1所示為MNOS的整體框架，其中虛線框內即為本文提出的擬態層部分，下面對MNOS各模塊分別進行介紹.

2.1擬態控制協議

本文設計的擬態控制協議格式如圖2所示:

Fig. 2 Mimic Protocol
圖2 擬態控制協議

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

2.2南、北向代理層

南、北向代理層主要都是擬態控制協議的封裝、解封裝，即進入擬態層的報文封裝為擬態控制協議，反之則解封裝出數據域OpenFlow報文.

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

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

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

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

2.3消息隊列

由于MNOS系統內部需要協調異構系統大量的通信，目前主流的異構系統通信的方法有2種：1)RPC(遠程協議調用);2)消息隊列.鑒于目前開源社區有較成熟的消息隊列框架，本文選擇基于消息隊列的異構子系統通信實現.

就目前而言，主流的消息隊列框架包括：RabbitMQ,ActiveMQ，ZeroMQ.RabbitMQ是AMQP協議領先的一個實現，它實現了代理(Broker)架構，意味著消息在發送到客戶端之前可以在中央節點上排隊.此特性使得RabbitMQ易于使用和部署，適宜于很多場景如路由、負載均衡或消息持久化等.但是，這使得它的可擴展性差，速度較慢，因為中央節點增加了延遲，消息封裝后也較大.

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

2.4擬態核心層

擬態核心層是MNOS功能核心部分，主要負責NOS的管理、調度和判決等功能，相應地，其邏輯架構包含NOS管理器、選調器和判決器.

2.4.1 NOS管理器

NOS管理器主要負責NOS管理和NOS狀態維護2個功能，下面分別進行介紹：

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

Fig. 3 Status information of NOS圖3 NOS的狀態信息

每個新加入的控制器都必須在初始化階段向NOS管理器注冊，由管理器分配其唯一標識的nos_id, 并確定控制器類型nos_kind，如Floodlight,Ryu,ONOS等；app_id和app_kind同控制器注冊時類似，這2個變量是為了維護該控制器上運行的APP信息；state表示控制器的狀態，主要有激活態(active)、空閑態(inactive)、初始態(initial)和可疑態(suspicious)，狀態state的變換過程如圖4所示：

Fig. 4 State transforming of NOS圖4 NOS的狀態變換

其中變換①由NOS管理器負責，主要工作是NOS初始化時的網絡狀態同步，由NOS管理器負責；變換②～③由選調器負責，確定控制器的工作狀態、角色，這部分在2.4.2節介紹；變換④～⑥由判決器負責，主要發生在發現控制器可疑或者去可疑時，這部分在2.4.3節介紹.

2) NOS管理.得益于docker、NFV、云等虛擬化技術，我們可以很方便地新增控制器(鏡像)進行拓展，如圖4所示，這里新增控制器也有可能是判決器發現可疑控制器，最后決定刪除而重新初始化的控制器(變換⑥).但新增控制器不能立即投入使用，因為涉及網絡狀態信息和APP狀態等問題，因此首先需要對其進行網絡狀態同步，完成圖4中變換①.

狀態同步的步驟如圖5所示:

Fig. 5 State synchronization圖5 狀態同步流程

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

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

② 擬態核心層向Floodlight發送獲取狀態的擬態控制協議報文，同時將時刻t0以后收到的switch報文進行緩存而不再發往Floodlight(如圖5中圓柱體)；

③ 收到Floodlight發送的時刻t0的狀態(對于路由APP，狀態信息即為路由表，Floodlight的節點路由表狀態信息存放于TopologyInstance中的pathcache變量中)后，將其數據進行轉換(適用于ONOS的數據)后發送給初始態的ONOS進行狀態同步(此時同步的是時刻t0的狀態)，同時將緩存的報文發往Floodlight進行處理；

④ 在時刻t2，Floodlight正常處理報文，并將緩存的報文和后續到達的報文依次發往ONOS進行處理；

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

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

2.4.2 選調器

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

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

2.4.3 判決器

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

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

3 選調策略

第2節我們給出了選調器的工作原理，在本節中，我們詳細介紹本文選調器的選調策略.

多樣性，即異構配置，是指對集合中冗余實例采用相同功能但軟件或硬件不同的配置，以增加系統的多樣性[16-17].通過引入多樣性增強網絡安全的方法已成為研究熱點并廣泛應用，這種配置方法可以有效避免因同一種軟件或硬件的漏洞、后門等造成共模故障，使整個冗余系統遭受毀滅性攻擊[16-17].因此，本文提出一種基于異構度增益的選調策略，即最大化MNOS系統中控制器異構度.用到的符號、變量如表1所示:

Table 1 Definitions and Notations

我們的選調目標是最大化系統選調前后的異構度增益DG(由于每次選調的控制器數量受限，所以相當于激活態和空閑態控制器的動態遷移)，異構度增益源于軟硬件2個方面，即DGH,DGK為最大化:

(1)

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

(2)

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

式(2)最優模型是典型的NP難問題：當前激活態控制器在選調后變為空閑態，而空閑態被選取后變為激活態，相當于是一種映射算法.因此，本文給出如下啟發式算法：每一輪選調都分為若干次遷移步驟，每一步都先從當前激活態集中選取出最破壞系統異構度的控制器，然后對其進行考察，按照式(1)(2)的原則選取候選控制器.最破壞系統異構度的控制器即某類型控制器數量最多的控制器.例如，某時刻激活態控制器集共有4種控制器，分別是3臺Ryu,一臺ONOS,一臺ODL和0臺Floodlight，那么在進行這一輪選調時，我們優先選擇其中的一臺Ryu進行遷移(移出激活態集)，并且由式(1)(2)可知，應當優先選擇Floodlight加入候選控制器集中，以此類推.

算法1. 選調算法.

輸入：φc，Ccur；

輸出：Cnxt.

①Cnxt=φ;

② whileφc≠0 andCcur≠?

③ 從Ccur中選擇最破壞異構度的控制器i;

④ forj∈CCcur

⑤ if (DGH+DGK)最大

⑥Ccur←j;

⑦ end if

⑧ end for

⑨Ccur←Ccur-i,φc←φc-1;

⑩ end while

假設控制器集共有|C|，則找到Cnxt的時間復雜度可近似為O(min(|Ccur|,φc)(|C|-|Ccur|))，所以復雜度最大為O(|Ccur|(|C|-|Ccur|))≤O(|C|24).

4 判決機制

判決器的任務是從各激活態控制器的響應報文中比對，抉擇出最可信的響應回復給底層交換機，并記錄可疑控制器.主要涉及2個關鍵點：比對內容和判決方法.在比對內容(粒度)方面，顯然，若比對粒度為比特級，則計算量過大，因此，本文根據OpenFlow消息的格式進行字段級比對，著重考察2個關鍵字段：匹配(match)字段和行為(action)字段.如圖6所示，攻擊者通過劫持SDN控制器(NOS1)篡改下發的流表規則，將原合法的轉發邏輯match:in_port=2,actions:output=1，篡改為match:in_port=2,actions:output=3，企圖引導用戶流量到攻擊者事先部署的Web服務器上.此時，判決器只需比對各控制器的match字段和action字段，從中選取較可靠的響應(output=1)下發給交換機.

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

上述示例采用的判決方法是2.4.3節中簡單的大數裁決機制(majority-bases decision)，實現容錯/容侵功能.但是這種方法多次判決之間相互獨立(每一次判決只和當前接收的響應有關)，無法有效利用先驗知識，因此，本文優化判決機制，在考慮先驗知識的情況下提升判決的準確性.

4.1問題描述

假設有m個激活態控制器，存在若干拜占庭(惡意)控制器，每個控制器對同一OpenFlow消息(如packet in報文)進行處理后返回響應報文，我們用f=(f1,f2,…,fl)′表示真正正確的響應報文，共有l個字段，其中fi為01位序列，表示待比對的第i字段(例如actions中output字段)，fi,j為該字段的第j位(fi,j={0,1},j=1,2,…,hi),hi為第i字段所占位數.如圖7所示，其中表示第k個控制器處理后的原始響應報文中第i字段的第j位，而則表示為該控制器實際向判決器返回的報文.顯然，一般而言，正常情況下應當滿足但是若控制器被攻擊，變為惡意控制器，那么可能就有假設惡意控制器反轉該結果的概率為Pmal(Pmal=P(oi,j≠ri,j)).因此判決器的目標就是在這些可能含有被篡改的報文中判決出最真實可靠的報文.

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

4.2判決機制優化

由4.1節可知，判決器的任務可以轉化為求解：

(3)

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

(4)

我們用an=(a1,a2,…,am)的01序列表示控制器集的狀態(惡意或正常)：若ak=1，則表示NOSk為惡意控制器；反之，則為正常控制器.而P(an)則表示當前激活態控制器集狀態為該序列的概率，代入式(4)可得：

(5)

可以看出，由于乘法效應，式(5)求解較為復雜，我們采用類似OpenFlow多級流表的思想，將式(5)分解轉化為多級相加，即單獨求解各個字段的最優解，可得：

(6)

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

(7)

(8)

因此，將式(7)(8)的結論代入，可將式(6)轉化為

(9)

我們假設攻擊者對每個控制器以相同的概率α成功實施攻擊，使其變為惡意控制器，并且由于控制器間相互異構，所以可以認為各個控制器被攻擊的狀態相互獨立，因此：

(10)

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

(11)

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

5 實驗仿真

本節對MNOS性能、選調策略和判決機制進行實驗評估.我們采用3種開源控制器Ryu, Floodlight, ONOS，在9臺華為服務器(RH2288H V3)和1臺Pica8 (P3297)交換機上搭建實驗環境，具體地，3臺運行Floodlight、2臺運行ONOS、4臺服務器運行Ryu(其中1臺同時運行南向代理層、1臺同時運行擬態核心層).

5.1MNOS安全性能

5.1.1 攻擊成功概率仿真

首先對MNOS的安全性能進行評估對比.本文主要與移動目標防御模型(MTD)[27]和基于拜占庭容錯(BFT)的SDN控制層[18-19]架構進行對比.

由于MTD架構下，每個周期只選取1個執行體提供服務，因此，可認為MTD是擬態防御在m=1時的特例.并且由于改進的BFT[26]，可在2f+1冗余情況下實現f個錯誤容忍，因此改進BFT在最終效果上等同于進行了大數判決，可視為靜態MNOS，即沒有動態選調功能，只能一直由m個控制器提供服務.

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

(12)

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

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

(13)

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

(14)

圖8所示為攻擊成功概率與Pa和每個時間間隔攻擊者可同時攻擊的控制器數量w的關系.可見，整體上，攻擊成功概率都隨攻擊能力w增加而增加；而MTD架構下，攻擊成功概率呈線性增加，且遠高于MNOS和BFT模型；而BFT模型也要高于本文的MNOS架構，由式(12)和式(14)對比可知，這是由于MNOS的動態選調降低了攻擊者攻擊激活態控制器的概率導致的，而當w≥5概率不再增加；而本文的MNOS安全性能明顯優于其他2種架構(本文MNOS在m=5,w=11時與BFT架構結果一致，因為此時攻擊者可攻擊全部控制器)，且性能隨m值的增加而增加，當然，時延開銷等也會相應增加，后文將就時延代價等問題進行分析.

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

5.1.2 入侵容忍能力驗證

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

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

5.1.3 時延開銷及壓力測試

最后由于引入了冗余控制器，并增設了擬態層，涉及選調、判決等模塊，因此本文對傳統單一控制器和MNOS的處理時延和吞吐量進行了對比分析評估.為了更好地描述和分析MNOS引入的額外時延開銷，給出本節涉及的相關符號和定義，如表2所示：

Table 2 Definitions and Notations

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

Toriginal=Tt d_ds+Tp d_c,

(15)

而MNOS的時延可以表示為

(16)

因此，額外增加的時延可以表示為

(17)

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

(18)

為分析上述各部分時延，下面給出MNOS的時延測試結果，我們采用圖5所示的拓撲，測試2個主機間的ping包時延(刪除了控制器中流表下發部分代碼，目的是讓所有數據包都經由控制器處理，便于測試并統計時延).結果如圖10所示，其中Original(加粗點劃線)表示傳統單一控制器.

Fig. 10 Time delay test圖10 時延測試

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

然后我們采用Cbench(controller benchmarker)對MNOS系統進行壓力測試，測試不同交換機數量下的吞吐量，結果如圖11所示.

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

加粗點劃線為正常單個Ryu控制器架構的測試結果(Floodlight和ONOS的吞吐量均為104～105級，遠大于Ryu，因此MNOS性能主要受Ryu的影響).可見，整體上吞吐量隨交換機數量變化不大，而激活態控制器數量越多，則吞吐量越小.同時，與單個Ryu的對比可見，MNOS架構對網絡吞吐量損害較大，同時延分析類似，這主要是由于判決機制導致的，性能仍有待提升.

5.2選調策略評估

下面對選調策略進行仿真評估.我們的參數設置為：共有3臺主機、4種控制器類型，每種有3個，ε1, ?1為0.1,ε2, ?2為0.3, 每輪選調開銷φc=3.仿真結果如圖12所示，其中方形劃線(Random1)為完全隨機選調;圓圈劃線(Random2)為考慮了異構度增益，但是隨機選擇待遷移的控制器，即算法1中第3步為隨機選取而不是選擇最破壞異構度的控制器優先遷移;三角劃線(MNOS)即為本文提出的選調策略.

Fig. 12 Diversity gain圖12 異構度增益

由仿真結果可以看出，本文提出的選調策略以及分步遷移算法可以增加激活態控制器集的異構程度，從而有效避免同構產生的攻擊感染問題，增加攻擊者攻擊難度.

5.3判決機制評估

下面對本文的判決機制進行仿真分析.其中參數設置為：m=21,hi=4(由4.2節分析，hi值不宜過大，且字段所占位數都為4的倍數),ε=0.1，惡意控制器和判決器采用的Pmal取值分別為0.5,0.6,0.7,0.8,0.9,1.0.我們進行10 000次重復試驗，最終得到的博弈雙方收益函數-錯誤率如表3所示：

Table 3 The Payoff (Pe)

6 結束語

SDN控制層作為軟件定義網絡中的核心管理模塊，對全網的正常運行起著關鍵性作用，因此其安全性和可靠性需求不言而喻.本文在分析已有的防御機制的基礎上，基于擬態防御思想，提出了動態異構冗余模型的擬態網絡操作系統MNOS架構.MNOS通過構建異構冗余的網絡操作系統，實現控制層的動態調度，增加控制層的不確定性，從而降低攻擊成功概率.為增加控制層的異構度，本文提出了基于異構度增益的選調策略，進一步增加攻擊者的攻擊成本.最后，本文采用的判決機制，相比大數判決可以進一步提升判決的準確性.

當然，MNOS架構也存在一定的不足，如實驗仿真中代價分析部分所述，MNOS由于采用冗余控制器共同決定最終結果，因此將會增加一定的時延，并對網絡吞吐量損害較大.對此，可以采用預判決機制進行改善.后續的可能研究思路主要包括優化判決機制，降低計算復雜度；研究選調策略的優化，如根據NOS安全狀態動態調整選調策略等.

[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)

(鄔江興. 網絡空間擬態防御研究[J]. 信息安全學報, 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)

(扈紅超, 陳福才, 王禛鵬. 擬態防御DHR模型若干問題探討和性能評估[J]. 信息安全學報, 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.