楊哥關注的華為官方的【華安解密之DDoS攻防】非常實用，純純的乾貨，決定每天一篇分享給愛看頭條並且愛學習的條友們。
正文如下：
看過了我們上一篇解密的搜狐視頻攻擊事件，大家一定心有惶惶，上網看視頻本屬於娛樂消遣活動，居然會觸發DDoS攻擊，而每一個觀看視頻的人在不知不覺中就變成了攻擊者的幫兇。可見，網絡江湖異常險惡，攻防之間此消彼長，瞭解攻擊才能更好的防禦，這也是華安寫作解密系列的初衷。
在該事件中，攻擊者利用搜狐視頻網站的XSS漏洞（Cross Site Scripting，跨站腳本攻擊），劫持視頻觀看者的流量，向受害者發起海量的HTTP請求。最終，數以千萬計的HTTP請求形成了一次規模巨大的DDoS攻擊，使受害者無法提供正常的服務。
攻擊產生的源頭和攻擊方式都與HTTP協議有關。HTTP協議是當前使用最廣泛的協議，我們瀏覽網頁、看新聞查資料的背後都是HTTP協議在默默工作。上一篇我們已經對HTTP協議進行了簡單的介紹，本篇我們深入剖析基於HTTP協議的DDoS攻擊方式和防禦原理，首先來了解HTTP協議的基礎知識。
0x01 HTTP協議基礎
HTTP是一種請求/響應式的協議，客戶端向服務器發起請求，服務器收到請求後，向客戶端返回響應信息。HTTP報文分為請求報文和響應報文，HTTP請求報文的格式如下所示：
下面結合HTTP請求報文的抓包信息來學習各個字段的含義。
HTTP請求報文由請求行、請求頭部、空行和請求數據四個部分組成，各部分的具體解釋如下：
請求行
請求行由請求方法字段、URL字段和協議版本字段組成，這三個字段之間使用空格分隔，最後由回車符\\r+換行符\\n結束。例如，GET /index.html HTTP/1.1\\r\\n。這裡順便提一下URL和URI，URL全稱是Uniform Resource Locator（統一資源定位），URI全稱是Uniform Resource Indentifier（統一資源標識），一般情況下我們看到瀏覽器處理的是URL，而在HTTP協議規範中會使用更通用的概念URI作為資源標識符。
請求行中值得關注的就是請求方法字段，常用的請求方法有GET，表示客戶端從服務器獲取數據，即要求服務器將URL定位的資源放在響應報文中，返回給客戶端；POST，表示客戶端向服務器提交數據，由服務器進行處理，如表單提交、賬號登錄等操作使用的就是POST請求方法。
GET和POST這兩種請求方法經常會被用來進行DDoS攻擊，例如在搜狐視頻攻擊事件中，廣大“幫兇”使用的就是GET請求方法，向受害者發起海量的HTTP請求。除了這兩種請求方法，HTTP協議還支持HEAD、PUT、OPTIONS、DELETE等請求方法，此處不再贅述。
請求頭部
請求頭部由“關鍵字/值”對組成，每行一對，關鍵字和值之間使用英文冒號“:”分隔，最後由回車符+換行符結束。請求頭部中可以包含多個類型的關鍵字，這些關鍵字用於通知服務器有關於客戶端請求的信息。
例如，User-Agent表示客戶端告知服務器自己的瀏覽器信息；Host表示接受請求的服務器地址；Content-Length表示客戶端要向服務器提交的數據長度；Cookie表示客戶端向服務器發送自己的Cookie信息等等。
空行
請求頭部的後面會有一個空行，裡面包括回車符和換行符，表示請求頭部結束，接下來為請求數據部分。這一行必不可少，因為它用來告知服務器以後不再有請求頭，如果服務器沒有收到這個空行則會一直保持連接。後面我們也會講到攻擊者偽造不包含空行的HTTP請求報文來消耗服務器資源，進行DDoS攻擊的情況。
請求數據
請求數據是HTTP報文的載荷，即HTTP報文要傳輸的內容。請求數據部分是可選的，請求方法是GET時，HTTP報文中就不包含請求數據；請求方法是POST時，HTTP報文中包含請求數據。
瞭解HTTP請求報文的格式後，接下來我們看一看HTTP響應報文的格式：
結合HTTP響應報文的抓包信息來學習各個字段的含義。
HTTP響應報文由狀態行、響應頭部、空行和響應數據四個部分組成，各部分的具體解釋如下：
狀態行
狀態行由協議版本字段、狀態碼字段和狀態碼描述字段組成，這三個字段之間使用空格分隔，最後由回車符+換行符結束。例如，HTTP/1.1 200 OK\\r\\n。
狀態行中值得關注的是狀態碼字段，常用的狀態碼有200，表示服務器響應成功；302，表示請求方法為GET時，服務器告知客戶端需要重定向到新的URL；307表示請求方法為POST時，服務器告知客戶端需要重定向到新的URL；404，表示服務器無法找到所請求URL對應的資源；408，表示請求超時，客戶端需要重新提交請求。
響應頭部
響應頭部與請求頭部類似，也是由“關鍵字/值”對組成，每行一對，關鍵字和值之間使用英文冒號“:”分隔，最後由回車符+換行符結束。響應頭部中可以包含多個類型的關鍵字，用來通知客戶端有關於服務器響應的信息。
空行
響應頭部的後面也會有一個空行，裡面包括回車符和換行符，表示響應頭部結束，接下來為響應數據部分。
響應數據
響應數據是服務器返回給客戶端的信息，上面抓包示意圖中顯示的響應數據是一個HTML網頁，也可以是圖片、視頻等信息。
上面介紹了HTTP報文的格式，並對其中的關鍵字段進行了解釋，下面再來了解一下HTTP協議的基本交互流程。我們提到過，HTTP是一種請求/響應式的協議，客戶端與服務器建立TCP三次握手後，客戶端向服務器發出HTTP請求，服務器向客戶端返回HTTP響應，在一來一回之間完成了數據的傳輸，如下圖所示。
學習完前面的內容，相信大家對HTTP協議有了更進一步的認識。目前Internet上運行著多種基於HTTP協議的Web信息系統，這些Web信息系統存在的安全問題必須重視。像搜狐視頻攻擊事件中的XSS攻擊，以及SQL注入、CSRF（Cross-Site Request Forgery，跨站請求偽造）等攻擊方式都在危害著Web信息系統的安全，甚至會觸發DDoS攻擊。由Web信息系統的一個安全漏洞演化為大規模的DDoS流量型攻擊，其中的安全問題值得深思。
回到DDoS攻擊上來，針對HTTP協議的DDoS攻擊主要有利用GET和POST請求方法的Flood類攻擊，以及利用HTTP協議實現機制的慢速類攻擊，我們先來看HTTP GET Flood攻擊。
0x02 HTTP GET Flood攻擊與防禦
HTTP GET Flood攻擊的原理很簡單，攻擊者利用攻擊工具或者操縱殭屍主機，向目標服務器發起大量的HTTP GET報文，請求服務器上涉及數據庫操作的URI或其它消耗系統資源的URI，造成服務器資源耗盡，無法響應正常請求。
華為Anti-DDoS解決方案防禦HTTP GET Flood攻擊的常用手段是源認證，這種防禦方式適用於客戶端為瀏覽器的場景，因為瀏覽器支持完整的HTTP協議棧，可以正常回應Anti-DDoS系統發出的探測報文。源認證包括兩種方式，最基本的方式是302重定向認證。
302重定向認證
302重定向認證的原理是Anti-DDoS系統代替服務器向客戶端響應302狀態碼（針對GET請求方法的重定向），告知客戶端需要重定向到新的URL，以此來驗證客戶端的真實性。真實客戶端的瀏覽器可以自動完成重定向過程，通過認證；而虛假源或者一般的攻擊工具沒有實現完整的HTTP協議棧，不支持自動重定向，無法通過認證。
1、當連續一段時間內去往目標Web服務器的HTTP GET請求報文超過告警閾值後，Anti-DDoS系統啟動源認證機制。源認證機制啟動後，Anti-DDoS系統將會代替服務器與客戶端建立TCP三次握手。
2、Anti-DDoS系統攔截HTTP請求，代替Web服務器回應302狀態碼，將客戶端的訪問重定向到一個新的URI。
3、如果這個源是虛假源，或者不支持完整HTTP協議棧的攻擊工具，不會向新的URI發起請求。
4、如果這個源是真實客戶端，則會向新的URI發起請求。Anti-DDoS系統收到請求後，將該客戶端的源IP地址加入白名單。然後Anti-DDoS系統會再次回應302狀態碼，將客戶端的訪問重定向到一開始訪問的URI。
5、後續這個客戶端發出的HTTP請求報文命中白名單直接通過。
我們結合一組抓包信息來看一下交互報文的具體情況。
1、Anti-DDoS系統代替Web服務器與客戶端建立TCP三次握手，然後客戶端發起訪問請求。
2、Anti-DDoS系統代替Web服務器回應302狀態碼，希望客戶端訪問一個新的URI地址“http://156.*.*.*/?dbiekfcjekngdjec”，然後雙方關閉連接。
3、真實客戶端會再次與Anti-DDoS系統建立TCP三次握手，並向新的URI“http://156.*.*.*/?dbiekfcjekngdjec”發起請求。
4、Anti-DDoS系統收到請求後，判定該客戶端為真實客戶端，將其IP地址加入白名單。同時Anti-DDoS系統會再次回應302狀態碼，將客戶端的訪問重定向到一開始訪問的URI，然後雙方關閉連接。後面該客戶端發出的HTTP請求報文就可以命中白名單直接通過了。
除了302狀態碼重定向方式，還有一種META Refresh重定向方式。META Refresh方式是通過修改HTML頁面來實現重定向，具有侷限性；而302狀態碼方式是利用HTTP協議規範來實現重定向，適用性更好。所以302狀態碼方式是目前使用比較廣泛的重定向方式。
另外還有一種情況，網絡中存在HTTP代理服務器時，只要代理服務器IP地址通過源認證加入白名單，殭屍主機就可以利用代理服務器IP地址繞開源認證，導致防禦失效。針對這種情況，Anti-DDoS系統提供了代理檢測功能。開啟該功能後，Anti-DDoS系統會檢測HTTP請求是不是通過代理服務器發出的。如果是，Anti-DDoS系統會從HTTP報文中獲取請求者的實際IP地址進行源認證，通過認證後才加入白名單。
302重定向認證利用HTTP響應報文中的302狀態碼來實現對客戶端的源認證功能，但是如果攻擊工具實現了完整的HTTP協議棧，或者像搜狐視頻攻擊事件中攻擊源都是真實的瀏覽器這種情況，會導致302重定向認證方式失效。此時，可以使用源認證中的增強方式，即驗證碼認證。
驗證碼認證
驗證碼認證的原理是Anti-DDoS系統要求客戶端輸入驗證碼，以此來判斷請求是否由真實的用戶發起，而不是由攻擊工具或殭屍主機發起。因為攻擊工具或殭屍主機無法自動響應隨機變化的驗證碼，所以能夠有效的防禦攻擊。
1、當連續一段時間內去往目標Web服務器的HTTP GET請求報文超過告警閾值後，Anti-DDoS系統啟動源認證機制。源認證機制啟動後，Anti-DDoS系統將會代替服務器與客戶端建立TCP三次握手。
2、Anti-DDoS系統攔截HTTP請求，向客戶端返回驗證碼頁面，要求客戶端輸入驗證碼。
3、如果這個源是攻擊工具或殭屍主機，不會輸入驗證碼。
4、如果這個源是真實客戶端，則會輸入驗證碼並通過認證，Anti-DDoS系統將該客戶端的源IP地址加入白名單。然後Anti-DDoS系統會請客戶端繼續訪問一開始的URI。
5、後續這個客戶端發出的HTTP請求報文命中白名單直接通過。
下面給出了Anti-DDoS系統向客戶端返回的驗證碼頁面的報文，以及對應的實際頁面：
驗證碼認證方式與302認證方式相比，防禦效果更好，但是由於需要人機交互輸入驗證碼，用戶體驗稍差一些。在實際使用驗證碼認證方式時，可以增加源IP統計的環節，即Anti-DDoS系統先基於目的IP進行統計，當去往某個目的IP的HTTP請求超過閾值時，啟動基於源IP的統計。當來自某個源的HTTP請求也超過閾值時，才啟動驗證碼認證機制。這樣就會精確控制需要進行驗證碼認證的源IP範圍，避免大範圍的源IP都要輸入驗證碼。
302重定向認證和驗證碼認證這兩種源認證方式是防禦HTTP GET Flood攻擊的有效手段，但是源認證方式也存在一定的侷限，比如機頂盒視頻點播、特定移動網絡等場景中，無法對客戶端使用源認證方式。為此，Anti-DDoS系統還支持URI動態指紋學習和URI行為監測防禦方式，作為源認證方式的補充，滿足不同場景的需求。
URI動態指紋學習
URI動態指紋學習方式適用於攻擊源訪問的URI比較固定的情況，因為要形成攻擊效果，攻擊者一般都會以容易消耗系統資源的URI作為攻擊目標。一個攻擊源會發出多個針對該URI的請求，最終呈現為該源對特定的URI發送大量的請求報文。
基於這個原理，Anti-DDoS系統對客戶端所訪問的URI進行指紋學習，找到攻擊目標URI指紋。在一定的週期內，當同一個源發出的包含同一指紋的請求超過設置的閾值時，就將該源加入黑名單。
URI行為監測
URI行為監測防禦方式要先設置需要重點監測的URI，可以將消耗資源多、容易受到攻擊的URI加入到“重點監測URI”列表中。URI行為監測防禦方式通過判斷兩個比例是否超過閾值來確定攻擊源。
首先，在特定時間內對某個目的服務器的所有訪問中，對重點監測URI的訪問數與總訪問數的比例超過設置的閾值時，Anti-DDoS系統啟動針對源的URI檢測。當這個源對某個重點檢測URI的訪問數與總訪問數的比例超過設置的閾值時，就將該源加入黑名單。
HTTP GET Flood攻擊的原理和防禦方式介紹完畢，下一篇我們將介紹利用POST請求方法的HTTP POST Flood攻擊以及HTTP慢速攻擊，請大家繼續關注。
上期鏈接：
閱讀更多 弱電Bar 的文章
