自建CDN防禦DDoS（1）：知己知彼，建設持久防線

本議題是我們在OWASP杭州區2013年歲末年初安全沙龍中進行分享的内容，在此我們對這個議題的整體内容進行了重新歸納梳理，形成了文字版。

在本文中，DDoS的案例與應對經驗均來自于某市場占有率很高的客服系統所遇到的實際場景，分别從成本、效率和具體架構設計（選型、配置、優化等）角度來分析通過自建CDN來應對不同類型的DDoS攻擊。

客服系統的主要業務是提供基于網頁的實時動态的文字聊天，主要應用在各類網絡商品銷售、網站線上客服等領域，總使用者數58萬，同時線上活躍的使用者約12萬/天。

這些應用領域通常行業之間的競争比較激烈，其中包括線上下無法名正言順的灰色+暴利産業，導緻競争對手之間經常發動DDoS惡意攻擊。但營銷網站往往是單面加速，加上推廣時效性很強，很難被徹底打擊，于是一些自作聰明的黑客通過攻擊網站的線上客服系統，導緻網站無法跟訪客溝通，不能交易，進而達到惡意攻擊的目的。是以客服系統這個原本有助于網站營銷的工具反而成了被攻擊的主要對象，雖然傷得委屈，但也不得不面對挑戰。

我們遭遇的DDoS攻擊類型包括：延緩性的CC攻擊和緻命的大流量攻擊。下面将對兩種攻擊方式的攻擊特點、防禦思路和我們用過的一些防禦方案進行簡單的介紹。

攻擊者借助網絡上提供的大量代理伺服器IP，利用攻擊軟體，生成指向受害主機的合法請求。

這類攻擊對攻擊者來說成本低，而且網上現成的軟體多，攻擊的風格相對比較”溫柔謹慎”，其目的是通過逐漸增多的垃圾請求，消耗伺服器的正常應用開銷如CPU,記憶體,網卡壓力，甚至是網絡擁堵，然後請求無響應，無出口流量，導緻網站變慢，達到網站無法通路的目的。

對于這類攻擊，有兩個漏洞特點可以被我們利用，進而阻止這類惡意的CC攻擊，關鍵是響應一定要快。

第一個特征，由于是人為生成了大量的非法請求，引發網絡的incoming流量會異常增大（正常情況下，incoming流量小，outgoing流量大）；第二個特征，攻擊力度有一個漸增過程，我們要充分利用這個寶貴的時間，讓機器第一時間智能的做出反應，調用日志分析腳本做決策，加以防禦或者引流。

具體的方法有多種，這裡隻列舉我們所使用的兩種：

使用監控軟體的流量監控圖來觸發日志分析腳本，如圖所示（zabbix為例）：

利用bash腳本來統計incoming流量，發現異常時，調用相應日志分析腳本，實作阻擊。

過濾腳本實作原理就是在伺服器上啟動日志分析機制，在第一時間找出異常的IP、Agent，URL或者其它特征碼，從核心層利用iptables對惡意IP進行過濾，在應用層上利用nginx的http關鍵詞進行過濾，直接傳回badcode 444進行攔截。

無論是從核心級别還是應用級别，對伺服器本身的CPU和記憶體的依賴度高，如iptables的過濾本身對伺服器的CPU壓力很大，在阻止IP超過15K個，伺服器基本不可用了；Nginx在阻止HTTP請求時，由于nginx會給每個http請求配置設定記憶體和處理鍊規則，記憶體資源耗盡；随着流量的不斷增大和攻擊時間的持續，網卡壓力也大，資源最終被耗盡。

是以，這個方案治标不治本。

這種攻擊通常以tcp syn，icmp和UDP（尤其是UDP包，單UDP的資料包可以很大）方式為主。客服系統遭遇到的最大的一次為16G的攻擊流量，整個機房都被影響到。攻擊者通常控制大量殭屍電腦或者直接勾結IDC裡的伺服器和帶寬資源，對目标進行流量打擊。此時流量會快速占滿伺服器的網絡帶寬，導緻無法響應任何使用者請求。

這類攻擊需要購買大量帶寬資源，對于攻擊方來說，成本挺高，但是下手“快狠準”，目的是讓網站在短時間内徹底無響應。

由于這類攻擊會引起流量陡增，IDC裡的流量監控裝置也會很明顯的察覺到這個現象。IDC通常采取的措施一般是丢車保帥，直接将這個被攻擊的IP拉黑名單甚至直接拔線，讓攻擊對象自殺。這對本應該需要幫助的客戶無疑是落井下石，雪上加霜。

應付此類流量攻擊的防禦方式有：

架設硬防火牆

租用高防節點

租用CDN分散目标流量

架設硬防火牆：市面上2G硬防單價在10W左右，叢集防禦代價更大，雖然硬體級的防禦性能較高，但面對流量洪水也是杯水車薪，且副作用也不容小觑。

租用高防節點：高防節點有防禦帶寬，防禦流量，共享獨享區分，各個套餐的組合價格相差很大，分流政策也不同，超過高防承諾的流量後，防禦失效或者再加錢，但都有性能損耗和副作用。

租用CDN分散目标流量：市面上的CDN提供商都是以流量為收費标準，這對于經常遭受流量攻擊的網站來說，反而要為攻擊流量買單，這着實讓人哭笑不得。

綜上所述，我們無論做哪個抉擇都很痛苦。

我們跟發起攻擊的人有過長達近一年的交流，目前了解到這是一個非常完整的産業鍊（上遊人員早已身居海外，遠端遙控指揮行動，根本無法查處），他們手上控制了大量的攻擊資源，并且攻擊資源本身就來自于IDC。攻擊者為了快速牟利，本身也喜歡和推薦這種直接了當的方式來對目标進行打擊，在發動攻擊時，他們能夠調集到多個IDC的帶寬資源來對目标打擊（這一現象也折射出了目前國内不規範的IDC管理）。

從這一角度來看，被打擊方永遠都處于弱勢地位，以勢單力薄的架構和極其有限的資源，根本無法抵抗強大的叢集資源攻擊。

我們一直思考一個問題：如果我們持續投入這些資金，危機過去或者若幹年後，能給我們留下些什麼？是以，我們跳出了單節點防禦和租用CDN的思路，綜合上述方案的優點，轉而自建CDN的方案。

自建CDN的好處有幾個方面：

旁路做流量清洗（痘痘長在别人臉上最好）

資源充分利用：無攻擊的時候，做路由加速，有攻擊的時候，做節點切換（一物多用）

随着投入的資金增加，防禦DDoS攻擊的能力增強（長遠規劃，資金回報率高）

有關自建CDN具體建設的思路如何，成本多少，我們會在系列的下一篇文章中進行介紹。

下面，我們将介紹自建CDN的具體建設規劃，主要從以下幾個方面進行考量：硬體成本、帶寬成本、架構設計、實際部署。

在硬體上，我們選型的需求是在1U的基礎上具有強勁的性能，同時成本效益要高。

我們選擇了（強氧）雙子星伺服器，其硬體規格為：1U機身+支援雙路至強CPU+最大支援48G記憶體+雙千兆網口x2+H3C S1208八口千兆，提供三年質保服務，總價約1.5萬。

單線機房的機房和帶寬資源，由于不需要經過第三方拉線撮合，直接從營運代理商購買，是以選擇餘地大，成本效益高。以租用電信、聯通單線資源為例，每條線獨享100M帶寬，提供8個IP，有些機房自帶硬防，能夠防禦5G-10G流量。

平均費用，每個節點帶寬成本基本在1.6~2.5萬/年。

CDN架構上要充分展現出抗攻擊能力和靈活應變的原則。是以，我們将CDN節點分解成反向代理+緩存加速+攻擊防禦這三個不同層次的功能結構。

反向代理功能（作用：路由加速，隐藏主節點，負載均衡）

緩存加速功能（作用：靜态推送，節省後端主節點帶寬）

攻擊防禦功能（作用：快速解析，比對過濾惡意攻擊）

開源世界裡能夠擔當反向代理及緩存的軟體不少，而且各有優劣。作為架構師，要考慮如何選型，我們從性能、功能、配置上來進行比較篩選。

軟體名稱

性能

功能

過濾規則配置

Squid

不能多核是硬傷，磁盤緩存容量有優勢，性能中等

多，支援ACL角色控制，也支援ICP緩存協定

支援外部規則檔案讀取及熱加載，支援熱啟動

Varnish

多核支援，記憶體緩存，性能強

夠用，不支援叢集，支援後端存活檢查

不支援外部檔案讀取，需要轉義，支援熱啟動

Nginx

多核支援，支援代理插件，性能較強

多，通過插件可以充當多角色伺服器

ATS

多核支援，磁盤/記憶體緩存，性能強

夠用，支援插件開發，也支援ICP協定

支援外部規則檔案讀取及熱加載，支援熱啟動，但缺乏文檔

HAProxy

多核支援，無緩存，HTTP頭支援文法操作，性能強

少，隻專注HTTP頭部解析和轉發功能，支援ACL角色控制，支援後端存活檢查

支援外部規則檔案讀取及熱加載，支援熱啟動，支援會話粘滞和長連接配接

我們對這三層功能結構分别進行了測試調優及生産線的實踐檢驗，從以下方面評估：

HTTP防禦性能：HAProxy在應對大流量CC攻擊時，做正則比對及頭部過濾時，CPU消耗隻占10%~20%。其它軟體均狂占CPU資源約90%以上，容易成瓶頸導緻整個系統無響應。

反向代理性能：單純轉發效率以記憶體緩存型的Varnish性能最強，ATS和Nginx次之，考慮大容量緩存因素，ATS也是個不錯的選擇，但文檔缺乏，需要持續關注。Nginx是專門針對C10K的産物，性能不錯，配合衆多插件，改造性很強。

過濾規則的可配置性：HAProxy，ATS，Squid均支援規則檔案讀取、ACL定制和熱加載、熱啟動。Nginx則不支援外部檔案正則比對，略差一點，但可塑性強。

是以，綜合上述考慮，最終我們采用的架構是HAProxy+Varnish/ATS/Nginx的組合，即防禦型反向代理緩存方案，功能角色如下：

前面由HAProxy全力負責動靜資源分離，實作會話粘滞，節點負載均衡，故障轉移，遇到危急時承擔基于Http協定的CC類型攻擊防禦。

後面為可插拔替換的反向代理緩存引擎：根據生産線上的實際應用場景及緩存對象的容量來決定使用記憶體型的varnish或者是磁盤型的ats，如果需要定制功能很強（防盜鍊）的反向代理如Nginx+plugins。

這個組合最大的特點是：

支援外部過濾規則的讀取，尤其是關鍵字元串無需轉義，可直接追加到檔案中。

支援配置檔案熱加載生效，都支援reload，服務平滑生效。

可插拔式的緩存元件靈活應對各種業務需求。

部署簡單，節點失效/生效切換友善。

LVS缺席：為什麼這裡沒有提及LVS，因為LVS是個重量級、高效穩定的四層轉發，不能作七層HTTP協定的識别，但完全可以架設在七層之前。是以，LVS的使用并不會影響網絡結構，後續仍然可以想上就上，隻是前提要兼顧到LVS的單點故障。

最終我們在主節點周圍一共部署了8個CDN節點（節點數量根據自身公司實力及實際生産環境要求而靈活調整，此數字僅作參考），這些節點又按照地域劃分成了四個大區：北方（以山東，河北為主）、西南（以四川為主）、華東（以甯波，嘉興為主） 華南（以福建，湖南為主 ）兼顧全國各個省份。

8個單線加速節點，每個節點100Mx8，8台雙子星伺服器，總共投資約30W（後續費用隻考慮帶寬支出，約15W/年），我們應急撥款為10W，每個月CDN預算為2W。

項目進度安排：

1～4個月抓進度：特點是快速部點。這裡有個訣竅，前期可以先跟IDC按月或者季度簽約，然後通過監控看連續的節點品質，如果節點品質不佳，更換提供商，這樣損失不會太大，如果節點品質好，就半年付或者年付，這樣就可以保證品質和成本效益最高；

5～8個月為完善期：根據預算，有節奏的加點，加帶寬，保證帶寬的備援度；

8個月以後為穩定期：根據實際情況保證節點的最大可用性，同時也提升了整體防禦能力。

開啟HAProxy的httplog功能，記錄日志。

HAProxy的配置政策：

Varnish的配置政策：

節點各自承擔相應的日志記錄，分析日志的系統開銷，發現異常請求後直接在haproxy前端做ACL規則 過濾，是以，攻擊壓力不會傳遞給後端伺服器，保證後端安全。

節點受到的攻擊流量過大，機房可以拉黑IP或者引流，後端智能DNS會自動把這個節點剔除，後續請求不要通過此節點。

在本系列的下一篇文章中，我們會介紹這個CDN架構的一些後續改進工作，包括智能DNS、大規模日志分析、利用OpenCDN改善背景管理等。

張磊，來自杭州谷歌開發者社群。專注于資訊安全技術領域，曾主導多項銀行/證券行業網站安全測試和入侵驗證分析項目，為四大銀行提供安全防護技術支援。目前創業做網際網路安全防護