慢速 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 連線是否相互同意時產生的。
更多
- How to Protect Against Slow HTTP Attacks
- Slow Http Post attack in Nginx
- Cloudflare Solution
今天先到這兒，希望對雲原生，技術領導力， 企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管管，團隊建設 有參考作用 , 您可能感興趣的文章:
領導人怎樣帶領好團隊
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
影片直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續整合/CD
網際網路電商購物車架構演變案例
網際網路業務場景下訊息佇列架構
網際網路高效研發團隊管理演進之一
訊息系統架構設計演進
網際網路電商搜尋架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
網際網路資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之效能實時度量系統演變
如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱號：
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。
該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。