云環境下基于SDN的高效流量監控方案

劉世嘉，王 勇,+，劉玉明

(1.桂林電子科技大學 計算機與信息安全學院，廣西 桂林 541004；2.桂林電子科技大學 廣西云計算與復雜系統高校重點實驗室，廣西 桂林 541004；3.桂林電子科技大學 廣西云計算與大數據協同創新中心，廣西 桂林 541004)

0 引 言

近年來云計算技術受到各大廠商追捧，其高速發展的背后，安全問題日顯嚴重[1]。傳統數據中心多為南北向流量，而隨著云計算技術的到來，云存儲、并行計算等需要大規模集群協同的業務產生了大量的東西向流量，推動了南北向流量往云平臺內部虛擬機間產生的東西向流量轉變[2]。傳統安全設備和流量采集方法[3]對東西向流量的安全防護無能為力，因此東西向流量的接觸盲區，無疑為云安全態勢分析提出了新的難題。為了實現云環境中東西向流量的可視可控，近年來相繼出現了多種流量捕獲方案[4]，而現有的絕大數方案都是以SDN流量牽引[5]為基礎，通過SDN將所有虛擬機產生的東西向流量牽引進軟件安全檢測系統進行檢測[6]，從而實現東西向流量的監控。但是，軟件防護系統的性能受制于宿主物理機性能，所有東西向流量的匯入檢測會帶來巨大的負載，可能會造成單點失效的問題，導致流量無法轉發，用戶業務開展受到影響。基于上述的問題，本文提出一種的高效的流量采集與檢測方法來監控流量，通過SDN控制器對流量進行自適應采樣，避免因密集的固定周期采樣給控制器帶來額外負載，之后提取出特征信息，經常用分類算法的類別劃分處理后，再下發不同級別的流表策略，先快速過濾掉可被識別的正常流量，牽引需要檢測的東西向流量進入軟件安全檢測系統，以此減小需要捕獲的流量的規模。在既不影響控制器性能，也不影響檢測率的同時，避免占用過多流表項，有效降低了帶寬的占用，減小了軟件安全檢測系統的負載。

1 相關工作

為了能夠獲取東西向流量，Giotis K等[7]提出一種將sFlow與Openflow交換機結合的方法來提升異常檢測的效率和擴展性，該方法分為3個階段：流量捕獲、異常檢測、攻擊緩解，其中流量捕獲部分采用了SDN流表統計信息采集與sFlow插件主動采集結合的方法，保證了處理效率。但是，在云環境多租戶應用場景下，sFlow無法識別不同租戶產生的相同地址且不易大規模部署。Peng H等[8]利用SDN進行流量采集，方法是固定10 s輪詢周期對交換機收取流表統計信息，提取出特征以構建多維流特征向量交由DPTCM-KNN算法進行異常流量的分類檢測。該方案使用的固定輪詢周期，在周期設定的長短上會對測量精度與設備負載產生影響，需要平衡三者的關系，否則會加重交換機的負載。Zanna P等[9]提出一種在控制器集成IDS模塊的方法，利用控制器下發流表的方式動態阻止入侵。該方案通過Packet In消息上送所有待檢測流量至SDN控制器，當流量規模增大時，會加重控制器負載，容易造成單點失效。Ha T等[10]提出一種利用SDN將流量鏡像到多臺IDS中進行檢測的方法，將同類型攻擊統計成組后鏡像到同一臺IDS，借此提升檢測率并負載均衡被檢測流量。該方案的流量采集仍然是先匯集到一臺交換機后再進行分發檢測，且方案在傳統三層網絡架構下實施，云環境的多計算節點網絡架構難以依此進行部署。池亞平等[11]提出一種IDS與控制器聯動的入侵防御方案，通過將所有流量重定向到Snort進行檢測，在檢測到入侵后通過控制器下發策略阻止入侵。該方案Snort部署于計算節點上，所有流量的匯入會增加負載，影響計算節點性能，同時也會對其上的虛擬機性能造成影響，并且會產生大量過期的重定向流表項。邵國林等[12]利用OpenFlow技術將所有虛擬機流量重定向至外部IDS檢測，檢測完成后需要將合規流量重新注入。該方案因需要將流量在IDS進行二次轉發，當流量規模增大時，IDS的轉發性能成為瓶頸，會造成單點失效，影響正常業務流量的轉發。

上述方法雖然都將SDN技術運用到流量的捕獲中，但多數是欠考慮地牽引所有流量到軟件防護/檢測系統，因其工作重點在入侵檢測上，并沒有考慮到云環境中產生的大規模流量對其負載產生的影響。為此，本文設計的方案提出通過自適應流量采樣并分級別預處理的方法，有效緩解軟件檢測系統的負載，降低安全控制信道的占用和對控制器性能的影響。

2 基于SDN的高效流量監控方案及相關設計

2.1 總體方案設計

本文提出的基于SDN的高效流量監控方案由3個主要模塊組成：一是自適應流量采樣模塊，提供可根據各條流的帶寬占用情況，動態調整采樣頻率的功能；二是包處理模塊，提供對采樣來的流量提取特征信息并轉存至通用存儲識別模塊待檢測分類的功能；三是策略響應模塊，提供分級別響應不同流表策略對流量進行具體牽引控制的功能。方案的總體架構如圖1所示。

圖1 本文設計的方案總體架構

2.2 自適應流量采樣模塊

為了實現對流量的后續識別處理，首先需要通過OpenFlow交換機將流量上送至控制器，也即對流量進行采樣。通過觸發Packet-In消息，OpenFlow交換機可以將指定流量封裝后上送至RYU控制器處理，而觸發Packet-In消息的方法分為兩種：匹配到流表項中的行動主動上送；不存在與流表項一致的條目被動上送。需要注意的是，上送控制器的過程需要占用交換機與控制器間的安全信道帶寬。目前，控制器多以固定頻率的方式進行輪詢以采集交換機的流量統計信息，高頻率的輪詢能夠提升流量統計信息的精度，但也會擠占過多交換機與控制器間的安全信道帶寬，同時也會給控制器造成過大負載。因此，需要一個合適的方案來平衡采樣精度與性能負載間的關系。

本文設計的方案的自適應流量采集模塊，通過動態操作FlowMod構造流表的hard_timeout參數，使流表在到達指定的時間后實現超時自動刪除，從而讓該條流的后續流量在沒有下發新的流表前觸發流表項中的被動Packet-In消息，將流量封裝后上送至控制器，實現流量的采樣操作。為了平衡采樣精度與性能負載之間的關系，還需要通過FlowMod為流表設置FlowRemoved標記，該標記在每條流表超時刪除后能夠上報其持續時間內的流量統計信息，根據回收各條流表超時后的統計信息計算出其持續時間內的帶寬占用情況，以此動態規劃下一次的hard_timeout超時時間。當帶寬占用小時，通過降低超時時間提高采樣的頻率保證精度，反之則增加超時時間減小采樣頻率降低性能負載。

流表hard_timeout的超時時間(T)的計算過程如式1所示

T=(byte_count/duration_sec)*τ+

(1)

其中，byte_count為流表存活期間匹配的流量大小、duration_sec為流表存活時間，兩者通過回收的流表統計信息中獲取；τ為在30 s的時間區間內劃分出的時間窗口間隔；為 [1,2,…,τ] 上等概率取值的隨機變量，引入該變量可以避免因超時時間相同而在某一相同時刻出現峰值流量增加控制器負載，而造成控制器單點失效的情況。在計算流表超時時間時，取10 Mbps～100 Mbps的帶寬范圍，τ取 3 s 為間隔進行實驗，在本文的實驗中表現較好。由上述設計實現的偽代碼見表1。

2.3 包處理模塊

包處理模塊的作用是對前一步采集的流量進行解析并

表1 自適應流量采樣算法

提取特征信息轉存后待分析，經過Packet_In消息封裝后的數據包到達RYU控制器，由Packet_In消息處理模塊進行解包，通過引入隊列操作將獲得的數據包依次送入包處理模塊，以此緩解當控制器遇到峰值負載而造成丟包的問題。

包處理模塊通過get_protocols方法對數據包進行層層解析，從數據包中可獲得的字段見表2，將這些信息連同時間戳按不同數據包組織成一一對應的鍵值對存入特征字典，之后轉存至通用存儲識別模塊的Redis內存數據庫待后續分類，此處根據存儲需求，選用了Redis常用數據存儲類型中的隊列類型，通過使用PUSH、POP等操作可以快速的將任務按FIFO順序依次進行出入隊列操作。

表2 數據包提取的字段

將所有由包處理模塊組織好的特征字典依次存入Redis隊列后，可方便地提供兼容接口被常用檢測分類方法如Snort、AC自動機、DFA算法等提取檢測過濾部分威脅低的正常流量，本文中利用建立的白名單規則進行快速分類，經分類后再分別存放入不同的Redis隊列以供后續的策略響應模塊調用下發流表策略。

2.4 策略響應模塊

方案中策略響應模塊完成對檢測后流量的具體控制，利用RYU靈活的FlowMod流表構造能力，從Redis隊列中取回分類好的結果進行解析并構造出不同的流表規則后下發給交換機。策略響應模塊還預留了擴展接口，可以根據需求觸發更多級別的控制事件，提供更加細粒度的流量控制能力。本文設計的方案根據流量不同的類型，將風險級別劃分為3個等級，實現不同粒度的控制，針對風險級別，給出以下劃分依據。

(1)正常級別的流量，確定正常的流量不需要轉送至軟件安全檢測系統進行進一步的檢測，直接下發去往目的地的正常轉發流表，優先級最低；

(2)端口級檢測級別的流量，在被檢測出某個端口存在風險后，構造流表的action方法將目標端口規則的流量牽引至同節點最鄰近的軟件安全檢測系統進行進一步的檢測，優先級高于正常級別；

(3)完全檢測級別的流量，通過構造流表的action方法直接牽引至同節點最鄰近的軟件安全檢測系統，優先級最高。

通過上述分級，實現了不同類型流量響應不同級別的流表規則，過濾掉可先被識別的正常流量，減少牽引至軟件安全檢測系統的流量規模，降低其檢測負載，避免因負載過高造成單點失效。

方案采用RYU控制器，并在現有的模塊上進行二次開發，實現系統各模塊間的整體調度；另外通過Redis內存數據庫實現定制的消息中間件及處理方法，促成控制器與通用存儲識別模塊之間數據存取與檢測識別任務的快速解耦和高效處理；在控制流表的設計上，充分利用RYU API的特性，在一條流表實現多種功能的同時，避免因重復調用業務邏輯而造成SDN控制器額外的處理負載；此外，策略響應模塊還預留了通用接口，提高了控制功能的可擴展性，能夠接入更多對流量的控制邏輯。

3 實驗設計與結果分析

3.1 實驗環境

為了驗證本文設計的方案的性能和檢測率差異，通過Mininet、Openvswitch和RYU控制器構建的實驗平臺的網絡拓撲如圖2所示，采用的軟硬件測試平臺見表3。

圖2 實驗平臺網絡拓撲圖

名稱版本CPUIntel Core i7-4790內存16 G操作系統Ubuntu 16.04Mininet版本2.3.0d1Openvswitch版本2.5.4OpenFlow協議版本1.3

3.2 實驗設計與結果分析

首先，為了驗證本文所提出的方案對控制器的性能和負載產生的影響更小，提煉以文獻[10]和文獻[11]為代表的流量牽引方案(簡稱方案α)，去除其入侵防御的業務邏輯并僅保留核心轉發邏輯(將所有流量復制并牽引到軟件安全檢測系統)。利用上述實驗平臺，在一臺虛擬機上開啟Iperf服務端，在另一臺虛擬機上用Iperf客戶端發送以10 Mbps～100 Mbps逐級遞增的帶寬測試丟包率，發送的流量均視為正常流量轉發處理。方案α與本文方案β的丟包率和時延對比如圖3和圖4所示。

圖3 丟包率對比

圖4 時延對比

從上圖的實驗結果可以看到，方案β的時延與方案α相差不大，浮動在正常的范圍內。而丟包率對比中，40 Mbps 帶寬前由于本文方案的采樣邏輯會給SDN控制器性能造成一些影響，丟包率會略高于方案α。當超過40 Mbps 帶寬時，方案α因負載增加丟包率逐漸加大，本文方案的丟包數量上升緩慢，隨著總包數的激增，整體丟包率要略優于方案α，以上說明本文設計的方案β不會給控制器增加過多負載，且避免了控制器峰值負載給性能帶來的不良影響。

另外，為了論證本文方案能夠保持更高的檢測率，添加方案α和β的入侵防御業務邏輯，利用上述實驗平臺部署了一臺基于Snort的軟件安全檢測系統用于檢測牽引而來的東西向流量，在一臺虛擬機上利用Scapy構造并發送正常的網絡數據包以模擬實際的網絡通信環境，在另一臺虛擬機上構造并發送攻擊流量以模擬攻擊環境。正常流量以10 000至40 000個逐級遞增的數量模擬不同規模下的網絡負載，攻擊流量固定發送5000個，采取10次實驗數據取平均值的方法對比了兩種方案對攻擊流量的檢測率，兩者的檢測率結果如圖5所示。

圖5 檢測率對比

實驗結果表明，隨著正常流量數量的逐級遞增，Snort的檢測負載驟然提升系統出現嚴重的丟包現象，導致方案α的檢測率在正常流量超過20 000個后下降明顯，到達40 000個后甚至降至64.2%。而本文方案能夠讓Snort的檢測負載保持在一個正常的水平，正常流量數量達到40 000個時仍然能保持90%以上的檢測率，效果的提升上顯著優于方案α。

4 結束語

以上的實驗結果表明，本文提出的一種云環境下基于SDN的高效流量監控方案，通過自適應流量采樣模塊、包處理模塊、策略響應模塊對需要監控的東西向流量進行預處理，識別并放行可確定的流量，有效降低了安全控制信道和安全檢測系統的負載，能夠使安全檢測系統的檢測率保持在90%以上，遠高于被對比的方案，說明本文設計的方案不會對檢測率產生負面影響。同時，對比實驗結果表明本文設計的方案在帶寬超過40 Mbps后，丟包率和時延表現均優于被對比的方案，避免了控制器峰值負載給性能帶來的影響。