王東濱，吳東哲，智慧，郭昆,4,5，張勖，時金橋，張宇，陸月明,4

（1.北京郵電大學網(wǎng)絡(luò)空間安全學院，北京 100876；2.鏈網(wǎng)融合技術(shù)教育部工程研究中心，北京 100876；3.中國民航信息網(wǎng)絡(luò)股份有限公司，北京 100190；4.移動互聯(lián)網(wǎng)安全技術(shù)國家工程研究中心，北京 100876；5.中關(guān)村實驗室，北京 100094；6.哈爾濱工業(yè)大學網(wǎng)絡(luò)空間安全學院，黑龍江 哈爾濱 150001；7.鵬城實驗室網(wǎng)絡(luò)空間安全研究中心，廣東 深圳 518055）

0 引言

傳統(tǒng)封閉的網(wǎng)絡(luò)設(shè)備內(nèi)置了過多復雜協(xié)議，隨著網(wǎng)絡(luò)規(guī)模的不斷擴大，網(wǎng)絡(luò)配置復雜度越來越高、網(wǎng)絡(luò)的管理和維護越來越復雜，增加了運營商定制優(yōu)化網(wǎng)絡(luò)的難度[1]。軟件定義網(wǎng)絡(luò)（SDN，software defined network）將控制平面與數(shù)據(jù)平面分離解耦，使具有全局網(wǎng)絡(luò)視圖的控制平面能夠?qū)?shù)據(jù)平面進行集中式管理，實現(xiàn)路由策略集中計算和下發(fā)，數(shù)據(jù)平面按照控制平面下發(fā)的流規(guī)則進行網(wǎng)絡(luò)數(shù)據(jù)的傳輸轉(zhuǎn)發(fā)。軟件定義網(wǎng)絡(luò)使網(wǎng)絡(luò)管理變得更具靈活性和創(chuàng)新性，并通過多控制器實現(xiàn)網(wǎng)絡(luò)擴展及對大規(guī)模復雜網(wǎng)絡(luò)的集中管理和維護[2-4]。

目前，OpenFlow[2]作為軟件定義網(wǎng)絡(luò)協(xié)議已被廣泛采用，當有網(wǎng)絡(luò)報文到達數(shù)據(jù)平面交換機時，交換機會先匹配已安裝的流規(guī)則，如果成功匹配，則按照流規(guī)則的動作執(zhí)行修改、轉(zhuǎn)發(fā)和丟棄網(wǎng)絡(luò)報文等操作；如果未成功匹配（即出現(xiàn)table-miss），則交換機將網(wǎng)絡(luò)報文封裝到packet-in消息中上報給控制平面控制器，控制器計算轉(zhuǎn)發(fā)路徑后，向交換機下發(fā)安裝流規(guī)則的flow-mod 消息和轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文到下一跳交換機的packet-out消息，交換機執(zhí)行安裝該網(wǎng)絡(luò)流的流規(guī)則，并將網(wǎng)絡(luò)報文轉(zhuǎn)發(fā)給下一跳交換機。該網(wǎng)絡(luò)流后續(xù)到達的網(wǎng)絡(luò)報文匹配上已安裝的流規(guī)則后直接被轉(zhuǎn)發(fā)，不需要再次上報packet-in 消息給控制器。在轉(zhuǎn)發(fā)路徑上的每一跳，交換機都按照上述流程處理收到的網(wǎng)絡(luò)報文。

為了更加高效地實現(xiàn)流規(guī)則的匹配，交換機廣泛采用三態(tài)內(nèi)容尋址存儲器（TCAM）存儲和匹配流規(guī)則，但是TCAM 價格昂貴，僅可支持8 000 條流規(guī)則的存儲，有限的交換機流表空間容量和控制器的集中式傳輸控制管理使軟件定義網(wǎng)絡(luò)更易遭受拒絕服務(wù)攻擊的威脅[5-9]。軟件定義網(wǎng)絡(luò)拒絕服務(wù)攻擊如圖1 所示，攻擊者會隨機生成無法成功匹配交換機流規(guī)則的大量拒絕服務(wù)攻擊流量，與正常網(wǎng)絡(luò)流量混合在一起進入交換機。由于難以識別和管控拒絕服務(wù)攻擊，交換機不得不緩存所有網(wǎng)絡(luò)報文，并向控制器上報所有無法匹配流規(guī)則的網(wǎng)絡(luò)報文的packet-in 消息，使控制器在計算路徑和發(fā)送安裝流規(guī)則的flow-mod 消息、轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文的packet-out 消息上耗盡CPU 和緩存資源；同時在交換機有限的流表空間中安裝了大量拒絕服務(wù)攻擊的流規(guī)則，短時間內(nèi)將導致有限的流表空間溢出，無法為正常的網(wǎng)絡(luò)流量安裝流規(guī)則，嚴重影響軟件定義網(wǎng)絡(luò)服務(wù)質(zhì)量。安全危害如下：1) 沒有安裝流規(guī)則的正常網(wǎng)絡(luò)流將會觸發(fā)table-miss 的處理過程，相較于能夠匹配流規(guī)則被直接轉(zhuǎn)發(fā)的處理過程，增加了網(wǎng)絡(luò)報文的轉(zhuǎn)發(fā)時延，降低了網(wǎng)絡(luò)可用帶寬；2) 無法安裝流規(guī)則的正常網(wǎng)絡(luò)流的每個網(wǎng)絡(luò)報文都將會觸發(fā)一次table-miss 處理過程，消耗更多的控制器計算和存儲資源，放大拒絕服務(wù)攻擊效果；3) 網(wǎng)絡(luò)報文轉(zhuǎn)發(fā)時延的增加會使越來越多的網(wǎng)絡(luò)報文停留在交換機有限的緩存中，甚至導致丟包。同時，軟件定義網(wǎng)絡(luò)交換機的流表空間被所有端口共用，每個端口都會獨立地為流入的網(wǎng)絡(luò)新流報文在共享的有限容量的流表中安裝流規(guī)則。當一個端口出現(xiàn)拒絕服務(wù)攻擊流量時，會影響其他端口正常網(wǎng)絡(luò)流的流規(guī)則安裝。并且攻擊者會通過精心設(shè)計生成攻擊流量，不僅對攻擊流量的接入交換機產(chǎn)生拒絕服務(wù)攻擊效果，也使分布式攻擊流量流經(jīng)同一個中間交換機，形成攻擊匯聚，發(fā)生再次拒絕服務(wù)攻擊，導致更嚴重的拒絕服務(wù)攻擊效果。

圖1 軟件定義網(wǎng)絡(luò)拒絕服務(wù)攻擊

為了避免軟件定義網(wǎng)絡(luò)交流機出現(xiàn)流表溢出，確保軟件定義網(wǎng)絡(luò)的穩(wěn)定運行和網(wǎng)絡(luò)服務(wù)質(zhì)量，需要解決以下2 個挑戰(zhàn)。

1) 在拒絕服務(wù)攻擊發(fā)生時，如何防止交換機流表空間被攻擊流的流規(guī)則占滿，避免流表溢出。

2) 網(wǎng)絡(luò)報文在轉(zhuǎn)發(fā)路徑傳輸過程中，如何避免在路徑上的交換機上出現(xiàn)網(wǎng)絡(luò)流匯聚導致的再次拒絕服務(wù)攻擊。

對于第一個挑戰(zhàn)，由于與傳統(tǒng)網(wǎng)絡(luò)一樣，拒絕服務(wù)攻擊流量和正常網(wǎng)絡(luò)流量混在一起，攻擊流量很難被準確識別和區(qū)分處理[10]，因此無法采用類似攻擊流量清洗的策略來減少安裝流規(guī)則的數(shù)量，并且難以實現(xiàn)安裝的流規(guī)則都是正常網(wǎng)絡(luò)流。對于第二個挑戰(zhàn)，攻擊者會精心構(gòu)造攻擊流量，使分布式的攻擊流量匯聚到軟件定義網(wǎng)絡(luò)同一個中間交換機上，可用流表空間少的交換機有可能成為攻擊者匯聚攻擊流量的目標。

在無法準確識別和消除攻擊流量的情況下，本文提出了抗拒絕服務(wù)攻擊的軟件定義網(wǎng)絡(luò)流表溢出防護技術(shù)FloodMitigation，來避免軟件定義網(wǎng)絡(luò)流表資源消耗和確保網(wǎng)絡(luò)服務(wù)質(zhì)量，主要的技術(shù)貢獻如下。

1) 提出了基于可用流表空間的限速流規(guī)則管理機制，動態(tài)限制出現(xiàn)拒絕服務(wù)攻擊的交換機端口的流規(guī)則安裝最大速度，避免交換機流表空間被拒絕服務(wù)攻擊流規(guī)則占滿而出現(xiàn)流表溢出的情況，以及影響其他端口正常網(wǎng)絡(luò)流的流規(guī)則安裝。優(yōu)先為出現(xiàn)頻次高的網(wǎng)絡(luò)流安裝流規(guī)則，減少了上報packet-in 消息的數(shù)量、控制器消耗、網(wǎng)絡(luò)傳輸時延和網(wǎng)絡(luò)報文緩存溢出導致的網(wǎng)絡(luò)丟包情況。

2) 提出了基于可用流表空間的路徑選擇，通過在多條轉(zhuǎn)發(fā)路徑的交換機間均衡流表利用率，避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚在可用流表空間少的交換機上所導致的再次拒絕服務(wù)攻擊。

3) 對FloodMitigation 進行了實驗驗證，實驗結(jié)果表明，F(xiàn)loodMitigation 能夠有效防止交換機流表溢出，降低控制器資源消耗、傳輸時延和網(wǎng)絡(luò)丟包，確保網(wǎng)絡(luò)可用帶寬。

1 相關(guān)工作

拒絕服務(wù)攻擊者通常向攻擊目標發(fā)起大量的偽造網(wǎng)絡(luò)報文的不同字段、短流的網(wǎng)絡(luò)攻擊流量，消耗目標的服務(wù)資源。傳統(tǒng)網(wǎng)絡(luò)的交換機、路由器等傳輸設(shè)備把拒絕服務(wù)攻擊流量等同于正常網(wǎng)絡(luò)流量進行轉(zhuǎn)發(fā)，不受拒絕服務(wù)攻擊影響，但是軟件定義網(wǎng)絡(luò)控制器響應(yīng)式地向交換機下發(fā)流規(guī)則來轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文，使交換機有限的流表容量和緩存容量、控制器集中式的傳輸控制管理等成為瓶頸，更易被拒絕服務(wù)攻擊者利用。很多研究從報文源真實性校驗丟棄報文、降低控制器和交換機資源占用、動態(tài)調(diào)整流表項超時時間等不同角度出發(fā)研究拒絕服務(wù)攻擊防護技術(shù)。

Shin 等[11]首次提出了軟件定義網(wǎng)絡(luò)拒絕服務(wù)攻擊威脅問題，并提出了基于連接遷移的防護機制，通過代理的方式對報文源地址的真實性進行校驗，校驗通過后轉(zhuǎn)發(fā)網(wǎng)絡(luò)數(shù)據(jù)報文，能夠有效地對有連接狀態(tài)的傳輸控制協(xié)議（TCP）拒絕服務(wù)攻擊進行檢測和過濾，但是無法應(yīng)對用戶數(shù)據(jù)報協(xié)議（UDP）等無連接狀態(tài)的拒絕服務(wù)攻擊，在實際應(yīng)用中有很大缺陷。Ambrosin 等[12]提出了類似的防御模型，基于代理和黑名單來緩解拒絕服務(wù)攻擊。面向流表資源和處理資源保護，F(xiàn)loodShield[13]通過源地址驗證丟棄偽造地址的網(wǎng)絡(luò)流量，對于不確定的網(wǎng)絡(luò)流量，采用基于控制器CPU 利用率的概率接受方式處理packet-in 和安裝流規(guī)則，但是隨著網(wǎng)絡(luò)攻擊流的增大，會導致控制器處理資源消耗增加、交換機流表溢出和網(wǎng)絡(luò)丟包等情況發(fā)生。DoSGuard[14]在控制器上保存主機介質(zhì)訪問控制（MAC）地址和交換機的映射關(guān)系，當控制器發(fā)現(xiàn)從某個端口上報的網(wǎng)絡(luò)報文的源MAC 未知時，通過向交換機安裝流規(guī)則，將未匹配流表的報文全部進行丟棄處理。

面向控制器的資源保護，F(xiàn)loodGuard[15]設(shè)置額外的緩存模塊，根據(jù)網(wǎng)絡(luò)報文的協(xié)議類型采用多隊列形式緩存packet-in 消息，并采用round robin 算法限速發(fā)給控制器處理，保護控制器處理資源。拒絕服務(wù)攻擊只會影響與其相同類型的協(xié)議隊列，保證了其他類型協(xié)議隊列中的packet-in正常處理，但是會使與拒絕服務(wù)攻擊流量在同一個隊列的正常網(wǎng)絡(luò)流量處理時延和丟包。文獻[16]設(shè)置額外備份控制器，過濾處理疑似惡意流量的packet-in 消息后，再限速將packet-in 消息發(fā)送給主控制器，從減少packet-in 消息的角度保護控制器的資源，但無法確保正常網(wǎng)絡(luò)流量傳輸時延以及避免丟包。

面向交換機的保護，F(xiàn)loodDefender[17]基于排隊論經(jīng)驗公式和鏈路利用率建立了流量遷移模型，當檢測到發(fā)生拒絕服務(wù)攻擊時，交換機根據(jù)網(wǎng)絡(luò)流量信息對packet-in 消息進行過濾，并依據(jù)與其鄰接的交換機的可用安全信道容量將網(wǎng)絡(luò)報文遷移給相鄰的交換機，能有效減少該交換機與控制器通過安全信道的數(shù)據(jù)交互，避免安全信道發(fā)生擁塞，但采用的過濾機制將會導致正常網(wǎng)絡(luò)流量被丟棄。Yuan等[5]提出在交換機可用流表空間不足時，通過通配符將流量遷移到相鄰的伙伴交換機上，利用伙伴交換機的空閑資源來共同處理網(wǎng)絡(luò)報文，但無法有效降低控制器的資源消耗。文獻[18]處理packet-in 消息，記錄這些報文的IP，當發(fā)往目的IP 的所有數(shù)據(jù)包的Renyi 熵超過閾值時，認為這些報文是攻擊流量，對報文進行丟包處理，但無法避免正常網(wǎng)絡(luò)流量丟包情況。文獻[19]將流量分為大象流和老鼠流，不為老鼠流安裝流表項，直接通過packet-out消息轉(zhuǎn)發(fā)，降低對流表的占用，但無法確保轉(zhuǎn)發(fā)的攻擊流量不流經(jīng)相同中間交換機，無法避免形成攻擊匯聚。

在流表資源方面，目前研究主要采用動態(tài)調(diào)整超時時間，縮小流表項在TCAM 中的無效時間，提高流表利用率，但大量的拒絕服務(wù)攻擊流依然會使流表溢出。文獻[20]基于控制器收集流歷史信息，對流表項空閑超時時間進行動態(tài)設(shè)置。HQTimer[21]采用深度強化學習根據(jù)當前命中率等信息的反饋進行動態(tài)超時時間的決策下發(fā)，從而達到更高的流表命中率，但無法避免拒絕服務(wù)攻擊流使流表溢出。文獻[22]通過流表溢出預測將流表項進行主動刪除，但會不可避免地將正常網(wǎng)絡(luò)流表項刪除。

現(xiàn)有工作從不同的性能瓶頸角度出發(fā)研究拒絕服務(wù)攻擊防護技術(shù)，但不能有效地防止流表溢出，以及防止拒絕服務(wù)攻擊流量在轉(zhuǎn)發(fā)中匯聚導致的再次拒絕服務(wù)。本文針對流表溢出防護問題，提出了基于流表可用空間的限速流規(guī)則管理，限制出現(xiàn)拒絕服務(wù)攻擊的交換機端口的流規(guī)則最大安裝速度和占用的流表空間數(shù)量，避免了流表溢出；然后采用基于可用流表空間的路徑選擇，在多條轉(zhuǎn)發(fā)路徑的交換機間均衡流表利用率，避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導致的再次拒絕服務(wù)攻擊。本文提出的軟件定義網(wǎng)絡(luò)流表溢出防護技術(shù)FloodMitigation 在沒有引入額外設(shè)備的情況下，實現(xiàn)了在拒絕服務(wù)攻擊下對流表空間溢出的防護。

2 流表溢出防護

2.1 流表溢出防護系統(tǒng)模型

針對拒絕服務(wù)攻擊導致的流表溢出問題，本文設(shè)計了軟件定義網(wǎng)絡(luò)流表溢出防護FloodMitigation，并將其作為集成模塊運行在控制平面上，包括流監(jiān)測、限速流規(guī)則管理、路徑選擇這3 個模塊，系統(tǒng)模型如圖2 所示。

圖2 系統(tǒng)模型

在軟件定義網(wǎng)絡(luò)正常運行時，只有流監(jiān)測模塊在運行，其他拒絕服務(wù)攻擊防護模塊處于待激活狀態(tài)。當檢測到交換機端口上出現(xiàn)拒絕服務(wù)攻擊時，流監(jiān)測模塊觸發(fā)限速流規(guī)則管理模塊，進行流表溢出防護。同時路徑選擇模塊采用負載均衡策略為網(wǎng)絡(luò)流選擇傳輸路徑，避免網(wǎng)絡(luò)流流經(jīng)同一個中間交換機導致流表溢出。處理流程如下。

1) 流監(jiān)測模塊統(tǒng)計交換機上報的packet-in 消息、網(wǎng)絡(luò)流量統(tǒng)計、計算和內(nèi)存資源占用率等網(wǎng)絡(luò)與系統(tǒng)狀態(tài)，建立基于交換機端口的網(wǎng)絡(luò)流統(tǒng)計信息表，并進行拒絕服務(wù)攻擊檢測。當出現(xiàn)拒絕服務(wù)攻擊時，觸發(fā)其他拒絕服務(wù)攻擊防護模塊。

2) 限速流規(guī)則管理模塊收到來自發(fā)生拒絕服務(wù)攻擊的交換機端口的packet-in 消息后，調(diào)用路徑選擇模塊計算轉(zhuǎn)發(fā)路徑，并進行限速安裝流規(guī)則，通過限制出現(xiàn)拒絕服務(wù)攻擊的交換機端口安裝流規(guī)則的最大數(shù)量和速度，避免發(fā)生拒絕服務(wù)攻擊的端口的流規(guī)則占滿整個流表空間，確保其他端口的網(wǎng)絡(luò)新流的流規(guī)則安裝使用。

3) 路徑選擇模塊被限速流規(guī)則管理模塊調(diào)用，基于交換機可用流表空間容量來選擇轉(zhuǎn)發(fā)路徑，從多條路徑中選取可用流表空間最大的路徑。通過均衡多條轉(zhuǎn)發(fā)路徑的交換機間的流表利用率，避免交換機轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚再次引發(fā)拒絕服務(wù)攻擊。

2.2 流監(jiān)測

流監(jiān)測模塊持續(xù)監(jiān)測交換機端口上報的packet-in 消息速率、網(wǎng)絡(luò)流量統(tǒng)計，以及控制器內(nèi)存和計算資源占用率等網(wǎng)絡(luò)與系統(tǒng)狀態(tài)，并建立基于交換機端口的網(wǎng)絡(luò)流統(tǒng)計信息表，結(jié)構(gòu)如圖3 所示。統(tǒng)計信息如下：packet-in 消息中包含的網(wǎng)絡(luò)流的源地址scr、目的地址dst、協(xié)議號protocol、源端口srcPort、目的端口dstPort 的五元組信息tuple5（圖3 中用tup 表示）；tuple5 內(nèi)容的哈希值key 作為網(wǎng)絡(luò)流統(tǒng)計項flow_entry 入口序號；該網(wǎng)絡(luò)流最近一次packet-in 到達的時間time；該網(wǎng)絡(luò)流的packet-in 消息的頻次frequency（圖3 中用freq 表示）。網(wǎng)絡(luò)流統(tǒng)計信息表用于拒絕服務(wù)攻擊檢測，并被限速流規(guī)則管理模塊用來決策是否為網(wǎng)絡(luò)流下發(fā)流規(guī)則。

圖3 網(wǎng)絡(luò)流統(tǒng)計信息表結(jié)構(gòu)

當 packet-in 消息到達時，流監(jiān)測模塊對packet-in 消息的五元組信息計算哈希值key，即網(wǎng)絡(luò)流統(tǒng)計信息表的入口序號。由于多個不同網(wǎng)絡(luò)流會哈希到同一個哈希值key，需要精確匹配packet-in中的五元組信息，找到對應(yīng)網(wǎng)絡(luò)流的流表項flow_entry，增加該網(wǎng)絡(luò)流上報packet-in 消息的頻次frequency，并采用雙向鏈表frequency_chain 將出現(xiàn)的頻次frequency 進行排序，排序后的frequency用于后續(xù)限速流規(guī)則管理模塊對網(wǎng)絡(luò)流是否下發(fā)流規(guī)則的決策。同時，更新最近出現(xiàn)時間time 字段，并采用雙向鏈表time_chain 將最近更新時間time 進行排序。如果控制器為網(wǎng)絡(luò)流向交換機下發(fā)安裝流規(guī)則或者在超時時間內(nèi)沒有新的packet-in 到達，則該網(wǎng)絡(luò)流統(tǒng)計項flow_entry 將被刪除。流監(jiān)測算法偽代碼如算法1 所示。

算法1流監(jiān)測算法

根據(jù)交換機上報的packet-in 消息，查找匹配的流表項flow_entry

流監(jiān)測模塊采用與FloodDefender[18]相同的拒絕服務(wù)攻擊檢測方法，通過異常閾值檢測識別交換機端口出現(xiàn)的拒絕服務(wù)攻擊。流監(jiān)測模塊持續(xù)統(tǒng)計網(wǎng)絡(luò)流的packet-in 消息的頻次frequency，一旦出現(xiàn)拒絕服務(wù)攻擊，低頻次的網(wǎng)絡(luò)流數(shù)量就會快速增加，當超過異常檢測閾值時，流監(jiān)測模塊將觸發(fā)限速流規(guī)則管理模塊，進行流表溢出防護。當?shù)皖l次的網(wǎng)絡(luò)流數(shù)量低于異常檢測閾值時，表示網(wǎng)絡(luò)中短流的數(shù)量處于安全范圍，流監(jiān)測模塊將停止調(diào)用限速流規(guī)則管理模塊，恢復正常處理網(wǎng)絡(luò)流的狀態(tài)。

2.3 限速流規(guī)則管理

限速流規(guī)則管理被觸發(fā)后，調(diào)用路徑選擇模塊對出現(xiàn)拒絕服務(wù)攻擊流量的交換機端口的packet-in計算轉(zhuǎn)發(fā)路徑，然后根據(jù)限速安裝速率以及該網(wǎng)絡(luò)流packet-in 出現(xiàn)的頻次決定是否向交換機下發(fā)安裝流規(guī)則的消息。對于未安裝流規(guī)則的網(wǎng)絡(luò)報文，將會向交換機下發(fā)packet-out 消息，直接將網(wǎng)絡(luò)報文轉(zhuǎn)發(fā)給下一跳交換機。

2.3.1 流規(guī)則限速安裝策略

交換機的流表空間被所有端口共用，為了避免出現(xiàn)拒絕服務(wù)攻擊的端口的網(wǎng)絡(luò)流量的流規(guī)則完全占滿流表空間，影響其他端口的流規(guī)則安裝，采用基于流表可用空間的限速安裝流規(guī)則策略，防止流表溢出。t時刻該端口的流規(guī)則最大安裝速率fmax(t)為

其中，T為流規(guī)則超時時間，α為流規(guī)則安裝速率的調(diào)節(jié)因子，c(t)為t時刻交換機可用流表空間大小。

其中，c(t-1)-fmax(t)為t-1 時刻安裝流規(guī)則后的可用流表空間容量。流規(guī)則對應(yīng)的網(wǎng)絡(luò)流在超時時間內(nèi)沒有新的網(wǎng)絡(luò)報文到達時，將會從交換機流表里刪除，fdel(t)為因流規(guī)則超時被刪除后t時刻可用的流規(guī)則數(shù)量。在交換機只有一個端口出現(xiàn)拒絕服務(wù)攻擊流的情況下，由于網(wǎng)絡(luò)攻擊流通常為短流，網(wǎng)絡(luò)報文數(shù)量少，一個拒絕服務(wù)攻擊持續(xù)時間少于單位時間，可認為fdel(t)等于在t-T時刻的最大安裝速率fmax(t-T)，即

設(shè)交換機流表空間容量為C，結(jié)合式(1)～式(3)可得

交換機端口檢測到拒絕服務(wù)攻擊時，根據(jù)式(4)，取T=10 s（控制器ONOS 的默認超時時間），按照最大速率fmax(t)為該端口的網(wǎng)絡(luò)流安裝流規(guī)則，交換機流表空間可用率和流規(guī)則安裝速率如圖4 所示，流表空間可用率、流規(guī)則安裝速率保持穩(wěn)定。隨著流規(guī)則安裝速率的調(diào)節(jié)因子α的增大，流表空間可用率下降、流規(guī)則安裝速率增長。當流規(guī)則安裝速率的調(diào)節(jié)因子α=1.0時，有53%流表可用空間可供其他端口所使用，流規(guī)則安裝速率約為5%。限速流規(guī)則管理能夠有效地限制出現(xiàn)拒絕服務(wù)攻擊的交換機端口安裝流規(guī)則的最大數(shù)量，防止流表溢出，并確保其他端口的網(wǎng)絡(luò)流規(guī)則的安裝使用。

圖4 交換機流表空間可用率和流規(guī)則安裝速率

2.3.2 流規(guī)則安裝

控制器收到packet-in 消息后，首先計算網(wǎng)絡(luò)報文的轉(zhuǎn)發(fā)路徑，然后查詢該網(wǎng)絡(luò)流出現(xiàn)的頻次。如果該網(wǎng)絡(luò)流出現(xiàn)的頻次位于前fmax(t)位，即該網(wǎng)絡(luò)流報文出現(xiàn)次數(shù)多，則通過flow-mod 消息向交換機下發(fā)安裝流規(guī)則，并下發(fā)packet-out 消息轉(zhuǎn)發(fā)數(shù)據(jù)報文；否則將不下發(fā)安裝流規(guī)則的flow-mod 消息，直接通過低開銷的packet-out 轉(zhuǎn)發(fā)該網(wǎng)絡(luò)報文（在ONOS 官方的性能測試中處理packet-out 消息的性能比處理flow-mod 消息的性能高一個數(shù)量級），能有效防止流表溢出，并減少網(wǎng)絡(luò)報文在緩存中的等待時間，確保了網(wǎng)絡(luò)報文傳輸時延。流規(guī)則安裝算法如算法2 所示。

算法2流規(guī)則安裝算法

根據(jù)packet-in 消息和流監(jiān)測返回的流表項flow_entry，給轉(zhuǎn)發(fā)交換機下發(fā)安裝流規(guī)則的flow-mod 消息和轉(zhuǎn)發(fā)報文的packet-out 消息

2.4 路徑選擇

軟件定義網(wǎng)絡(luò)中不同的交換機可用流表空間不同，拒絕服務(wù)攻擊流量被轉(zhuǎn)發(fā)流經(jīng)剩余流表空間較小的交換機時，更易造成交換機流表溢出、增加網(wǎng)絡(luò)報文傳輸時延、消耗控制器資源、丟包等問題。而控制器ONOS 采用基于最小時延策略的Djikstra 算法來計算路徑，無法確保剩余流表空間較小的交換機不被選進傳輸路徑。在軟件定義網(wǎng)絡(luò)中，源節(jié)點至目的節(jié)點通常有多條可達路徑，路徑選擇模塊計算路徑時，從多條路徑中選取可用流表空間最大的路徑，通過均衡多條轉(zhuǎn)發(fā)路徑的交換機間的流表利用率，避免轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導致的再次拒絕服務(wù)攻擊，防止再次出現(xiàn)流表溢出情況。

轉(zhuǎn)發(fā)路徑由路徑上的所有交換機組成，根據(jù)木桶原理，轉(zhuǎn)發(fā)路徑的可用流表空間大小取決于路徑上所有交換機中可用流表空間容量最小的交換機。為了選出可用流表空間最大的路徑，計算每條可選路徑的所有交換機的最大可用流表空間容量，從中選出可用流表空間容量最大的路徑。

從源地址src 到目的地址dst 的可達路徑集合為Psrc,dst，對于一個可達的第i條路徑Pi∈Psrc,dst，路徑的可用流表空間容量Vi為

其中，Si,j表示第i條路徑Pi上的交換機集合中的第j個交換機，v(Si,j)表示交換機Si,j的可用流表空間容量。

路徑選擇模塊計算源交換機src 至目的交換機dst 的路徑時，將從多條可達路徑中選取可用流表空間最大的路徑P，即

基于可用流表空間的路徑選擇算法如算法3所示。

算法3路徑選擇算法

路徑選擇模塊從所有可達路徑中，選擇可用流表空間最大的路徑來傳輸網(wǎng)絡(luò)新流，實質(zhì)上是均衡了所有可達路徑的交換機間的可用流表空間，避免交換機轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導致的再次拒絕服務(wù)攻擊，防止再次出現(xiàn)流表溢出情況。

3 實驗評估

本節(jié)通過實驗對提出的抗拒絕服務(wù)攻擊的軟件定義網(wǎng)絡(luò)流表溢出防護FloodMitigation 進行有效性驗證，驗證其在拒絕服務(wù)攻擊發(fā)生時對交換機流表利用率、時延、丟包率、帶寬可用率、控制器CPU 利用率等的保護。使用ONOS 2.2.1作為軟件定義網(wǎng)絡(luò)控制器，軟件定義網(wǎng)絡(luò)仿真實驗平臺Mininet 創(chuàng)建的Open vSwitch 2.10.1 作為數(shù)據(jù)平面交換機，并依據(jù)OpenFlow 硬件交換機Polaris xSwitch X10-24S2Q 的配置將交換機的流表空間容量設(shè)定為2 000 條。Mininet 和ONOS分別獨立運行在 Ubuntu 16.04 LTS 系統(tǒng)的OpenStack 實例中，實例運行環(huán)境為 XEON E5-2630 v3 CPU，內(nèi)存為20 GB。

在Mininet 中創(chuàng)建與FloodShield 類似的實驗拓撲，如圖5 所示，拓撲中共有20 臺交換機（S1～S20）和16 臺主機（H1～H16）。主機H1、H3、H5、H7、H9、H11、H13、H15使用Mawi 流量數(shù)據(jù)集生成訪問其他主機的網(wǎng)絡(luò)流量。同時由主機H2向H16發(fā)送拒絕服務(wù)攻擊流量，源端口號、目地端口號均為隨機變化。在實驗中，當流規(guī)則安裝速率的調(diào)節(jié)因 子α=1.0時，將所提FloodMitigation 與OpenFlow、FloodShield 在同等實驗環(huán)境中進行對比實驗，驗證防護效果。

圖5 實驗拓撲

3.1 基于限速安裝流規(guī)則機制的流表利用率

當主機H2向主機H16發(fā)送的攻擊速率分別為1 000 flow/s、2 000 flow/s 時，交換機S1的流表利用率如圖6 所示。由于OpenFlow 沒有安全防護，出現(xiàn)了流表溢出。FloodShield 采用基于控制器CPU 利用率以概率接受的方式安裝流規(guī)則的防護方式，但是沒有考慮流表利用率，依然出現(xiàn)了流表溢出。FloodMitigation 由于采用了基于流表可用空間的限速安裝流規(guī)則機制，能夠有效地限制出現(xiàn)拒絕服務(wù)攻擊的交換機端口安裝流規(guī)則的最大數(shù)量，防止流表溢出，并且在2 種不同攻擊速率下，流表利用率保持穩(wěn)定。

圖6 不同攻擊速率下交換機S1 的流表利用率

3.2 基于路徑選擇的流表利用率

本節(jié)實驗通過交換機間的流表利用率，驗證所提路徑選擇在均衡交換機流表利用率上的有效性。實驗中由H2向H16發(fā)送攻擊流量，網(wǎng)絡(luò)流量將流經(jīng)路徑H2—S1—S5或H2—S1—S6。

圖7(a)為在不啟用路徑選擇算法情況下交換機S5和S6的流表利用率，S6的流表利用率約為15%，而S5的流表利用率約為50%。這是因為控制器將H1發(fā)送的部分背景測試流量，以及流經(jīng)交換機S1的攻擊流量都轉(zhuǎn)發(fā)給了交換機S5。圖7(b)為啟用路徑選擇算法情況下交換機S5和S6的流表利用率，S5和S6的流表利用率接近。這是由于路徑選擇模塊在每次選擇路徑時，將從多條路徑中選取可用流表空間最大的路徑，能夠有效地實現(xiàn)多條轉(zhuǎn)發(fā)路徑的交換機間的流表利用率的均衡，避免交換機轉(zhuǎn)發(fā)網(wǎng)絡(luò)報文過程中出現(xiàn)網(wǎng)絡(luò)新流匯聚導致的再次拒絕服務(wù)攻擊，實現(xiàn)對流表的有效保護。

圖7 交換機S5 和S6 的流表利用率

3.3 控制器CPU 利用率

當拒絕服務(wù)攻擊速率分別為1 000 flow/s、2 000 flow/s 時，控制器CPU 利用率如圖8 所示。由于OpenFlow 沒有防護機制，其控制器CPU 利用率最高。FloodMitigation 始終比FloodShield 的控制器CPU 利用率低，并且隨著攻擊速率的增加，F(xiàn)loodShield 的控制器 CPU 利用率增加幅度比FloodMitigation 大。這是因為FloodShield 基于控制器CPU 利用率以概率接受的方式通過flow-mod 安裝流規(guī)則，隨著攻擊速率的增加，需要下發(fā)流規(guī)則的處理增多，CPU 利用率增加。而FloodMitigation采用基于流表可用空間的限速安裝流規(guī)則策略，能夠保持穩(wěn)定的流規(guī)則下發(fā)安裝速率，隨著攻擊速率的增加，F(xiàn)loodMitigation 的控制器CPU 利用率增加幅度小。

圖8 不同攻擊速率下的控制器CPU 利用率

3.4 時延、丟包率、帶寬可用率

本節(jié)實驗中H2發(fā)送拒絕服務(wù)攻擊流量，測量H1～H9的時延、丟包率、帶寬可用率，結(jié)果如圖9 所示。H1發(fā)送20 條UDP 流，每條UDP流有1 000 個網(wǎng)絡(luò)報文，統(tǒng)計接收到的網(wǎng)絡(luò)報文數(shù)量以及平均傳輸時延，并在 H1上使用 iperf工具測試可用帶寬。FloodShield 采用基于控制器CPU 利用率以概率接受的方式安裝流規(guī)則，隨著攻擊流量速度的增加，CPU 利用率增加，處理的packet-in 消息減少，緩存的packet-in 消息逐漸增多直至緩存溢出，出現(xiàn)丟包率增加和帶寬可用率減少的情況。而FloodMitigation 將無法安裝的網(wǎng)絡(luò)報文直接通過低開銷的packet-out 消息轉(zhuǎn)發(fā)，傳輸時延保持穩(wěn)定，沒有出現(xiàn)因緩存溢出進而導致的丟包率增加和帶寬可用率減少的情況。

圖9 時延、丟包率和帶寬可用率

4 結(jié)束語

現(xiàn)有工作從不同的性能瓶頸角度出發(fā)研究拒絕服務(wù)攻擊防護技術(shù)，但未能有效防護流表溢出，以及防止拒絕服務(wù)攻擊流量在轉(zhuǎn)發(fā)中匯聚導致的再次拒絕服務(wù)。本文提出了軟件定義網(wǎng)絡(luò)流表溢出防護技術(shù)FloodMitigation。通過基于可用流表空間的限速流規(guī)則管理機制，動態(tài)限制出現(xiàn)拒絕服務(wù)攻擊的交換機端口的流規(guī)則安裝最大速度，避免拒絕服務(wù)攻擊流量占用被所有端口共用的流表資源，以及避免影響其他端口的流規(guī)則安裝；同時基于可用流表空間的路徑選擇在多條轉(zhuǎn)發(fā)路徑的交換機間均衡流表利用率，避免網(wǎng)絡(luò)新流匯聚在可用流表空間少的交換機上所導致的再次拒絕服務(wù)攻擊。實驗結(jié)果表明，在沒有引入額外設(shè)備的情況下，F(xiàn)loodMitigation 在拒絕服務(wù)攻擊下能夠有效防止流表空間溢出的防護，并在避免網(wǎng)絡(luò)報文丟失、降低控制器資源消耗、確保網(wǎng)絡(luò)報文轉(zhuǎn)發(fā)時延等方面有效抵御拒絕服務(wù)攻擊。下一步的工作將結(jié)合流規(guī)則動態(tài)管理機制，實現(xiàn)對有限的流表資源的有效利用，并在硬件交換機上驗證拒絕服務(wù)攻擊防護效果。