DDoS攻擊走嚮應用層

發起網路層流量洪水？不不不，現在的DDoS攻擊者更鐘愛應用進程。攻擊者注意到人們已經越來越善於防禦大規模分散式拒絕服務(DDoS)攻擊了，於是他們換了個淹沒的目標——應用進程。

DDoS導流專家CloudFlare觀測到，消耗進程CPU時間、磁碟空間、內存分配等高層伺服器資源的網路攻擊急速增加，而靠淹沒網路架構中低層級帶寬資源的傳統DDoS攻擊似乎無甚變化。

5月21日，該雲服務提供商的安全產品經理 Alex Cruz Farmer 表示，通常速率在每天160左右的OSI第七層（應用層）攻擊如今能以每天1000的高速爆發。

與動輒每秒數百GB的垃圾流量洪水相比，這點速度看起來似乎很不值一提，但那是在你不作為接收端系統管理員的情況下：構建合理的應用層攻擊能以每秒相對少量的複雜請求令伺服器進程過載，無需大量數據包即可搞癱目標。

CloudFlare已推出速率限制產品，可搞定殭屍攻擊和應用層DDoS，但Farmer稱該產品經過1年的應用體驗後發現還需增加其他功能。

該產品不是簡單地封鎖流量源，而是讓用戶可以選擇通過CloudFlare的JavaScript或谷歌的reCptcha提出挑戰，作為UI和API緩解措施。

設置一條5分鐘內5次登錄嘗試失敗就禁用的規則很簡單，但這會傷到合法用戶。

1分鐘內登錄4次就很難，手速再快都難以企及，可以用來識別潛在的殭屍主機，應用速度限制並提起人類能通過而殭屍主機通不過的挑戰。

其他更為複雜的速度限制規則也可以設置，從提起 Cloudflare JavaScript 挑戰到鎖定賬戶24小時都可以。

在正式部署前，這些挑戰可以在 Cloudflare 的模擬工具中免費測試。

另一個改變是速度限制工具增加擴展性。對企業客戶而言，該系統現在從源響應頭通過匹配從源返回到CloudFlare的屬性來計算流量。

該功能是為減輕系統管理員維護不斷膨脹的問題IP地址列表而設計的，能使管理員基於此源響應頭觸發速度限制：

「

我們在源處產生一個包頭，添加到返回CloudFlare的響應中。因為匹配的是靜態的頭，我們可以基於該頭的內容設置嚴重性級別。比如說，如果是重複性攻擊，便可往該頭中填入表示嚴重性級別為「高」的值，觸發更長時間的封禁。

除此之外，還有一個用於防護資料庫免受枚舉攻擊的防禦措施，避免攻擊者通過快速逐條查詢記錄而讓資料庫進程鎖死：攻擊者向終端連續快速發送隨機字元串，導致資料庫卡死停頓。

比如說，CloudFlare某客戶就曾遭受過6小時內收到1億條資料庫查詢請求的枚舉攻擊。

由於攻擊者發送的是隨機字元串，任何「查無此記錄」的查詢請求都會產生一個 HTTP 404 錯誤代碼，速度限制就能應用在此處；或者，速度限制也可應用於 HTTP 404 和 HTTP 200 (查詢成功代碼)的組合。

類似的規則可以應用到試圖下載圖像資料庫（包含 HTTP 403 「禁止訪問」）的爬取器上，阻斷試圖通過爬取圖像讓伺服器過載或竊為己用的殭屍主機。

CloudFlare的專業版中，允許設置的規則數量從3條增加到了10條；商業版則更多，可設置15條。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！