CC攻擊防護有挑戰，那麼加了密的CC攻擊－－HTTPS SSL CC有多難？

12-29

今天阿里雲發2015年DDoS報告，防護住了一次峰值近百萬HTTPS SSL CC攻擊的事件。粗略計算一下，防禦HTTPS CC對系統的消耗大約是HTTP CC的10倍，這意味著95萬的加密CC差不多等同於近千萬的HTTP CC。Google了一下，無論是加了密，還是沒加密的CC，如此大的攻擊流量（即便是相同數量級的攻擊）是沒有的。

從下載的報告中看，防禦加密CC攻擊主要從行為學習、建模上來分析，原文如下：「
1）通常掃描式攻擊會對資源目錄進行不斷遍歷，那麼其訪問不同URL的可能性會非常大，同時獲取到的響應碼也是不確定的，可能會出現大量的非200正常響應碼；
2）在請求方法上，也可能會進行不停的變換嘗試，如GET、POST、OPTION等；
3）針對請求同一URL的參數，會進行不同的替換；
4）集中時間段內，可能會有大量IP訪問同一個固定的URL；
5）會不斷的偽造合法的User-Agent來避免UA規則的特徵查殺。」

我想光有這些學習肯定還是不夠的，還需要加解密的能力，這關係到效率問題，不知道95萬QPS要挑戰多大的offload能力。

總之，很多技術因素，阿里雲沒有透露，這就留下了太多的疑問。呼喚更多的解密！

現在CC攻擊基本和DDOS一樣泛濫了。在防護上，確實有著不小的難度. 一般來說，CC攻擊有一些特徵可以發現，比如肉雞的訪問頻率通常會快於正常的速度，但防禦不能這麼光憑訪問頻率來做粗暴的封禁，因為這裡面涉及到業務本身的特點等等，一不留神就很容易有誤報。目前業界的主流做法一般是cookie驗證、驗證碼提交等等方式。但這種常見防護方法，對付一些老手，已經是應付不來了。

比如一些黑客，會利用WordPress等一些插件的漏洞在一些大的站點A上埋下對目標站點B的訪問，這樣每一台訪問A站點的機器就自動成了肉雞對B發起訪問請求。這種攻擊倒也有解，因為這類的請求可能referer或者UA可能比較固定，站點B可以利用這個特徵做防護過濾。

又比如有一些壞小子，會專門去研究你的業務哪些URL最消耗性能，集中一批肉雞專打這種URL，那這個時候其實可以重點對這些URL做防護。

最難的是利用海量肉雞對站點進行慢速的訪問攻擊。這種攻擊沒有任何攻擊特徵，訪問速度也相對平緩，訪問的URL可能也會比較分散。這時候能應對的，我想就是各家廠商自身平時積累的IP信譽庫以及威脅情報能力了。

CC防護思路目前來看，資源以及多樣的防護演算法，缺一不可。首先你的資源要足夠多，不然一下子打過來，別說對請求做各種分析了，直接就打癱了，這也是決定為什麼我們小老百姓自己做防護不現實的原因。。。誰有那麼多資本去為了可能存在的海量攻擊預備機器資源？其次，CC一直是一個攻防博弈的過程，到目前來看，很難做到全自動化的防護並且還零誤殺，這就要求你有足夠的防護能力能應對各種不同場景下的攻擊，根據特徵選出合適的解法。

從這兩點上來說，感覺也只有阿里雲這種體量的能做到，畢竟有錢買資源又有人才。。。

被騙幾十萬總結出來的Ddos攻擊防護經驗！
2015年09月18日 05:09:30
來源：怪狗

本人從事網路安全行業20年。有15年防ddos攻擊防護經驗。被騙了很多回（都說能防300G，500G，買完就防不住了），本文當然重點給大家說明，ddos攻擊是什麼，中小企業如何防護，用到成本等。

2004年記得是，晚上我帶著螺絲刀，晚上2點去機房維護，有ddos攻擊，被警察當賊了，汗，那時華夏黑客同盟天天有攻擊，遠程連接不上得去機房，機房也不知道ddos是什麼只知道流量大，一句話，你中病毒了。電信通機房惠普大廈機房。

言歸正傳

首先我們說說ddos攻擊方式，記住一句話，這是一個世界級的難題並沒有解決辦法只能緩解

　　DDoS（Distributed Denial of Service，分散式拒絕服務）攻擊的主要目的是讓指定目標無法提供正常服務，甚至從互聯網上消失，是目前最強大、最難防禦的攻擊之一。這是一個世界級的難題並沒有解決辦法只能緩解.

　　按照發起的方式，DDoS可以簡單分為三類。

　　第一類以力取勝，海量數據包從互聯網的各個角落蜂擁而來，堵塞IDC入口，讓各種強大的硬體防禦系統、快速高效的應急流程無用武之地。這種類型的攻擊典型代表是ICMP Flood和UDP Flood，現在已不常見。

　　第二類以巧取勝，靈動而難以察覺，每隔幾分鐘發一個包甚至只需要一個包，就可以讓豪華配置的伺服器不再響應。這類攻擊主要是利用協議或者軟體的漏洞發起，例如Slowloris攻擊、Hash衝突攻擊等，需要特定環境機緣巧合下才能出現。

　　第三類是上述兩種的混合，輕靈渾厚兼而有之，既利用了協議、系統的缺陷，又具備了海量的流量，例如SYN Flood攻擊、DNS Query Flood攻擊，是當前的主流攻擊方式。

本文將一一描述這些最常見、最具代表性攻擊方式，並介紹它們的防禦方案。

SYN Flood

　　SYN Flood是互聯網上最經典的DDoS攻擊方式之一，最早出現於1999年左右，雅虎是當時最著名的受害者。SYN Flood攻擊利用了TCP三次握手的缺陷，能夠以較小代價使目標伺服器無法響應，且難以追查。

標準的TCP三次握手過程如下：

1、客戶端發送一個包含SYN標誌的TCP報文，SYN即同步（Synchronize），同步報文會指明客戶端使用的埠以及TCP連接的初始序號；

2、伺服器在收到客戶端的SYN報文後，將返回一個SYN+ACK（即確認Acknowledgement）的報文，表示客戶端的請求被接受，同時TCP初始序號自動加1；

3、客戶端也返回一個確認報文ACK給伺服器端，同樣TCP序列號被加1。

　　經過這三步，TCP連接就建立完成。TCP協議為了實現可靠傳輸，在三次握手的過程中設置了一些異常處理機制。第三步中如果伺服器沒有收到客戶端的最終ACK確認報文，會一直處於SYN_RECV狀態，將客戶端IP加入等待列表，並重發第二步的SYN+ACK報文。重發一般進行3-5次，大約間隔30秒左右輪詢一次等待列表重試所有客戶端。另一方面，伺服器在自己發出了SYN+ACK報文後，會預分配資源為即將建立的TCP連接儲存信息做準備，這個資源在等待重試期間一直保留。更為重要的是，伺服器資源有限，可以維護的SYN_RECV狀態超過極限後就不再接受新的SYN報文，也就是拒絕新的TCP連接建立。

　　SYN Flood正是利用了上文中TCP協議的設定，達到攻擊的目的。攻擊者偽裝大量的IP地址給伺服器發送SYN報文，由於偽造的IP地址幾乎不可能存在，也就幾乎沒有設備會給伺服器返回任何應答了。因此，伺服器將會維持一個龐大的等待列表，不停地重試發送SYN+ACK報文，同時佔用著大量的資源無法釋放。更為關鍵的是，被攻擊伺服器的SYN_RECV隊列被惡意的數據包佔滿，不再接受新的SYN請求，合法用戶無法完成三次握手建立起TCP連接。也就是說，這個伺服器被SYN Flood拒絕服務了。

對SYN Flood ddos攻擊軟體,有興趣的可以看看

DarkShell軟體使用編程教程+源碼+測試手冊我寫的。

DNS Query Flood

　　作為互聯網最基礎、最核心的服務，DNS自然也是DDoS攻擊的重要目標之一。打垮DNS服務能夠間接打垮一家公司的全部業務，或者打垮一個地區的網路服務。前些時候風頭正盛的黑客組織anonymous也曾經宣布要攻擊全球互聯網的13台根DNS伺服器，不過最終沒有得手。

UDP攻擊是最容易發起海量流量的攻擊手段，而且源IP隨機偽造難以追查。但過濾比較容易，因為大多數IP並不提供UDP服務，直接丟棄UDP流量即可。所以現在純粹的UDP流量攻擊比較少見了，取而代之的是UDP協議承載的DNS Query Flood攻擊。簡單地說，越上層協議上發動的DDoS攻擊越難以防禦，因為協議越上層，與業務關聯越大，防禦系統面臨的情況越複雜。

　　DNS Query Flood就是攻擊者操縱大量傀儡機器，對目標發起海量的域名查詢請求。為了防止基於ACL的過濾，必須提高數據包的隨機性。常用的做法是UDP層隨機偽造源IP地址、隨機偽造源埠等參數。在DNS協議層，隨機偽造查詢ID以及待解析域名。隨機偽造待解析域名除了防止過濾外，還可以降低命中DNS緩存的可能性，儘可能多地消耗DNS伺服器的CPU資源。

關於DNS Query Flood的代碼，我在2011年7月為了測試伺服器性能曾經寫過一份代碼，鏈接是DNS Query Flood攻擊。同樣的，這份代碼人為降低了攻擊性，只做測試用途。

HTTP Flood

　　上文描述的SYN Flood、DNS Query Flood在現階段已經能做到有效防禦了，真正令各大廠商以及互聯網企業頭疼的是HTTP Flood攻擊。HTTP Flood是針對Web服務在第七層協議發起的攻擊。它的巨大危害性主要表現在三個方面：發起方便、過濾困難、影響深遠。

SYN Flood和DNS Query Flood都需要攻擊者以root許可權控制大批量的傀儡機。收集大量root許可權的傀儡機很花費時間和精力，而且在攻擊過程中傀儡機會由於流量異常被管理員發現，攻擊者的資源快速損耗而補充緩慢，導致攻擊強度明顯降低而且不可長期持續。HTTP Flood攻擊則不同，攻擊者並不需要控制大批的傀儡機，取而代之的是通過埠掃描程序在互聯網上尋找匿名的HTTP代理或者SOCKS代理，攻擊者通過匿名代理對攻擊目標發起HTTP請求。匿名代理是一種比較豐富的資源，花幾天時間獲取代理並不是難事，因此攻擊容易發起而且可以長期高強度的持續。

　　另一方面，HTTP Flood攻擊在HTTP層發起，極力模仿正常用戶的網頁請求行為，與網站業務緊密相關，安全廠商很難提供一套通用的且不影響用戶體驗的方案。在一個地方工作得很好的規則，換一個場景可能帶來大量的誤殺。

　　最後，HTTP Flood攻擊會引起嚴重的連鎖反應，不僅僅是直接導致被攻擊的Web前端響應緩慢，還間接攻擊到後端的Java等業務層邏輯以及更後端的資料庫服務，增大它們的壓力，甚至對日誌存儲伺服器都帶來影響。

　　有意思的是，HTTP Flood還有個頗有歷史淵源的昵稱叫做CC攻擊。CC是Challenge Collapsar的縮寫，而Collapsar是國內一家著名安全公司的DDoS防禦設備。從目前的情況來看，不僅僅是Collapsar，所有的硬體防禦設備都還在被挑戰著，風險並未解除。

慢速連接攻擊

　　提起攻擊，第一反應就是海量的流量、海量的報文。但有一種攻擊卻反其道而行之，以慢著稱，以至於有些攻擊目標被打死了都不知道是怎麼死的，這就是慢速連接攻擊，最具代表性的是rsnake發明的Slowloris。　　

　　HTTP協議規定，HTTP Request以

結尾表示客戶端發送結束，服務端開始處理。那麼，如果永遠不發送

會如何？Slowloris就是利用這一點來做DDoS攻擊的。攻擊者在HTTP請求頭中將Connection設置為Keep-Alive，要求Web Server保持TCP連接不要斷開，隨後緩慢地每隔幾分鐘發送一個key-value格式的數據到服務端，如a:b
，導致服務端認為HTTP頭部沒有接收完成而一直等待。如果攻擊者使用多線程或者傀儡機來做同樣的操作，伺服器的Web容器很快就被攻擊者佔滿了TCP連接而不再接受新的請求。

很快的，Slowloris開始出現各種變種。比如POST方法向Web Server提交數據、填充一大大Content-Length但緩慢的一個位元組一個位元組的POST真正數據內容等等。關於Slowloris攻擊，rsnake也給出了一個測試代碼，參見http://ha.ckers.org/slowloris/slowloris.pl。

DDoS攻擊進階

混合攻擊

　　以上介紹了幾種基礎的攻擊手段，其中任意一種都可以用來攻擊網路，甚至擊垮阿里、百度、騰訊這種巨型網站。但這些並不是全部，不同層次的攻擊者能夠發起完全不同的DDoS攻擊，運用之妙，存乎一心。

高級攻擊者從來不會使用單一的手段進行攻擊，而是根據目標環境靈活組合。普通的SYN Flood容易被流量清洗設備通過反向探測、SYN Cookie等技術手段過濾掉，但如果在SYN Flood中混入SYN+ACK數據包，使每一個偽造的SYN數據包都有一個與之對應的偽造的客戶端確認報文，這裡的對應是指源IP地址、源埠、目的IP、目的埠、TCP窗口大小、TTL等都符合同一個主機同一個TCP Flow的特徵，流量清洗設備的反向探測和SYN Cookie性能壓力將會顯著增大。其實SYN數據報文配合其他各種標誌位，都有特殊的攻擊效果，這裡不一一介紹。對DNS Query Flood而言，也有獨特的技巧。

　　首先，DNS可以分為普通DNS和授權域DNS，攻擊普通DNS，IP地址需要隨機偽造，並且指明伺服器要求做遞歸解析；但攻擊授權域DNS，偽造的源IP地址則不應該是純隨機的，而應該是事先收集的全球各地ISP的DNS地址，這樣才能達到最大攻擊效果，使流量清洗設備處於添加IP黑名單還是不添加IP黑名單的尷尬處境。添加會導致大量誤殺，不添加黑名單則每個報文都需要反向探測從而加大性能壓力。

另一方面，前面提到，為了加大清洗設備的壓力不命中緩存而需要隨機化請求的域名，但需要注意的是，待解析域名必須在偽造中帶有一定的規律性，比如說只偽造域名的某一部分而固化一部分，用來突破清洗設備設置的白名單。道理很簡單，騰訊的伺服器可以只解析騰訊的域名，完全隨機的域名可能會直接被丟棄，需要固化。但如果完全固定，也很容易直接被丟棄，因此又需要偽造一部分。

　　其次，對DNS的攻擊不應該只著重於UDP埠，根據DNS協議，TCP埠也是標準服務。在攻擊時，可以UDP和TCP攻擊同時進行。

HTTP Flood的著重點，在於突破前端的cache，通過HTTP頭中的欄位設置直接到達Web Server本身。另外，HTTP Flood對目標的選取也非常關鍵，一般的攻擊者會選擇搜索之類需要做大量數據查詢的頁面作為攻擊目標，這是非常正確的，可以消耗伺服器儘可能多的資源。但這種攻擊容易被清洗設備通過人機識別的方式識別出來，那麼如何解決這個問題？很簡單，盡量選擇正常用戶也通過APP訪問的頁面，一般來說就是各種Web API。正常用戶和惡意流量都是來源於APP，人機差別很小，基本融為一體難以區分。

　　之類的慢速攻擊，是通過巧妙的手段佔住連接不釋放達到攻擊的目的，但這也是雙刃劍，每一個TCP連接既存在於服務端也存在於自身，自身也需要消耗資源維持TCP狀態，因此連接不能保持太多。如果可以解決這一點，攻擊性會得到極大增強，也就是說Slowloris可以通過stateless的方式發動攻擊，在客戶端通過嗅探捕獲TCP的序列號和確認維護TCP連接，系統內核無需關注TCP的各種狀態變遷，一台筆記本即可產生多達65535個TCP連接。

　　前面描述的，都是技術層面的攻擊增強。在人的方面，還可以有一些別的手段。如果SYN Flood發出大量數據包正面強攻，再輔之以Slowloris慢速連接，多少人能夠發現其中的秘密？即使伺服器宕機了也許還只發現了SYN攻擊想去加強TCP層清洗而忽視了應用層的行為。種種攻擊都可以互相配合，達到最大的效果。攻擊時間的選擇，也是一大關鍵，比如說選擇維護人員吃午飯時、維護人員下班堵在路上或者在地鐵里無線上網卡都沒有信號時、目標企業在舉行大規模活動流量飆升時等。

這裡描述的只是純粹的攻擊行為，因此不提供代碼，也不做深入介紹。

來自P2P網路的攻擊

　　前面的攻擊方式，多多少少都需要一些傀儡機，即使是HTTP Flood也需要搜索大量的匿名代理。如果有一種攻擊，只需要發出一些指令，就有機器自動上來執行，才是完美的方案。這種攻擊已經出現了，那就是來自P2P網路的攻擊。

大家都知道，互聯網上的P2P用戶和流量都是一個極為龐大的數字。如果他們都去一個指定的地方下載數據，使成千上萬的真實IP地址連接過來，沒有哪個設備能夠支撐住。拿BT下載來說，偽造一些熱門視頻的種子，發布到搜索引擎，就足以騙到許多用戶和流量了，但這只是基礎攻擊。

高級P2P攻擊，是直接欺騙資源管理伺服器。如迅雷客戶端會把自己發現的資源上傳到資源管理伺服器，然後推送給其他需要下載相同資源的用戶，這樣，一個鏈接就發布出去。通過協議逆向，攻擊者偽造出大批量的熱門資源信息通過資源管理中心分發出去，瞬間就可以傳遍整個P2P網路。更為恐怖的是，這種攻擊是無法停止的，即使是攻擊者自身也無法停止，攻擊一直持續到P2P官方發現問題更新伺服器且下載用戶重啟下載軟體時為止。

　　ChallengeCollapsar的名字源於挑戰國內知名安全廠商綠盟的抗DDOS設備-「黑洞」，通過botnet的傀儡主機或尋找匿名代理伺服器，向目標發起大量真實的http請求，最終消耗掉大量的並發資源，拖慢整個網站甚至徹底拒絕服務。

　　互聯網的架構追求擴展性本質上是為了提高並發能力，各種SQL性能優化措施：消除慢查詢、分表分庫、索引、優化數據結構、限制搜索頻率等本質都是為了解決資源消耗，而CC大有反其道而行之的意味，佔滿伺服器並發連接數，儘可能使請求避開緩存而直接讀資料庫，讀資料庫要找最消耗資源的查詢，最好無法利用索引，每個查詢都全表掃描，這樣就能用最小的攻擊資源起到最大的拒絕服務效果。

　　互聯網產品和服務依靠數據分析來驅動改進和持續運營，所以除了前端的APP、中間件和資料庫這類OLTP系統，後面還有OLAP，從日誌收集，存儲到數據處理和分析的大數據平台，當CC攻擊發生時，不僅OLTP的部分受到了影響，實際上CC會產生大量日誌，直接會對後面的OLAP產生影響，影響包括兩個層面，一個當日的數據統計完全是錯誤的。第二個層面因CC期間訪問日誌劇增也會加大後端數據處理的負擔。

　　CC是目前應用層攻擊的主要手段之一，在防禦上有一些方法，但不能完美解決這個問題。

反射型

　　2004年時DRDOS第一次披露，通過將SYN包的源地址設置為目標地址，然後向大量的

　　真實TCP伺服器發送TCP的SYN包，而這些收到SYN包的TCP server為了完成3次握手把SYN|ACK包「應答」給目標地址，完成了一次「反射」攻擊，攻擊者隱藏了自身，但有個問題是攻擊者製造的流量和目標收到的攻擊流量是1:1，且SYN|ACK包到達目標後馬上被回以RST包，整個攻擊的投資回報率不高。

　　反射型攻擊的本質是利用「質詢-應答」式協議，將質詢包的源地址通過原始套接字偽造設置為目標地址，則應答的「回包」都被發送至目標，如果回包體積比較大或協議支持遞歸效果，攻擊流量會被放大，成為一種高性價比的流量型攻擊。

　　反射型攻擊利用的協議目前包括NTP、Chargen、SSDP、DNS、RPC portmap等等。

流量放大型

以上面提到的DRDOS中常見的SSDP協議為例，攻擊者將Searchtype設置為ALL，搜索所有可用的設備和服務，這種遞歸效果產生的放大倍數是非常大的，攻擊者只需要以較小的偽造源地址的查詢流量就可以製造出幾十甚至上百倍的應答流量發送至目標。

防禦基礎

攻擊流量到底多大，這是一個關鍵問題。攻擊量的大小。用的防護方法不一樣。下面給你講一講，1G之內的防護方式。費用在，&<1萬，每月

　　談到DDoS防禦，首先就是要知道到底遭受了多大的攻擊。這個問題看似簡單，實際上卻有很多不為人知的細節在裡面。

以SYN Flood為例，為了提高發送效率在服務端產生更多的SYN等待隊列，攻擊程序在填充包頭時，IP首部和TCP首部都不填充可選的欄位，因此IP首部長度恰好是20位元組，TCP首部也是20位元組，共40位元組。

對於乙太網來說，最小的包長度數據段必須達到46位元組，而攻擊報文只有40位元組，因此，網卡在發送時，會做一些處理，在TCP首部的末尾，填充6個0來滿足最小包的長度要求。這個時候，整個數據包的長度為14位元組的乙太網頭，20位元組的IP頭，20位元組的TCP頭，再加上因為最小包長度要求而填充的6個位元組的0，一共是60位元組。

但這還沒有結束。乙太網在傳輸數據時，還有CRC檢驗的要求。網卡會在發送數據之前對數據包進行CRC檢驗，將4位元組的CRC值附加到包頭的最後面。這個時候，數據包長度已不再是40位元組，而是變成64位元組了，這就是常說的SYN小包攻擊，數據包結構如下：

到64位元組時，SYN數據包已經填充完成，準備開始傳輸了。攻擊數據包很小，遠遠不夠最大傳輸單元（MTU）的1500位元組，因此不會被分片。那麼這些數據包就像生產流水線上的罐頭一樣，一個包連著一個包緊密地擠在一起傳輸嗎？事實上不是這樣的。

乙太網在傳輸時，還有前導碼（preamble）和幀間距（inter-frame gap）。其中前導碼佔8位元組（byte），即64比特位。前導碼前面的7位元組都是10101010，1和0間隔而成。但第八個位元組就變成了10101011，當主機監測到連續的兩個1時，就知道後面開始是數據了。在網路傳輸時，數據的結構如下：

也就是說，一個本來只有40位元組的SYN包，在網路上傳輸時占的帶寬，其實是84位元組。

有了上面的基礎，現在可以開始計算攻擊流量和網路設備的線速問題了。當只填充IP頭和TCP頭的最小SYN包跑在乙太網絡上時，100Mbit的網路，能支持的最大PPS（Packet Per Second）是100×106 / (8 * (64+8+12)) = 148809，1000Mbit的網路，能支持的最大PPS是1488090。

SYN Flood防禦

前文描述過，SYN Flood攻擊大量消耗伺服器的CPU、內存資源，並佔滿SYN等待隊列。相應的，我們修改內核參數即可有效緩解。主要參數如下：

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_synack_retries = 2

分別為啟用SYN Cookie、設置SYN最大隊列長度以及設置SYN+ACK最大重試次數。

SYN Cookie的作用是緩解伺服器資源壓力。啟用之前，伺服器在接到SYN數據包後，立即分配存儲空間，並隨機化一個數字作為SYN號發送SYN+ACK數據包。然後保存連接的狀態信息等待客戶端確認。啟用SYN Cookie之後，伺服器不再分配存儲空間，而且通過基於時間種子的隨機數演算法設置一個SYN號，替代完全隨機的SYN號。發送完SYN+ACK確認報文之後，清空資源不保存任何狀態信息。直到伺服器接到客戶端的最終ACK包，通過Cookie檢驗演算法鑒定是否與發出去的SYN+ACK報文序列號匹配，匹配則通過完成握手，失敗則丟棄。當然，前文的高級攻擊中有SYN混合ACK的攻擊方法，則是對此種防禦方法的反擊，其中優劣由雙方的硬體配置決定

tcp_max_syn_backlog則是使用伺服器的內存資源，換取更大的等待隊列長度，讓攻擊數據包不至於佔滿所有連接而導致正常用戶無法完成握手。net.ipv4.tcp_synack_retries是降低伺服器SYN+ACK報文重試次數，儘快釋放等待資源。這三種措施與攻擊的三種危害一一對應，完完全全地對症下藥。但這些措施也是雙刃劍，可能消耗伺服器更多的內存資源，甚至影響正常用戶建立TCP連接，需要評估伺服器硬體資源和攻擊大小謹慎設置。

除了定製TCP/IP協議棧之外，還有一種常見做法是TCP首包丟棄方案，利用TCP協議的重傳機制識別正常用戶和攻擊報文。當防禦設備接到一個IP地址的SYN報文後，簡單比對該IP是否存在於白名單中，存在則轉發到後端。如不存在於白名單中，檢查是否是該IP在一定時間段內的首次SYN報文，不是則檢查是否重傳報文，是重傳則轉發並加入白名單，不是則丟棄並加入黑名單。是首次SYN報文則丟棄並等待一段時間以試圖接受該IP的SYN重傳報文，等待超時則判定為攻擊報文加入黑名單。

首包丟棄方案對用戶體驗會略有影響，因為丟棄首包重傳會增大業務的響應時間，有鑒於此發展出了一種更優的TCP Proxy方案。所有的SYN數據報文由清洗設備接受，按照SYN Cookie方案處理。和設備成功建立了TCP三次握手的IP地址被判定為合法用戶加入白名單，由設備偽裝真實客戶端IP地址再與真實伺服器完成三次握手，隨後轉發數據。而指定時間內沒有和設備完成三次握手的IP地址，被判定為惡意IP地址屏蔽一定時間。除了SYN Cookie結合TCP Proxy外，清洗設備還具備多種畸形TCP標誌位數據包探測的能力，通過對SYN報文返回非預期應答測試客戶端反應的方式來鑒別正常訪問和惡意行為。

清洗設備的硬體具有特殊的網路處理器晶元和特別優化的操作系統、TCP/IP協議棧，可以處理非常巨大的流量和SYN隊列。

HTTP Flood防禦

HTTP Flood攻擊防禦主要通過緩存的方式進行，盡量由設備的緩存直接返回結果來保護後端業務。大型的互聯網企業，會有龐大的CDN節點緩存內容。

當高級攻擊者穿透緩存時，清洗設備會截獲HTTP請求做特殊處理。最簡單的方法就是對源IP的HTTP請求頻率做統計，高於一定頻率的IP地址加入黑名單。這種方法過於簡單，容易帶來誤殺，並且無法屏蔽來自代理伺服器的攻擊，因此逐漸廢止，取而代之的是JavaScript跳轉人機識別方案。

HTTP Flood是由程序模擬HTTP請求，一般來說不會解析服務端返回數據，更不會解析JS之類代碼。因此當清洗設備截獲到HTTP請求時，返回一段特殊JavaScript代碼，正常用戶的瀏覽器會處理並正常跳轉不影響使用，而攻擊程序會攻擊到空處。

DNS Flood防禦

DNS攻擊防禦也有類似HTTP的防禦手段，第一方案是緩存。其次是重發，可以是直接丟棄DNS報文導致UDP層面的請求重發，可以是返回特殊響應強制要求客戶端使用TCP協議重發DNS查詢請求。

特殊的，對於授權域DNS的保護，設備會在業務正常時期提取收到的DNS域名列表和ISP DNS IP列表備用，在攻擊時，非此列表的請求一律丟棄，大幅降低性能壓力。對於域名，實行同樣的域名白名單機制，非白名單中的域名解析請求，做丟棄處理。

慢速連接攻擊防禦

Slowloris攻擊防禦比較簡單，主要方案有兩個。

第一個是統計每個TCP連接的時長並計算單位時間內通過的報文數量即可做精確識別。一個TCP連接中，HTTP報文太少和報文太多都是不正常的，過少可能是慢速連接攻擊，過多可能是使用HTTP 1.1協議進行的HTTP Flood攻擊，在一個TCP連接中發送多個HTTP請求。

第二個是限制HTTP頭部傳輸的最大許可時間。超過指定時間HTTP Header還沒有傳輸完成，直接判定源IP地址為慢速連接攻擊，中斷連接並加入黑名單。

～～～～～～～～～～～～～～～～～～～～～·

下面我們細說一下，不同攻擊量對應對方式

如果超過，&>10G 攻擊，如果大於10G攻擊軟體防護就扯蛋，

下面記住一句話，防ddos攻擊大小於取決於你帶寬的大小，與軟體沒關係。

國內現在100M帶寬一個月就，便宜的8000，貴的2萬多，1G帶寬，8萬，10G帶寬，80萬，你確定要自己防護？

業務邏輯很很多種，每家都不太一樣，

WEB類型，這個是攻擊最多，防護方案更廣，可以選擇國內，國外，cdn加速等，

遊戲類型，這個必須得放在國內，放國外太卡，掉線，沒人玩了

解決辦法就是找第三方防ddos解決商，

10~50G防護，國內很多機房都可以防護，問題你給的錢夠不夠idc機房是否給你防護，他們防護示意圖，

機房有一個總帶寬，如果你攻擊帶寬太大就影響他正常客戶，他就會找各種借口給你ip屏蔽。

很多攻擊持續的時間非常短，通常5分鐘以內，流量圖上表現為突刺狀的脈衝。

實際對機房沒有什麼影響，但是機房就給你ip屏蔽了，這個用於攻擊遊戲類網站，搞一會一掉線，用戶全掉光了，

50G之間，單機防護，浙江，江蘇，廣東，都可以防都可以防護，月成本，2萬左右，（價格說小於1萬那就是騙子，已經測試過）

網上很多說無視，320G防護，全是吹牛的，他說的320G，應當就是udp攻擊，因為電信上層給屏蔽了udp帶寬，

廣東有雙線，合適放遊戲類網站，速度快，防護還可以，

廣東有些ip是屏蔽國外的流量，還有屏蔽聯通的流量，意思就是除了電信的別的地方的流量都過不來，

就像這個ISP近源清洗

100～200G之個，這個現在是關鍵了，現在攻擊這個是最多的，遊戲類網站如果有怎麼大攻擊放國內，現在能有怎麼大防護的，電信，廣東，福州，廣西，聯通，有大連，

福州買過，2萬多一個月，說防300G，130G就給封了，騙子，dns防護也不行，10G左右的dns攻擊直接搞死了

廣東機房買過，3萬一個月，100g 就給封了，不過廣東可以秒解，買200個ip，還是能防一會，廣東的直接訪問不了dns,機房做策略了。

廣西，這個正測試，前幾天放了dns在廣西機房，打死了。

DNS攻擊防護也是重點，買了dnspod的最貴那個版本3萬多/年，封了，dnspod也，老吳不在那了嗎？搞別的去了，現在真是垃圾，指著dnspod防護差遠了，我給大家介紹一下，google有dns防護，好用，比dnspod便宜很多，還有CF，也非常好，200刀，沒打死過。

上面就浪費十來萬，測試dns測試100G防護，總結的經驗，

遊戲的只能放國內，還得看是udp,還是tcp，所以防護範圍小。

WEB的防護比較多，可以考慮放國外，

現在國外比較能吹的，

美國SK機房，防100G，買了，安排機器花了2天，這個攻擊完了ip,封1小時，真心不行。機房還老掉線，花了1萬左右可能一個月，

美國hs機房，防80G，一個月8萬，買了，打死了，他防到40G左右就給你封了，也跟騙子差不多，說是要加到200G防護，沒看到，

美國CD機房，最後花了&>10萬每月，找的他們老闆防住了，但是dns防護不行。

還有一家機房可以推薦，加拿大機房，單機防160G，集群480G，不封ip，防護還可以，缺點，卡，國內ping掉包，8000左右一個月，20元一個ip,

上面速度最快的是hs機房國內，150ms左右，沒攻擊的時候用用還行，有攻擊防護差點意思。

我不是給機房做廣告，我只是總結我最近防護的經驗，國內可以放免備案的機房也有，資源聯繫方式，dns防攻擊500G，都可以，你聯繫我。我可以免費告訴你這些資源的聯繫方式，

～～～～～～～～～～～～～～～～～～～～～～～～～～

最後說一下，雲加速，

國內的雲盾，收費死貴，防護不行，別看他家的了。

阿里雲防護，單機防4個G，不貴，小企業可以用，缺點得備案，還有如果你有非法信息，他們可以直接給報官了（最垃圾的是這點）

百度雲加速，說是防1T攻擊，我認真研究了一下，他是聯合，國外的CF雲加速，電信的雲堤（近源清洗）說能防1T，攻擊400G他轉到CF國外，國內600G攻擊，全是雲堤防護的，

什麼是近源清洗，就是江蘇有攻擊，到電信江蘇的出口的時候，isp，中國電信直接不讓他出口，

目前如中國電信的專門做抗DDOS的雲堤提供了[近源清洗]和[流量壓制]的服務，對於購買其服務的廠商來說可以自定義需要黑洞路由的IP與電信的設備聯動，黑洞路由是一種簡單粗暴的方法，除了攻擊流量，部分真實用戶的訪問也會被一起黑洞掉，對用戶體驗是一種打折扣的行為，本質上屬於為了保障留給其餘用戶的鏈路帶寬的棄卒保帥的做法，之所以還會有這種收費服務是因為假如不這麼做，全站服務會對所有用戶徹底無法訪問。對於雲清洗廠商而言，實際上也需要藉助黑洞路由與電信聯動。

百度雲加速，還沒測試過，不評價，總結國內的廠商全是吹牛B的比較多，行業就這樣，

國外的比較可靠，但是收費的確不便宜，

三家，可以推薦，

亞馬遜，30G攻擊無視，攻擊大了，也給你封了，推薦他最大優點，按流量收費，可以按小時收費，不要備案，國內還得先備案，這我買6個節點，用三天死了。

CF加速，這個dns防護無敵，百度雲加速就是聯合的他家。

akamai，這家是給蘋果做防護的，說只有蘋果發布會的打死過一次，我沒試太貴了，1G，3.5元，一天估計就得5000左右一天，

cdn加速，是防CC的一個主要手段

CDN/Internet層CDN並不是一種抗DDOS的產品，但對於web類服務而言，他卻正好有一定的抗DDOS能力，以大型電商的搶購為例，這個訪問量非常大，從很多指標上看不亞於DDOS的CC，而在平台側實際上在CDN層面用驗證碼過濾了絕大多數請求，最後到達資料庫的請求只佔整體請求量的很小一部分。

　　對http CC類型的DDOS，不會直接到源站，CDN會先通過自身的帶寬硬抗，抗不了的或者穿透CDN的動態請求會到源站，如果源站前端的抗DDOS能力或者源站前的帶寬比較有限，就會被徹底DDOS。

～～～～～～～～～～～～～～～

如果你是正規網站，你別怕有攻擊，不會有怎麼大攻擊的，現在黑客主要攻擊那些非正規的網站,H 站，棋牌，菠菜，都是攻擊要錢的，

正規網站他不會天天來打死你，攻擊你的都是競爭對手。

如果有一天，有人攻擊你要錢，下面就是要做的事。

立案和追蹤

目前對於流量在100G以上的攻擊是可以立案的，這比過去幸福了很多。過去沒有本土特色的資源甚至都沒法立案，但是立案只是萬里長征的第一步，如果你想找到人，必須成功完成以下步驟：

? 在海量的攻擊中，尋找倒推的線索，找出可能是CC伺服器的IP或相關域名等

? 「黑」吃「黑」，端掉CC伺服器

? 通過登錄IP或藉助第三方APT的大數據資源（如果你能得到的話）物理定位攻擊者

? 陪叔叔們上門抓捕

? 上法庭訴訟

如果這個人沒有特殊身份，也許你就能如願，但假如遇到一些特殊人物，你幾個月都白忙乎。而黑吃黑的能力則依賴於安全團隊本身的滲透能力比較強，且有閒情逸緻做這事。這個過程對很多企業來說成本還是有點高，光有實力的安全團隊這條門檻就足以砍掉絕大多數公司。筆者過去也只是恰好有緣遇到了這麼一個團隊。

是有成功案例，燕郊，黃總，有人攻擊他要錢，完了他打了幾千，報警抓住了。但不是你報警就有人管你的，還得有關係（國情你懂的）不過，你可以找我呀，我可以告訴你怎麼辦呀。哈哈。

總結一下，

WEB網站攻擊，一般流量，直接syn,udp，打不死，就攻擊你的dns,不行還能舉報你，

遊戲網站，他不直接打死你，讓你老掉線，玩不了，目的達到了。所以這類網站需要提前布置防護。

還有支付類網站，

中小企業，主要看攻擊量的大小選擇方案，如果你們公司不差錢，那就別向下看了，

下面我可是報行業內幕，

&<30G攻擊， 3000左右一個月，非連續攻擊，可用，單機防，

&<50G攻擊，1萬左右一個月，非連續攻擊，可用，雙機防，

&<100G攻擊，2～3萬，連續攻擊/日，需要用集群防，

&<300G攻擊，5～8萬，連續攻擊/日，需要集群，加CDN，學習百度雲加速，國外的防護讓CF幫著防，國內的找雲堤防，

所以，總結一下那些公司是騙人的，你們不白花錢去再測試了。我已經測試過了。

時間緊很多點沒有寫全，寫透，今後找個時間再總結分類。

2015年9月

打個廣告，騰訊類似崗位找有能力的大神，來了就能一探究竟~~ （知乎的回復沒有標籤選項很不習慣）

您好有沒有https ddos相關總結？？

樓上幾個彷彿很有錢的樣子阿里雲的防禦貴的要死

國內防DDOS的大部分思路還是在肉雞和被攻擊對象這一層，難道沒有想過從黑客到肉雞這一層來做？據說國外早就在弄這一塊了。。。

百萬級的CC相當於1秒鐘有100萬用戶在請求，加密之後這個量是非常大的，國內大部分廠商防禦CC基本上都是宣傳每小時防禦多少IP，其實這個有水分，攻擊者肉雞一多的時候，不到10000個IP就不防禦了，其實這個時候QPS可能都不到5萬，真正衡量CC防禦性能的還是QPS，100萬的QPS目前估計也只有雲計算廠商才能做到了。

阿里雲的快速彈性擴容和大數據在防禦這種超大規模攻擊的時候起了很重要的作用。攻擊量快速上漲，防禦性能也會自動彈性擴容，沒有太多攻擊的時候資源也不會浪費。阿里雲的大數據分析系統每天都要處理TB級別的數據。兩者結合才有了這樣的防禦能力。

CC攻擊的場景和搶購、秒殺、活動的場景很類似！平時沒這麼大壓力的，但是關鍵時刻必須能頂住！瞬間壓力遠超正常的幾百幾千倍！好幾個數量級的差異。天貓雙十一不可能直接買幾十倍的硬體伺服器來抗。關鍵是還是阿里雲能隨時擴容伺服器！這種彈性的能力只有雲廠商才能具備！防禦資源可調度，成本大幅降低！被攻擊（活動）後動態擴容，攻擊（活動）結束動態縮容！這方面阿里雲的積累是挺深的！