慢速 HTTP 拒絕服務： 分析、利用和緩解
慢速 HTTP 攻擊Slow HTTP DoS Attack基於這樣一個事實，即 HTTP 協議在設計上要求服務器在處理請求之前完全接收請求。如果 HTTP 請求未完成，或者傳輸速率很低，服務器就會一直佔用資源等待其他數據。如果服務器佔用過多資源，可能會導致目標主機拒絕服務。因爲我們將阻止其他用戶通過協議連接或創建會話。對任何一個允許HTTP訪問的服務器，攻擊者先在客戶端上向該服務器建立一個content-length比較大的連接，然後通過該連接以非常低的速度（例如，1秒～10秒發一個字節）向服務器發包，並維持該連接不斷開。如果攻擊者在客戶端上不斷建立這樣的連接，服務器上可用的連接將慢慢被佔滿，從而導致服務器拒絕用戶正常的訪問申請。
簡而言之，攻擊者向網絡服務器發送合法的 HTTP 請求頭。在這些報文頭中，正確指定了報文主體的大小。但是，信息主體的發送速度卻非常慢。這種速度可以慢到每兩分鐘一個字節，但還不足以導致客戶端-服務器傳輸超時，從而導致會話關閉。由於信息是正常處理的，目標服務器會盡力遵守規則，因此服務器的速度會隨之大大降低。當攻擊者同時發起數百甚至數千次 "慢速 HTTP "攻擊時，服務器資源幾乎在幾秒鐘內就會被消耗殆盡，導致合法客戶端連接無法訪問。 這類攻擊很容易實施，因爲使用最小帶寬的單臺機器可以在很短的時間內（最多 65539 次）建立數千個連接，產生數千個未完成的 HTTP 請求。
可怕的是，這些攻擊很難與正常流量區分開來。由於它們不需要應用層的大量資源，因此可以從一臺計算機啓動，這使得它們非常容易啓動且難以緩解。傳統的速度檢測技術無法阻止此類攻擊。也許一種方法是更新服務器的可用性，服務器上的可用連接越多（nginx 的 max_clients = worker_processes * worker_connections），攻擊壓垮該服務器的可能性就越小。不幸的是，在很多情況下，攻擊者會簡單地擴大攻擊規模，試圖儘可能多地超載。這些攻擊可能就像耗時較長的合法請求，因此很難使用傳統的反 DoS 工具進行檢測和阻止。我給你留了一個紙條，通過這種攻擊的頁面：
工作原理
分析 HTTP GET 請求有助於更好地解釋慢速 HTTP DoS 攻擊如何以及爲何可能發生。
一個簡單的請求如下所示：
特別值得注意的是上述 GET 請求中的 [CRLF]。回車換行（CRLF）是一個不可打印字符，用於表示一行的結束。與文本編輯器類似，HTTP 請求會在行尾包含一個 [CRLF] 字符以開始新行，幷包含兩個 [CRLF] 字符（即 [CRLF] [CRLF]）以指示空行。
HTTP 協議將空行定義爲標頭的結束。慢速 HTTP DoS 攻擊就是利用了這一點，不發送尾部空行來完成報頭。
更糟的是，入侵檢測系統（IDS）通常檢測不到慢速 HTTP DoS 攻擊，因爲這種攻擊不包含惡意代碼請求。在 IDS（入侵檢測系統）看來，HTTP 請求是合法的，並會將其傳遞給網絡服務器，而不會察覺到攻擊。
開發
在對技術進行微調時，一個重要的信息是確定服務器上保持連接狀態的最長時間（秒），這將使我們能夠優化作爲攻擊者的資源。
一個 Python 腳本就能完成這項工作（）：
在第一次嘗試中，我們的窗口大小是 75 秒，第 8 條調試信息告訴我們服務器關閉了連接，因此這不是我們的值，作爲攻擊者，我們將浪費 1 秒鐘來啓動另一個新連接。因此，我們用 74 秒進行了測試，成功地保持了會話的活力。
工具https://github.com/shekyan/slowhttptest
docker pull shekyan/slowhttptest
根據這些測試，我們的命令將如下所示：
slowhttptest -c 65539 -H -g -o report.csv -i 10 -r 200 -t GET -u https://targethost.com:443 -x 74 -p 3 -l 1800
-c 65539 // 同時啓動的最大連接數
-h // slowloris 模式 - 慢速 http
-g // 生成 CSV 和 HTML 格式的統計數據
-o report.csv // 自定義輸出文件的路徑和/或名稱，如果指定了 -g 則有效
-i 10 // 每次會話發送信息的間隔時間（以秒爲單位），這意味着 HTTP 會話打開後，將等待 10 秒發送信息，以此類推。
-r 200 // 連接比率，每次啓動 200 個連接，它們是累積的，根據攻擊服務器的處理速度，5 秒後我們將有 1000 個實時連接。
-t GET // 在攻擊中使用的 HTTP 方法
-u https://targethost.com:443 // 目標 URL，與在瀏覽器中輸入的格式相同
-x 74 // 會話的最長持續時間，該值從第一次保持存活測試中獲得
-3 // 請求探針，用於監控服務器在攻擊期間是否正常響應，3 秒被設定爲最長等待時間，如果在規定秒數後服務器沒有響應，則認爲服務器被 DoSed。
-l 1800 // 指定以秒爲單位的攻擊持續時間（本例中爲 30 分鐘）
請求探針的響應時間超過 3 秒，因此被視爲 DoSed。
因此，我們將訪問該網站，檢查它是否如腳本所示在運行：
事實上，我們已經耗盡了服務器的資源，因此它不再接受合法連接，以至於主機註冊的 DNS 服務顯示路由進展順利，直到它到達服務器併產生 HTTP 522 錯誤。522 代碼代表連接超時，是在驗證網絡服務器和 DNS 之間的 TCP 連接是否相互同意時產生的。
更多
今天先到這兒，希望對雲原生，技術領導力， 企業管理，系統架構設計與評估，團隊管理, 項目管理, 產品管管，團隊建設 有參考作用 , 您可能感興趣的文章:
領導人怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
視頻直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續集成/CD
互聯網電商購物車架構演變案例
互聯網業務場景下消息隊列架構
互聯網高效研發團隊管理演進之一
消息系統架構設計演進
互聯網電商搜索架構演化之一
企業信息化與軟件工程的迷思
企業項目化管理介紹
軟件項目成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
項目管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
互聯網數據庫架構設計思路
IT基礎架構規劃方案一(網絡系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之性能實時度量系統演變
如有想了解更多軟件設計與架構, 系統IT,企業信息化, 團隊管理 資訊，請關注我的微信訂閱號：
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。
該文章也同時發佈在我的獨立博客中-Petter Liu Blog。