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

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

云計(jì)算

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

作者簡介

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

需求場景

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

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

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

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

兩層HTTP防火墻

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

SAE HTTP層防火墻組成

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

CC防火墻

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

1，如何實(shí)時(shí)分析海量HTTP日志?

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

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

我們先來看整體CC防火墻架構(gòu)圖：

CC防火墻架構(gòu)圖

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

策略中心

策略分成下面兩個(gè)維度：

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

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

自學(xué)習(xí)：

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

#p#

防火墻的實(shí)現(xiàn)

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

優(yōu)化Nginx

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

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

http/ngx_http_request.c

當(dāng)rc為444時(shí)，直接就把connection關(guān)閉，這對于CC防火墻來說是最理想的結(jié)果，因?yàn)椴恍枰M裝response。

iptables

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

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

nginx防火墻CPU占用率

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

iptables防火墻

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

當(dāng)然，在這里要注意兩點(diǎn)：

• 指定from和to，因?yàn)橹恍枰袛嗥ヅ鋎ata的部分，而不是全部
• 對于string，要匹配HTTP協(xié)議，當(dāng)然這里有精確度問題，這個(gè)要改進(jìn)的話，原生iptables模塊是沒辦法了，可以寫個(gè)iptabels擴(kuò)展解決

drop & reject

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

但是drop帶來一個(gè)附屬問題，就是鏈接不釋放的問題，因?yàn)檎５腍TTP流量監(jiān)測是：

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

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

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

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

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

Netlink-Queue

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

TCP包處理流程

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

當(dāng)Queue起作用后，我們可以監(jiān)控Queue狀態(tài)以獲取服務(wù)狀態(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會不會成為瓶頸呢?是有可能的，因?yàn)閕p queue handler對于一個(gè)協(xié)議簇不能支持多隊(duì)列，如果遇到這種情況，可以考慮采用nfqueue，它可以支持多隊(duì)列，提高處理速度，當(dāng)然這個(gè)可以結(jié)合實(shí)際的場景進(jìn)行。另外，還可以調(diào)整netlink緩存進(jìn)行優(yōu)化。

總結(jié)

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

網(wǎng)站欄目：如何為云平臺打造高性能CC防火墻
網(wǎng)頁路徑：http://www.5511xx.com/article/ccsogep.html