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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　類似的規則可以應用到試圖下載圖像數據庫（包含 HTTP 403 “禁止訪問”）的爬取器上，阻斷試圖通過爬取圖像讓服務器過載或竊為己用的僵尸主機。

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

責任編輯：韓希宇