SDN網絡拓撲污染攻擊防御機制研究

鄭 正 徐明偉 李 琦 張 云

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

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

(13222026288@163.com)

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

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

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

1 SDN拓撲管理原理

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

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

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

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

Fig. 1 Procedure of link discovery in SDN圖1 SDN網絡鏈路發現過程

2 SDN拓撲攻擊

2.1 網絡用戶流量劫持攻擊

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

Fig. 2 Procedure of Web client harvest圖2 劫持網絡用戶流量過程

2.2 鏈路偽造攻擊

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

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

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

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

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

2.3 漏洞分析和現有方案

存在這2類攻擊的主要原因是：目前控制器缺少對網絡拓撲消息的驗證，無法保證拓撲信息的真實性.因此對于網絡鏈路信息，控制器無法辨別消息的真偽，故攻擊者篡改其內容并不會被發現.當控制器收到LLDP包時，是默認為真實的LLDP包.攻擊者利用這樣的漏洞可以在網絡中偽造出虛假的主機和鏈路，進而可以導致網絡中信息傳輸的混亂、網絡崩潰甚至是網絡被攻擊者完全控制.

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

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

1) SDN網絡的原則就是將網絡的控制層和數據層分離.控制層不應該執行數據層包含的功能，控制器雖然能構造LLDP等網絡包，但是ICMP是數據層的數據包，由控制器來構造就違背了SDN的設計原則，會造成控制器功能和執行的混亂.

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

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

3 拓撲污染防御—SecTopo

3.1 方案概述

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

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

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

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

Fig. 5 The architecture of SecTopo圖5 SecTopo結構圖

3.2 主機接入檢查模塊

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

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

此外，當1臺主機長時間沒有發送流量，主機直連的交換機上關于該主機的流表項全部過期后，該主機又開始發送流量時，在主機列表中并不存在該主機消息，控制器收到關于該主機的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主要步驟為建立表格和查詢表格，時間復雜度在O(n).根據2.1節提到的網絡流量劫持，攻擊者使用網絡中某個服務器的IP地址和物理地址，發送偽造的主機流量，例如IPv4流量，直連的交換機收到該主機流量后會向控制器發送含有IPv4的Packet-In消息.當該部分收到的Packet-In消息包含的是IPv4網絡包，會檢查該Packet-In消息里的主機物理地址是否存在于主機表格中，如果存在，再檢查表格中該條目的其他的信息和Packet-In消息里對應信息是否符合，如果信息不符合，就認為是攻擊行為.

3.3 流表項處理模塊

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

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

算法2. 檢測流表更新.

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

①temp_1=srcmac,switchid,portnum;

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

② IFsiginstall==True THEN /*下發流表項時*/

③ 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 鏈路發現處理模塊

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

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

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

與現有方案TopoGuard相比，本文提出的SecTopo在控制層不需要構造數據層探測包的情況下，可以更有效地防御拓撲污染攻擊.此外，SecTopo可以有效地防御重放攻擊，并支持網絡的動態更新.具體比較如表1所示：

Table 1 The Comparision of SecTopo and TopoGuard

4 實驗評估

4.1 實驗設置

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

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

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

4.2 方案有效性

本實驗驗證SecTopo是否能夠檢測出網絡拓撲污染攻擊.控制器運行SecTopo模型，使用Scapy工具模擬實現網絡拓撲污染攻擊，通過控制臺輸出來觀察SecTopo對攻擊的反應.

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

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和端口號，與主機列表中對應信息作對比，發現位置信息不符合.SecTopo就及時地報告錯誤，阻止了以后的步驟，避免了拓撲污染.

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

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

4.3 方案性能

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

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

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

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

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

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

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

5 討 論

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

6 相關工作

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

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

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

7 結 論

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

[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