日前，Netflix 發布了一篇博文，闡述了在微服務架構中緩解應用程序 DDoS 攻擊的策略。該博文概要闡述了如何識別觸發這種攻擊的請求，如何使用開源的 Repulsive Grizzly 和 Cloud Kraken 框架進行測試，最后，還提供了保護系統的一些最佳實踐。
Netflix 應用程序安全專家 Scott Behrens 與產品和應用程序安全主管 Bryan Payne 首先指出，微服務架構特別容易受到應用程序 DDoS 攻擊，這是因為頻繁的 API 調用會導致服務周圍產生多個網絡跳躍（ network hops），很容易導致系統攻擊自身：
“微服務架構中的單一請求可能會生成數以萬計的復雜中間層和后端服務調用。”
這些應用程序 DDoS 攻擊帶來的第一個挑戰是識別。有些看起來像是用戶合法的 API 調用，當這種調用即將引發大量內部資源消耗時，如何及時檢測出來？
他們列出的首要策略之一就是確定 API 調用需要多長時間。這里我們不會監控前端的請求時間，這有可能會帶來誤報，監控后端服務的請求時間更為有利。然后對這些請求進行逆向工程，以確定哪種原始 API 調用可能會觸發它。
當開發人員找尋出這些 API 調用時，它是一個查看請求本身的過程，并找出可以使其更為耗時的方法。比如，我們可以擴大搜索請求中的范圍參數，以獲得更大的結果集。在確定是否找到了正確的請求時，可以使用錯誤指示器（indicator），比如速率限制和異常，或簡單地增加延遲。
一旦開發人員確定了這些請求，我們建議使用 Repulsive Grizzly （一個應用層 DDoS 測試框架）來運行它們。它并非一個識別工具，它會針對被測系統觸發這些請求，從而提供了一種簡化測試過程的方法。
他們還引入了 Cloudly Kraken，這是一個開源的 AWS 測試工具，有助于在全球范圍內協調測試運行。這是通過管理一組可擴展的跨區域 AWS 實例完成的，每個實例都運行 Repulsive Grizzly 測試套件。它還提供時間同步功能，確保測試并行運行。
一旦請求被識別并通過測試驗證，我們會建議采取以下緩解策略：
生成這樣的一種架構，最大限度減小微服務之間的依賴關系。如果一個服務失敗，理想狀況下，它應該實現故障隔離，而不會影響其他服務。了解服務隊列和服務請求。例如，限制批量大小或請求的對象。提供從后端服務到 Web 應用程序防火墻的反饋環路。這為它提供了在 API 調用時下游資源利用率的額外信息，在很多 Web 應用程序防火墻的部署中，它只會監控邊緣（edge）服務器，無法得到請求對 API 網關的影響。監視緩存未命中，多數情況下可能是因為高速緩存未正確配置。利用客戶端的各種彈性模式，如斷路器和超時設定。完整的博文可以點此處在線閱讀，在文章中作者通過案例研究深入分析了該主題。
查看英文原文： Netflix: Application DDoS Protection in Microservice Architectures
京公網安備 11010502049343號