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