如何為云平臺打造高性能CC防火墻

作者：叢磊 2015-11-23 09:38:03

云計算

云安全 作為公有云計算平臺，SAE長期以來一直飽受各種攻擊，這里面涉及各種類型，包括Syn-flood、UDP-floold、DNS/NTP反射、TCP flag攻擊等，當然這里面最常見還是基于HTTP協(xié)議的CC攻擊，因為篇幅有限，所以今天先不介紹TCP/IP防火墻，集中在HTTP層面。

作者簡介

叢磊，SAE總負責人 SAE創(chuàng)始人，2006年加入新浪公司，2008年起開始帶領技術團隊從事云計算方面的研究和開發(fā)，2009年作為技術經(jīng)理主導開發(fā)了國內(nèi)首個公有云Sina App Engine。經(jīng)過數(shù)年的努力，SAE已經(jīng)擁有數(shù)十萬開發(fā)者，成為國內(nèi)云計算數(shù)一數(shù)二的PaaS平臺。作為國內(nèi)最早研究云計算的一線工程師，叢磊具有豐富開發(fā)和設計經(jīng)驗，并且擁有兩項算法專利。目前，叢磊負責整個新浪公有云計算業(yè)務，同時擔任可信云認證的評審專家。

需求場景

作為公有云計算平臺，SAE長期以來一直飽受各種攻擊，這里面涉及各種類型，包括Syn-flood、UDP-floold、DNS/NTP反射、TCP flag攻擊等，當然這里面最常見還是基于HTTP協(xié)議的CC攻擊，因為篇幅有限，所以今天先不介紹TCP/IP防火墻，集中在HTTP層面。

我們可以把正常的HTTP訪問分為：

HTTP訪問=正常訪問+抓站+攻擊

這三類行為有明顯的區(qū)分特征，主要體現(xiàn)在頻率和特征上，比如抓站的目的是抓取信息，而不是讓你網(wǎng)站502，而攻擊往往是要把網(wǎng)站Rank打下來，直接打到用戶訪問不了。而這三類行為又沒有特別清晰的界限，比如何種訪問叫正常抓站?抓到什么程度叫惡意抓站?這些定義往往是跟用戶業(yè)務行為相關，從云計算平臺的角度界定起來有難度。舉個例子，內(nèi)推網(wǎng)是SAE上的一個HR招聘網(wǎng)站，每天有上千萬的訪問，從內(nèi)推的角度肯定希望各大搜索引擎能夠合理的抓取/索引，擴大信息出口，但又不希望同行抓取，保護有價值的內(nèi)容，但這個度是跟業(yè)務相關的，可能在業(yè)務初期可以松點，業(yè)務起來后可以嚴一點。

兩層HTTP防火墻

從云計算平臺，無法幫用戶設定這些跟業(yè)務緊密相關的參數(shù)，只能把這個關交給用戶自身，這也就形成了“應用防火墻”。但從云計算平臺角度，又有義務幫用戶擋住惡意的CC攻擊，于是，SAE把這兩類需求組成了兩個產(chǎn)品：

SAE HTTP層防火墻組成

“應用防火墻”，用戶可以從SAE操作面板看到，應用防火墻的難點在于充分自定義，包括觸發(fā)閾值后的行為，這部分SAE近期將進行版本升級，功能將會更強大，今天先重點說“CC防火墻”。

CC防火墻

既然CC防火墻的定位是防護惡意HTTP攻擊，那么需要解決的環(huán)節(jié)有：

1，如何實時分析海量HTTP日志?

1，從日志中，如何發(fā)現(xiàn)攻擊?用什么策略判斷是攻擊?

2，斷定是攻擊后，用什么辦法攔住后續(xù)請求?

我們先來看整體CC防火墻架構圖：

CC防火墻架構圖

每天SAE產(chǎn)生上10億的請求，這些請求都會經(jīng)過CC防火墻，由日志重定向系統(tǒng)發(fā)送到Storm日志分發(fā)系統(tǒng)，而策略中心會下發(fā)策略，觸發(fā)策略的IP和應用會由trigger反饋到CC防火墻上的agent，并最終更新到CC防火墻的內(nèi)存里。

策略中心

策略分成下面兩個維度：

1. 首先確定哪些應用可能被攻擊(當前PV/IP、歷史PV/IP)，這里面需要降噪處理，否則有些業(yè)務突然正常的流量突增(秒殺)可能收到影響
2. 針對A篩選出來的可能被攻擊的應用，分析其IP行為，這里分為兩步：

• 將IP按行為進行分組，行為類似的IP為一組，組規(guī)模越大的可疑性越大(動用的資源更多)
• 針對群組IP分析，主要依靠 Feq(Request)/Num(URI)，可疑性與頻率成正比，而與訪問地址的離散度成反比

自學習：

任何規(guī)則都會存在誤殺，所以必要的自學習是必要的，系統(tǒng)會跟實際情況通過梯度下降算法調(diào)整策略參數(shù)的最優(yōu)點。另外，對于機器學習，準確率和召回率是一對矛盾體，針對我們遇到的場景，我們的所有參數(shù)學習都偏向準確率，因為召回率可以由應用防火墻做補充，從我們線上運行的實際情況看，準確率為100%，目前沒有誤報。

#p#

防火墻的實現(xiàn)

防火墻本身沒有用任何商用產(chǎn)品，完全是基于傳統(tǒng)Linux服務器，最原始的CC防火墻是基于Nginx做的，針對觸發(fā)規(guī)則的IP返回403(NGX_HTTP_FORBIDDEN)，但經(jīng)過我們實驗，這樣在請求量大的時候會有性能問題，主要是消耗CPU，容易在帶寬沒有吃滿的把CPU跑滿，這個問題后來我們發(fā)現(xiàn)有個辦法優(yōu)化：

優(yōu)化Nginx

不返回403，而直接返回444(NGX_HTTP_CLOSE)

NGX_HTTP_CLOSE是一個Nginx自定義的返回碼，目的是直接關閉鏈接，而不進行write_handle后面的輸出，換句話說，要比403等返回節(jié)約大量CPU，看這段Nginx代碼：

http/ngx_http_request.c

當rc為444時，直接就把connection關閉，這對于CC防火墻來說是最理想的結(jié)果，因為不需要組裝response。

iptables

Nginx 444的性能已經(jīng)有了很大提升，但離我們的期望還有些距離，那么還能不能優(yōu)化呢?我們想到了iptable extension string，可以根據(jù)sk_buff的data的特征進行過濾，那么效果怎么樣呢?

我們做一個實驗，以相同的10000并發(fā)壓測一個靜態(tài)URL 100萬次，在Nginx防火墻上，表現(xiàn)為：

nginx防火墻CPU占用率

我們換成iptabels string防火墻，表現(xiàn)為：

iptables防火墻

看到差距了嗎，非常大!!!同樣的壓縮指標在iptables面前簡直不算什么，原因也很簡單，就是直接在netdev層根據(jù)sk_buff的data段分析，無需進行應用層協(xié)議解析，所以才會有如此巨大的性能提升。那么kmp和bm算法有區(qū)別嗎?經(jīng)過我們實驗，在測試場景上區(qū)別微乎其微。

當然，在這里要注意兩點：

• 指定from和to，因為只需要判斷匹配data的部分，而不是全部
• 對于string，要匹配HTTP協(xié)議，當然這里有精確度問題，這個要改進的話，原生iptables模塊是沒辦法了，可以寫個iptabels擴展解決

drop & reject

在我們Linux系統(tǒng)團隊具體實施時，又遇到一個有趣的問題，就是當iptables匹配這個規(guī)則后，執(zhí)行的動作，我們有兩個選擇drop和reject，drop故名思議就是丟包，但這樣會觸發(fā)TCP層的重試，相當于deley每次HTTP攻擊的時間，這是符合我們的預期的，因為增加了攻擊者的時間成本。再來看reject，iptables user層支持大體上兩種回報，一種是ICMP的控制包，一種是TCP層的reset包，這兩種包在攻擊方都會引起連接中斷，從而可以立即發(fā)起下一個攻擊請求，所以顯然drop是正確選擇。

但是drop帶來一個附屬問題，就是鏈接不釋放的問題，因為正常的HTTP流量監(jiān)測是：

step1：C<=>S建立三次握手連接

step2：C發(fā)起HTTP請求

step3：S分析數(shù)據(jù)包，匹配規(guī)則后丟棄

step4：C持續(xù)重發(fā)，直到重傳定時器判斷超時

在這里有一個問題，就是當drop后，S端的connection是還在的，也就是說，這時候你在S端利用netstat、ss類似的工具查看，可以發(fā)現(xiàn)ESTABLISHED連接存在，這樣雖然攻擊者的請求時間變長了，后續(xù)的包進不來了，但是會耗費大量的connection，從而占用大量內(nèi)核資源，導致系統(tǒng)性能下降。怎么解決呢?

Netlink-Queue

我們的工程師發(fā)現(xiàn)，可以利用ip-queue，處理被規(guī)則匹配的攻擊包，然后修改包為reset包，從而使S端釋放鏈接，事實證明，這個辦法非常有效。

TCP包處理流程

如圖所示，我們所做的只是將攻擊包置reset位，等待用戶層進程處理，處理后，觸發(fā)應用層釋放socket，從而保護了服務端資源。

當Queue起作用后，我們可以監(jiān)控Queue狀態(tài)以獲取服務狀態(tài)，類似：

  
 
 
 
   
  
  
  
[root@dev include]# cat /proc/net/ip_queue 
   
  
  
  
Peer PID          : 7659 
   
  
  
  
Copy mode        : 2 
   
  
  
  
Copy range        : 2048 
   
  
  
  
Queue length      : 0 
   
  
  
  
Queue max. length : 1024 
   
  
  
  
Queue dropped    : 0 
   
  
  
  
Netlink dropped  : 0 
  
 
 

那么Queue會不會成為瓶頸呢?是有可能的，因為ip queue handler對于一個協(xié)議簇不能支持多隊列，如果遇到這種情況，可以考慮采用nfqueue，它可以支持多隊列，提高處理速度，當然這個可以結(jié)合實際的場景進行。另外，還可以調(diào)整netlink緩存進行優(yōu)化。

總結(jié)

SAE利用CC防火墻結(jié)合應用防火墻，有效的保護了用戶的HTTP請求，當然目前這套系統(tǒng)還存在著不足，包括Storm計算能力、應用防火墻的自定義性不足、應用防火墻重定向等方面，這也是我們后面的工作方向。

當前文章：如何為云平臺打造高性能CC防火墻
網(wǎng)頁網(wǎng)址：http://m.5511xx.com/article/ccsogep.html