上周，我們的網站遭到了一次DDoS攻擊。雖然我對DDoS的防御還是比較了解，但是真正遇到時依然打了我個措手不及。DDoS防御是一件比較繁瑣的事，面對各種不同類型的攻擊，防御方式也不盡相同。對於攻擊來的太快量也很大這種時，在自身環境下做調整已經無法抵抗攻擊。為了緩解網站壓力，在嘗試了其他方式后最終還是選擇切換到了知道創宇的高防產品。過程中也遇到了很多問題，但是為以后的DDoS防御留下的很多經驗。所以寫下這篇文章，與大家分享。
這次DDoS攻擊的類型是CC攻擊，CC攻擊是目前應用層攻擊的主要手段之一，只需要借助代理服務器生成指向目標系統的合法請求，就能實現偽裝和DDoS。
其實我們都有這樣的體驗，訪問一個靜態頁面，即使人多也不需要太長時間，但如果在高峰期訪問論壇、貼吧等，那就很慢了，因為服務器系統需要到數據庫中判斷訪問者是否有讀帖、發言等權限。訪問的人越多，論壇的頁面越多，數據庫壓力就越大，被訪問的頻率也越高，占用的系統資源也就相當的大。CC攻擊就充分利用了這個特點，模擬多個正常用戶不停地訪問如論壇這些需要大量數據操作的頁面，造成服務器資源的浪費。
當時我們發現服務器的CPU長時間處於100%的狀態，永遠都有處理不完的請求，網絡擁塞，正常訪問被中止。但是由於CC攻擊技術性含量高，我們又無法見到真實源IP，也見不到特別大的異常流量，但服務器就是無法進行正常連接。最后才確定，這些其實都是CC攻擊的典型特征。
CC攻擊之所以會選擇代理服務器是因為代理可以有效地隱藏自己的身份，也可以繞開防火牆，因為基本上所有的防火牆都會檢測並發的TCP/IP連接數目，超過一定數目一定頻率就會被認為是Connection-Flood。當然也可以使用肉雞來發動CC攻擊，攻擊者使用CC攻擊軟件控制大量肉雞發動攻擊，肉雞可以模擬正常用戶訪問網站的請求偽造成合法數據包，相比前者來說更難防御。
CC攻擊是針對Web服務在第七層協議發起的攻擊，在越上層協議上發動DDoS攻擊越難以防御，上層協議與業務關聯愈加緊密，防御系統面臨的情況也會更復雜。比如CC攻擊中最重要的方式之一HTTP Flood，不僅會直接導致被攻擊的Web前端響應緩慢，對承載的業務造成致命的影響，還可能會引起連鎖反應，間接攻擊到后端的Java等業務層邏輯以及更后端的數據庫服務。真的非常的扎心！后來知道創宇的工程師告訴我們，由於CC攻擊成本低、威力大，80%的DDoS攻擊都是CC攻擊。而攻擊造成的后果就是：帶寬資源嚴重被消耗，網站癱瘓；CPU、內存利用率飆升，主機癱瘓；瞬間快速打擊，無法快速響應。
那我們是如何一步一步解決的？其實在遇到攻擊時，我們有仔細考慮過很多方案，是選擇高防機房、機房流量清洗還是雲防御？
遭到攻擊的第一刻，我們首先想到的是用機房進行流量遷移。網上也有很多過來人推薦這種辦法。確實，這種辦法能快速的響應，面對小流量的攻擊時價錢合理同事也十分有效。但問題是，攻擊者一直孜孜不倦，流量越打越大，我們花出去的錢也越來越多…無奈之下我們只能轉向考慮高防，高防的優勢還是很明顯，配置簡單接入方便，能很快見效，合理的套餐選擇使得攻擊大時價格能低於機房清洗。在選擇高防產品時我們對阿里雲、騰訊雲和知道創宇三家進行了評估。三家實力都很雄厚，價格阿里雲>騰訊雲>知道創宇，但也就幾百的差距，沒什么影響。最后選擇知道創宇的主要原因是，我們這次遭遇到的攻擊也是以CC為主，他們防御CC的能力確實很牛，所以…
最后一點點經驗給到大家：遇到1G以下的攻擊，使用防火牆就可以搞定（或者使用一些免費的雲防御產品）；流量1G—10G時可以選擇機房進行流量遷移和清洗；大於10G時使用高防CDN（雲防御）是相對最靠譜並且價錢最能接受的。由於攻防資源和成本的天平嚴重傾斜，讓攻擊更加肆無忌憚。只有做好充分的准備，在威脅來臨的時候才不至於亂了陣腳。因此，平時就對網絡架構進行優化顯得十分的必要，負載均衡方案也能大大提高應對DDoS攻擊的能力。
希望這點經驗能幫到大家，歡迎留言交流。