如何為云平臺(tái)打造高性能CC防火墻
作者簡(jiǎn)介
叢磊 ，SAE總負(fù)責(zé)人 SAE創(chuàng)始人，2006年加入新浪公司，2008年起開(kāi)始帶領(lǐng)技術(shù)團(tuán)隊(duì)從事云計(jì)算方面的研究和開(kāi)發(fā)，2009年作為技術(shù)經(jīng)理主導(dǎo)開(kāi)發(fā)了國(guó)內(nèi)首個(gè)公有云Sina App Engine。經(jīng)過(guò)數(shù)年的努力，SAE已經(jīng)擁有數(shù)十萬(wàn)開(kāi)發(fā)者，成為國(guó)內(nèi)云計(jì)算數(shù)一數(shù)二的PaaS平臺(tái)。作為國(guó)內(nèi)最早研究云計(jì)算的一線工程師，叢磊具有豐富開(kāi)發(fā)和設(shè)計(jì)經(jīng)驗(yàn)，并且擁有兩項(xiàng)算法專利。目前，叢磊負(fù)責(zé)整個(gè)新浪公有云計(jì)算業(yè)務(wù)，同時(shí)擔(dān)任可信云認(rèn)證的評(píng)審專家。
需求場(chǎng)景
作為公有云計(jì)算平臺(tái)，SAE長(zhǎng)期以來(lái)一直飽受各種攻擊，這里面涉及各種類型，包括Syn-flood、UDP-floold、DNS/NTP反射、TCP flag攻擊等，當(dāng)然這里面最常見(jiàn)還是基于HTTP協(xié)議的CC攻擊，因?yàn)槠邢?，所以今天先不介紹TCP/IP防火墻，集中在HTTP層面。
我們可以把正常的HTTP訪問(wèn)分為：
HTTP訪問(wèn)=正常訪問(wèn)+抓站+攻擊
這三類行為有明顯的區(qū)分特征，主要體現(xiàn)在頻率和特征上，比如抓站的目的是抓取信息，而不是讓你網(wǎng)站502，而攻擊往往是要把網(wǎng)站Rank打下來(lái)，直接打到用戶訪問(wèn)不了。而這三類行為又沒(méi)有特別清晰的界限，比如何種訪問(wèn)叫正常抓站?抓到什么程度叫惡意抓站?這些定義往往是跟用戶業(yè)務(wù)行為相關(guān)，從云計(jì)算平臺(tái)的角度界定起來(lái)有難度。舉個(gè)例子，內(nèi)推網(wǎng)是SAE上的一個(gè)HR招聘網(wǎng)站，每天有上千萬(wàn)的訪問(wèn)，從內(nèi)推的角度肯定希望各大搜索引擎能夠合理的抓取/索引，擴(kuò)大信息出口，但又不希望同行抓取，保護(hù)有價(jià)值的內(nèi)容，但這個(gè)度是跟業(yè)務(wù)相關(guān)的，可能在業(yè)務(wù)初期可以松點(diǎn)，業(yè)務(wù)起來(lái)后可以嚴(yán)一點(diǎn)。
兩層HTTP防火墻
從云計(jì)算平臺(tái)，無(wú)法幫用戶設(shè)定這些跟業(yè)務(wù)緊密相關(guān)的參數(shù)，只能把這個(gè)關(guān)交給用戶自身，這也就形成了“應(yīng)用防火墻”。但從云計(jì)算平臺(tái)角度，又有義務(wù)幫用戶擋住惡意的CC攻擊，于是，SAE把這兩類需求組成了兩個(gè)產(chǎn)品：
SAE HTTP層防火墻組成
“應(yīng)用防火墻”，用戶可以從SAE操作面板看到，應(yīng)用防火墻的難點(diǎn)在于充分自定義，包括觸發(fā)閾值后的行為，這部分SAE近期將進(jìn)行版本升級(jí)，功能將會(huì)更強(qiáng)大，今天先重點(diǎn)說(shuō)“CC防火墻”。
CC防火墻
既然CC防火墻的定位是防護(hù)惡意HTTP攻擊，那么需要解決的環(huán)節(jié)有：
1，如何實(shí)時(shí)分析海量HTTP日志?
1，從日志中，如何發(fā)現(xiàn)攻擊?用什么策略判斷是攻擊?
2，斷定是攻擊后，用什么辦法攔住后續(xù)請(qǐng)求?
我們先來(lái)看整體CC防火墻架構(gòu)圖：
CC防火墻架構(gòu)圖
每天SAE產(chǎn)生上10億的請(qǐng)求，這些請(qǐng)求都會(huì)經(jīng)過(guò)CC防火墻，由日志重定向系統(tǒng)發(fā)送到Storm日志分發(fā)系統(tǒng)，而策略中心會(huì)下發(fā)策略，觸發(fā)策略的IP和應(yīng)用會(huì)由trigger反饋到CC防火墻上的agent，并最終更新到CC防火墻的內(nèi)存里。
策略中心
策略分成下面兩個(gè)維度：
- 首先確定哪些應(yīng)用可能被攻擊(當(dāng)前PV/IP、歷史PV/IP)，這里面需要降噪處理，否則有些業(yè)務(wù)突然正常的流量突增(秒殺)可能收到影響
- 針對(duì)A篩選出來(lái)的可能被攻擊的應(yīng)用，分析其IP行為，這里分為兩步：
- 將IP按行為進(jìn)行分組，行為類似的IP為一組，組規(guī)模越大的可疑性越大(動(dòng)用的資源更多)
- 針對(duì)群組IP分析，主要依靠 Feq(Request)/Num(URI)，可疑性與頻率成正比，而與訪問(wèn)地址的離散度成反比
自學(xué)習(xí)：
任何規(guī)則都會(huì)存在誤殺，所以必要的自學(xué)習(xí)是必要的，系統(tǒng)會(huì)跟實(shí)際情況通過(guò)梯度下降算法調(diào)整策略參數(shù)的最優(yōu)點(diǎn)。另外，對(duì)于機(jī)器學(xué)習(xí)，準(zhǔn)確率和召回率是一對(duì)矛盾體，針對(duì)我們遇到的場(chǎng)景，我們的所有參數(shù)學(xué)習(xí)都偏向準(zhǔn)確率，因?yàn)檎倩芈士梢杂蓱?yīng)用防火墻做補(bǔ)充，從我們線上運(yùn)行的實(shí)際情況看，準(zhǔn)確率為100%，目前沒(méi)有誤報(bào)。
#p#
防火墻的實(shí)現(xiàn)
防火墻本身沒(méi)有用任何商用產(chǎn)品，完全是基于傳統(tǒng)Linux服務(wù)器，最原始的CC防火墻是基于Nginx做的，針對(duì)觸發(fā)規(guī)則的IP返回403(NGX_HTTP_FORBIDDEN)，但經(jīng)過(guò)我們實(shí)驗(yàn)，這樣在請(qǐng)求量大的時(shí)候會(huì)有性能問(wèn)題，主要是消耗CPU，容易在帶寬沒(méi)有吃滿的把CPU跑滿，這個(gè)問(wèn)題后來(lái)我們發(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后面的輸出，換句話說(shuō)，要比403等返回節(jié)約大量CPU，看這段Nginx代碼：
http/ngx_http_request.c
當(dāng)rc為444時(shí)，直接就把connection關(guān)閉，這對(duì)于CC防火墻來(lái)說(shuō)是最理想的結(jié)果，因?yàn)椴恍枰M裝response。
iptables
Nginx 444的性能已經(jīng)有了很大提升，但離我們的期望還有些距離，那么還能不能優(yōu)化呢?我們想到了iptable extension string，可以根據(jù)sk_buff的data的特征進(jìn)行過(guò)濾，那么效果怎么樣呢?
我們做一個(gè)實(shí)驗(yàn)，以相同的10000并發(fā)壓測(cè)一個(gè)靜態(tài)URL 100萬(wàn)次，在Nginx防火墻上，表現(xiàn)為：
nginx防火墻CPU占用率
我們換成iptabels string防火墻，表現(xiàn)為：
iptables防火墻
看到差距了嗎，非常大!!!同樣的壓縮指標(biāo)在iptables面前簡(jiǎn)直不算什么，原因也很簡(jiǎn)單，就是直接在netdev層根據(jù)sk_buff的data段分析，無(wú)需進(jìn)行應(yīng)用層協(xié)議解析，所以才會(huì)有如此巨大的性能提升。那么kmp和bm算法有區(qū)別嗎?經(jīng)過(guò)我們實(shí)驗(yàn)，在測(cè)試場(chǎng)景上區(qū)別微乎其微。
當(dāng)然，在這里要注意兩點(diǎn)：
- 指定from和to，因?yàn)橹恍枰袛嗥ヅ鋎ata的部分，而不是全部
- 對(duì)于string，要匹配HTTP協(xié)議，當(dāng)然這里有精確度問(wèn)題，這個(gè)要改進(jìn)的話，原生iptables模塊是沒(méi)辦法了，可以寫(xiě)個(gè)iptabels擴(kuò)展解決
drop & reject
在我們Linux系統(tǒng)團(tuán)隊(duì)具體實(shí)施時(shí)，又遇到一個(gè)有趣的問(wèn)題，就是當(dāng)iptables匹配這個(gè)規(guī)則后，執(zhí)行的動(dòng)作，我們有兩個(gè)選擇drop和reject，drop故名思議就是丟包，但這樣會(huì)觸發(fā)TCP層的重試，相當(dāng)于deley每次HTTP攻擊的時(shí)間，這是符合我們的預(yù)期的，因?yàn)樵黾恿斯粽叩臅r(shí)間成本。再來(lái)看reject，iptables user層支持大體上兩種回報(bào)，一種是ICMP的控制包，一種是TCP層的reset包，這兩種包在攻擊方都會(huì)引起連接中斷，從而可以立即發(fā)起下一個(gè)攻擊請(qǐng)求，所以顯然drop是正確選擇。
但是drop帶來(lái)一個(gè)附屬問(wèn)題，就是鏈接不釋放的問(wèn)題，因?yàn)檎５腍TTP流量監(jiān)測(cè)是：
step1：C<=>S建立三次握手連接
step2：C發(fā)起HTTP請(qǐng)求
step3：S分析數(shù)據(jù)包，匹配規(guī)則后丟棄
step4：C持續(xù)重發(fā)，直到重傳定時(shí)器判斷超時(shí)
在這里有一個(gè)問(wèn)題，就是當(dāng)drop后，S端的connection是還在的，也就是說(shuō)，這時(shí)候你在S端利用netstat、ss類似的工具查看，可以發(fā)現(xiàn)ESTABLISHED連接存在，這樣雖然攻擊者的請(qǐng)求時(shí)間變長(zhǎng)了，后續(xù)的包進(jìn)不來(lái)了，但是會(huì)耗費(fèi)大量的connection，從而占用大量?jī)?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會(huì)不會(huì)成為瓶頸呢?是有可能的，因?yàn)閕p queue handler對(duì)于一個(gè)協(xié)議簇不能支持多隊(duì)列，如果遇到這種情況，可以考慮采用nfqueue，它可以支持多隊(duì)列，提高處理速度，當(dāng)然這個(gè)可以結(jié)合實(shí)際的場(chǎng)景進(jìn)行。另外，還可以調(diào)整netlink緩存進(jìn)行優(yōu)化。
總結(jié)
SAE利用CC防火墻結(jié)合應(yīng)用防火墻，有效的保護(hù)了用戶的HTTP請(qǐng)求，當(dāng)然目前這套系統(tǒng)還存在著不足，包括Storm計(jì)算能力、應(yīng)用防火墻的自定義性不足、應(yīng)用防火墻重定向等方面，這也是我們后面的工作方向。
