王東濱,吳東哲,智慧,郭昆,4,5,張勖,時(shí)金橋,張宇,陸月明,4
(1.北京郵電大學(xué)網(wǎng)絡(luò)空間安全學(xué)院,北京 100876;2.鏈網(wǎng)融合技術(shù)教育部工程研究中心,北京 100876;3.中國民航信息網(wǎng)絡(luò)股份有限公司,北京 100190;4.移動(dòng)互聯(lián)網(wǎng)安全技術(shù)國家工程研究中心,北京 100876;5.中關(guān)村實(shí)驗(yàn)室,北京 100094;6.哈爾濱工業(yè)大學(xué)網(wǎng)絡(luò)空間安全學(xué)院,黑龍江 哈爾濱 150001;7.鵬城實(shí)驗(yàn)室網(wǎng)絡(luò)空間安全研究中心,廣東 深圳 518055)
傳統(tǒng)封閉的網(wǎng)絡(luò)設(shè)備內(nèi)置了過多復(fù)雜協(xié)議,隨著網(wǎng)絡(luò)規(guī)模的不斷擴(kuò)大,網(wǎng)絡(luò)配置復(fù)雜度越來越高、網(wǎng)絡(luò)的管理和維護(hù)越來越復(fù)雜,增加了運(yùn)營商定制優(yōu)化網(wǎng)絡(luò)的難度[1]。軟件定義網(wǎng)絡(luò)(SDN,software defined network)將控制平面與數(shù)據(jù)平面分離解耦,使具有全局網(wǎng)絡(luò)視圖的控制平面能夠?qū)?shù)據(jù)平面進(jìn)行集中式管理,實(shí)現(xiàn)路由策略集中計(jì)算和下發(fā),數(shù)據(jù)平面按照控制平面下發(fā)的流規(guī)則進(jìn)行網(wǎng)絡(luò)數(shù)據(jù)的傳輸轉(zhuǎn)發(fā)。軟件定義網(wǎng)絡(luò)使網(wǎng)絡(luò)管理變得更具靈活性和創(chuàng)新性,并通過多控制器實(shí)現(xiàn)網(wǎng)絡(luò)擴(kuò)展及對(duì)大規(guī)模復(fù)雜網(wǎng)絡(luò)的集中管理和維護(hù)[2-4]。
目前,OpenFlow[2]作為軟件定義網(wǎng)絡(luò)協(xié)議已被廣泛采用,當(dāng)有網(wǎng)絡(luò)報(bào)文到達(dá)數(shù)據(jù)平面交換機(jī)時(shí),交換機(jī)會(huì)先匹配已安裝的流規(guī)則,如果成功匹配,則按照流規(guī)則的動(dòng)作執(zhí)行修改、轉(zhuǎn)發(fā)和丟棄網(wǎng)絡(luò)報(bào)文等操作;如果未成功匹配(即出現(xiàn)table-miss),則交換機(jī)將網(wǎng)絡(luò)報(bào)文封裝到packet-in消息中上報(bào)給控制平面控制器,控制器計(jì)算轉(zhuǎn)發(fā)路徑后,向交換機(jī)下發(fā)安裝流規(guī)則的flow-mod 消息和轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文到下一跳交換機(jī)的packet-out消息,交換機(jī)執(zhí)行安裝該網(wǎng)絡(luò)流的流規(guī)則,并將網(wǎng)絡(luò)報(bào)文轉(zhuǎn)發(fā)給下一跳交換機(jī)。該網(wǎng)絡(luò)流后續(xù)到達(dá)的網(wǎng)絡(luò)報(bào)文匹配上已安裝的流規(guī)則后直接被轉(zhuǎn)發(fā),不需要再次上報(bào)packet-in 消息給控制器。在轉(zhuǎn)發(fā)路徑上的每一跳,交換機(jī)都按照上述流程處理收到的網(wǎng)絡(luò)報(bào)文。
為了更加高效地實(shí)現(xiàn)流規(guī)則的匹配,交換機(jī)廣泛采用三態(tài)內(nèi)容尋址存儲(chǔ)器(TCAM)存儲(chǔ)和匹配流規(guī)則,但是TCAM 價(jià)格昂貴,僅可支持8 000 條流規(guī)則的存儲(chǔ),有限的交換機(jī)流表空間容量和控制器的集中式傳輸控制管理使軟件定義網(wǎng)絡(luò)更易遭受拒絕服務(wù)攻擊的威脅[5-9]。軟件定義網(wǎng)絡(luò)拒絕服務(wù)攻擊如圖1 所示,攻擊者會(huì)隨機(jī)生成無法成功匹配交換機(jī)流規(guī)則的大量拒絕服務(wù)攻擊流量,與正常網(wǎng)絡(luò)流量混合在一起進(jìn)入交換機(jī)。由于難以識(shí)別和管控拒絕服務(wù)攻擊,交換機(jī)不得不緩存所有網(wǎng)絡(luò)報(bào)文,并向控制器上報(bào)所有無法匹配流規(guī)則的網(wǎng)絡(luò)報(bào)文的packet-in 消息,使控制器在計(jì)算路徑和發(fā)送安裝流規(guī)則的flow-mod 消息、轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文的packet-out 消息上耗盡CPU 和緩存資源;同時(shí)在交換機(jī)有限的流表空間中安裝了大量拒絕服務(wù)攻擊的流規(guī)則,短時(shí)間內(nèi)將導(dǎo)致有限的流表空間溢出,無法為正常的網(wǎng)絡(luò)流量安裝流規(guī)則,嚴(yán)重影響軟件定義網(wǎng)絡(luò)服務(wù)質(zhì)量。安全危害如下:1) 沒有安裝流規(guī)則的正常網(wǎng)絡(luò)流將會(huì)觸發(fā)table-miss 的處理過程,相較于能夠匹配流規(guī)則被直接轉(zhuǎn)發(fā)的處理過程,增加了網(wǎng)絡(luò)報(bào)文的轉(zhuǎn)發(fā)時(shí)延,降低了網(wǎng)絡(luò)可用帶寬;2) 無法安裝流規(guī)則的正常網(wǎng)絡(luò)流的每個(gè)網(wǎng)絡(luò)報(bào)文都將會(huì)觸發(fā)一次table-miss 處理過程,消耗更多的控制器計(jì)算和存儲(chǔ)資源,放大拒絕服務(wù)攻擊效果;3) 網(wǎng)絡(luò)報(bào)文轉(zhuǎn)發(fā)時(shí)延的增加會(huì)使越來越多的網(wǎng)絡(luò)報(bào)文停留在交換機(jī)有限的緩存中,甚至導(dǎo)致丟包。同時(shí),軟件定義網(wǎng)絡(luò)交換機(jī)的流表空間被所有端口共用,每個(gè)端口都會(huì)獨(dú)立地為流入的網(wǎng)絡(luò)新流報(bào)文在共享的有限容量的流表中安裝流規(guī)則。當(dāng)一個(gè)端口出現(xiàn)拒絕服務(wù)攻擊流量時(shí),會(huì)影響其他端口正常網(wǎng)絡(luò)流的流規(guī)則安裝。并且攻擊者會(huì)通過精心設(shè)計(jì)生成攻擊流量,不僅對(duì)攻擊流量的接入交換機(jī)產(chǎn)生拒絕服務(wù)攻擊效果,也使分布式攻擊流量流經(jīng)同一個(gè)中間交換機(jī),形成攻擊匯聚,發(fā)生再次拒絕服務(wù)攻擊,導(dǎo)致更嚴(yán)重的拒絕服務(wù)攻擊效果。
圖1 軟件定義網(wǎng)絡(luò)拒絕服務(wù)攻擊
為了避免軟件定義網(wǎng)絡(luò)交流機(jī)出現(xiàn)流表溢出,確保軟件定義網(wǎng)絡(luò)的穩(wěn)定運(yùn)行和網(wǎng)絡(luò)服務(wù)質(zhì)量,需要解決以下2 個(gè)挑戰(zhàn)。
1) 在拒絕服務(wù)攻擊發(fā)生時(shí),如何防止交換機(jī)流表空間被攻擊流的流規(guī)則占滿,避免流表溢出。
2) 網(wǎng)絡(luò)報(bào)文在轉(zhuǎn)發(fā)路徑傳輸過程中,如何避免在路徑上的交換機(jī)上出現(xiàn)網(wǎng)絡(luò)流匯聚導(dǎo)致的再次拒絕服務(wù)攻擊。
對(duì)于第一個(gè)挑戰(zhàn),由于與傳統(tǒng)網(wǎng)絡(luò)一樣,拒絕服務(wù)攻擊流量和正常網(wǎng)絡(luò)流量混在一起,攻擊流量很難被準(zhǔn)確識(shí)別和區(qū)分處理[10],因此無法采用類似攻擊流量清洗的策略來減少安裝流規(guī)則的數(shù)量,并且難以實(shí)現(xiàn)安裝的流規(guī)則都是正常網(wǎng)絡(luò)流。對(duì)于第二個(gè)挑戰(zhàn),攻擊者會(huì)精心構(gòu)造攻擊流量,使分布式的攻擊流量匯聚到軟件定義網(wǎng)絡(luò)同一個(gè)中間交換機(jī)上,可用流表空間少的交換機(jī)有可能成為攻擊者匯聚攻擊流量的目標(biāo)。
在無法準(zhǔn)確識(shí)別和消除攻擊流量的情況下,本文提出了抗拒絕服務(wù)攻擊的軟件定義網(wǎng)絡(luò)流表溢出防護(hù)技術(shù)FloodMitigation,來避免軟件定義網(wǎng)絡(luò)流表資源消耗和確保網(wǎng)絡(luò)服務(wù)質(zhì)量,主要的技術(shù)貢獻(xiàn)如下。
1) 提出了基于可用流表空間的限速流規(guī)則管理機(jī)制,動(dòng)態(tài)限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口的流規(guī)則安裝最大速度,避免交換機(jī)流表空間被拒絕服務(wù)攻擊流規(guī)則占滿而出現(xiàn)流表溢出的情況,以及影響其他端口正常網(wǎng)絡(luò)流的流規(guī)則安裝。優(yōu)先為出現(xiàn)頻次高的網(wǎng)絡(luò)流安裝流規(guī)則,減少了上報(bào)packet-in 消息的數(shù)量、控制器消耗、網(wǎng)絡(luò)傳輸時(shí)延和網(wǎng)絡(luò)報(bào)文緩存溢出導(dǎo)致的網(wǎng)絡(luò)丟包情況。
2) 提出了基于可用流表空間的路徑選擇,通過在多條轉(zhuǎn)發(fā)路徑的交換機(jī)間均衡流表利用率,避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚在可用流表空間少的交換機(jī)上所導(dǎo)致的再次拒絕服務(wù)攻擊。
3) 對(duì)FloodMitigation 進(jìn)行了實(shí)驗(yàn)驗(yàn)證,實(shí)驗(yàn)結(jié)果表明,F(xiàn)loodMitigation 能夠有效防止交換機(jī)流表溢出,降低控制器資源消耗、傳輸時(shí)延和網(wǎng)絡(luò)丟包,確保網(wǎng)絡(luò)可用帶寬。
拒絕服務(wù)攻擊者通常向攻擊目標(biāo)發(fā)起大量的偽造網(wǎng)絡(luò)報(bào)文的不同字段、短流的網(wǎng)絡(luò)攻擊流量,消耗目標(biāo)的服務(wù)資源。傳統(tǒng)網(wǎng)絡(luò)的交換機(jī)、路由器等傳輸設(shè)備把拒絕服務(wù)攻擊流量等同于正常網(wǎng)絡(luò)流量進(jìn)行轉(zhuǎn)發(fā),不受拒絕服務(wù)攻擊影響,但是軟件定義網(wǎng)絡(luò)控制器響應(yīng)式地向交換機(jī)下發(fā)流規(guī)則來轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文,使交換機(jī)有限的流表容量和緩存容量、控制器集中式的傳輸控制管理等成為瓶頸,更易被拒絕服務(wù)攻擊者利用。很多研究從報(bào)文源真實(shí)性校驗(yàn)丟棄報(bào)文、降低控制器和交換機(jī)資源占用、動(dòng)態(tài)調(diào)整流表項(xiàng)超時(shí)時(shí)間等不同角度出發(fā)研究拒絕服務(wù)攻擊防護(hù)技術(shù)。
Shin 等[11]首次提出了軟件定義網(wǎng)絡(luò)拒絕服務(wù)攻擊威脅問題,并提出了基于連接遷移的防護(hù)機(jī)制,通過代理的方式對(duì)報(bào)文源地址的真實(shí)性進(jìn)行校驗(yàn),校驗(yàn)通過后轉(zhuǎn)發(fā)網(wǎng)絡(luò)數(shù)據(jù)報(bào)文,能夠有效地對(duì)有連接狀態(tài)的傳輸控制協(xié)議(TCP)拒絕服務(wù)攻擊進(jìn)行檢測和過濾,但是無法應(yīng)對(duì)用戶數(shù)據(jù)報(bào)協(xié)議(UDP)等無連接狀態(tài)的拒絕服務(wù)攻擊,在實(shí)際應(yīng)用中有很大缺陷。Ambrosin 等[12]提出了類似的防御模型,基于代理和黑名單來緩解拒絕服務(wù)攻擊。面向流表資源和處理資源保護(hù),F(xiàn)loodShield[13]通過源地址驗(yàn)證丟棄偽造地址的網(wǎng)絡(luò)流量,對(duì)于不確定的網(wǎng)絡(luò)流量,采用基于控制器CPU 利用率的概率接受方式處理packet-in 和安裝流規(guī)則,但是隨著網(wǎng)絡(luò)攻擊流的增大,會(huì)導(dǎo)致控制器處理資源消耗增加、交換機(jī)流表溢出和網(wǎng)絡(luò)丟包等情況發(fā)生。DoSGuard[14]在控制器上保存主機(jī)介質(zhì)訪問控制(MAC)地址和交換機(jī)的映射關(guān)系,當(dāng)控制器發(fā)現(xiàn)從某個(gè)端口上報(bào)的網(wǎng)絡(luò)報(bào)文的源MAC 未知時(shí),通過向交換機(jī)安裝流規(guī)則,將未匹配流表的報(bào)文全部進(jìn)行丟棄處理。
面向控制器的資源保護(hù),F(xiàn)loodGuard[15]設(shè)置額外的緩存模塊,根據(jù)網(wǎng)絡(luò)報(bào)文的協(xié)議類型采用多隊(duì)列形式緩存packet-in 消息,并采用round robin 算法限速發(fā)給控制器處理,保護(hù)控制器處理資源。拒絕服務(wù)攻擊只會(huì)影響與其相同類型的協(xié)議隊(duì)列,保證了其他類型協(xié)議隊(duì)列中的packet-in正常處理,但是會(huì)使與拒絕服務(wù)攻擊流量在同一個(gè)隊(duì)列的正常網(wǎng)絡(luò)流量處理時(shí)延和丟包。文獻(xiàn)[16]設(shè)置額外備份控制器,過濾處理疑似惡意流量的packet-in 消息后,再限速將packet-in 消息發(fā)送給主控制器,從減少packet-in 消息的角度保護(hù)控制器的資源,但無法確保正常網(wǎng)絡(luò)流量傳輸時(shí)延以及避免丟包。
面向交換機(jī)的保護(hù),F(xiàn)loodDefender[17]基于排隊(duì)論經(jīng)驗(yàn)公式和鏈路利用率建立了流量遷移模型,當(dāng)檢測到發(fā)生拒絕服務(wù)攻擊時(shí),交換機(jī)根據(jù)網(wǎng)絡(luò)流量信息對(duì)packet-in 消息進(jìn)行過濾,并依據(jù)與其鄰接的交換機(jī)的可用安全信道容量將網(wǎng)絡(luò)報(bào)文遷移給相鄰的交換機(jī),能有效減少該交換機(jī)與控制器通過安全信道的數(shù)據(jù)交互,避免安全信道發(fā)生擁塞,但采用的過濾機(jī)制將會(huì)導(dǎo)致正常網(wǎng)絡(luò)流量被丟棄。Yuan等[5]提出在交換機(jī)可用流表空間不足時(shí),通過通配符將流量遷移到相鄰的伙伴交換機(jī)上,利用伙伴交換機(jī)的空閑資源來共同處理網(wǎng)絡(luò)報(bào)文,但無法有效降低控制器的資源消耗。文獻(xiàn)[18]處理packet-in 消息,記錄這些報(bào)文的IP,當(dāng)發(fā)往目的IP 的所有數(shù)據(jù)包的Renyi 熵超過閾值時(shí),認(rèn)為這些報(bào)文是攻擊流量,對(duì)報(bào)文進(jìn)行丟包處理,但無法避免正常網(wǎng)絡(luò)流量丟包情況。文獻(xiàn)[19]將流量分為大象流和老鼠流,不為老鼠流安裝流表項(xiàng),直接通過packet-out消息轉(zhuǎn)發(fā),降低對(duì)流表的占用,但無法確保轉(zhuǎn)發(fā)的攻擊流量不流經(jīng)相同中間交換機(jī),無法避免形成攻擊匯聚。
在流表資源方面,目前研究主要采用動(dòng)態(tài)調(diào)整超時(shí)時(shí)間,縮小流表項(xiàng)在TCAM 中的無效時(shí)間,提高流表利用率,但大量的拒絕服務(wù)攻擊流依然會(huì)使流表溢出。文獻(xiàn)[20]基于控制器收集流歷史信息,對(duì)流表項(xiàng)空閑超時(shí)時(shí)間進(jìn)行動(dòng)態(tài)設(shè)置。HQTimer[21]采用深度強(qiáng)化學(xué)習(xí)根據(jù)當(dāng)前命中率等信息的反饋進(jìn)行動(dòng)態(tài)超時(shí)時(shí)間的決策下發(fā),從而達(dá)到更高的流表命中率,但無法避免拒絕服務(wù)攻擊流使流表溢出。文獻(xiàn)[22]通過流表溢出預(yù)測將流表項(xiàng)進(jìn)行主動(dòng)刪除,但會(huì)不可避免地將正常網(wǎng)絡(luò)流表項(xiàng)刪除。
現(xiàn)有工作從不同的性能瓶頸角度出發(fā)研究拒絕服務(wù)攻擊防護(hù)技術(shù),但不能有效地防止流表溢出,以及防止拒絕服務(wù)攻擊流量在轉(zhuǎn)發(fā)中匯聚導(dǎo)致的再次拒絕服務(wù)。本文針對(duì)流表溢出防護(hù)問題,提出了基于流表可用空間的限速流規(guī)則管理,限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口的流規(guī)則最大安裝速度和占用的流表空間數(shù)量,避免了流表溢出;然后采用基于可用流表空間的路徑選擇,在多條轉(zhuǎn)發(fā)路徑的交換機(jī)間均衡流表利用率,避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導(dǎo)致的再次拒絕服務(wù)攻擊。本文提出的軟件定義網(wǎng)絡(luò)流表溢出防護(hù)技術(shù)FloodMitigation 在沒有引入額外設(shè)備的情況下,實(shí)現(xiàn)了在拒絕服務(wù)攻擊下對(duì)流表空間溢出的防護(hù)。
針對(duì)拒絕服務(wù)攻擊導(dǎo)致的流表溢出問題,本文設(shè)計(jì)了軟件定義網(wǎng)絡(luò)流表溢出防護(hù)FloodMitigation,并將其作為集成模塊運(yùn)行在控制平面上,包括流監(jiān)測、限速流規(guī)則管理、路徑選擇這3 個(gè)模塊,系統(tǒng)模型如圖2 所示。
圖2 系統(tǒng)模型
在軟件定義網(wǎng)絡(luò)正常運(yùn)行時(shí),只有流監(jiān)測模塊在運(yùn)行,其他拒絕服務(wù)攻擊防護(hù)模塊處于待激活狀態(tài)。當(dāng)檢測到交換機(jī)端口上出現(xiàn)拒絕服務(wù)攻擊時(shí),流監(jiān)測模塊觸發(fā)限速流規(guī)則管理模塊,進(jìn)行流表溢出防護(hù)。同時(shí)路徑選擇模塊采用負(fù)載均衡策略為網(wǎng)絡(luò)流選擇傳輸路徑,避免網(wǎng)絡(luò)流流經(jīng)同一個(gè)中間交換機(jī)導(dǎo)致流表溢出。處理流程如下。
1) 流監(jiān)測模塊統(tǒng)計(jì)交換機(jī)上報(bào)的packet-in 消息、網(wǎng)絡(luò)流量統(tǒng)計(jì)、計(jì)算和內(nèi)存資源占用率等網(wǎng)絡(luò)與系統(tǒng)狀態(tài),建立基于交換機(jī)端口的網(wǎng)絡(luò)流統(tǒng)計(jì)信息表,并進(jìn)行拒絕服務(wù)攻擊檢測。當(dāng)出現(xiàn)拒絕服務(wù)攻擊時(shí),觸發(fā)其他拒絕服務(wù)攻擊防護(hù)模塊。
2) 限速流規(guī)則管理模塊收到來自發(fā)生拒絕服務(wù)攻擊的交換機(jī)端口的packet-in 消息后,調(diào)用路徑選擇模塊計(jì)算轉(zhuǎn)發(fā)路徑,并進(jìn)行限速安裝流規(guī)則,通過限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口安裝流規(guī)則的最大數(shù)量和速度,避免發(fā)生拒絕服務(wù)攻擊的端口的流規(guī)則占滿整個(gè)流表空間,確保其他端口的網(wǎng)絡(luò)新流的流規(guī)則安裝使用。
3) 路徑選擇模塊被限速流規(guī)則管理模塊調(diào)用,基于交換機(jī)可用流表空間容量來選擇轉(zhuǎn)發(fā)路徑,從多條路徑中選取可用流表空間最大的路徑。通過均衡多條轉(zhuǎn)發(fā)路徑的交換機(jī)間的流表利用率,避免交換機(jī)轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚再次引發(fā)拒絕服務(wù)攻擊。
流監(jiān)測模塊持續(xù)監(jiān)測交換機(jī)端口上報(bào)的packet-in 消息速率、網(wǎng)絡(luò)流量統(tǒng)計(jì),以及控制器內(nèi)存和計(jì)算資源占用率等網(wǎng)絡(luò)與系統(tǒng)狀態(tài),并建立基于交換機(jī)端口的網(wǎng)絡(luò)流統(tǒng)計(jì)信息表,結(jié)構(gòu)如圖3 所示。統(tǒng)計(jì)信息如下:packet-in 消息中包含的網(wǎng)絡(luò)流的源地址scr、目的地址dst、協(xié)議號(hào)protocol、源端口srcPort、目的端口dstPort 的五元組信息tuple5(圖3 中用tup 表示);tuple5 內(nèi)容的哈希值key 作為網(wǎng)絡(luò)流統(tǒng)計(jì)項(xiàng)flow_entry 入口序號(hào);該網(wǎng)絡(luò)流最近一次packet-in 到達(dá)的時(shí)間time;該網(wǎng)絡(luò)流的packet-in 消息的頻次frequency(圖3 中用freq 表示)。網(wǎng)絡(luò)流統(tǒng)計(jì)信息表用于拒絕服務(wù)攻擊檢測,并被限速流規(guī)則管理模塊用來決策是否為網(wǎng)絡(luò)流下發(fā)流規(guī)則。
圖3 網(wǎng)絡(luò)流統(tǒng)計(jì)信息表結(jié)構(gòu)
當(dāng) packet-in 消息到達(dá)時(shí),流監(jiān)測模塊對(duì)packet-in 消息的五元組信息計(jì)算哈希值key,即網(wǎng)絡(luò)流統(tǒng)計(jì)信息表的入口序號(hào)。由于多個(gè)不同網(wǎng)絡(luò)流會(huì)哈希到同一個(gè)哈希值key,需要精確匹配packet-in中的五元組信息,找到對(duì)應(yīng)網(wǎng)絡(luò)流的流表項(xiàng)flow_entry,增加該網(wǎng)絡(luò)流上報(bào)packet-in 消息的頻次frequency,并采用雙向鏈表frequency_chain 將出現(xiàn)的頻次frequency 進(jìn)行排序,排序后的frequency用于后續(xù)限速流規(guī)則管理模塊對(duì)網(wǎng)絡(luò)流是否下發(fā)流規(guī)則的決策。同時(shí),更新最近出現(xiàn)時(shí)間time 字段,并采用雙向鏈表time_chain 將最近更新時(shí)間time 進(jìn)行排序。如果控制器為網(wǎng)絡(luò)流向交換機(jī)下發(fā)安裝流規(guī)則或者在超時(shí)時(shí)間內(nèi)沒有新的packet-in 到達(dá),則該網(wǎng)絡(luò)流統(tǒng)計(jì)項(xiàng)flow_entry 將被刪除。流監(jiān)測算法偽代碼如算法1 所示。
算法1流監(jiān)測算法
根據(jù)交換機(jī)上報(bào)的packet-in 消息,查找匹配的流表項(xiàng)flow_entry
流監(jiān)測模塊采用與FloodDefender[18]相同的拒絕服務(wù)攻擊檢測方法,通過異常閾值檢測識(shí)別交換機(jī)端口出現(xiàn)的拒絕服務(wù)攻擊。流監(jiān)測模塊持續(xù)統(tǒng)計(jì)網(wǎng)絡(luò)流的packet-in 消息的頻次frequency,一旦出現(xiàn)拒絕服務(wù)攻擊,低頻次的網(wǎng)絡(luò)流數(shù)量就會(huì)快速增加,當(dāng)超過異常檢測閾值時(shí),流監(jiān)測模塊將觸發(fā)限速流規(guī)則管理模塊,進(jìn)行流表溢出防護(hù)。當(dāng)?shù)皖l次的網(wǎng)絡(luò)流數(shù)量低于異常檢測閾值時(shí),表示網(wǎng)絡(luò)中短流的數(shù)量處于安全范圍,流監(jiān)測模塊將停止調(diào)用限速流規(guī)則管理模塊,恢復(fù)正常處理網(wǎng)絡(luò)流的狀態(tài)。
限速流規(guī)則管理被觸發(fā)后,調(diào)用路徑選擇模塊對(duì)出現(xiàn)拒絕服務(wù)攻擊流量的交換機(jī)端口的packet-in計(jì)算轉(zhuǎn)發(fā)路徑,然后根據(jù)限速安裝速率以及該網(wǎng)絡(luò)流packet-in 出現(xiàn)的頻次決定是否向交換機(jī)下發(fā)安裝流規(guī)則的消息。對(duì)于未安裝流規(guī)則的網(wǎng)絡(luò)報(bào)文,將會(huì)向交換機(jī)下發(fā)packet-out 消息,直接將網(wǎng)絡(luò)報(bào)文轉(zhuǎn)發(fā)給下一跳交換機(jī)。
2.3.1 流規(guī)則限速安裝策略
交換機(jī)的流表空間被所有端口共用,為了避免出現(xiàn)拒絕服務(wù)攻擊的端口的網(wǎng)絡(luò)流量的流規(guī)則完全占滿流表空間,影響其他端口的流規(guī)則安裝,采用基于流表可用空間的限速安裝流規(guī)則策略,防止流表溢出。t時(shí)刻該端口的流規(guī)則最大安裝速率fmax(t)為
其中,T為流規(guī)則超時(shí)時(shí)間,α為流規(guī)則安裝速率的調(diào)節(jié)因子,c(t)為t時(shí)刻交換機(jī)可用流表空間大小。
其中,c(t-1)-fmax(t)為t-1 時(shí)刻安裝流規(guī)則后的可用流表空間容量。流規(guī)則對(duì)應(yīng)的網(wǎng)絡(luò)流在超時(shí)時(shí)間內(nèi)沒有新的網(wǎng)絡(luò)報(bào)文到達(dá)時(shí),將會(huì)從交換機(jī)流表里刪除,fdel(t)為因流規(guī)則超時(shí)被刪除后t時(shí)刻可用的流規(guī)則數(shù)量。在交換機(jī)只有一個(gè)端口出現(xiàn)拒絕服務(wù)攻擊流的情況下,由于網(wǎng)絡(luò)攻擊流通常為短流,網(wǎng)絡(luò)報(bào)文數(shù)量少,一個(gè)拒絕服務(wù)攻擊持續(xù)時(shí)間少于單位時(shí)間,可認(rèn)為fdel(t)等于在t-T時(shí)刻的最大安裝速率fmax(t-T),即
設(shè)交換機(jī)流表空間容量為C,結(jié)合式(1)~式(3)可得
交換機(jī)端口檢測到拒絕服務(wù)攻擊時(shí),根據(jù)式(4),取T=10 s(控制器ONOS 的默認(rèn)超時(shí)時(shí)間),按照最大速率fmax(t)為該端口的網(wǎng)絡(luò)流安裝流規(guī)則,交換機(jī)流表空間可用率和流規(guī)則安裝速率如圖4 所示,流表空間可用率、流規(guī)則安裝速率保持穩(wěn)定。隨著流規(guī)則安裝速率的調(diào)節(jié)因子α的增大,流表空間可用率下降、流規(guī)則安裝速率增長。當(dāng)流規(guī)則安裝速率的調(diào)節(jié)因子α=1.0時(shí),有53%流表可用空間可供其他端口所使用,流規(guī)則安裝速率約為5%。限速流規(guī)則管理能夠有效地限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口安裝流規(guī)則的最大數(shù)量,防止流表溢出,并確保其他端口的網(wǎng)絡(luò)流規(guī)則的安裝使用。
圖4 交換機(jī)流表空間可用率和流規(guī)則安裝速率
2.3.2 流規(guī)則安裝
控制器收到packet-in 消息后,首先計(jì)算網(wǎng)絡(luò)報(bào)文的轉(zhuǎn)發(fā)路徑,然后查詢?cè)摼W(wǎng)絡(luò)流出現(xiàn)的頻次。如果該網(wǎng)絡(luò)流出現(xiàn)的頻次位于前fmax(t)位,即該網(wǎng)絡(luò)流報(bào)文出現(xiàn)次數(shù)多,則通過flow-mod 消息向交換機(jī)下發(fā)安裝流規(guī)則,并下發(fā)packet-out 消息轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)文;否則將不下發(fā)安裝流規(guī)則的flow-mod 消息,直接通過低開銷的packet-out 轉(zhuǎn)發(fā)該網(wǎng)絡(luò)報(bào)文(在ONOS 官方的性能測試中處理packet-out 消息的性能比處理flow-mod 消息的性能高一個(gè)數(shù)量級(jí)),能有效防止流表溢出,并減少網(wǎng)絡(luò)報(bào)文在緩存中的等待時(shí)間,確保了網(wǎng)絡(luò)報(bào)文傳輸時(shí)延。流規(guī)則安裝算法如算法2 所示。
算法2流規(guī)則安裝算法
根據(jù)packet-in 消息和流監(jiān)測返回的流表項(xiàng)flow_entry,給轉(zhuǎn)發(fā)交換機(jī)下發(fā)安裝流規(guī)則的flow-mod 消息和轉(zhuǎn)發(fā)報(bào)文的packet-out 消息
軟件定義網(wǎng)絡(luò)中不同的交換機(jī)可用流表空間不同,拒絕服務(wù)攻擊流量被轉(zhuǎn)發(fā)流經(jīng)剩余流表空間較小的交換機(jī)時(shí),更易造成交換機(jī)流表溢出、增加網(wǎng)絡(luò)報(bào)文傳輸時(shí)延、消耗控制器資源、丟包等問題。而控制器ONOS 采用基于最小時(shí)延策略的Djikstra 算法來計(jì)算路徑,無法確保剩余流表空間較小的交換機(jī)不被選進(jìn)傳輸路徑。在軟件定義網(wǎng)絡(luò)中,源節(jié)點(diǎn)至目的節(jié)點(diǎn)通常有多條可達(dá)路徑,路徑選擇模塊計(jì)算路徑時(shí),從多條路徑中選取可用流表空間最大的路徑,通過均衡多條轉(zhuǎn)發(fā)路徑的交換機(jī)間的流表利用率,避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導(dǎo)致的再次拒絕服務(wù)攻擊,防止再次出現(xiàn)流表溢出情況。
轉(zhuǎn)發(fā)路徑由路徑上的所有交換機(jī)組成,根據(jù)木桶原理,轉(zhuǎn)發(fā)路徑的可用流表空間大小取決于路徑上所有交換機(jī)中可用流表空間容量最小的交換機(jī)。為了選出可用流表空間最大的路徑,計(jì)算每條可選路徑的所有交換機(jī)的最大可用流表空間容量,從中選出可用流表空間容量最大的路徑。
從源地址src 到目的地址dst 的可達(dá)路徑集合為Psrc,dst,對(duì)于一個(gè)可達(dá)的第i條路徑Pi∈Psrc,dst,路徑的可用流表空間容量Vi為
其中,Si,j表示第i條路徑Pi上的交換機(jī)集合中的第j個(gè)交換機(jī),v(Si,j)表示交換機(jī)Si,j的可用流表空間容量。
路徑選擇模塊計(jì)算源交換機(jī)src 至目的交換機(jī)dst 的路徑時(shí),將從多條可達(dá)路徑中選取可用流表空間最大的路徑P,即
基于可用流表空間的路徑選擇算法如算法3所示。
算法3路徑選擇算法
路徑選擇模塊從所有可達(dá)路徑中,選擇可用流表空間最大的路徑來傳輸網(wǎng)絡(luò)新流,實(shí)質(zhì)上是均衡了所有可達(dá)路徑的交換機(jī)間的可用流表空間,避免交換機(jī)轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導(dǎo)致的再次拒絕服務(wù)攻擊,防止再次出現(xiàn)流表溢出情況。
本節(jié)通過實(shí)驗(yàn)對(duì)提出的抗拒絕服務(wù)攻擊的軟件定義網(wǎng)絡(luò)流表溢出防護(hù)FloodMitigation 進(jìn)行有效性驗(yàn)證,驗(yàn)證其在拒絕服務(wù)攻擊發(fā)生時(shí)對(duì)交換機(jī)流表利用率、時(shí)延、丟包率、帶寬可用率、控制器CPU 利用率等的保護(hù)。使用ONOS 2.2.1作為軟件定義網(wǎng)絡(luò)控制器,軟件定義網(wǎng)絡(luò)仿真實(shí)驗(yàn)平臺(tái)Mininet 創(chuàng)建的Open vSwitch 2.10.1 作為數(shù)據(jù)平面交換機(jī),并依據(jù)OpenFlow 硬件交換機(jī)Polaris xSwitch X10-24S2Q 的配置將交換機(jī)的流表空間容量設(shè)定為2 000 條。Mininet 和ONOS分別獨(dú)立運(yùn)行在 Ubuntu 16.04 LTS 系統(tǒng)的OpenStack 實(shí)例中,實(shí)例運(yùn)行環(huán)境為 XEON E5-2630 v3 CPU,內(nèi)存為20 GB。
在Mininet 中創(chuàng)建與FloodShield 類似的實(shí)驗(yàn)拓?fù)?,如圖5 所示,拓?fù)渲泄灿?0 臺(tái)交換機(jī)(S1~S20)和16 臺(tái)主機(jī)(H1~H16)。主機(jī)H1、H3、H5、H7、H9、H11、H13、H15使用Mawi 流量數(shù)據(jù)集生成訪問其他主機(jī)的網(wǎng)絡(luò)流量。同時(shí)由主機(jī)H2向H16發(fā)送拒絕服務(wù)攻擊流量,源端口號(hào)、目地端口號(hào)均為隨機(jī)變化。在實(shí)驗(yàn)中,當(dāng)流規(guī)則安裝速率的調(diào)節(jié)因 子α=1.0時(shí),將所提FloodMitigation 與OpenFlow、FloodShield 在同等實(shí)驗(yàn)環(huán)境中進(jìn)行對(duì)比實(shí)驗(yàn),驗(yàn)證防護(hù)效果。
圖5 實(shí)驗(yàn)拓?fù)?/p>
當(dāng)主機(jī)H2向主機(jī)H16發(fā)送的攻擊速率分別為1 000 flow/s、2 000 flow/s 時(shí),交換機(jī)S1的流表利用率如圖6 所示。由于OpenFlow 沒有安全防護(hù),出現(xiàn)了流表溢出。FloodShield 采用基于控制器CPU 利用率以概率接受的方式安裝流規(guī)則的防護(hù)方式,但是沒有考慮流表利用率,依然出現(xiàn)了流表溢出。FloodMitigation 由于采用了基于流表可用空間的限速安裝流規(guī)則機(jī)制,能夠有效地限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口安裝流規(guī)則的最大數(shù)量,防止流表溢出,并且在2 種不同攻擊速率下,流表利用率保持穩(wěn)定。
圖6 不同攻擊速率下交換機(jī)S1 的流表利用率
本節(jié)實(shí)驗(yàn)通過交換機(jī)間的流表利用率,驗(yàn)證所提路徑選擇在均衡交換機(jī)流表利用率上的有效性。實(shí)驗(yàn)中由H2向H16發(fā)送攻擊流量,網(wǎng)絡(luò)流量將流經(jīng)路徑H2—S1—S5或H2—S1—S6。
圖7(a)為在不啟用路徑選擇算法情況下交換機(jī)S5和S6的流表利用率,S6的流表利用率約為15%,而S5的流表利用率約為50%。這是因?yàn)榭刂破鲗1發(fā)送的部分背景測試流量,以及流經(jīng)交換機(jī)S1的攻擊流量都轉(zhuǎn)發(fā)給了交換機(jī)S5。圖7(b)為啟用路徑選擇算法情況下交換機(jī)S5和S6的流表利用率,S5和S6的流表利用率接近。這是由于路徑選擇模塊在每次選擇路徑時(shí),將從多條路徑中選取可用流表空間最大的路徑,能夠有效地實(shí)現(xiàn)多條轉(zhuǎn)發(fā)路徑的交換機(jī)間的流表利用率的均衡,避免交換機(jī)轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導(dǎo)致的再次拒絕服務(wù)攻擊,實(shí)現(xiàn)對(duì)流表的有效保護(hù)。
圖7 交換機(jī)S5 和S6 的流表利用率
當(dāng)拒絕服務(wù)攻擊速率分別為1 000 flow/s、2 000 flow/s 時(shí),控制器CPU 利用率如圖8 所示。由于OpenFlow 沒有防護(hù)機(jī)制,其控制器CPU 利用率最高。FloodMitigation 始終比FloodShield 的控制器CPU 利用率低,并且隨著攻擊速率的增加,F(xiàn)loodShield 的控制器 CPU 利用率增加幅度比FloodMitigation 大。這是因?yàn)镕loodShield 基于控制器CPU 利用率以概率接受的方式通過flow-mod 安裝流規(guī)則,隨著攻擊速率的增加,需要下發(fā)流規(guī)則的處理增多,CPU 利用率增加。而FloodMitigation采用基于流表可用空間的限速安裝流規(guī)則策略,能夠保持穩(wěn)定的流規(guī)則下發(fā)安裝速率,隨著攻擊速率的增加,F(xiàn)loodMitigation 的控制器CPU 利用率增加幅度小。
圖8 不同攻擊速率下的控制器CPU 利用率
本節(jié)實(shí)驗(yàn)中H2發(fā)送拒絕服務(wù)攻擊流量,測量H1~H9的時(shí)延、丟包率、帶寬可用率,結(jié)果如圖9 所示。H1發(fā)送20 條UDP 流,每條UDP流有1 000 個(gè)網(wǎng)絡(luò)報(bào)文,統(tǒng)計(jì)接收到的網(wǎng)絡(luò)報(bào)文數(shù)量以及平均傳輸時(shí)延,并在 H1上使用 iperf工具測試可用帶寬。FloodShield 采用基于控制器CPU 利用率以概率接受的方式安裝流規(guī)則,隨著攻擊流量速度的增加,CPU 利用率增加,處理的packet-in 消息減少,緩存的packet-in 消息逐漸增多直至緩存溢出,出現(xiàn)丟包率增加和帶寬可用率減少的情況。而FloodMitigation 將無法安裝的網(wǎng)絡(luò)報(bào)文直接通過低開銷的packet-out 消息轉(zhuǎn)發(fā),傳輸時(shí)延保持穩(wěn)定,沒有出現(xiàn)因緩存溢出進(jìn)而導(dǎo)致的丟包率增加和帶寬可用率減少的情況。
圖9 時(shí)延、丟包率和帶寬可用率
現(xiàn)有工作從不同的性能瓶頸角度出發(fā)研究拒絕服務(wù)攻擊防護(hù)技術(shù),但未能有效防護(hù)流表溢出,以及防止拒絕服務(wù)攻擊流量在轉(zhuǎn)發(fā)中匯聚導(dǎo)致的再次拒絕服務(wù)。本文提出了軟件定義網(wǎng)絡(luò)流表溢出防護(hù)技術(shù)FloodMitigation。通過基于可用流表空間的限速流規(guī)則管理機(jī)制,動(dòng)態(tài)限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口的流規(guī)則安裝最大速度,避免拒絕服務(wù)攻擊流量占用被所有端口共用的流表資源,以及避免影響其他端口的流規(guī)則安裝;同時(shí)基于可用流表空間的路徑選擇在多條轉(zhuǎn)發(fā)路徑的交換機(jī)間均衡流表利用率,避免網(wǎng)絡(luò)新流匯聚在可用流表空間少的交換機(jī)上所導(dǎo)致的再次拒絕服務(wù)攻擊。實(shí)驗(yàn)結(jié)果表明,在沒有引入額外設(shè)備的情況下,F(xiàn)loodMitigation 在拒絕服務(wù)攻擊下能夠有效防止流表空間溢出的防護(hù),并在避免網(wǎng)絡(luò)報(bào)文丟失、降低控制器資源消耗、確保網(wǎng)絡(luò)報(bào)文轉(zhuǎn)發(fā)時(shí)延等方面有效抵御拒絕服務(wù)攻擊。下一步的工作將結(jié)合流規(guī)則動(dòng)態(tài)管理機(jī)制,實(shí)現(xiàn)對(duì)有限的流表資源的有效利用,并在硬件交換機(jī)上驗(yàn)證拒絕服務(wù)攻擊防護(hù)效果。