SDN網(wǎng)絡(luò)拓?fù)湮廴竟舴烙鶛C(jī)制研究

鄭 正 徐明偉 李 琦 張 云

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

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

(13222026288@163.com)

軟件定義網(wǎng)絡(luò)(software-defined networking, SDN)起源于2006年斯坦福大學(xué)的Clean Slate研究課題，2009年SDN的概念正式被提出.此后SDN相關(guān)技術(shù)的研究迅速開(kāi)展起來(lái)，成為近年來(lái)的研究熱點(diǎn).與傳統(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ā)情況.目前越來(lái)越多的公司部署了SDN相關(guān)技術(shù)，例如谷歌公司采用SDN技術(shù)優(yōu)化其數(shù)據(jù)中心互連.然而，SDN系統(tǒng)設(shè)計(jì)之初沒(méi)有考慮到的安全漏洞逐漸暴露出來(lái)，例如SDN拓?fù)湮廴竟鬧1].隨著SDN應(yīng)用越來(lái)越廣泛，SDN安全性問(wèn)題也凸顯出來(lái).

SDN拓?fù)湮廴韭┒词强刂破鞯讓拥耐負(fù)浞?wù)中存在的安全漏洞，直接影響SDN的可用性.拓?fù)浞?wù)通過(guò)搜集下層網(wǎng)絡(luò)信息，給上層應(yīng)用和計(jì)算路由等主要網(wǎng)絡(luò)服務(wù)提供全網(wǎng)的拓?fù)湫畔?因此，解決拓?fù)浞?wù)的安全漏洞對(duì)于研究和應(yīng)用SDN至關(guān)重要.Hong等人[1]首次研究防御SDN拓?fù)湮廴竟舻姆桨?但是，該方案中提出的方法并不能有效地防御拓?fù)涔?此外，該方案不僅破壞了SDN的控制和數(shù)據(jù)相分離的原則，而且引入了非常大的存儲(chǔ)開(kāi)銷.

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

1 SDN拓?fù)涔芾碓?/h2>

SDN通過(guò)對(duì)上層應(yīng)用(例如負(fù)載均衡和最短路徑路由服務(wù)等)提供可編程接口，使得應(yīng)用能夠根據(jù)控制器提供的拓?fù)湫畔⑦M(jìn)行路由計(jì)算.控制器中的拓?fù)涔芾矸?wù)負(fù)責(zé)維護(hù)拓?fù)湫畔ⅲ饕?個(gè)部分功能：1)發(fā)現(xiàn)交換機(jī)；2)發(fā)現(xiàn)主機(jī)；3)發(fā)現(xiàn)鏈路.目前已知的拓?fù)涔芾矸?wù)漏洞存在于主機(jī)發(fā)現(xiàn)和鏈路發(fā)現(xiàn)這2個(gè)部分:

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

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

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

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

2 SDN拓?fù)涔?/h2>

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

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

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

2.2 鏈路偽造攻擊

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

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

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

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

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

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

存在這2類攻擊的主要原因是：目前控制器缺少對(duì)網(wǎng)絡(luò)拓?fù)湎⒌尿?yàn)證，無(wú)法保證拓?fù)湫畔⒌恼鎸?shí)性.因此對(duì)于網(wǎng)絡(luò)鏈路信息，控制器無(wú)法辨別消息的真?zhèn)危使粽叽鄹钠鋬?nèi)容并不會(huì)被發(fā)現(xiàn).當(dāng)控制器收到LLDP包時(shí)，是默認(rèn)為真實(shí)的LLDP包.攻擊者利用這樣的漏洞可以在網(wǎng)絡(luò)中偽造出虛假的主機(jī)和鏈路，進(jìn)而可以導(dǎo)致網(wǎng)絡(luò)中信息傳輸?shù)幕靵y、網(wǎng)絡(luò)崩潰甚至是網(wǎng)絡(luò)被攻擊者完全控制.

文獻(xiàn)[1]提出了TopoGuard模型來(lái)防御拓?fù)湮廴竟?，該模型是通過(guò)驗(yàn)證主機(jī)遷移的前置和后置條件來(lái)判斷是否存在主機(jī)位置劫持攻擊.主機(jī)遷移的前置條件是控制器收到端口的Port_Down信號(hào)；后置條件是遷移結(jié)束以后，控制器給該主機(jī)原來(lái)的位置發(fā)送ICMP探測(cè)的結(jié)果是不可達(dá)的，確保在原來(lái)的位置上不能再訪問(wèn)該主機(jī).只有滿足這2個(gè)條件才能確定該主機(jī)位置移動(dòng)是真實(shí)的.

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

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ù)包，由控制器來(lái)構(gòu)造就違背了SDN的設(shè)計(jì)原則，會(huì)造成控制器功能和執(zhí)行的混亂.

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

3) 控制器存儲(chǔ)每個(gè)端口所連接的設(shè)備類型，這種方式所需的存儲(chǔ)空間有些部分可能會(huì)存在浪費(fèi)，因?yàn)樵诤芏嗲闆r下，每臺(tái)交換機(jī)的每個(gè)端口上在不同時(shí)間可能會(huì)連接多個(gè)網(wǎng)絡(luò)設(shè)備.

3 拓?fù)湮廴痉烙猄ecTopo

3.1 方案概述

為了解決拓?fù)湮廴竟?，我們提出了SecTopo.SecTopo在SDN控制器拓?fù)涔芾矸?wù)中提供網(wǎng)絡(luò)拓?fù)湫畔⒌尿?yàn)證功能.SecTopo的基本目標(biāo)就是建立一個(gè)有效驗(yàn)證網(wǎng)絡(luò)拓?fù)湫畔⒌臋C(jī)制.SecTopo結(jié)構(gòu)如圖5所示，SecTopo主要包含3個(gè)驗(yàn)證模塊：主機(jī)接入檢查模塊、鏈路發(fā)現(xiàn)處理模塊和流表項(xiàng)處理模塊.主機(jī)接入模塊和流表項(xiàng)處理模塊用于解決主機(jī)位置劫持攻擊，而鏈路發(fā)現(xiàn)處理模塊用于解決鏈路偽造攻擊.

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

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

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

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

3.2 主機(jī)接入檢查模塊

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

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

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

算法1. 主機(jī)接入檢查.

輸入:詢問(wèn)流表項(xiàng)的Packet-In；

輸出:True或False.

①temp=MacAddress,switchid,portnum;

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

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

③ IF Packet-In包含的主機(jī)MAC地址在

hostlist中 THEN

④hostlist.add(temp);

⑤ END IF

⑥ RETURN True;

⑦ END IF

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

⑨ IF主機(jī)的MAC地址已在hostlist中

THEN

⑩ IFtemp是hostlist中1個(gè)條目THEN

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

3.3 流表項(xiàng)處理模塊

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

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

算法2. 檢測(cè)流表更新.

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

①temp_1=srcmac,switchid,portnum;

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

② IFsiginstall==True THEN /*下發(fā)流表項(xiàng)時(shí)*/

③ IFtemp_1 匹配flowlist中條目A

THEN

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

⑤ ELSE

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

⑦count=1;

⑧ END IF

⑨ END IF

⑩ IFsigdelete==True THEN /*交換機(jī)刪除1個(gè)流表項(xiàng)時(shí)*/

THEN

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

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

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

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

算法3. 檢查L(zhǎng)LDP包真實(shí)性.

輸入:來(lái)自交換機(jī)的LLDP；

輸出:True 或 False.

①temp_2=switchid,portnum,token;

/*從LLDP中提取信息*/

② IF收到的LLDP無(wú)法匹配LLDPlist中條目THEN

③ RETURN False; /*則認(rèn)為是偽造的

LLDP*/

④ END IF

⑤ IFtemp_2.switchid,portnum匹配

hostlist中條目CTHEN

⑥ RETURN False;

⑦ END IF

3.5 與TopoGuard的比較

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

Table 1 The Comparision of SecTopo and TopoGuard

4 實(shí)驗(yàn)評(píng)估

4.1 實(shí)驗(yàn)設(shè)置

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

本實(shí)驗(yàn)部分進(jìn)行了2組實(shí)驗(yàn)，分別是驗(yàn)證方案有效性和測(cè)試方案性能.驗(yàn)證有效性和測(cè)試性能的實(shí)驗(yàn)中，為了提高測(cè)試精度，不引入其他影響因素，故采用了圖6所示的拓?fù)?在測(cè)試時(shí)間開(kāi)銷時(shí)，多個(gè)節(jié)點(diǎn)情況下的平均時(shí)間開(kāi)銷變化不大.在測(cè)試吞吐量時(shí)，在交換機(jī)和主機(jī)拓?fù)湟?guī)模變大時(shí)，控制器吞吐性能會(huì)受到影響.

Fig. 6 Topology graph of the experiment圖6 實(shí)驗(yàn)拓?fù)鋱D

4.2 方案有效性

本實(shí)驗(yàn)驗(yàn)證SecTopo是否能夠檢測(cè)出網(wǎng)絡(luò)拓?fù)湮廴竟?控制器運(yùn)行SecTopo模型，使用Scapy工具模擬實(shí)現(xiàn)網(wǎng)絡(luò)拓?fù)湮廴竟?，通過(guò)控制臺(tái)輸出來(lái)觀察SecTopo對(duì)攻擊的反應(yīng).

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

Fig. 7 The detection of host position attack圖7 主機(jī)位置劫持檢測(cè)

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

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

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

4.3 方案性能

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

Table 2 Token’s Overhead on the Floodlight表2 校驗(yàn)字段對(duì)Floodlight的時(shí)間開(kāi)銷 ms

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

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

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

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

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

5 討 論

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

6 相關(guān)工作

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

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

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

7 結(jié) 論

本文總結(jié)了現(xiàn)有的SDN拓?fù)涔艉头烙ぷ?，提出了輕量級(jí)的拓?fù)湮廴締?wèn)題的防御方案——SecTopo，一種安全的動(dòng)態(tài)管理接入網(wǎng)絡(luò)主機(jī)的算法和安全的鏈路發(fā)現(xiàn)算法，并且對(duì)一些可能的情況進(jìn)行了分析.下一步的研究主要是解決主機(jī)劫持攻擊的對(duì)象為普通用戶時(shí)的攻擊防御問(wèn)題，并且進(jì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