楊哥關注的華為官方的【華安解密之DDoS攻防】非常實用，純純的乾貨，決定每天一篇分享給愛看頭條並且愛學習的條友們。
正文如下：
在苦心鑽研DDoS防禦技術之前，哥也曾經和大多數人一樣，認為網絡犯罪都是黑客的事，只想安安靜靜地做個美（好）男（網）子（民），互聯網上的各種紛爭都與我無關，直到哥不知不覺充當了一次“肉雞”。
話說那時的搜狐已經是名列前茅的網站，那時的哥也還是個年輕的小鮮肉，當哥整天抱著搜狐視頻看電視看球賽看廣告的時候，下面的事情發生了……
0x01 事件回顧
2014年5月，當哥還沉浸在搜狐熱播的時候，頗負盛名的搜狐視頻，卻揹負了一起著名的DDoS攻擊事件。
當時，日本CDN服務商Incapsula聲稱，自己的一位客戶的服務器遭遇了搜狐視頻發起的DDoS攻擊，期間總共有超過2萬的網民通過搜狐視頻向這位客戶發起超過2000萬次的HTTP Get請求。然而如此知名的網站，怎麼會甘冒不韙，公然向別人發起攻擊呢？原來，搜狐視頻是在未知的情況下被黑客利用，成為了攻擊的源頭。
有句話叫“趁虛而入”，搜狐視頻網站上恰好就有這麼一個漏洞給了黑客“打劫”的機會。通過這個漏洞，黑客註冊一個搜狐視頻賬戶，在頭像中注入惡意代碼（JavaScript），然後用這個賬戶在視頻的評論區發佈大量的評論。你看，每條評論都帶有用戶頭像，頭像中帶有惡意代碼，這樣，每條評論都附帶著惡意代碼。當任何用戶訪問這個視頻頁面的時候，都會觸發惡意代碼，實際上控制了搜狐視頻用戶的瀏覽器。
那麼這段惡意代碼幹了什麼呢？簡單說，這段代碼就是在用戶不知情的情況下，定時向受害者發起HTTP訪問請求。這個定時器，是1秒。
也就是說，當搜狐視頻用戶觀看視頻時，他的瀏覽器會每秒向受害者發起一次請求。如果用戶觀看30分鐘視頻，那麼就會向受害者發起1800次請求。大家可能會覺得，這也沒有多少呀，但是，搜狐視頻這樣的大型視頻網站，同時在線觀看熱門視頻的用戶都是成千上萬級別的，黑客在多個熱門視頻下發布海量評論，輕鬆獲得無數“肉雞”。眾人拾柴火焰高，如果星火燎原到千家萬戶同時持續地向受害者發送請求，攻擊效果就可想而知了。
嗯，每一個人都是幫兇。
0x02 HTTP協議基本知識
HTTP協議，HyperText Transfer Protocol，超文本傳輸協議。我們先來簡單回顧下HTTP協議的基本原理。
HTTP協議最基本的交互流程如下。
完成TCP三次握手後，客戶端向服務器發起HTTP請求。正常情況下，服務器回應200 OK，在應答中添加應答長度，然後開始傳輸數據。
HTTP協議還有一種重定向的交互流程，如下。
完成TCP三次握手後，客戶端向服務器發起HTTP請求。如果客戶端請求的這個URL是過期的，那麼服務器就會回應客戶端302重定向報文，並攜帶新的URL地址。然後客戶端再重新向新的URL地址發起請求，服務器回應200 OK，並開始傳輸數據。
0x03 華為Anti-DDoS解決方案怎麼做？
HTTP協議是一種基於TCP協議的應用層協議，而HTTP類的攻擊，最高效的防禦方式就是源認證方式進行校驗。華為Anti-DDoS解決方案可以感知TCP協議和HTTP協議，可以針對攻擊源進行多層級的源認證和校驗。
源認證體系主要有三個層面：
第一層，TCP/IP源認證
一般用於TCP三次握手還沒建立成功前，驗證攻擊源的TCP/IP是否真實可信，比如IP源認證是對IP層面的校驗，認證這個源是不是真實存在的源；而TCP代理和首包丟棄校驗是對於TCP協議棧層面的校驗，用於判斷是否是這個源發出的真實請求。
很顯然上述攻擊事件已經完成了TCP三次握手，不屬於TCP/IP範疇，關於TCP/IP源認證的防禦機制，我們會在後面詳細介紹，本節著重介紹應用層源認證。
第二層，應用層源認證
如果肉雞使用工具調用真實的TCP/IP協議棧發動攻擊，則TCP/IP源認證無法識別是否是攻擊，我們必須啟用應用層源認證，比如利用HTTP 302重定向請求，可以認證客戶“瀏覽器”是否可信。只有真實瀏覽器才具備完整的HTTP協議棧校驗機制。
第三層，用戶源認證
在客戶端是真實的基礎上，進一步驗證是否由真實用戶發出的請求，而不是肉雞瀏覽器被黑客控制強制發出的請求。針對這種情況，終極的手段就是，人機交互，輸入驗證碼和圖片運算。其實驗證碼機制就是對登錄用戶的一次安全驗證，判斷一下是不是真實用戶發起的請求。如果是DDoS工具發起的請求，是無法自動響應隨機應變的驗證碼的。
我們再回到前面的攻擊事件上來。攻擊報文是由瀏覽器發出的請求，沒有人為參與，源IP是真實存在的，瀏覽器也是真實存在的，但是請求行為是虛假的。所以在防禦的時候，就要識別出HTTP請求中，哪些是真實的用戶發送的請求，哪些是肉雞瀏覽器發的請求。瀏覽器具有完整的HTTP協議校驗機制，對於302重定向報文，瀏覽器可以直接完成交互過程，無須用戶參與，顯然302重定向方式識別不了攻擊報文。只能通過驗證碼這種需要人機交互的方式來識別攻擊報文，顯然對照的是第三個層面。
對於HTTP攻擊防禦，第二層提到的302重定向和第三層的驗證碼方式都是非常有效的防禦手段，302重定向更常用。只要客戶端具備完善的302重定向機制，就可以通過302重定向源探測方式識別虛假源。但是302重定向無法識別殭屍瀏覽器，對於殭屍瀏覽器可以使用驗證碼方式，只是驗證碼需要用戶參與，用戶體驗稍差一點。
還有一種特殊情況，當網絡中有HTTP代理服務器時，只要有一次源認證通過，Anti-DDoS就會將代理服務器IP地址加入白名單，後續黑客就會利用代理服務器IP繞過源認證檢查，從而導致防禦失敗。這種情況下，就要配合代理檢查功能一起使用，檢測HTTP請求是否為通過代理發出的請求。如果是，Anti-DDoS會從HTTP報文中獲取請求者的實際IP地址，將通過認證的真實IP地址和代理服務器IP地址加入白名單，後續只有此實際源IP地址發送的報文才能直接通過，其他源IP發送報文時，Anti-DDoS會對其進行源認證，達到防禦效果。
今天先拋個磚，就講到這裡。從下週開始，未來兩週時間裡，華安將和大家一起討論下HTTP Flood的各種攻擊和防禦手段，Anti-DDoS技術的路上，我們共同進步。
往期連接：
閱讀更多 弱電Bar 的文章
