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