鄭 正 徐明偉 李 琦 張 云

1(清華大學(xué)深圳研究生院 廣東深圳 518055)

2(清華大學(xué)計算機科學(xué)與技術(shù)系 北京 100084)

(13222026288@163.com)

軟件定義網(wǎng)絡(luò)(software-defined networking, SDN)起源于2006年斯坦福大學(xué)的Clean Slate研究課題，2009年SDN的概念正式被提出.此后SDN相關(guān)技術(shù)的研究迅速開展起來，成為近年來的研究熱點.與傳統(tǒng)網(wǎng)絡(luò)不同，SDN是邏輯上集中的網(wǎng)絡(luò)，將網(wǎng)絡(luò)中的控制平面和數(shù)據(jù)轉(zhuǎn)發(fā)平面分離，從而讓網(wǎng)絡(luò)管理者能夠更加靈活地管理網(wǎng)絡(luò)、解決網(wǎng)絡(luò)突發(fā)情況.目前越來越多的公司部署了SDN相關(guān)技術(shù)，例如谷歌公司采用SDN技術(shù)優(yōu)化其數(shù)據(jù)中心互連.然而，SDN系統(tǒng)設(shè)計之初沒有考慮到的安全漏洞逐漸暴露出來，例如SDN拓撲污染攻擊[1].隨著SDN應(yīng)用越來越廣泛，SDN安全性問題也凸顯出來.

SDN拓撲污染漏洞是控制器底層的拓撲服務(wù)中存在的安全漏洞，直接影響SDN的可用性.拓撲服務(wù)通過搜集下層網(wǎng)絡(luò)信息，給上層應(yīng)用和計算路由等主要網(wǎng)絡(luò)服務(wù)提供全網(wǎng)的拓撲信息.因此，解決拓撲服務(wù)的安全漏洞對于研究和應(yīng)用SDN至關(guān)重要.Hong等人[1]首次研究防御SDN拓撲污染攻擊的方案.但是，該方案中提出的方法并不能有效地防御拓撲攻擊.此外，該方案不僅破壞了SDN的控制和數(shù)據(jù)相分離的原則，而且引入了非常大的存儲開銷.

本文提出新的防御方案——SecTopo，通過監(jiān)控交換機和控制器之間傳輸?shù)耐負湫畔ⅰ鳈C接入和位置改變、流表項的增刪、發(fā)送和接收的LLDP消息等來收集主機信息和交換機流表項變化信息等相關(guān)信息，然后對拓撲變化的消息進行校驗，從而發(fā)現(xiàn)攻擊行為，并發(fā)出警報.實驗證明，部署SecTopo后，控制器吞吐量僅下降了4.6%，引入了極小的開銷.

1 SDN拓撲管理原理

SDN通過對上層應(yīng)用(例如負載均衡和最短路徑路由服務(wù)等)提供可編程接口，使得應(yīng)用能夠根據(jù)控制器提供的拓撲信息進行路由計算.控制器中的拓撲管理服務(wù)負責(zé)維護拓撲信息，主要包含3個部分功能：1)發(fā)現(xiàn)交換機；2)發(fā)現(xiàn)主機；3)發(fā)現(xiàn)鏈路.目前已知的拓撲管理服務(wù)漏洞存在于主機發(fā)現(xiàn)和鏈路發(fā)現(xiàn)這2個部分:

1) 主機發(fā)現(xiàn)原理.當(dāng)交換機收到由新接入網(wǎng)絡(luò)的主機發(fā)送的網(wǎng)絡(luò)包時，會向控制器報告這個網(wǎng)絡(luò)包.控制器通過該消息獲取主機的信息(主機的物理地址、IP地址、位置信息等)，然后下發(fā)相關(guān)的流表項.當(dāng)再次收到交換機詢問規(guī)則的消息時，控制器根據(jù)該消息查詢是否存儲過該主機，如果查到主機，但是位置信息不匹配，就認為主機位置發(fā)生了改變，然后更新控制器存儲的該主機的位置信息.然而整個過程缺少認證步驟，攻擊者通過發(fā)送偽裝主機的消息，就可以偽裝網(wǎng)絡(luò)中的某臺主機.

2) 鏈路發(fā)現(xiàn)原理.控制器使用開放流量發(fā)現(xiàn)協(xié)議(OFDP)動態(tài)檢查SDN交換機之間的有效鏈路，該協(xié)議通過發(fā)送鏈路層發(fā)現(xiàn)協(xié)議(LLDP)包來實現(xiàn).

鏈路發(fā)現(xiàn)原理的基本過程如圖1所示，控制器每隔一段時間向SDN交換機發(fā)送LLDP消息，SDN交換機X轉(zhuǎn)發(fā)該LLDP包，下一跳交換機Y收到來自交換機X的LLDP包后轉(zhuǎn)發(fā)給控制器，控制器通過該消息就可以學(xué)習(xí)到一條從交換機X到交換機Y的單向鏈路.

Fig. 1 Procedure of link discovery in SDN圖1 SDN網(wǎng)絡(luò)鏈路發(fā)現(xiàn)過程

2 SDN拓撲攻擊

2.1 網(wǎng)絡(luò)用戶流量劫持攻擊

對于主機位置的改變，控制器無法驗證消息、確認事件是否為真.如圖2所示，攻擊者使用網(wǎng)絡(luò)服務(wù)器的物理地址、IP地址向直連SDN交換機發(fā)送數(shù)據(jù)包.按照主機發(fā)現(xiàn)服務(wù)流程，由于攻擊者發(fā)送的數(shù)據(jù)包是新流的數(shù)據(jù)包，SDN交換機會報告給控制器，而控制器無法驗證數(shù)據(jù)包發(fā)送者是否為合法的用戶，會默認依據(jù)該消息的內(nèi)容認定網(wǎng)絡(luò)服務(wù)器的位置已經(jīng)發(fā)生了移動.在完成轉(zhuǎn)發(fā)流表項下發(fā)更新后，后續(xù)如果有其他正常主機試圖訪問該網(wǎng)絡(luò)服務(wù)器時，由于拓撲管理信息中該服務(wù)器的位置已變更為攻擊者所在的位置，所以正常用戶的訪問流量都會被轉(zhuǎn)發(fā)到攻擊者處，導(dǎo)致用戶無法訪問該服務(wù)器.

Fig. 2 Procedure of Web client harvest圖2 劫持網(wǎng)絡(luò)用戶流量過程

2.2 鏈路偽造攻擊

控制器通過LLDP包探測網(wǎng)絡(luò)中有效鏈路，而鏈路發(fā)現(xiàn)服務(wù)必須要滿足2個條件：1)確保LLDP包沒有被篡改過；2)確保LLDP包只在SDN交換機間傳播.但在實際中，這2點是無法保證的.很多SDN控制器源碼是開源的，任何人都可以獲取LLDP包格式和每個字段的語義，并且交換機每個端口都可以發(fā)送LLDP包，包括連接著主機的端口.

1) 注入偽造LLDP包.攻擊者通過給直連的交換機發(fā)送偽造的LLDP包發(fā)起攻擊.如圖3所示，通過監(jiān)控來自SDN交換機的流量，攻擊者能夠獲得真實的LLDP包，并且很容易破解 LLDP包里每個字段的語義.攻擊者按照LLDP包格式，根據(jù)攻擊需求偽造相應(yīng)的LLDP包，或者直接修改真實的LLDP包，例如，將LLDP包中DPID、端口號進行修改，再將其發(fā)送給直連SDN交換機A.當(dāng)交換機A收到LLDP包后，便會給控制器發(fā)送該LLDP包.于是，控制器就會學(xué)習(xí)到一條攻擊者偽造的鏈路.

Fig. 3 Procedure of faked LLDP injection圖3 偽造LLDP包注入過程

2) 重放LLDP包.在重放攻擊中，攻擊者將一臺目標(biāo)交換機發(fā)來的LLDP包重放給另一臺目標(biāo)交換機，這樣就在2臺交換機之間構(gòu)造出一條虛假鏈路.攻擊場景如圖4所示，攻擊者控制多臺主機，預(yù)先找好適合重放的主機，攻擊者通過與交換機Y直連的重放主機控制其他被攻陷的主機.圖4中，虛線是控制器視角下2個主機之間的通信信道(該信道是由攻擊者構(gòu)造)，實線表示的是實際的通信信道.當(dāng)主機A收到來自交換機X的LLDP包時，攻擊者讓主機A通過隧道等方式將LLDP包發(fā)給重放主機.攻擊者根據(jù)攻擊需求讓重放主機將LLDP包也以同樣方式發(fā)送給主機B，主機B將LLDP包發(fā)給與之直連的交換機Z.當(dāng)交換機Z收到LLDP包時候，按照正常的處理步驟發(fā)送給控制器，控制器便學(xué)習(xí)到一條由攻擊者偽造的不存在的鏈路.

Fig. 4 Procedure of LLDP relay圖4 LLDP重放攻擊方法

2.3 漏洞分析和現(xiàn)有方案

存在這2類攻擊的主要原因是：目前控制器缺少對網(wǎng)絡(luò)拓撲消息的驗證，無法保證拓撲信息的真實性.因此對于網(wǎng)絡(luò)鏈路信息，控制器無法辨別消息的真?zhèn)?，故攻擊者篡改其?nèi)容并不會被發(fā)現(xiàn).當(dāng)控制器收到LLDP包時，是默認為真實的LLDP包.攻擊者利用這樣的漏洞可以在網(wǎng)絡(luò)中偽造出虛假的主機和鏈路，進而可以導(dǎo)致網(wǎng)絡(luò)中信息傳輸?shù)幕靵y、網(wǎng)絡(luò)崩潰甚至是網(wǎng)絡(luò)被攻擊者完全控制.

文獻[1]提出了TopoGuard模型來防御拓撲污染攻擊，該模型是通過驗證主機遷移的前置和后置條件來判斷是否存在主機位置劫持攻擊.主機遷移的前置條件是控制器收到端口的Port_Down信號；后置條件是遷移結(jié)束以后，控制器給該主機原來的位置發(fā)送ICMP探測的結(jié)果是不可達的，確保在原來的位置上不能再訪問該主機.只有滿足這2個條件才能確定該主機位置移動是真實的.

針對篡改LLDP包的攻擊行為，該模型提出的防御措施是計算LLDP中DPID和端口號的HMAC值，通過在LLDP包中放置HMAC值來驗證.針對重放，該模型使用檢查發(fā)出端口的設(shè)備類型的方式來防御.文獻[1]認為攻擊主機會發(fā)送只有主機才能產(chǎn)生的流量，例如ARP流量.控制器根據(jù)Packet-In消息來決定該屬性的值(主機或交換機).但是該方案存在3個缺陷：

1) SDN網(wǎng)絡(luò)的原則就是將網(wǎng)絡(luò)的控制層和數(shù)據(jù)層分離.控制層不應(yīng)該執(zhí)行數(shù)據(jù)層包含的功能，控制器雖然能構(gòu)造LLDP等網(wǎng)絡(luò)包，但是ICMP是數(shù)據(jù)層的數(shù)據(jù)包，由控制器來構(gòu)造就違背了SDN的設(shè)計原則，會造成控制器功能和執(zhí)行的混亂.

2) 在LLDP包中加入HMAC值驗證LLDP包的真實性的方案是很容易繞過的.攻擊者使用2臺主機分別連接到不同的SDN交換機，一臺用于監(jiān)聽LLDP包，提取出HMAC、DPID和端口號；另一臺根據(jù)提取的信息，再向網(wǎng)絡(luò)中注入偽造LLDP包，即可繞開防御.因為每個端口每次發(fā)送的LLDP包中HMAC值都是固定不變的，所以只要分析出HMAC值，該防御方案就會失效.因此，僅是使用不變的HMAC值是無法進行有效防御攻擊的.

3) 控制器存儲每個端口所連接的設(shè)備類型，這種方式所需的存儲空間有些部分可能會存在浪費，因為在很多情況下，每臺交換機的每個端口上在不同時間可能會連接多個網(wǎng)絡(luò)設(shè)備.

3 拓撲污染防御—SecTopo

3.1 方案概述

為了解決拓撲污染攻擊，我們提出了SecTopo.SecTopo在SDN控制器拓撲管理服務(wù)中提供網(wǎng)絡(luò)拓撲信息的驗證功能.SecTopo的基本目標(biāo)就是建立一個有效驗證網(wǎng)絡(luò)拓撲信息的機制.SecTopo結(jié)構(gòu)如圖5所示，SecTopo主要包含3個驗證模塊：主機接入檢查模塊、鏈路發(fā)現(xiàn)處理模塊和流表項處理模塊.主機接入模塊和流表項處理模塊用于解決主機位置劫持攻擊，而鏈路發(fā)現(xiàn)處理模塊用于解決鏈路偽造攻擊.

1) 主機接入檢查模塊通過監(jiān)聽控制器收到的Packet-In消息，記錄網(wǎng)絡(luò)中主機，判斷該主機是否是真實的主機.這里真實主機的意思是，該主機使用本機的IP和MAC地址發(fā)送主機流量.

2) 流表項處理模塊通過監(jiān)聽控制器下發(fā)流表項信號和交換機上傳的流表項刪除消息，維護每個交換機端口流表項的記錄表，并且通過該表判斷某個端口的主機是否離開了網(wǎng)絡(luò).

3) 鏈路發(fā)現(xiàn)處理模塊負責(zé)管理控制器下發(fā)的LLDP包，并且對收到的LLDP包進行檢查，防止利用LLDP包來偽造鏈路的攻擊.

Fig. 5 The architecture of SecTopo圖5 SecTopo結(jié)構(gòu)圖

3.2 主機接入檢查模塊

主機接入檢查部分用于驗證新加入網(wǎng)絡(luò)的主機身份，防止偽裝主機的行為.該部分通過監(jiān)聽Packet-In消息，維護接入網(wǎng)絡(luò)主機信息表，該表中每一條目包含：主機的MAC地址、主機接入網(wǎng)絡(luò)的交換機號和端口號，便于查詢.

算法1描述了主機接入檢查部分的處理步驟，輸入為SDN交換機詢問主機的流表項消息，輸出為是否相信該主機.通常，當(dāng)主機接入網(wǎng)絡(luò)時，由于主機直連的交換機查找不到對應(yīng)的流表項，會向控制器發(fā)送含有主機ARP消息的Packet-In消息.主機接入檢查部分通過監(jiān)聽這類的Packet-In消息來學(xué)習(xí)主機的信息，并在主機信息表中記錄下來.當(dāng)主機離開了網(wǎng)絡(luò)，需要從列表中刪除該條目，這部分是通過流表項處理部分來完成的.

此外，當(dāng)1臺主機長時間沒有發(fā)送流量，主機直連的交換機上關(guān)于該主機的流表項全部過期后，該主機又開始發(fā)送流量時，在主機列表中并不存在該主機消息，控制器收到關(guān)于該主機的Packet-In消息后，SecTopo需要將該主機重新加入主機列表.

算法1. 主機接入檢查.

輸入:詢問流表項的Packet-In；

輸出:True或False.

①temp=MacAddress,switchid,portnum;

/*從Packet-In消息中提取MAC，SWID，PORT*/

② IF Packet-In中消息類型為ARP THEN

③ IF Packet-In包含的主機MAC地址在

hostlist中 THEN

④hostlist.add(temp);

⑤ END IF

⑥ RETURN True;

⑦ END IF

⑧ IF Packet-In消息類型為IPv4 THEN

⑨ IF主機的MAC地址已在hostlist中

THEN

⑩ IFtemp是hostlist中1個條目THEN

算法1主要步驟為建立表格和查詢表格，時間復(fù)雜度在O(n).根據(jù)2.1節(jié)提到的網(wǎng)絡(luò)流量劫持，攻擊者使用網(wǎng)絡(luò)中某個服務(wù)器的IP地址和物理地址，發(fā)送偽造的主機流量，例如IPv4流量，直連的交換機收到該主機流量后會向控制器發(fā)送含有IPv4的Packet-In消息.當(dāng)該部分收到的Packet-In消息包含的是IPv4網(wǎng)絡(luò)包，會檢查該Packet-In消息里的主機物理地址是否存在于主機表格中，如果存在，再檢查表格中該條目的其他的信息和Packet-In消息里對應(yīng)信息是否符合，如果信息不符合，就認為是攻擊行為.

3.3 流表項處理模塊

流表項處理部分的主要功能是檢測主機是否離開網(wǎng)絡(luò)，并在3.2節(jié)提出的主機列表中刪除已經(jīng)離開網(wǎng)絡(luò)的主機.當(dāng)主機直連的SDN交換機上所有關(guān)于該主機的流表項全部過期時，就認為該主機離開了網(wǎng)絡(luò).如果主機只是長時間沒有發(fā)送流量，控制器只需要通過分析由SDN交換機向控制器發(fā)送的尋路消息，將該主機的信息再次加入主機列表即可.該部分通過監(jiān)聽控制器下發(fā)流表項的信號和SDN交換機寫入刪除流表項的信號來維護流表項列表.該列表記錄每個端口直連主機流入網(wǎng)絡(luò)的流的有效的流表項條數(shù).通過對每個端口對應(yīng)的流表項動態(tài)管理，我們可以得知連接到哪些端口的主機離開了網(wǎng)絡(luò)，就可以通知主機處理部分刪除對應(yīng)的主機條目.

算法2描述了這部分流表項處理的流程，其輸入是下發(fā)流表項和流表項刪除的信號.當(dāng)有流表項下發(fā)時，根據(jù)下發(fā)的流表項中的交換機ID號、端口號和主機MAC地址，增加該條目的流表項數(shù)目.當(dāng)收到來自交換機直連主機流量進入網(wǎng)絡(luò)的流表項過期消息時，就減少對應(yīng)端口的流表項數(shù)目.當(dāng)主機直連的交換機上以該主機MAC地址為源地址的流表項數(shù)目為0時，SecTopo就認為該主機離開了網(wǎng)絡(luò)，將主機表格中對應(yīng)的主機條目刪除，這樣就實現(xiàn)了主機處理部分刪除主機列表中離開網(wǎng)絡(luò)的主機的功能.算法2的主要步驟是建立表格和查詢表格，時間復(fù)雜度為O(n).

算法2. 檢測流表更新.

輸入:下發(fā)流表項信號siginstall、刪除流表項信號sigdelete.

①temp_1=srcmac,switchid,portnum;

/*從消息中提取源MAC，SWID，PORT*/

② IFsiginstall==True THEN /*下發(fā)流表項時*/

③ IFtemp_1 匹配flowlist中條目A

THEN

④count=count+1; /*條目A的count值加1*/

⑤ ELSE

⑥flowlist.add(temp_1); /*新建1個條目*/

⑦count=1;

⑧ END IF

⑨ END IF

⑩ IFsigdelete==True THEN /*交換機刪除1個流表項時*/

THEN

3.4 鏈路發(fā)現(xiàn)處理模塊

這個部分主要是檢查LLDP包，以防止鏈路偽造攻擊.在控制器下發(fā)的LLDP包中添加校驗字段，并將該LLDP包中的交換機ID號、端口號和對應(yīng)的隨機字符串等信息記錄在列表中，用于校驗控制器收到的LLDP包，從收到的LLDP包排除偽造的LLDP包.根據(jù)LLDP包中端口信息，查詢主機列表，排除重放攻擊產(chǎn)生的LLDP包等.

當(dāng)控制器開始下發(fā)LLDP包時候，SecTopo給每條LLDP消息上加入1個由Hash函數(shù)產(chǎn)生的隨機字符串作為校驗字段，并將該隨機字符串與交換機端口號存儲起來.為了簡單高效，本文的實現(xiàn)參考了文獻[2]，校驗字段采用了Hash函數(shù)產(chǎn)生的字符串低32位.

當(dāng)控制器收到LLDP包時，使用算法3可以檢查出攻擊者發(fā)送的LLDP包.算法3的輸入是控制器收到的LLDP包.每當(dāng)控制器收到LLDP包時，LLDP消息處理部分首先檢查LLDP中的校驗字段、交換機ID號和端口號是否與存儲的內(nèi)容一致.如果校驗字段不一致，就認為存在攻擊行為；如果一致，在LLDP包中，通過LLDP包中包含的交換機ID號和端口號，查找3.2節(jié)提出的主機列表中是否存在該端口的信息，如果存在，則說明該端口是直連主機的端口，而控制器不應(yīng)該收到該LLDP包，由此判斷該LLDP包是重放攻擊產(chǎn)生的.算法3主要步驟是順序查詢表格，時間復(fù)雜度為O(n).

算法3. 檢查LLDP包真實性.

輸入:來自交換機的LLDP；

輸出:True 或 False.

①temp_2=switchid,portnum,token;

/*從LLDP中提取信息*/

② IF收到的LLDP無法匹配LLDPlist中條目THEN

③ RETURN False; /*則認為是偽造的

LLDP*/

④ END IF

⑤ IFtemp_2.switchid,portnum匹配

hostlist中條目CTHEN

⑥ RETURN False;

⑦ END IF

3.5 與TopoGuard的比較

與現(xiàn)有方案TopoGuard相比，本文提出的SecTopo在控制層不需要構(gòu)造數(shù)據(jù)層探測包的情況下，可以更有效地防御拓撲污染攻擊.此外，SecTopo可以有效地防御重放攻擊，并支持網(wǎng)絡(luò)的動態(tài)更新.具體比較如表1所示：

Table 1 The Comparision of SecTopo and TopoGuard

4 實驗評估

4.1 實驗設(shè)置

本實驗使用Floodlight1.1版本的控制器，使用Mininet2.2.1版本作為網(wǎng)絡(luò)模擬器，并使用Open vSwitch(OVS)2.3.2版本作為OpenFlow交換機.實驗的攻擊代碼是使用Scapy工具編寫的.本實驗的硬件測試環(huán)境是安裝了Ubuntu14.04TLS版本的PC機，內(nèi)存為4 GB，處理器為Intel Core i5-3470.實驗代碼采用嵌入方式，在3個相關(guān)程序?qū)?yīng)函數(shù)中添加或修改相關(guān)代碼，總計增加310行左右.

本實驗部分進行了2組實驗，分別是驗證方案有效性和測試方案性能.驗證有效性和測試性能的實驗中，為了提高測試精度，不引入其他影響因素，故采用了圖6所示的拓撲.在測試時間開銷時，多個節(jié)點情況下的平均時間開銷變化不大.在測試吞吐量時，在交換機和主機拓撲規(guī)模變大時，控制器吞吐性能會受到影響.

Fig. 6 Topology graph of the experiment圖6 實驗拓撲圖

4.2 方案有效性

本實驗驗證SecTopo是否能夠檢測出網(wǎng)絡(luò)拓撲污染攻擊.控制器運行SecTopo模型，使用Scapy工具模擬實現(xiàn)網(wǎng)絡(luò)拓撲污染攻擊，通過控制臺輸出來觀察SecTopo對攻擊的反應(yīng).

1) 檢測主機位置劫持攻擊.主機A為正常用戶，主機B(MAC：00:00:00:00:00:02)作為攻擊者，以主機A(MAC：00:00:00:00:00:01)的身份向直連的交換機發(fā)送網(wǎng)絡(luò)流量，在實驗環(huán)境中模擬實現(xiàn)攻擊.通過控制臺的輸出，如圖7所示，觀察到SecTopo成功地檢測出了主機B發(fā)出的偽造流量.

Fig. 7 The detection of host position attack圖7 主機位置劫持檢測

從圖7中，我們看到主機列表中存儲的是主機A原本的位置信息，是在交換機X(交換機ID號為00:00:00:00:00:00:00:01)的端口1處.主機B聲稱A移動到了交換機Y(交換機ID號為00:00:00:00:00:00:00:02)的端口1處.SecTopo的主機接入檢查部分通過檢查Packet-In中交換機的ID和端口號，與主機列表中對應(yīng)信息作對比，發(fā)現(xiàn)位置信息不符合.SecTopo就及時地報告錯誤，阻止了以后的步驟，避免了拓撲污染.

2) 檢測鏈路偽造攻擊.LLDP包中的校驗字段部分的產(chǎn)生過程，參考了文獻[2]中產(chǎn)生密鑰的方法.通過Java產(chǎn)生隨機數(shù)，使用加密庫文件的API對產(chǎn)生的隨機數(shù)計算散列值.實驗選用的Hash函數(shù)是SHA1，選取散列值的低32 b作為校驗字段.當(dāng)攻擊者偽造LLDP包，SecTopo通過LLDP包中的校驗字段檢測出偽造包.對剩下的LLDP包進行重放攻擊檢查.這樣分開處理的原因是盡可能減少在檢查LLDP包上的時間開銷，保證最終控制器獲取的鏈路信息是真實的.實驗中仍然是使用Scapy工具來構(gòu)造攻擊流量，圖8顯示SecTopo檢查到由Scapy構(gòu)造的攻擊包.

Fig. 8 The detection of link fabrication attack圖8 鏈路偽造攻擊的檢測

4.3 方案性能

SecTopo對于控制器性能的影響和網(wǎng)絡(luò)數(shù)據(jù)包延遲影響主要集中在對控制器吞吐量變化的影響和產(chǎn)生并且檢查LLDP包的時間開銷上.本部分測試SecTopo對于控制器的計算開銷的影響和吞吐量變化的影響.SecTopo的時間開銷主要來自鏈路發(fā)現(xiàn)處理部分中產(chǎn)生隨機字符串和計算隨機數(shù)的散列值、處理Packet-In消息這2個部分.產(chǎn)生和檢查每條LLDP包分別調(diào)用不同程序?qū)崿F(xiàn)，并且時間開銷主要集中在產(chǎn)生和檢查LLDP包上，故方案的計算開銷只與LLDP包的數(shù)目有關(guān)，與網(wǎng)絡(luò)拓撲結(jié)構(gòu)無關(guān)，為了減少其他因素影響，測試開銷也采用圖6拓撲.實驗使用Java system.nanoTime API對LLDP包的構(gòu)造和檢驗這2部分的時間開銷做了測試評估.實驗中共測試了4組，每組為50次構(gòu)造和校驗LLDP的時間開銷，最終平均的時間開銷如表2所示:

Table 2 Token’s Overhead on the Floodlight表2 校驗字段對Floodlight的時間開銷 ms

表2展示了2個部分的開銷情況：LLDP包的構(gòu)造和LLDP包校驗.對于LLDP包的構(gòu)造，主要的時間開銷是在校驗字段的產(chǎn)生部分，也就是調(diào)用隨機數(shù)生成函數(shù)和計算隨機字符串這2個部分.構(gòu)造每個包平均需要0.075 ms，構(gòu)造部分占控制器構(gòu)造LLDP包總時間的比例約為26.31%.

我們斷言，偽造LLDP包的攻擊難度和資源要求遠低于實現(xiàn)重放LLDP攻擊的難度和需求，所以網(wǎng)絡(luò)中存在偽造鏈路的攻擊流量中，偽造的LLDP包占的比重會更大.所以在正常的驗證LLDP包的過程中，SecTopo時間開銷的影響主要是在檢查校驗字段是否與之前產(chǎn)生的值相符合，這部分的平均開銷為0.010 ms，平均占控制器處理時間總比例約為2.78%.事實上，在測試的4組數(shù)據(jù)中有2組數(shù)據(jù)顯示，校驗LLDP的校驗字段值的時間開銷接近0.001 ms，雖然存在API測試的時間精度問題，但是這也反映出SecTopo對于控制器的影響的確很小.

在測試SecTopo對于控制器吞吐量影響的實驗中，使用Cbench測試控制器使用方案前后吞吐量變化情況.實驗分別檢查了在每臺交換機連接100臺主機，網(wǎng)絡(luò)交換機數(shù)量在1，2，4，6，8，10，16時控制器吞吐量變化情況.結(jié)果如圖9所示：

Fig. 9 Throughput change of controller圖9 控制器吞吐率的變化

總的來說，網(wǎng)絡(luò)中交換機數(shù)目相同時，控制器使用SecTopo方案前后吞吐量變化很小.特別是在交換機數(shù)目為1，2，10，16時，從圖9可以看出2條折線的差距很小.2條折線的變化趨勢一致，網(wǎng)絡(luò)中交換機數(shù)目從1～4臺時控制器的吞吐量都是快速上升；從4臺以后，吞吐量都是逐漸下降，并且趨于穩(wěn)定，此時控制器面對更多的交換機請求無法及時處理.平均來說，部署SecTopo后，控制器的吞吐量僅僅下降了4.6%，由此可以認為，SecTopo對于控制器處理消息的吞吐量影響很小.

5 討 論

目前，SecTopo能夠基本解決拓撲污染問題.值得注意的是，當(dāng)攻擊者獲取了服務(wù)器MAC地址和IP地址后，服務(wù)器離開網(wǎng)絡(luò)，攻擊者可以通過其他端口接入網(wǎng)絡(luò)，并偽裝該服務(wù)器.在這種情況下，SecTopo無法判別該服務(wù)器是否是攻擊者偽裝的，所以，這種攻擊是SecTopo無法防御的.這種攻擊的一種可行的防御方法是擴展ARP消息，即每臺主機在接入網(wǎng)絡(luò)之前，由網(wǎng)絡(luò)管理員發(fā)放1個有效且唯一的校驗字段.當(dāng)主機連入網(wǎng)絡(luò)發(fā)送ARP包時，將該校驗字段放入ARP消息中，控制器通過該ARP消息來驗證主機的身份.

6 相關(guān)工作

SDN安全問題包括數(shù)據(jù)轉(zhuǎn)發(fā)策略異常檢測和路徑驗證.對于數(shù)據(jù)轉(zhuǎn)發(fā)策略異常檢測，目前有2種檢測機制：1)在控制平面和數(shù)據(jù)平面之間添加1個中間層代理來對每一條下發(fā)的策略進行檢測；2)在控制器上部署一個策略檢測的部件即可完成策略異常檢測.目前關(guān)于引入中間層代理的一些研究有：數(shù)據(jù)包包頭分析(HSA)[3]通過幾何模型提出了一種普適的獨立于協(xié)議的框架來驗證網(wǎng)絡(luò)的配置問題.NetPlumber[4]利用HSA的思想實現(xiàn)了網(wǎng)絡(luò)一致性問題的檢測，例如回環(huán)、黑洞等.VeriFlow[5]解決了對網(wǎng)絡(luò)設(shè)備的依賴.關(guān)于部署策略檢測部件的機制包括：Maple[6]系統(tǒng).NetPlumber和VeriFlow沒有提供一個有效的自適應(yīng)解決方案來處理策略違反問題.FlowGuard[7]在此基礎(chǔ)之上，提出了一個架構(gòu)來解決這些問題.SE-Floodlight[8]是部署在Floodlight控制器基礎(chǔ)之上的安全擴展，這種擴展部件引入了身份驗證、優(yōu)先級等安全機制.

路徑驗證主要通過數(shù)據(jù)包驗證和基于流量轉(zhuǎn)發(fā)異常檢測．基于數(shù)據(jù)包驗證的方案包括：ICING[9]提供的路徑驗證機制、Passport[10]實現(xiàn)的數(shù)據(jù)源驗證以及OPT方案[11]等．基于流量轉(zhuǎn)發(fā)異常檢測是基于多跳數(shù)據(jù)轉(zhuǎn)發(fā)統(tǒng)計信息進行驗證，包括Sphinx[12]和ShortMAC[13]．

在文獻[14]中，提出了傳統(tǒng)網(wǎng)絡(luò)中存在的2類OSPF拓撲攻擊問題，跟本文所涉及的SDN拓撲污染攻擊比較相似.OSPF是傳統(tǒng)網(wǎng)絡(luò)中最常用的內(nèi)部網(wǎng)關(guān)路由協(xié)議，該協(xié)議規(guī)定路由器通過LSA包來學(xué)習(xí)整個網(wǎng)絡(luò)中其他路由器的信息.針對OSPF的第1種攻擊方法是攻擊者假設(shè)自治域內(nèi)的所有路由器配置的是相同的密鑰，通過控制1臺域內(nèi)路由器向受害者路由器發(fā)送一條偽造的LSA，誘使受害者與網(wǎng)絡(luò)中一個不存在的路由器建立鄰接關(guān)系.這種攻擊方法與通過注入偽造LLDP包實施鏈路偽造攻擊類似，分別使路由器或控制器學(xué)習(xí)到虛假的網(wǎng)絡(luò)拓撲，在網(wǎng)絡(luò)中產(chǎn)生黑洞.第2類攻擊利用了LSA的特點，在OSPF的RFC文獻中提出，如果2個LSA的序列號(sequence number)、校驗和(checksum)和壽命(age)這3個字段相同，就認為這2個LSA相同.而在實際中，只要序列號和校驗和相同，就認為2個LSA是相同的.所以攻擊者可以產(chǎn)生能匹配最近產(chǎn)生LSA的偽裝LSA，通過廣播實施攻擊.當(dāng)攻擊者收到受害者路由器真實的LSA，就廣播偽裝LSA，當(dāng)鄰居路由器先收到偽裝LSA，再收到真實LSA就會認為真實LSA是重復(fù)包，進行丟棄，使得全網(wǎng)學(xué)習(xí)到錯誤的拓撲信息.

7 結(jié) 論

本文總結(jié)了現(xiàn)有的SDN拓撲攻擊和防御工作，提出了輕量級的拓撲污染問題的防御方案——SecTopo，一種安全的動態(tài)管理接入網(wǎng)絡(luò)主機的算法和安全的鏈路發(fā)現(xiàn)算法，并且對一些可能的情況進行了分析.下一步的研究主要是解決主機劫持攻擊的對象為普通用戶時的攻擊防御問題，并且進一步尋找和解決SDN底層服務(wù)的漏洞.

[1] Hong Sungmin, Xu Lei, Wang Haopei, et al. Poisoning network visibility in software-defined networks: New attacks and countermeasures[C] //Proc of ISOC NDSS’15. Reston, VA: ISOC, 2015: 8-11

[2] Li Qi, Zhang Xinwen, Zheng Qingji, et al. LIVE: Lightweight integrity verification and content access control for named data networking[J]. IEEE Trans on Information Forensics and Security, 2015, 10(2): 308-320

[3] Kazemian P, Varghese G, McKeown N. Header space analysis: Static checking for networks[C] //Proc of USENIX NSDI’12. Berkeley, CA: USENIX Association, 2015: 113-126

[4] Kazemian P, Chang M H, Zeng Hongyi, et al. Real time network policy checking using header space analysis[C] //Proc of USENIX NSDI’13. Berkeley, CA: USENIX Association, 2013: 99-111

[5] Khurshid A, Zou Xuan, Zhou Wenxuan, et al. VeriFlow: Verifying network-wide invariants in real time[C] //Proc of USENIX NSDI’13. Berkeley, CA: USENIX Association, 2013: 15-27

[6] Voellmy A, Wang Junchang, Yang Y R, et al. Maple: Simplifying SDN programming using algorithmic policies[C] //Proc of ACM SIGCOMM’13. New York: ACM, 2013: 87-98

[7] Hu Hongxin, Han W, Ahn G J, et al. FLOWGUARD: Building robust firewalls for software-defined networks[C]//Proc of ACM SIGCOMM Workshop HotSDN’14. New York: ACM, 2014: 97-102

[8] Porras P, Cheung S, Fong M, et al. Securing the software-defined network control layer[C] //Proc of ISOC NDSS’15. Reston, VA: ISOC, 2015: 1-15

[9] Naous J, Walfish M, Nicolosi A, et al. Verifying and enforcing network paths with ICING[C] //Proc of ACM CoNEXT’11. New York: ACM, 2011: 1-12

[10] Liu Xin, Li Ang, Yang Xiaowei, et al. Passport: Secure and adoptable source authentication[C] //Proc of USENIX NSDI’08. Berkeley, CA: USENIX Association, 2008: 365-378

[11] Kim H J, Basescu C, Jia Limin, et al. Lightweight source authentication and path validation[C] //Proc of ACM SIGCOMM’14. New York: ACM, 2014: 271-282

[12] Mohan D, Rishabh P, Kshiteej M, et al. SPHINX: Detecting security attacks in software-defined networks[C] //Proc of ISOC NDSS’15. Reston, VA: ISCO, 2015: 8-11

[13] Zhang Xin, Zhou Zongwei, Hsiao H C, et al. ShortMAC: Efficient data-plane fault localization[C/OL] //Proc of ISOC NDSS’12. Reston, VA: ISOC, 2012 [2016-10-02]. http://repository.cmu.edu/cylab/84/

[14] Nakibly G, Kirshon A, Gonikman D, et al. Persistent OSPF attacks[C/OL] //Proc of ISOC NDSS’12. Reston, VA: ISOC, 2012 [2016-10-02]. http://crypto.stanford.edu/～dabo/papers/ospf.pdf