何 丹,張 悅

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

2(中移(蘇州)軟件技術(shù)有限公司 大數(shù)據(jù)產(chǎn)品部,蘇州 215000)

1 引言

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

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

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

圖1 云內(nèi)WAF 防護

2 業(yè)界WAF 方案分析

中國移動在全國布局公有云WAF 應(yīng)用中,發(fā)現(xiàn)業(yè)界方案在流量防護效率、整體引流拓?fù)浞雷o吞吐量表現(xiàn)不足.

2.1 流量監(jiān)測現(xiàn)狀

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

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

首先,接收Flow 步驟和解析Flow 步驟以及歸并計算步驟其處理能力被設(shè)定預(yù)設(shè)固定值.無法動態(tài)自適應(yīng)調(diào)整處理能力.

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

圖2 WAF 流量解析過程

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

2.2 引流拓?fù)洮F(xiàn)狀

一般業(yè)務(wù)的防護系統(tǒng)WAF,如果云網(wǎng)絡(luò)不是SDN網(wǎng)絡(luò),需要通過流量代理的方式在云實現(xiàn)東西向流量的牽引調(diào)度:將防護流量引流到WAF 設(shè)備,代理引流需要在部署機器中設(shè)置一個引流代理,通過代理來將防護流量引入WAF 設(shè)備.通過在部署機器中集中的引流虛擬機接收防護策略,并按照防護策略對流量進行牽引到WAF 設(shè)備的一種拓?fù)?拓?fù)渲蠾AF 的流量牽引為單線單WAF 集群模式.安全控制平臺將相應(yīng)的引流請求發(fā)送至這個引流代理,引流代理根據(jù)虛擬機所在宿主機的位置以及虛擬機當(dāng)前的網(wǎng)絡(luò)情況,下發(fā)相應(yīng)的引流指令,并且完成對應(yīng)的網(wǎng)絡(luò)配置,實現(xiàn)流量牽引.

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

圖3 流量牽引

3 流量監(jiān)測改造

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

3.1 流量統(tǒng)計監(jiān)測

如2.1 業(yè)內(nèi)對流量解析的流程通過固定的格式包來解析所得到的對應(yīng)Flow 流,并采用單步的收集過程,而后進行歸并計算.整體流程的統(tǒng)計監(jiān)測結(jié)果一般如圖4.

圖4 流量統(tǒng)計監(jiān)測

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

3.2 流量解析模塊

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

3.3 改造流量監(jiān)測模型

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

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

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

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

以上3 個處理步驟采用線程,通過動態(tài)化的線程組,進行實現(xiàn)動態(tài)能力自動調(diào)節(jié).

圖5 高性能流量監(jiān)測流程

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

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

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

3.4 自適應(yīng)統(tǒng)計同步算法詳解

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

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

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

圖6 處理模塊之間交互

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

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

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

4 引流拓?fù)涓脑?/h2>

本章解決2.2 業(yè)界的WAF 的引流拓?fù)渫掏铝康偷膯栴}:業(yè)界WAF 引流的SDN 的引流方案為控制策略和流量承載都通過SDN 網(wǎng)關(guān)來處理,SDN 網(wǎng)關(guān)可以通過代碼接口用NETCONF 協(xié)議進行控制配置,比如下發(fā)路由實現(xiàn)流量牽引等,7750 為諾基亞的SDN 網(wǎng)關(guān)設(shè)備,通過7750 進行集中下發(fā)策略和承載引流,使得控制過程和業(yè)務(wù)承載難以真正相互分離.單一的防護資源池?zé)o法并發(fā)的進行流量的牽引.導(dǎo)致防護吞吐量較低.無法充分利用WAF 的防護能力.本章提出WAF引流拓?fù)涓脑?實現(xiàn)SDN 牽引流量承載和控制策略下發(fā)分離,實現(xiàn)WAF 的并發(fā)調(diào)用防護,另一方面通過繞過7750 的SDN 對引流進行并發(fā)操作,提高中國移動WAF 設(shè)備使用效率,提高WAF 系統(tǒng)防護的吞吐能力.

4.1 WAF 的SDN 引流拓?fù)?/h3>

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

圖7 常規(guī)SDN 引流

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

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

2)軟WAF 對流量進行檢測,合規(guī)請求通行,并對源地址進行轉(zhuǎn)換,此過程源目地址為:Nat_WAF——業(yè)務(wù)網(wǎng)絡(luò)服務(wù)器IP.

4)業(yè)務(wù)網(wǎng)絡(luò)服務(wù)器將響應(yīng)內(nèi)容發(fā)送給軟WAF,此過程源目地址為:業(yè)務(wù)網(wǎng)絡(luò)服務(wù)器IP——Nat_WAF.

5)軟WAF 收到業(yè)務(wù)網(wǎng)絡(luò)服務(wù)器的響應(yīng)后,轉(zhuǎn)發(fā)響應(yīng)內(nèi)容給客戶端.

7750 構(gòu)成了業(yè)務(wù)側(cè)的核心,防護策略、流量牽引只能通過7750 串行下達,無法并發(fā)的進行流量的牽引.導(dǎo)致防護吞吐量較低.

4.2 改造WAF 引流拓?fù)?/h3>

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

圖8 SDN 引流改造

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

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

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

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

分析結(jié)構(gòu):此時的拓?fù)浣涌诳刂品雷o策略從上圖的左側(cè)通過安全管理平臺直接進行下發(fā),通過平臺算法映射下發(fā)到WAF 設(shè)備,而承載流量通過有7750 的SDN 網(wǎng)絡(luò)新加LB 并與平臺相同映射,實現(xiàn)策略對應(yīng)的WAF 實現(xiàn)策略與流量承載分離.

總結(jié):1)改造后使得用戶側(cè)防護策略可以繞過7750 直接通過平臺映射到對應(yīng)設(shè)備,使得控制端可以并發(fā)調(diào)用防護.2)7750 不用關(guān)心具體的引流目標(biāo)WAF,只需把流量引入LB,由LB 采取對應(yīng)控制端引流映射WAF,實現(xiàn)對應(yīng)策略的流量牽引.

5 試點實驗效果

本章實驗在中國移動某省公司公有云進行試點測試,分別實驗(采用流量監(jiān)測提升和拓?fù)涓脑焯嵘?高性能WAF 方案比業(yè)界傳統(tǒng)方案的流量監(jiān)測防護效率和流量吞吐量.

5.1 實驗流量監(jiān)測效率

測試環(huán)境1 搭建:WAF 流量檢測端與流量業(yè)務(wù)發(fā)送端直連,對流量檢測端進實驗測試對比分析,對象為1:高性能WAF 方案和2:傳統(tǒng)WAF 防護方案.測試模型如圖9.

圖9 測試模型

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

1 和2 對象測試結(jié)果如圖10.

圖10 流量監(jiān)測效率對比

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

實驗1 結(jié)果分析:

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

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

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

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

圖11 防護吞吐量對比

5.2 實驗防護吞吐量

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

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

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

實驗2 結(jié)果分析:

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

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

3)結(jié)合1、2 得到采用高性能并發(fā)拓?fù)涞母咝阅艿腤AF 方案,可以實現(xiàn)WAF 流量牽引的并發(fā)調(diào)度,在第一個調(diào)度啟動周期后就可以實現(xiàn)并發(fā)調(diào)度3 臺主機的并發(fā)流量防護,達到30 mb 左右,因而高性能WAF方案的實現(xiàn)了無任務(wù)排隊的并發(fā)高吞吐量防護.

6 總結(jié)

通過改造流量監(jiān)測方案在流量監(jiān)測改造上設(shè)計的處理步驟自適應(yīng)機制算法,在公有云實施測試中有效實現(xiàn)了下游網(wǎng)絡(luò)處理能力自適應(yīng)匹配,減少了監(jiān)測流量的丟包,提高了WAF 流量監(jiān)測效率.

通過改造WAF 防護拓?fù)涞陌踩桨?新加平臺策略映射,新加LB 對應(yīng)引流,有效繞過傳統(tǒng)方案的交換機7750 串行處理核心的問題,通過平臺端直接映射策略到設(shè)備,網(wǎng)絡(luò)側(cè)新加LB 將對應(yīng)映射策略引流.實現(xiàn)WAF 防護控制與承載分離,由此公有云實施測試中,證明了可并發(fā)用戶調(diào)度實現(xiàn)方案高吞吐的提升.