（1.北京郵電大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，北京 100876；2.鏈網(wǎng)融合技術(shù)教育部工程研究中心，北京 100876；3.中國(guó)民航信息網(wǎng)絡(luò)股份有限公司，北京 100190；4.移動(dòng)互聯(lián)網(wǎng)安全技術(shù)國(guó)家工程研究中心，北京 100876；5.中關(guān)村實(shí)驗(yàn)室，北京 100094；6.哈爾濱工業(yè)大學(xué)網(wǎng)絡(luò)空間安全學(xué)院，黑龍江 哈爾濱 150001；7.鵬城實(shí)驗(yàn)室網(wǎng)絡(luò)空間安全研究中心，廣東 深圳 518055）
0 引言
傳統(tǒng)封閉的網(wǎng)絡(luò)設(shè)備內(nèi)置了過(guò)多復(fù)雜協(xié)議，隨著網(wǎng)絡(luò)規(guī)模的不斷擴(kuò)大，網(wǎng)絡(luò)配置復(fù)雜度越來(lái)越高、網(wǎng)絡(luò)的管理和維護(hù)越來(lái)越復(fù)雜，增加了運(yùn)營(yíng)商定制優(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)新性，并通過(guò)多控制器實(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ī)生成無(wú)法成功匹配交換機(jī)流規(guī)則的大量拒絕服務(wù)攻擊流量，與正常網(wǎng)絡(luò)流量混合在一起進(jìn)入交換機(jī)。由于難以識(shí)別和管控拒絕服務(wù)攻擊，交換機(jī)不得不緩存所有網(wǎng)絡(luò)報(bào)文，并向控制器上報(bào)所有無(wú)法匹配流規(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ú)法為正常的網(wǎng)絡(luò)流量安裝流規(guī)則，嚴(yán)重影響軟件定義網(wǎng)絡(luò)服務(wù)質(zhì)量。安全危害如下：1) 沒(méi)有安裝流規(guī)則的正常網(wǎng)絡(luò)流將會(huì)觸發(fā)table-miss 的處理過(guò)程，相較于能夠匹配流規(guī)則被直接轉(zhuǎn)發(fā)的處理過(guò)程，增加了網(wǎng)絡(luò)報(bào)文的轉(zhuǎn)發(fā)時(shí)延，降低了網(wǎng)絡(luò)可用帶寬；2) 無(wú)法安裝流規(guī)則的正常網(wǎng)絡(luò)流的每個(gè)網(wǎng)絡(luò)報(bào)文都將會(huì)觸發(fā)一次table-miss 處理過(guò)程，消耗更多的控制器計(jì)算和存儲(chǔ)資源，放大拒絕服務(wù)攻擊效果；3) 網(wǎng)絡(luò)報(bào)文轉(zhuǎn)發(fā)時(shí)延的增加會(huì)使越來(lái)越多的網(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ì)通過(guò)精心設(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ā)路徑傳輸過(guò)程中，如何避免在路徑上的交換機(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]，因此無(wú)法采用類似攻擊流量清洗的策略來(lái)減少安裝流規(guī)則的數(shù)量，并且難以實(shí)現(xiàn)安裝的流規(guī)則都是正常網(wǎng)絡(luò)流。對(duì)于第二個(gè)挑戰(zhàn)，攻擊者會(huì)精心構(gòu)造攻擊流量，使分布式的攻擊流量匯聚到軟件定義網(wǎng)絡(luò)同一個(gè)中間交換機(jī)上，可用流表空間少的交換機(jī)有可能成為攻擊者匯聚攻擊流量的目標(biāo)。
在無(wú)法準(zhǔn)確識(shí)別和消除攻擊流量的情況下，本文提出了抗拒絕服務(wù)攻擊的軟件定義網(wǎng)絡(luò)流表溢出防護(hù)技術(shù)FloodMitigation，來(lái)避免軟件定義網(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) 提出了基于可用流表空間的路徑選擇，通過(guò)在多條轉(zhuǎn)發(fā)路徑的交換機(jī)間均衡流表利用率，避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過(guò)程中出現(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ò)可用帶寬。
1 相關(guān)工作
拒絕服務(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ī)則來(lái)轉(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ù)攻擊威脅問(wèn)題，并提出了基于連接遷移的防護(hù)機(jī)制，通過(guò)代理的方式對(duì)報(bào)文源地址的真實(shí)性進(jìn)行校驗(yàn)，校驗(yàn)通過(guò)后轉(zhuǎn)發(fā)網(wǎng)絡(luò)數(shù)據(jù)報(bào)文，能夠有效地對(duì)有連接狀態(tài)的傳輸控制協(xié)議（TCP）拒絕服務(wù)攻擊進(jìn)行檢測(cè)和過(guò)濾，但是無(wú)法應(yīng)對(duì)用戶數(shù)據(jù)報(bào)協(xié)議（UDP）等無(wú)連接狀態(tài)的拒絕服務(wù)攻擊，在實(shí)際應(yīng)用中有很大缺陷。Ambrosin 等[12]提出了類似的防御模型，基于代理和黑名單來(lái)緩解拒絕服務(wù)攻擊。面向流表資源和處理資源保護(hù)，F(xiàn)loodShield[13]通過(guò)源地址驗(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ì)訪問(wèn)控制（MAC）地址和交換機(jī)的映射關(guān)系，當(dāng)控制器發(fā)現(xiàn)從某個(gè)端口上報(bào)的網(wǎng)絡(luò)報(bào)文的源MAC 未知時(shí)，通過(guò)向交換機(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è)置額外備份控制器，過(guò)濾處理疑似惡意流量的packet-in 消息后，再限速將packet-in 消息發(fā)送給主控制器，從減少packet-in 消息的角度保護(hù)控制器的資源，但無(wú)法確保正常網(wǎng)絡(luò)流量傳輸時(shí)延以及避免丟包。
面向交換機(jī)的保護(hù)，F(xiàn)loodDefender[17]基于排隊(duì)論經(jīng)驗(yàn)公式和鏈路利用率建立了流量遷移模型，當(dāng)檢測(cè)到發(fā)生拒絕服務(wù)攻擊時(shí)，交換機(jī)根據(jù)網(wǎng)絡(luò)流量信息對(duì)packet-in 消息進(jìn)行過(guò)濾，并依據(jù)與其鄰接的交換機(jī)的可用安全信道容量將網(wǎng)絡(luò)報(bào)文遷移給相鄰的交換機(jī)，能有效減少該交換機(jī)與控制器通過(guò)安全信道的數(shù)據(jù)交互，避免安全信道發(fā)生擁塞，但采用的過(guò)濾機(jī)制將會(huì)導(dǎo)致正常網(wǎng)絡(luò)流量被丟棄。Yuan等[5]提出在交換機(jī)可用流表空間不足時(shí)，通過(guò)通配符將流量遷移到相鄰的伙伴交換機(jī)上，利用伙伴交換機(jī)的空閑資源來(lái)共同處理網(wǎng)絡(luò)報(bào)文，但無(wú)法有效降低控制器的資源消耗。文獻(xiàn)[18]處理packet-in 消息，記錄這些報(bào)文的IP，當(dāng)發(fā)往目的IP 的所有數(shù)據(jù)包的Renyi 熵超過(guò)閾值時(shí)，認(rèn)為這些報(bào)文是攻擊流量，對(duì)報(bào)文進(jìn)行丟包處理，但無(wú)法避免正常網(wǎng)絡(luò)流量丟包情況。文獻(xiàn)[19]將流量分為大象流和老鼠流，不為老鼠流安裝流表項(xiàng)，直接通過(guò)packet-out消息轉(zhuǎn)發(fā)，降低對(duì)流表的占用，但無(wú)法確保轉(zhuǎn)發(fā)的攻擊流量不流經(jīng)相同中間交換機(jī)，無(wú)法避免形成攻擊匯聚。
在流表資源方面，目前研究主要采用動(dòng)態(tài)調(diào)整超時(shí)時(shí)間，縮小流表項(xiàng)在TCAM 中的無(wú)效時(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ú)法避免拒絕服務(wù)攻擊流使流表溢出。文獻(xiàn)[22]通過(guò)流表溢出預(yù)測(cè)將流表項(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ù)問(wèn)題，提出了基于流表可用空間的限速流規(guī)則管理，限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口的流規(guī)則最大安裝速度和占用的流表空間數(shù)量，避免了流表溢出；然后采用基于可用流表空間的路徑選擇，在多條轉(zhuǎn)發(fā)路徑的交換機(jī)間均衡流表利用率，避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過(guò)程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導(dǎo)致的再次拒絕服務(wù)攻擊。本文提出的軟件定義網(wǎng)絡(luò)流表溢出防護(hù)技術(shù)FloodMitigation 在沒(méi)有引入額外設(shè)備的情況下，實(shí)現(xiàn)了在拒絕服務(wù)攻擊下對(duì)流表空間溢出的防護(hù)。
2 流表溢出防護(hù)
2.1 流表溢出防護(hù)系統(tǒng)模型
針對(duì)拒絕服務(wù)攻擊導(dǎo)致的流表溢出問(wèn)題，本文設(shè)計(jì)了軟件定義網(wǎng)絡(luò)流表溢出防護(hù)FloodMitigation，并將其作為集成模塊運(yùn)行在控制平面上，包括流監(jiān)測(cè)、限速流規(guī)則管理、路徑選擇這3 個(gè)模塊，系統(tǒng)模型如圖2 所示。
圖2 系統(tǒng)模型
在軟件定義網(wǎng)絡(luò)正常運(yùn)行時(shí)，只有流監(jiān)測(cè)模塊在運(yùn)行，其他拒絕服務(wù)攻擊防護(hù)模塊處于待激活狀態(tài)。當(dāng)檢測(cè)到交換機(jī)端口上出現(xiàn)拒絕服務(wù)攻擊時(shí)，流監(jiān)測(cè)模塊觸發(fā)限速流規(guī)則管理模塊，進(jìn)行流表溢出防護(hù)。同時(shí)路徑選擇模塊采用負(fù)載均衡策略為網(wǎng)絡(luò)流選擇傳輸路徑，避免網(wǎng)絡(luò)流流經(jīng)同一個(gè)中間交換機(jī)導(dǎo)致流表溢出。處理流程如下。
1) 流監(jiān)測(cè)模塊統(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ù)攻擊檢測(cè)。當(dāng)出現(xiàn)拒絕服務(wù)攻擊時(shí)，觸發(fā)其他拒絕服務(wù)攻擊防護(hù)模塊。
2) 限速流規(guī)則管理模塊收到來(lái)自發(fā)生拒絕服務(wù)攻擊的交換機(jī)端口的packet-in 消息后，調(diào)用路徑選擇模塊計(jì)算轉(zhuǎn)發(fā)路徑，并進(jìn)行限速安裝流規(guī)則，通過(guò)限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口安裝流規(guī)則的最大數(shù)量和速度，避免發(fā)生拒絕服務(wù)攻擊的端口的流規(guī)則占滿整個(gè)流表空間，確保其他端口的網(wǎng)絡(luò)新流的流規(guī)則安裝使用。
3) 路徑選擇模塊被限速流規(guī)則管理模塊調(diào)用，基于交換機(jī)可用流表空間容量來(lái)選擇轉(zhuǎn)發(fā)路徑，從多條路徑中選取可用流表空間最大的路徑。通過(guò)均衡多條轉(zhuǎn)發(fā)路徑的交換機(jī)間的流表利用率，避免交換機(jī)轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過(guò)程中出現(xiàn)網(wǎng)絡(luò)新流匯聚再次引發(fā)拒絕服務(wù)攻擊。
2.2 流監(jiān)測(cè)
流監(jiān)測(cè)模塊持續(xù)監(jiān)測(cè)交換機(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ù)攻擊檢測(cè)，并被限速流規(guī)則管理模塊用來(lái)決策是否為網(wǎng)絡(luò)流下發(fā)流規(guī)則。
圖3 網(wǎng)絡(luò)流統(tǒng)計(jì)信息表結(jié)構(gòu)
當(dāng) packet-in 消息到達(dá)時(shí)，流監(jiān)測(cè)模塊對(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)沒(méi)有新的packet-in 到達(dá)，則該網(wǎng)絡(luò)流統(tǒng)計(jì)項(xiàng)flow_entry 將被刪除。流監(jiān)測(cè)算法偽代碼如算法1 所示。
算法1流監(jiān)測(cè)算法
根據(jù)交換機(jī)上報(bào)的packet-in 消息，查找匹配的流表項(xiàng)flow_entry
流監(jiān)測(cè)模塊采用與FloodDefender[18]相同的拒絕服務(wù)攻擊檢測(cè)方法，通過(guò)異常閾值檢測(cè)識(shí)別交換機(jī)端口出現(xiàn)的拒絕服務(wù)攻擊。流監(jiān)測(cè)模塊持續(xù)統(tǒng)計(jì)網(wǎng)絡(luò)流的packet-in 消息的頻次frequency，一旦出現(xiàn)拒絕服務(wù)攻擊，低頻次的網(wǎng)絡(luò)流數(shù)量就會(huì)快速增加，當(dāng)超過(guò)異常檢測(cè)閾值時(shí)，流監(jiān)測(cè)模塊將觸發(fā)限速流規(guī)則管理模塊，進(jìn)行流表溢出防護(hù)。當(dāng)?shù)皖l次的網(wǎng)絡(luò)流數(shù)量低于異常檢測(cè)閾值時(shí)，表示網(wǎng)絡(luò)中短流的數(shù)量處于安全范圍，流監(jiān)測(cè)模塊將停止調(diào)用限速流規(guī)則管理模塊，恢復(fù)正常處理網(wǎng)絡(luò)流的狀態(tài)。
2.3 限速流規(guī)則管理
限速流規(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)沒(mé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ī)端口檢測(cè)到拒絕服務(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ī)則安裝速率增長(zhǎng)。當(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ù)多，則通過(guò)flow-mod 消息向交換機(jī)下發(fā)安裝流規(guī)則，并下發(fā)packet-out 消息轉(zhuǎn)發(fā)數(shù)據(jù)報(bào)文；否則將不下發(fā)安裝流規(guī)則的flow-mod 消息，直接通過(guò)低開銷的packet-out 轉(zhuǎn)發(fā)該網(wǎng)絡(luò)報(bào)文（在ONOS 官方的性能測(cè)試中處理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)測(cè)返回的流表項(xiàng)flow_entry，給轉(zhuǎn)發(fā)交換機(jī)下發(fā)安裝流規(guī)則的flow-mod 消息和轉(zhuǎn)發(fā)報(bào)文的packet-out 消息
2.4 路徑選擇
軟件定義網(wǎng)絡(luò)中不同的交換機(jī)可用流表空間不同，拒絕服務(wù)攻擊流量被轉(zhuǎn)發(fā)流經(jīng)剩余流表空間較小的交換機(jī)時(shí)，更易造成交換機(jī)流表溢出、增加網(wǎng)絡(luò)報(bào)文傳輸時(shí)延、消耗控制器資源、丟包等問(wèn)題。而控制器ONOS 采用基于最小時(shí)延策略的Djikstra 算法來(lái)計(jì)算路徑，無(wú)法確保剩余流表空間較小的交換機(jī)不被選進(jìn)傳輸路徑。在軟件定義網(wǎng)絡(luò)中，源節(jié)點(diǎn)至目的節(jié)點(diǎn)通常有多條可達(dá)路徑，路徑選擇模塊計(jì)算路徑時(shí)，從多條路徑中選取可用流表空間最大的路徑，通過(guò)均衡多條轉(zhuǎn)發(fā)路徑的交換機(jī)間的流表利用率，避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過(guò)程中出現(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á)路徑中，選擇可用流表空間最大的路徑來(lái)傳輸網(wǎng)絡(luò)新流，實(shí)質(zhì)上是均衡了所有可達(dá)路徑的交換機(jī)間的可用流表空間，避免交換機(jī)轉(zhuǎn)發(fā)網(wǎng)絡(luò)報(bào)文過(guò)程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導(dǎo)致的再次拒絕服務(wù)攻擊，防止再次出現(xiàn)流表溢出情況。
3 實(shí)驗(yàn)評(píng)估
本節(jié)通過(guò)實(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ù)洌鐖D5 所示，拓?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ù)集生成訪問(wèn)其他主機(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>
3.1 基于限速安裝流規(guī)則機(jī)制的流表利用率
當(dāng)主機(jī)H2向主機(jī)H16發(fā)送的攻擊速率分別為1 000 flow/s、2 000 flow/s 時(shí)，交換機(jī)S1的流表利用率如圖6 所示。由于OpenFlow 沒(méi)有安全防護(hù)，出現(xiàn)了流表溢出。FloodShield 采用基于控制器CPU 利用率以概率接受的方式安裝流規(guī)則的防護(hù)方式，但是沒(méi)有考慮流表利用率，依然出現(xiàn)了流表溢出。FloodMitigation 由于采用了基于流表可用空間的限速安裝流規(guī)則機(jī)制，能夠有效地限制出現(xiàn)拒絕服務(wù)攻擊的交換機(jī)端口安裝流規(guī)則的最大數(shù)量，防止流表溢出，并且在2 種不同攻擊速率下，流表利用率保持穩(wěn)定。
圖6 不同攻擊速率下交換機(jī)S1 的流表利用率
3.2 基于路徑選擇的流表利用率
本節(jié)實(shí)驗(yàn)通過(guò)交換機(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ā)送的部分背景測(cè)試流量，以及流經(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)文過(guò)程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導(dǎo)致的再次拒絕服務(wù)攻擊，實(shí)現(xiàn)對(duì)流表的有效保護(hù)。
圖7 交換機(jī)S5 和S6 的流表利用率
3.3 控制器CPU 利用率
當(dāng)拒絕服務(wù)攻擊速率分別為1 000 flow/s、2 000 flow/s 時(shí)，控制器CPU 利用率如圖8 所示。由于OpenFlow 沒(méi)有防護(hù)機(jī)制，其控制器CPU 利用率最高。FloodMitigation 始終比FloodShield 的控制器CPU 利用率低，并且隨著攻擊速率的增加，F(xiàn)loodShield 的控制器 CPU 利用率增加幅度比FloodMitigation 大。這是因?yàn)镕loodShield 基于控制器CPU 利用率以概率接受的方式通過(guò)flow-mod 安裝流規(guī)則，隨著攻擊速率的增加，需要下發(fā)流規(guī)則的處理增多，CPU 利用率增加。而FloodMitigation采用基于流表可用空間的限速安裝流規(guī)則策略，能夠保持穩(wěn)定的流規(guī)則下發(fā)安裝速率，隨著攻擊速率的增加，F(xiàn)loodMitigation 的控制器CPU 利用率增加幅度小。
圖8 不同攻擊速率下的控制器CPU 利用率
3.4 時(shí)延、丟包率、帶寬可用率
本節(jié)實(shí)驗(yàn)中H2發(fā)送拒絕服務(wù)攻擊流量，測(cè)量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工具測(cè)試可用帶寬。FloodShield 采用基于控制器CPU 利用率以概率接受的方式安裝流規(guī)則，隨著攻擊流量速度的增加，CPU 利用率增加，處理的packet-in 消息減少，緩存的packet-in 消息逐漸增多直至緩存溢出，出現(xiàn)丟包率增加和帶寬可用率減少的情況。而FloodMitigation 將無(wú)法安裝的網(wǎng)絡(luò)報(bào)文直接通過(guò)低開銷的packet-out 消息轉(zhuǎn)發(fā)，傳輸時(shí)延保持穩(wěn)定，沒(méi)有出現(xiàn)因緩存溢出進(jìn)而導(dǎo)致的丟包率增加和帶寬可用率減少的情況。
圖9 時(shí)延、丟包率和帶寬可用率
4 結(jié)束語(yǔ)
現(xiàn)有工作從不同的性能瓶頸角度出發(fā)研究拒絕服務(wù)攻擊防護(hù)技術(shù)，但未能有效防護(hù)流表溢出，以及防止拒絕服務(wù)攻擊流量在轉(zhuǎn)發(fā)中匯聚導(dǎo)致的再次拒絕服務(wù)。本文提出了軟件定義網(wǎng)絡(luò)流表溢出防護(hù)技術(shù)FloodMitigation。通過(guò)基于可用流表空間的限速流規(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é)果表明，在沒(méi)有引入額外設(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ù)效果。
