慢速 HTTP 拒絕服務(wù)： 分析、利用和緩解
??? 慢速 HTTP 攻擊Slow HTTP DoS Attack基于這樣一個(gè)事實(shí)，即 HTTP 協(xié)議在設(shè)計(jì)上要求服務(wù)器在處理請(qǐng)求之前完全接收請(qǐng)求。如果 HTTP 請(qǐng)求未完成，或者傳輸速率很低，服務(wù)器就會(huì)一直占用資源等待其他數(shù)據(jù)。如果服務(wù)器占用過(guò)多資源，可能會(huì)導(dǎo)致目標(biāo)主機(jī)拒絕服務(wù)。因?yàn)槲覀儗⒆柚蛊渌脩敉ㄟ^(guò)協(xié)議連接或創(chuàng)建會(huì)話。對(duì)任何一個(gè)允許HTTP訪問(wèn)的服務(wù)器，攻擊者先在客戶端上向該服務(wù)器建立一個(gè)content-length比較大的連接，然后通過(guò)該連接以非常低的速度（例如，1秒～10秒發(fā)一個(gè)字節(jié)）向服務(wù)器發(fā)包，并維持該連接不斷開(kāi)。如果攻擊者在客戶端上不斷建立這樣的連接，服務(wù)器上可用的連接將慢慢被占滿，從而導(dǎo)致服務(wù)器拒絕用戶正常的訪問(wèn)申請(qǐng)。
??? 簡(jiǎn)而言之，攻擊者向網(wǎng)絡(luò)服務(wù)器發(fā)送合法的 HTTP 請(qǐng)求頭。在這些報(bào)文頭中，正確指定了報(bào)文主體的大小。但是，信息主體的發(fā)送速度卻非常慢。這種速度可以慢到每?jī)煞昼娨粋€(gè)字節(jié)，但還不足以導(dǎo)致客戶端-服務(wù)器傳輸超時(shí)，從而導(dǎo)致會(huì)話關(guān)閉。由于信息是正常處理的，目標(biāo)服務(wù)器會(huì)盡力遵守規(guī)則，因此服務(wù)器的速度會(huì)隨之大大降低。當(dāng)攻擊者同時(shí)發(fā)起數(shù)百甚至數(shù)千次 "慢速 HTTP "攻擊時(shí)，服務(wù)器資源幾乎在幾秒鐘內(nèi)就會(huì)被消耗殆盡，導(dǎo)致合法客戶端連接無(wú)法訪問(wèn)。 這類攻擊很容易實(shí)施，因?yàn)槭褂米钚挼膯闻_(tái)機(jī)器可以在很短的時(shí)間內(nèi)（最多 65539 次）建立數(shù)千個(gè)連接，產(chǎn)生數(shù)千個(gè)未完成的 HTTP 請(qǐng)求。
??? 可怕的是，這些攻擊很難與正常流量區(qū)分開(kāi)來(lái)。由于它們不需要應(yīng)用層的大量資源，因此可以從一臺(tái)計(jì)算機(jī)啟動(dòng)，這使得它們非常容易啟動(dòng)且難以緩解。傳統(tǒng)的速度檢測(cè)技術(shù)無(wú)法阻止此類攻擊。也許一種方法是更新服務(wù)器的可用性，服務(wù)器上的可用連接越多（nginx 的 max_clients = worker_processes * worker_connections），攻擊壓垮該服務(wù)器的可能性就越小。不幸的是，在很多情況下，攻擊者會(huì)簡(jiǎn)單地?cái)U(kuò)大攻擊規(guī)模，試圖盡可能多地超載。這些攻擊可能就像耗時(shí)較長(zhǎng)的合法請(qǐng)求，因此很難使用傳統(tǒng)的反 DoS 工具進(jìn)行檢測(cè)和阻止。我給你留了一個(gè)紙條，通過(guò)這種攻擊的頁(yè)面：
工作原理
分析 HTTP GET 請(qǐng)求有助于更好地解釋慢速 HTTP DoS 攻擊如何以及為何可能發(fā)生。
一個(gè)簡(jiǎn)單的請(qǐng)求如下所示：
特別值得注意的是上述 GET 請(qǐng)求中的 [CRLF]?；剀嚀Q行（CRLF）是一個(gè)不可打印字符，用于表示一行的結(jié)束。與文本編輯器類似，HTTP 請(qǐng)求會(huì)在行尾包含一個(gè) [CRLF] 字符以開(kāi)始新行，并包含兩個(gè) [CRLF] 字符（即 [CRLF] [CRLF]）以指示空行。
HTTP 協(xié)議將空行定義為標(biāo)頭的結(jié)束。慢速 HTTP DoS 攻擊就是利用了這一點(diǎn)，不發(fā)送尾部空行來(lái)完成報(bào)頭。
更糟的是，入侵檢測(cè)系統(tǒng)（IDS）通常檢測(cè)不到慢速 HTTP DoS 攻擊，因?yàn)檫@種攻擊不包含惡意代碼請(qǐng)求。在 IDS（入侵檢測(cè)系統(tǒng)）看來(lái)，HTTP 請(qǐng)求是合法的，并會(huì)將其傳遞給網(wǎng)絡(luò)服務(wù)器，而不會(huì)察覺(jué)到攻擊。
開(kāi)發(fā)
在對(duì)技術(shù)進(jìn)行微調(diào)時(shí)，一個(gè)重要的信息是確定服務(wù)器上保持連接狀態(tài)的最長(zhǎng)時(shí)間（秒），這將使我們能夠優(yōu)化作為攻擊者的資源。
一個(gè) Python 腳本就能完成這項(xiàng)工作（）：
在第一次嘗試中，我們的窗口大小是 75 秒，第 8 條調(diào)試信息告訴我們服務(wù)器關(guān)閉了連接，因此這不是我們的值，作為攻擊者，我們將浪費(fèi) 1 秒鐘來(lái)啟動(dòng)另一個(gè)新連接。因此，我們用 74 秒進(jìn)行了測(cè)試，成功地保持了會(huì)話的活力。
工具h(yuǎn)ttps://github.com/shekyan/slowhttptest
docker pull shekyan/slowhttptest
根據(jù)這些測(cè)試，我們的命令將如下所示：
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 // 同時(shí)啟動(dòng)的最大連接數(shù)
-h // slowloris 模式 - 慢速 http
-g // 生成 CSV 和 HTML 格式的統(tǒng)計(jì)數(shù)據(jù)
-o report.csv // 自定義輸出文件的路徑和/或名稱，如果指定了 -g 則有效
-i 10 // 每次會(huì)話發(fā)送信息的間隔時(shí)間（以秒為單位），這意味著 HTTP 會(huì)話打開(kāi)后，將等待 10 秒發(fā)送信息，以此類推。
-r 200 // 連接比率，每次啟動(dòng) 200 個(gè)連接，它們是累積的，根據(jù)攻擊服務(wù)器的處理速度，5 秒后我們將有 1000 個(gè)實(shí)時(shí)連接。
-t GET // 在攻擊中使用的 HTTP 方法
-u https://targethost.com:443 // 目標(biāo) URL，與在瀏覽器中輸入的格式相同
-x 74 // 會(huì)話的最長(zhǎng)持續(xù)時(shí)間，該值從第一次保持存活測(cè)試中獲得
-3 // 請(qǐng)求探針，用于監(jiān)控服務(wù)器在攻擊期間是否正常響應(yīng)，3 秒被設(shè)定為最長(zhǎng)等待時(shí)間，如果在規(guī)定秒數(shù)后服務(wù)器沒(méi)有響應(yīng)，則認(rèn)為服務(wù)器被 DoSed。
-l 1800 // 指定以秒為單位的攻擊持續(xù)時(shí)間（本例中為 30 分鐘）
請(qǐng)求探針的響應(yīng)時(shí)間超過(guò) 3 秒，因此被視為 DoSed。
因此，我們將訪問(wèn)該網(wǎng)站，檢查它是否如腳本所示在運(yùn)行：
事實(shí)上，我們已經(jīng)耗盡了服務(wù)器的資源，因此它不再接受合法連接，以至于主機(jī)注冊(cè)的 DNS 服務(wù)顯示路由進(jìn)展順利，直到它到達(dá)服務(wù)器并產(chǎn)生 HTTP 522 錯(cuò)誤。522 代碼代表連接超時(shí)，是在驗(yàn)證網(wǎng)絡(luò)服務(wù)器和 DNS 之間的 TCP 連接是否相互同意時(shí)產(chǎn)生的。
更多
- How to Protect Against Slow HTTP Attacks
- Slow Http Post attack in Nginx
- Cloudflare Solution
今天先到這兒，希望對(duì)云原生，技術(shù)領(lǐng)導(dǎo)力， 企業(yè)管理，系統(tǒng)架構(gòu)設(shè)計(jì)與評(píng)估，團(tuán)隊(duì)管理, 項(xiàng)目管理, 產(chǎn)品管管，團(tuán)隊(duì)建設(shè) 有參考作用 , 您可能感興趣的文章:
領(lǐng)導(dǎo)人怎樣帶領(lǐng)好團(tuán)隊(duì)
構(gòu)建創(chuàng)業(yè)公司突擊小團(tuán)隊(duì)
國(guó)際化環(huán)境下系統(tǒng)架構(gòu)演化
微服務(wù)架構(gòu)設(shè)計(jì)
視頻直播平臺(tái)的系統(tǒng)架構(gòu)演化
微服務(wù)與Docker介紹
Docker與CI持續(xù)集成/CD
互聯(lián)網(wǎng)電商購(gòu)物車架構(gòu)演變案例
互聯(lián)網(wǎng)業(yè)務(wù)場(chǎng)景下消息隊(duì)列架構(gòu)
互聯(lián)網(wǎng)高效研發(fā)團(tuán)隊(duì)管理演進(jìn)之一
消息系統(tǒng)架構(gòu)設(shè)計(jì)演進(jìn)
互聯(lián)網(wǎng)電商搜索架構(gòu)演化之一
企業(yè)信息化與軟件工程的迷思
企業(yè)項(xiàng)目化管理介紹
軟件項(xiàng)目成功之要素
人際溝通風(fēng)格介紹一
精益IT組織與分享式領(lǐng)導(dǎo)
學(xué)習(xí)型組織與企業(yè)
企業(yè)創(chuàng)新文化與等級(jí)觀念
組織目標(biāo)與個(gè)人目標(biāo)
初創(chuàng)公司人才招聘與管理
人才公司環(huán)境與企業(yè)文化
企業(yè)文化、團(tuán)隊(duì)文化與知識(shí)共享
高效能的團(tuán)隊(duì)建設(shè)
項(xiàng)目管理溝通計(jì)劃
構(gòu)建高效的研發(fā)與自動(dòng)化運(yùn)維
某大型電商云平臺(tái)實(shí)踐
互聯(lián)網(wǎng)數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)思路
IT基礎(chǔ)架構(gòu)規(guī)劃方案一(網(wǎng)絡(luò)系統(tǒng)規(guī)劃)
餐飲行業(yè)解決方案之客戶分析流程
餐飲行業(yè)解決方案之采購(gòu)戰(zhàn)略制定與實(shí)施流程
餐飲行業(yè)解決方案之業(yè)務(wù)設(shè)計(jì)流程
供應(yīng)鏈需求調(diào)研CheckList
企業(yè)應(yīng)用之性能實(shí)時(shí)度量系統(tǒng)演變
如有想了解更多軟件設(shè)計(jì)與架構(gòu), 系統(tǒng)IT,企業(yè)信息化, 團(tuán)隊(duì)管理 資訊，請(qǐng)關(guān)注我的微信訂閱號(hào)：
文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-844270.html
作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權(quán)歸作者和博客園共有，歡迎轉(zhuǎn)載，但未經(jīng)作者同意必須保留此段聲明，且在文章頁(yè)面明顯位置給出原文連接，否則保留追究法律責(zé)任的權(quán)利。
該文章也同時(shí)發(fā)布在我的獨(dú)立博客中-Petter Liu Blog。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-844270.html
到了這里，關(guān)于慢速 HTTP 拒絕服務(wù)： 分析利用和緩解的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
