背景：

網站安全漏洞在被發現後，需要修復，而修復需要時間，有些廠商可能無能力修復，甚至部分網站主可能連是否存在漏洞都無法感知（尤其是攻擊者使用0day的情況下）。或者剛公開的1day漏洞，廠商來不及修復，而眾多黑客已經掌握利用方法四面出擊，防不勝防。這個時候如果有統一集中的網站防護系統（WAF）來防護，則漏洞被利用的風險將大大降低，同時也為漏洞修復爭取時間！

筆者所在公司的業務較多，光域名就成千上萬，同時網路流量巨大，動輒成百上千G。而這些業務部署在數十萬臺伺服器上，管理運維職能又分散在數十個業務部門，安全團隊不能直接的管理運維。在日常的安全管理和對抗中，還會經常性或者突發性的遇到0day需要響應，比如更新檢測引擎的功能和規則，這些都是比較現實的挑戰。

對於WAF的實現，業界知名的網站安全防護產品也各有特色。本文將對主流的WAF架構做一個簡單的介紹，和大家分享下。同時結合筆者所在公司業務的實際情況，採用了一種改進方案進行探索，希望本文能達到拋磚引玉的效果。(不足之處請各位大牛多多指教)  

特別宣告：以下方案無優劣之分，僅有適合不適合業務場景的區別。

業界常見網站安全防護方案

方案A：本機伺服器模組模式

      通過在Apache，IIS等Web伺服器內嵌實現檢測引擎，所有請求的出入流量均先經過檢測引擎的檢測，如果請求無問題則呼叫CGI處理業務邏輯，如果請求發現攻擊特徵，再根據配置進行相應的動作。以此對運行於Web伺服器上的網站進行安全防護。著名的安全開源專案ModSecurity及naxsi防火牆就是此種模式。

優點：

1、 網路結構簡單，只需要部署Web伺服器的安全模組  

挑戰：

1、 維護困難。當有大規模的伺服器叢集時，任何更新都涉及到多臺伺服器。

2、 需要部署操作，在面臨大規模部署時成本較高。

3、 無集中化的資料中心。針對安全事件的分析往往需要有集中式的資料彙總，而此種模式下使用者請求資料分散在各個Web伺服器上。  

方案B：反向代理模式

      使用這種模式的方案需要修改DNS，讓域名解析到反向代理伺服器。當用戶向某個域名發起請求時，請求會先經過反向代理進行檢測，檢測無問題之後再轉發給後端的Web伺服器。這種模式下，反向代理除了能提供Web安全防護之外，還能充當抗DDoS攻擊，內容加速（CDN）等功能。雲安全廠商CloudFlare採用這種模式。

優點：

1、 集中式的流量出入口。可以針對性地進行大資料分析。

2、 部署方便。可多地部署，附帶提供CDN功能。  

挑戰：

1、 動態的額外增加一層。會帶來使用者請求的網路開銷等。

2、 站點和後端Web伺服器較多的話，轉發規則等配置較複雜。

3、 流量都被捕捉，涉及到敏感資料保護問題，可能無法被接受。  

方案C：硬體防護裝置

      這種模式下，硬體防護裝置串在網路鏈路中，所有的流量經過核心交換機引流到防護裝置中，在防護裝置中對請求進行檢測，合法的請求會把流量傳送給Web伺服器。當發現攻擊行為時，會阻斷該請求，後端Web伺服器無感知到任何請求。防護裝置廠商如imperva等使用這種模式。  

優點：

1、 對後端完全透明。  

挑戰：

1、 部署需改變網路架構，額外的硬體採購成本。

2、 如Web伺服器分佈在多個IDC，需在多個IDC進行部署。

3、 流量一直在增加，需考慮大流量處理問題。以及流量自然增長後的升級維護成本。

4、 規則依賴於廠商，無法定製化，不夠靈活。

我們的探索  

筆者所在的公司在不同的場景下，也近似的採納了一種或者多種方案的原型加以改進使用運營。（比如方案C，其實我們也有給力的小夥伴做了很棒的努力，通過自研的方式解決了不少挑戰，以後有機會或許也會和大家分享一些細節）  

今天給大家介紹的，是我們有別於業界常見模型的一種思路：    

方案D：伺服器模組+檢測雲模式

這種模式其實是方案A的增強版，也會在Web伺服器上實現安全模組。不同點在於，安全模組的邏輯非常簡單，只是充當橋樑的作用。檢測雲則承擔著所有的檢測發現任務。當安全模組接收到使用者的請求時，會通過UDP或者TCP的方式，把使用者請求的HTTP文字封裝後，傳送到檢測雲進行檢測。當檢測無問題時，告知安全模組把請求交給CGI處理。當請求中檢測到攻擊特徵時，則檢測雲會告知安全模組阻斷請求。這樣所有的邏輯、策略都在檢測雲端。

我們之所以選擇這個改進方案來實現防護系統，主要是出於以下幾個方面的考慮：  

1、       維護問題

假如使用A方案，當面臨更新時，無法得到及時的響應。同時，由於安全邏輯是嵌入到Web伺服器中的，任何變更都存在影響業務的風險，這是不能容忍的。  

2、       網路架構

如果使用方案B，則需要調動大量的流量，同時需要提供一個超大規模的統一接入叢集。而為了使用者就近訪問提高訪問速度，接入叢集還需要在全國各地均有部署，對於安全團隊來說，成本和維護難度難以想象。

      使用該方案時，需要考慮如下幾個主要的挑戰：  

1、       網路延時

採用把檢測邏輯均放在檢測雲的方式，相對於A來說，會增加一定的網路開銷。不過，如果檢測雲放在內網裡，這個問題就不大，99%的情況下，同城內網傳送和接收一個UDP包只需要1ms。  

2、       效能問題：

由於是把全量流量均交給集中的檢測雲進行檢測，大規模的請求可能會帶來檢測雲效能的問題。這樣在實現的時候就需要設計一個好的後端架構，必須充分考慮到負載均衡，流量排程等問題。  

3、       部署問題：

該方案依然需要業務進行1次部署，可能會涉及到重編譯web伺服器等工作量，有一定的成本。並且當涉及到數千個域名時，問題變的更為複雜。可能需要區分出高危業務來對部署有一個前後順序，並適時的通過一些事件來驅動部署。

最後，我們目前已灰度上線了這套防禦方案，覆蓋重要以及高危的業務站點。目前日均處理量約數百億的規模，且正在快速增長階段。