高性能公有云WAF安全方案①

何 丹,張 悅

1(中移(蘇州)軟件技術有限公司 云計算產品部,蘇州 215000)

2(中移(蘇州)軟件技術有限公司 大數據產品部,蘇州 215000)

1 引言

WAF (Web Application Firewall)是Web 網絡應用防護系統,擔當著是Web 應用的防護,由于現如今Web 應用在當今互聯網應用中的主流應用,一般來說WAF 的應用防護包括一般包括常見的Web 防護,比如異常的流量監測、DDoS 攻擊、https 攻擊、SQL 注入的攻擊、命令注入攻擊、cookie/seesion 劫持、應用平臺攻擊劫持等攻擊[1].而這些業界對全面防護能力的要求都離不開專業的WAF 設備防護以及流量防護方案.

而云計算業務的應用越來越普及,行業內的企業和單位已經將自己的Web 業務信息系統逐漸的遷移至云服務中.集中化的云虛機部,使得部署資源的集中化.這些企事業單位享受著云化業務帶來的好處的同時,其集中化云Web 服務的安全無疑是最大的挑戰[2],然而集中化的云端部署,也為WAF 防護應用的發揮提供了舞臺.

業界公有云提供云內WAF 安全框架如圖1,將云內Web 流量先交由專業WAF 設備來防護清洗.

圖1 云內WAF 防護

2 業界WAF 方案分析

中國移動在全國布局公有云WAF 應用中,發現業界方案在流量防護效率、整體引流拓撲防護吞吐量表現不足.

2.1 流量監測現狀

WAF 防護系統在做流量防護的時候,需要時刻對流量進行檢測分析.而流量監控分析的功能是采集交換機不斷的生成Flow,并將采集后的Flow 流的拆包解析、歸并.流量監測分析技術實現的是對高速轉發的網絡層IP 數據流流量信息進行采集,Flow 提供的是網絡流量的會話級視圖,這種會話級視圖,可以定義為包含一個源IP 地址和目的IP 地址間傳輸的數據包流數據交換形式.

這種業界Flow 流的串行分析流程,存在以下問題:

首先,接收Flow 步驟和解析Flow 步驟以及歸并計算步驟其處理能力被設定預設固定值.無法動態自適應調整處理能力.

其次,對著圖2 的處理步驟,整體流量監控機制缺乏收集能力與解析能力之間的協同同步機制,以及缺乏接收能力和解析能力兩者之間的協同同步機制.每個處理步驟無法感知其上游處理業務壓力及下游步驟處理能力.

圖2 WAF 流量解析過程

上述缺陷,或者由于上游步驟傳過來的數據量較大,而下游步驟的處理能力被固定的較小,導致來不及接收,來不及解析的丟包情況.使得監控數據的丟失而降低防護的精度.或者由于上游數據量較小,而預置的下游步驟的處理能力被預設的很大,導致等待接收,等待解析的浪費計算資源情況.而在突發大流量的WAF 應用場景中,這種流量監測機制通常會無法適應突發的統計數據量將流量丟棄,影響中國移動云WAF的防御的效果.

2.2 引流拓撲現狀

一般業務的防護系統WAF,如果云網絡不是SDN網絡,需要通過流量代理的方式在云實現東西向流量的牽引調度:將防護流量引流到WAF 設備,代理引流需要在部署機器中設置一個引流代理,通過代理來將防護流量引入WAF 設備.通過在部署機器中集中的引流虛擬機接收防護策略,并按照防護策略對流量進行牽引到WAF 設備的一種拓撲,拓撲中WAF 的流量牽引為單線單WAF 集群模式.安全控制平臺將相應的引流請求發送至這個引流代理,引流代理根據虛擬機所在宿主機的位置以及虛擬機當前的網絡情況,下發相應的引流指令,并且完成對應的網絡配置,實現流量牽引.

這種業界引流代理一方面在進行引流操作時,需要獲取對云計算系統較大的操作權限,代理功能依賴于平臺環境,這樣每種代理和云計算平臺之間很難進行解耦[3],而且代理的部署設置難以移植和進行部署復用.另一方面這種單線的引流回大幅的增加圖3 左側vswitch 的負載.拓撲中WAF 的流量牽引為單線單WAF集群模式,引流過程中需要占用大量的平臺內部網絡資源進行.而且這種代理引流會使得操作依附于云計算平臺,使得操作復雜.而業界SDN 引流也為4.1 介紹串行單線引流.防護策略與流量牽引的串行結構使得策略與操作沒有分離,限制了SDN 引流效率[4],和WAF 的防護吞吐率.

圖3 流量牽引

3 流量監測改造

本章設計流量監測改造方案解決2.1 提出的流量監測低效問題,方案包括設計3.3 模型,以及3.4 改造算法.方案提供了各個處理流程可動態化調整處理能力的機制,實現自適應動態化調整處理能力,解決了流量處理步驟能力固定的問題.方案提供了同步算法,使得各個處理流程之間的協同調整處理能力以及啟動的同步機制,實現了處理步驟之間的能力相互感知,并動態變化能力以匹配高效協同,解決了處理步驟能力配合低效的問題.

3.1 流量統計監測

如2.1 業內對流量解析的流程通過固定的格式包來解析所得到的對應Flow 流,并采用單步的收集過程,而后進行歸并計算.整體流程的統計監測結果一般如圖4.

圖4 流量統計監測

這是包含網絡七元組的統計信息源地址、目的地址、源端口、協議類型、流量大小等.這些信息都是可用提供WAF 平臺防DDoS 或者其他功能的特征信息.DDoS 攻擊會使得網絡上出現可檢測的統計性特征[5,6]:比如一個網絡真實節點的節點位置相對固定,其地址的TTL 值比較穩定,由于TTL 的值難以變動,所以可以用來將其視為一個特征值來判定虛假的IP 攻擊行為;比如SYN Flood 類型的攻擊中最明顯的攻擊特征就是由于虛假的SYN 請求過多,半連接劇烈增長,而與之對應的FIN 信號很少.這種情況下可以具體設計將間隔時間內將SYN 和FIN 的比值作為閾值判斷,當SYN 信號的數量超過FIN 信號數量過多,起比值超過閾值的時候可作為攻擊特征;另外訪問攻擊目標的源地址的新增IP 數量劇烈上升特征,也能做攻擊判定.

3.2 流量解析模塊

對流量解析具體的業界流程為例:由圖2 顯示在此過程中的收集Flow 和歸并計算按照流程分兩步處理,這樣的設計在做流量監控的時候,會導致性能上的缺陷.首先Flow 記錄的發送能力和接受和收集Flow接受能力難以配和和協同.在Flow 記錄高速大量的全部進行發送,而此Server 端沒辦法感知到Flow 流的速度,從而導致Server 端無法全部解析Flow 記錄,而無法計算解析的Flow 包,將會被當做流量冗余而被丟棄,最終使得Server 端的缺乏協同而丟失數據Flow 而導致流量統計精度不足.另一方面若Flow 記錄發生的量小,Server 端的處理能力被預置的很大,會造成Server端的等待,其預置的處理能力將會空置和浪費.

3.3 改造流量監測模型

本文提出高效流量統計方案所提出的解決方法和系統包括,如圖5 所示.

1)線程組模塊Server 端接收Flow 的接收模塊.

2)線程組模塊Server 端解析Flow 的解析模塊.

3)線程組模塊Server 端計算Flow 歸并計算模塊.

以上3 個處理步驟采用線程,通過動態化的線程組,進行實現動態能力自動調節.

圖5 高性能流量監測流程

1)如圖所示定義udpserver.c 的Server 端的線程能力接收組,以及Server 端的解analyse.c 的解析線程能力進程,以及Server 端的歸并模塊功能線程組.

2)本功能模塊組感知到不能夠滿足當前處理能力需求的時候,比如當前解析線程數量為n-1 模塊解析速度較慢,則本模塊動態化處理能力增加處理能力資源,Server 端啟動新線程n 來提升解析速度,此時的處理能力為使得模塊處理速度達到n.

3)相反的當本模塊能力感知能力為過剩的時候.則同步算法要銷毀最新啟動的線程,從而線程能力組的能力下降到n-1,釋放單位的線程資源.

3.4 自適應統計同步算法詳解

1)在處理能力的適配上,是根據處理能力需要自動調整的,而處理能力大小的由信號量變量的值來決定.接收線程通過UDPserver 中的recvfrom()函數不斷的循環監聽抓取交換機發的Flow 流.(Flow 流是UDP 包),并將Flow 流寫入長度為n 的隊列[7],對于此隊列長度n,如圖6 所示.

圖6 中接收步驟為生產者,不斷的往自己的隊列塞從交換機那抓取的Flow 記錄,解析模塊從隊列里面抽取,成為消費者.他們共享上述隊列的資源池.

2)設計算法的決策閾值,本方案中設計高閾值為隊列資源池的長度n,低閾值為空的隊列資源池的長度0,上圖當生產者和消費者的之間的信號量作為兩進程之間的線程組通信信號.當步驟之間的信號量達到對應的閾值n,或者步驟之間的信號量達到對應的閾值0,則按照步驟3)的算法進行決策執行.

圖6 處理模塊之間交互

3)如果接收步驟過快,步驟信號量達到滿載的n,此時此發明啟動設定增加消費者:當此接收線程為j,解析線程為i,當j 寫入的數據數量mi,mi 在0～n 之間,mi 在每接收一個單位其值加1,在解析數據從隊列取走數據解析時其值減1,當mi 到達隊列長度n(寫滿)則對解析步驟進行加速(加大消費者能力速度)此時解析步驟啟動一個新線程i+1.此時閾值判斷量為新的變量n=mi+1.

4)如果解析步驟過快,步驟信號量達到空載的0 此發明啟動設定減少消費者:當此發送線程為j,解析線程為i,當j 寫入的數據數量mi,mi 在0～n 之間,到達隊列長度0(取空)則對解析步驟進行減速(降低消費者能力速度)此時解析步驟銷毀最新啟動的當前線程i.此時閾值判斷量為新的變量n=mi-1.

5)此算法的控制邏輯為圖5 中P1V1 標記處通過信號量向后控制.向后控制邏輯順序類似棧結構:寫入相對過快則啟動解析新線程順序為解析(1 號,2 號,3 號,…,i 號,i+1);寫入相對過慢則銷毀的是當前解析線程號銷毀順序(i 號,i-1 號,…,2 號,1 號).

4 引流拓撲改造

本章解決2.2 業界的WAF 的引流拓撲吞吐量低的問題:業界WAF 引流的SDN 的引流方案為控制策略和流量承載都通過SDN 網關來處理,SDN 網關可以通過代碼接口用NETCONF 協議進行控制配置,比如下發路由實現流量牽引等,7750 為諾基亞的SDN 網關設備,通過7750 進行集中下發策略和承載引流,使得控制過程和業務承載難以真正相互分離.單一的防護資源池無法并發的進行流量的牽引.導致防護吞吐量較低.無法充分利用WAF 的防護能力.本章提出WAF引流拓撲改造,實現SDN 牽引流量承載和控制策略下發分離,實現WAF 的并發調用防護,另一方面通過繞過7750 的SDN 對引流進行并發操作,提高中國移動WAF 設備使用效率,提高WAF 系統防護的吞吐能力.

4.1 WAF 的SDN 引流拓撲

通過SDN 集中的控制器,來掌握整體的網絡結構圖[8-12].如果需要云平臺里面的目標Web 服務器進行防護,需要進行檢測和防護的流量,方案的SDN 完成流量的牽引的結構大概如圖7 所示:以某廠商的云平臺SDN 引流方案為例子.

圖7 常規SDN 引流

如圖7 的流程圖所示,首先用戶通過平臺控制平面的操作把引流信息通過NETCONF 下達給7750 流量牽引的命令,其次從流量層面來看首先流量通過7750 進行牽引,結合控制層面來看,整體的SDN 的東西向引流如下:

1)公網訪問防護IP 時,經過7750 后,路由到WAF,此時的流量過程為源目地址為:客戶端IP——WAF.

2)軟WAF 對流量進行檢測,合規請求通行,并對源地址進行轉換,此過程源目地址為:Nat_WAF——業務網絡服務器IP.

4)業務網絡服務器將響應內容發送給軟WAF,此過程源目地址為:業務網絡服務器IP——Nat_WAF.

5)軟WAF 收到業務網絡服務器的響應后,轉發響應內容給客戶端.

7750 構成了業務側的核心,防護策略、流量牽引只能通過7750 串行下達,無法并發的進行流量的牽引.導致防護吞吐量較低.

4.2 改造WAF 引流拓撲

在高性能SDN 并發引流的改造如圖8，具體思路提出如下.

圖8 SDN 引流改造

1)以6 臺WAF 為.他們按照hash 映射算法與平臺映射.

2)通過安全管理平臺下發實際的防護策略直接到設備WAF1,WAF2 上此時策略到WAF1、WAF2 上的IP 為真實IP.

3)SDN 將保護流量直接牽引到LB.

4)此時LB 和平臺采用與1)一致的hash 映射算法牽引到目的WAF 設備,牽引地址為WAF1 和WAF2的共同的高可用地址VIP.

分析結構:此時的拓撲接口控制防護策略從上圖的左側通過安全管理平臺直接進行下發,通過平臺算法映射下發到WAF 設備,而承載流量通過有7750 的SDN 網絡新加LB 并與平臺相同映射,實現策略對應的WAF 實現策略與流量承載分離.

總結:1)改造后使得用戶側防護策略可以繞過7750 直接通過平臺映射到對應設備,使得控制端可以并發調用防護.2)7750 不用關心具體的引流目標WAF,只需把流量引入LB,由LB 采取對應控制端引流映射WAF,實現對應策略的流量牽引.

5 試點實驗效果

本章實驗在中國移動某省公司公有云進行試點測試,分別實驗(采用流量監測提升和拓撲改造提升)高性能WAF 方案比業界傳統方案的流量監測防護效率和流量吞吐量.

5.1 實驗流量監測效率

測試環境1 搭建:WAF 流量檢測端與流量業務發送端直連,對流量檢測端進實驗測試對比分析,對象為1:高性能WAF 方案和2:傳統WAF 防護方案.測試模型如圖9.

圖9 測試模型

測試內容為對0.2 s 后開始同時分別對兩組WAF模塊分別發送500 mb/s 的流量來考察觀測對象1:在測試時間高性能方案的流量監測結果.2:常規方案的流量監測結果.兩組的時間段都一致,發送端和接收端的測試時間也相同.

1 和2 對象測試結果如圖10.

圖10 流量監測效率對比

實驗仿真測試結果驗證思路為驗證流量統計和實際流量偏移量,w 為統計時間.其中為 s (w)高性能監控算法監控統計流量,u(w)為常規算法監控統計流量.θ1 、θ 2為對應算法偏差量.

實驗1 結果分析:

1)流量發送端,向WAF 系統發送需要防護監測的流量.在時間在0.2 s 時刻,發送流量由0 b/s 突發增加到500 mb/s.

2)流量統計端,為WAF 系統內防護流量統計,如圖11,采用改造流量監測統計算法的高性能WAF 系統,面對突發數據壓力,按照3.4 自適應算法預期,迅速自適應增加處理能力,在1 s 時刻,就監控解析了480 mb/s以上的流量.

3)對比傳統WAF 系統,其到3.2 s 時刻才監控解析了480 mb/s 以上的流量.在 w ∈(0-1)偏差的監測數據包因為傳統方案無動態自增處理能力機制而大量丟包.1 s 時刻手動增加傳統方案監測資源能力,才慢慢在3.2 s 時刻監測足夠數據.

4)1)-3)分析結合仿真計算結論式(1)和式(2),得到采用改造流量監測方案的高性能WAF 方案比傳統WAF系統的流量監測丟包率更少,θ1小 于θ 2更高效貼合實際流量的承載.因而高性能WAF 方案的防護效率更高.

圖11 防護吞吐量對比

5.2 實驗防護吞吐量

實驗2 設計:對象1、2 同時對公有云環境內的3 臺云主機按照相同策略進行WAF 防護.

實驗對象為1:高性能WAF 方案,2:傳統WAF 防護方案,單臺業務訪問流量訪問為10 mb/s.實驗測試對象為檢測WAF 防護系統池的防護吞吐量.

時間 w選取說明,單臺主機策略的WAF 防護系統的調度啟動周期為10 s 以上,啟動后WAF 系統有吞吐流量可以統計.實驗選取第一個啟動周期中的10 s時間段作為統計周期來進行統計.w ∈(0-10).

實驗2 結果分析:

1)傳統WAF 防護方案在第一個啟動周期10 s 內,w∈(0-10)順序啟動了一臺主機的流量防護,而其他主機防護策略還在排隊,統計周期內整個傳統WAF 方案在10 mb 左右的防護流量.

2)高性能的WAF 方通過改造引流拓撲,策略與引流承載分離,測試結果實現可并發的防護,如圖在w∈(0-10),3 臺的防護流量全部牽引到位.

3)結合1、2 得到采用高性能并發拓撲的高性能的WAF 方案,可以實現WAF 流量牽引的并發調度,在第一個調度啟動周期后就可以實現并發調度3 臺主機的并發流量防護,達到30 mb 左右,因而高性能WAF方案的實現了無任務排隊的并發高吞吐量防護.

6 總結

通過改造流量監測方案在流量監測改造上設計的處理步驟自適應機制算法,在公有云實施測試中有效實現了下游網絡處理能力自適應匹配,減少了監測流量的丟包,提高了WAF 流量監測效率.

通過改造WAF 防護拓撲的安全方案:新加平臺策略映射,新加LB 對應引流,有效繞過傳統方案的交換機7750 串行處理核心的問題,通過平臺端直接映射策略到設備,網絡側新加LB 將對應映射策略引流.實現WAF 防護控制與承載分離,由此公有云實施測試中,證明了可并發用戶調度實現方案高吞吐的提升.