應用（第7層）DDoS防護

適用於： ✔️ Application Gateway v2 ✔️ Front Door Premium

Azure Web 應用程式防火牆（WAF）包含多種防禦機制，有助於防止分散式阻斷服務（DDoS）攻擊。 DDoS 攻擊可同時針對網路層（L3/L4）及應用層（L7）。 Azure DDoS 防護能防禦大型網路層的體積攻擊。 Azure WAF 運作於第 7 層，保護網頁應用程式免受 L7 DDoS 攻擊，如 HTTP 洪水。 這些防禦措施共同防止攻擊者入侵你的應用程式，影響其可用性與效能。

應用層攻擊發動成本低廉，且難以區分與合法流量：每個請求本身看起來都很有效，只有匯總速率、分布和客戶端組合才能揭露攻擊。 因此，有效的L7防禦較少依賴單一控制，而是依賴攻擊 開始前 已存在的分層配置。

選擇你的防禦層

規劃 L7 DDoS 防護時，請使用以下模式。 每一層都能接收流量，而上層卻無法。

基線配置檢查清單

在被攻擊前完成這些步驟。 調整它們以符合你的申請需求。

1. 部署 Azure WAF 搭配 Azure Front Door Premium 或 Application Gateway WAF v2，以防範 L7 應用層攻擊。
2. 將 WAF 政策切換到 預防模式。 偵測模式下的政策只會記錄流量，不會阻擋流量。 先驗證並調整針對生產流量的政策以減少誤報，然後再開啟預防功能。
3. 指派 HTTP DDoS 規則集（Azure Front Door Premium 和 Application Gateway WAF v2 均提供），讓自動化緩解在您真正需要它之前，先學習您的流量基準。
4. 啟用 Bot Manager 管理的規則集 ，以識別並處理已知的惡意機器人。
5. 至少設定一條 籠統的速率限制規則 （參見 速率限制）。
6. 將原始 實例數量擴大，確保有足夠的備用容量，並將 Application Gateway 設定為自動擴展，但不強制執行最低最大實例數。
7. 在 Azure Front Door 上啟用快取，讓突發尖峰流量在邊緣節點被吸收，而不是由來源伺服器承受。
8. 涵蓋您的 L3/L4 暴露，這會因平台而異。 請參閱 平台 DDoS 防護因平台而異。 鎖定你的 Origin，只接受來自 Azure Front Door 或 Application Gateway 的流量。
9. 開啟 Log Analytics 的診斷日誌，並在 Analyze WAF 中建立查詢，並在事件發生前存取日誌。

平台 DDoS 防護因平台而異

L7 防禦只有在底層的公共 IP 位址能承受體積攻擊時才有意義，且兩個 Azure WAF 平台並非從同一處開始。

Azure Front Door 預設有平台的 DDoS 防護。 Azure Front Door 是一個全球分布式邊緣服務，其邊緣由 Azure 的基礎設施 DDoS 保護，且無需額外費用且無需設定。 流量會終止於 Front Door 邊緣節點，而不是終止於你所擁有的 IP 位址，因此在 L3/L4 層級上，攻擊者沒有你的公用 IP 可作為攻擊目標。 這種保護是平台本身的，所以你不會為了取得它而購買或啟用任何東西。

應用閘道需要 Azure DDoS 網路保護。 應用閘道是一種區域資源，擁有 你虛擬網路中的公共 IP 位址。 Azure 預設的基礎結構層級保護可保護 Azure 平台本身，但不會針對該 IP 提供經過調校的個別資源緩解措施、遙測資料或攻擊報告。 為了保護閘道的公開 IP 免受 L3/L4 體積攻擊，請在包含該 IP 的虛擬網路上啟用 Azure DDoS 網路防護。 這是付費且另行購買的服務。

選擇或設計部署時的實際後果：

• 如果您位於 Azure Front Door 後方，請將預算編列給 L7 控制項；L3/L4 邊緣防護已經就緒。
• 如果你使用應用閘道器且尚未啟用 DDoS 網路保護，你的 WAF 規則即使被完美調整，仍可被對閘道的公共 IP 進行體積攻擊繞過。 啟用它。
• 不管是哪種情況，你對外公開的 來源公用 IP 仍然需要 Azure DDoS 網路保護，並且必須加以鎖定，讓只有 WAF 服務能夠存取它們。 位於未受保護且可從公網存取的來源伺服器前方的受保護前端，其實並沒有受到保護。

欲了解更多資訊，請參閱 Azure DDoS 防護概述及「用 Azure DDoS 網路保護保護您的應用程式閘道」。

HTTP DDoS 規則集的自動防護（預覽）

像 IP 過濾器、地理過濾和固定速率限制這類靜態控制，往往無法跟上分散式殭屍網路的腳步：門檻是猜測，且永遠開啟，且你必須隨著流量模式演變而重新調整。 HTTP DDoS 規則集是 Azure WAF 首個自動化的第 7 層防護模型，能以最少的使用者設定學習、偵測並防禦。 它目前以預覽版形式提供於 Azure Front Door Premium 和 Application Gateway WAF v2 兩者。 一旦分配，它會持續將正常流量定為基準，當突波顯示攻擊時，會選擇性地阻擋違規客戶端，無需緊急調整。

兩個平台的設計在最重要的方面都相同：

• 兩個門檻，一併評估。 規則集同時學習全域閾值（每個前門設定檔或每個應用閘道）及個別基於 IP 的閾值。 基於 IP 的門檻僅在全域門檻被突破後才會強制執行。 這種設計防止規則集對少數 IP 位址的尖峰產生影響，除非這些尖峰真的讓總流量超過正常值。
• 以各資源為範圍。 閾值是在全球資源層級學習的。 如果您將含有該規則集的一個 WAF 原則指派給多個 Front Door 設定檔或多個閘道器，服務會分別為每個設定檔或閘道器計算閾值。
• 敏感度。 每條規則提供三種靈敏度等級。 較高靈敏度會施加較低的閾值;較低靈敏度會施加更高的閾值。 中等是預設且建議的設定。
• 評估順序。 WAF 會先評估 HTTP DDoS 規則集，甚至在自訂規則之前。 帶有 允許 動作的自訂規則會繞過所有其他 WAF 檢查，但不會繞過 HTTP DDoS 規則集。
• 略過受信任流量的規則集。 帶有 允許 動作的自訂規則在這裡沒用——它繞過了所有其他規則集，但不會繞過 HTTP DDoS 規則集。 改用 WAF 例外 ，你可以將例外範圍限制在特定規則、規則群組，或整個受管理規則集，包括 HTTP DDoS 規則集。 請參閱使用例外狀況豁免可信流量。
• 需要持續的交通。 規則集只有在學會可靠的基線後才能行動。 如果資源在學習階段獲得的流量不足，規則集將無法進行偵測或提供保護，直到其獲得足夠的流量為止。 具體需求請參閱平台表。

平台差異

規則集規則

規則集目前包含兩條規則。 每條規則都維護其獨立的流量基線，並可配置其敏感度與動作：

罰球區

兩個平台都透過 懲罰區 機制來緩解影響。 當用戶端的流量超過規則組某一規則的門檻時，該用戶端 IP 位址會被放入懲罰區，並由 WAF 封鎖，懲罰區持續時間為 15 分鐘，在應用閘道上持續 15 分鐘。 當該期限結束時，IP 位址會重新取得存取權限，除非再次突破門檻，否則會回到罰則框。

這個設計對你讀取遙測數據的方式很重要：只有初始規則命中會被記錄。 在 IP 位址已經在罰則框中時，額外被封鎖的請求不會在 Front Door 上記錄，因此基於日誌的統計低估了被封鎖請求的數量。 在應用閘道上，使用 懲罰盒區塊數 指標表示真實區塊數，並使用懲 罰盒大小 表示目前被懲罰的 IP 位址數量。

預覽期間的監控

當某個 IP 位址超過臨界值時，系統會為 HTTP DDoS 規則集記錄一筆動作為 封鎖 的日誌項目，且 WAF 受管規則比對 指標會增加。

• Front Door：使用 Web 應用程式防火牆 請求計數指標，並依規則名稱篩選來計數區塊數，以及 Web 應用程式防火牆 HTTPDDoSRuleset Is Active 指標，當學習完成且規則集準備好處理突破學習閾值的流量時，該指標會報告1。
• 應用程式閘道： 來自受處罰的 IP 位址之後每個遭封鎖的要求，都會使 Managed Rule Match 指標遞增，而 處罰箱大小 和 處罰箱封鎖次數 指標則會直接追蹤處罰箱。

使用例外規則豁免受信任的流量

健康探測、合成監控、負載測試、合作夥伴整合以及內部批次作業都會產生看似洪水但實際上並非的流量。 歷史上，沒有辦法將它們從 DDoS 規則集中豁免，因為自訂 的允許 規則會繞過預設規則集、核心規則集和機器人防護規則集，但刻意不會繞過 HTTP DDoS 規則集。

WAF 例外 則填補了這個差距。 例外對於符合特定屬性、範圍限定於單一規則、規則群組或整個管理規則集的請求，會繞過 WAF 檢查。 你可以對 HTTP DDoS 規則集以及 DRS、CRS 和 Bot Protection 套用例外。

例外匹配於：

• 遠端 IP 位址（等於或 IP 相符），通常用於將已知的監控、負載測試或合作夥伴來源 IP 範圍排除在 DDoS 規則集之外
• 要求 URI
• 要求標頭名稱和值，透過「等於」、「開頭為」、「結尾為」或「包含」進行比對

關於在 DDoS 規則組中使用例外的指引：

• 盡可能縮小範圍。 偏好每條規則例外，而不是整個規則集都被豁免。 廣泛的例外會讓攻擊者獲得一條繞過自動化緩解措施的書面路徑。 如果負載產生器只需要免於遵循 500100 規則，就不要同時豁免該裝置遵循 500110 規則。
• 排除來源，而非路徑。 針對已知測試框架的 IP 式例外受到限制。 在公開端點上建立基於 URI 的例外，對任何找到它的人來說都是一扇敞開的大門。
• 依照排定時程檢視它們。 對於一次性負載測試新增的例外條款，可能在一年後仍然有效。
• 注意界限。 每個 WAF 政策最多支援 60 個例外，每個 Front Door 在所有相關政策中合計支援 60 個例外。 單一例外最多可包含 600 個 IP 位址、10 個 URI 或 10 個請求標頭。
• 例外情況則需使用次世代 WAF 引擎及管理規則集版本 DRS 2.1 或更新版本。

使用適合工作的工具： 排除項目 跳過請求中一個元素（雜訊的 cookie 或標頭），同時檢查其他部分; 例外 會跳過特定規則或規則集以匹配請求; 自訂的允許規則 會繞過除 HTTP DDoS 規則集外的所有內容。

封鎖前先提出質疑

封鎖在 L7 攻擊中是一種粗暴手段：攻擊流量經常來自同時攜帶真實使用者的 IP 位址和地理位置。 挑戰機制讓你能將自動化與人工分離，避免直接封鎖的附帶損害，這是 Azure WAF 處理 L7 洪水時相較於僅用區塊速率限制策略的最大改變。

• JavaScript 挑戰 是一項隱形挑戰，不需要人工介入。 若瀏覽器成功計算挑戰，WAF 會驗證客戶端為非機器人，並持續評估剩餘規則;失敗的請求會被封鎖。 將其設為一般網站流量的預設挑戰。 對挑戰端點的請求不會轉發到你的後端，也不計入速率限制。
• CAPTCHA 是一種互動式挑戰，需要使用者參與，最適合用於高價值流程，如登入、註冊和結帳，因為自動化濫用成本高昂，且幾秒鐘的使用者摩擦是可以接受的。 挑戰 cookie 有效期可在政策設定中設定，介於 5 至 1,440 分鐘之間，預設為 30 分鐘。 CAPTCHA 會產生按使用量計費的額外費用。

在部署前，請針對這兩種功能的限制做規劃：

• AJAX 和 API 呼叫不被支援。 不要在 API 路由前面設置挑戰。 改為在那裡使用速率限制和比對規則。
• 挑戰是針對HTML資源設計的，不是針對嵌入圖片、CSS或JavaScript檔案。
• 在第一個觸發挑戰的請求中，POST 主體在 Azure Front Door 上被限制為 64 KB，在 Application Gateway 上限制為 128 KB。
• 這兩個功能都不支援 Internet Explorer;兩者都支援目前版本的 Microsoft Edge、Chrome、Firefox 和 Safari。
• 當用戶端的 IP 位址變更時，或在跨來源（CORS）請求時，JavaScript 挑戰會再次觸發。
• 在 Application Gateway 上，JavaScript 挑戰還在預覽階段，且不支援速率限制自訂規則。 容器應用程式閘道 WAF 不支援此功能。

速率限制

至少，建立一個速率限制規則，阻止任何單一用戶端的高速率請求。 將此規則設為最低 優先權 （最高數值）的速率限制規則，以便先評估更具體的速率限制或匹配規則。

Azure Front Door

• 速率限制是根據 socket IP 位址來設定，這是開啟 Azure Front Door TCP 連線的用戶端地址，可能是代理伺服器而非終端使用者。
• 閾值評估時間為固定時間窗口 ，為一 至五分鐘。 一旦超過門檻值，Azure Front Door 就會在該時段的剩餘時間內封鎖所有符合該規則的流量。 利用 五分鐘的時間窗口 來緩解 HTTP 洪水：攻擊者在第一分鐘內被封鎖，剩下的四分鐘內仍被封鎖。
• 較大視窗且閾值最小，是最有效的防 DDoS 配置。 較大的視窗和較大的閾值也會使結果更嚴格地接近所設定的閾值。 在非常低的閾值下（低於約每分鐘 200 個要求），某些超過閾值的要求仍可能通過，因為來自單一用戶端的要求可能會落到計數器尚未重新整理的 Front Door 伺服器上。
• 速率限制規則僅支援 日誌 與 封鎖 動作; 允許 不被支援。
• 藉由比對長度大於 0 的 Host 標頭，將規則套用至所有流量，因為每個對 Azure Front Door 發出的有效要求都具有此標頭。

應用程式閘道 WAF v2

• 速率限制使用 滑動視窗 演算法。 所有符合條件的流量都會在首次超過閾值的時間窗內被丟棄。 從第二個時間範圍開始，將允許達到閾值的流量，藉此對相符的用戶端產生節流效果，而不是完全中斷服務。

• 規則需要 GroupByUserSession 來控制請求的計數方式。 此功能允許你以客戶端 IP 以外的方式限制速率：

  按變數分組	在下列情況下使用
  ClientAddr (預設值)	正常情況下，每個來源 IP 有獨立計數器
  ClientAddrXFFHeader	你的閘道器位於 CDN 或代理伺服器後方，真實客戶端 IP 也在裡面 X-Forwarded-For
  GeoLocation	在地理集中洪水期間，你要限制各國或地區的交通量
  GeoLocationXFFHeader	與上述相同，使用 X-Forwarded-For 中的 IP 位址
  None	針對狹義比對模式 (例如登入頁面或可疑使用者代理程式清單) 共用單一計數器。

• 速率限制規則需要最新的 WAF 引擎（預設規則集請選擇 CRS 3.2 或更新版本），且在空隙雲層中不被支援。

• 應用閘道會獨立計算 每個 政策所附加端點的閾值。 套用於五個接聽器的單一政策會維護五組計數器。

• 門檻並非嚴格執行，因此不要用速率限制來做細緻的交通控制。 利用它來減輕異常率並維持可用性。 對於使用 GeoLocation 或 None 的寬鬆比對規則，請格外小心；門檻值若選擇不當，可能導致合法流量頻繁發生短暫中斷。

設定地理感知閾值

單一的全球門檻必須設得足夠寬鬆，才能因應你業務量最高的國家，這也使它在其他所有地方都顯得過於寬鬆。 大多數應用在和平時期的地理分布非常偏頗——少數國家或地區幾乎產生所有合法流量，其餘則產生少量流量。 攻擊流量很少會遵循這種分佈。 根據地理區域調整閾值大小，將這種不對稱轉化為偵測訊號與緩解控制。

首先，請至少在一整週內測量您的和平時期分布，這樣平日、週末和時區的影響就能被呈現：

• 喺 Azure Front Door 上，將 Request count metric 分割成 ClientCountry 維度。

• 在 Log Analytics 中，請從存取日誌中的用戶端 IP 位址推導國家：

  AzureDiagnostics
  | where Category == "FrontdoorAccessLog"
  | where TimeGenerated > ago(7d)
  | extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
  | summarize Requests = count(), Clients = dcount(clientIp_s) by Country
  | extend ShareOfTraffic = round(100.0 * Requests / toscalar(
        AzureDiagnostics
        | where Category == "FrontdoorAccessLog" and TimeGenerated > ago(7d)
        | count), 2)
  | order by Requests desc
  

然後將結果分組成不同層級，並為每個層級設定門檻：

如何實作這些層級取決於平台：

• 應用閘道 WAF v2 - 使用 GroupByVariable: GeoLocation （或 GeoLocationXFFHeader 在 CDN 或代理伺服器後方）讓同一地理區域的所有流量共用一個計數器，並為每個層級建立一條速率限制規則，並建立自己的門檻。 由於入侵會對該地理位置的每個用戶端產生影響，因此請保守地調整這些閾值的規模，並先在記錄動作中進行驗證：設定不當的廣泛比對地理規則可能會對合法流量造成頻繁的短暫中斷。
• Azure Front Door - 計數器是依 socket IP 位址設定的，所以應該用地理匹配條件來建立分層：每個分層設定一條速率限制規則，並在相關國家配對，每個國家都有自己的門檻。 長尾地理位置中的每個用戶端所獲得的流量上限，會遠低於主要市場中的用戶端，且單一用戶端的行為不會影響其他用戶端。

以下是幾種保持可維護性的做法：

• 規則依序從最具體到最不具體排序：初級市場規則優先權較高（數值較低），其次是次要規則，最後是長尾規則，全域包容規則則是最低優先權的利率上限規則。
• 針對長尾地理位置，建議優先採用挑戰動作，而不是直接封鎖。 來自一個合法流量不大的國家的流量整體上令人懷疑，但仍包含真實用戶——旅客、VPN 用戶和遠端員工。
• 行銷啟動、區域擴張及重大產品活動後重新衡量。 具地理感知能力的配置，其效果取決於據以決定其規模的基準。
• 事件期間要留意反向指標：某個平時僅占整體流量 1% 的國家，若突然占到 40%，這是最快能確認你所見的是攻擊而非自然增長的方法之一。

從您的流量中選擇門檻

使用下列 Log Analytics 查詢來評估全部攔截規則的大小。 針對應用程式閘道，請以 FrontdoorAccessLog 取代 ApplicationGatewayAccessLog。

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| summarize count() by bin(TimeGenerated, 5m), clientIp_s
| summarize max(count_), percentile(count_, 99), percentile(count_, 95)

若要設定前述各地區的門檻值，請將國家新增至同一個查詢中：

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| extend Country = tostring(geo_info_from_ip_address(clientIp_s).country)
| summarize count() by bin(TimeGenerated, 5m), clientIp_s, Country
| summarize max(count_), percentile(count_, 99), percentile(count_, 95) by Country
| order by percentile_count__99 desc

將門檻設在和平時期交通的第99百分位以上，而非最高值。 最大值通常來自爬蟲程式或設定錯誤的用戶端，而若依此來設定大小，會使規則過於寬鬆，無法在遭受攻擊時發揮作用。

針對性緩解的自訂規則

建立自訂 WAF 規則，以阻擋或限制具有可識別簽名（如特定使用者代理、標頭、Cookie、查詢字串模式、URI 或其組合）的 HTTP 與 HTTPS 攻擊。 除了字串比對外，Azure Front Door WAF 自訂規則還可針對下列項目進行比對：

• 地理位置：封鎖來自服務區域外的流量，或將其導向靜態頁面。
• 用戶端 IP 位址（CIDR）以及你識別為惡意的位址和範圍的 IP 限制清單。
• AS 編號 (ASN)：緩解源自託管服務提供者或轉傳網路 (且合法使用者並非來自該處) 的洪水攻擊，而無需手動列舉 IP 範圍。
• 用戶端指紋（JA4）：比對 JA4 指紋，這是一種根據用戶端的 TLS 握手與 HTTP 特性計算出的雜湊值。 由於攻擊工具和殭屍網路用戶端無論從哪個 IP 位址發送都能產生一致的指紋，JA4 是分散式攻擊中最持久的簽名之一：輪換數千個來源 IP 地址不會改變指紋，封鎖或限制指紋則用一條規則摧毀整個殭屍網路。 在對其強制執行之前，請先將該指紋與平時的記錄比對。 熱門瀏覽器和常見的 SDK 會在大量合法用戶之間共享指紋，因此未經驗證的 JA4 封鎖可能非常廣泛。 先部署 日誌 動作，確認指紋只出現在攻擊流量中，然後切換到 Block 或速率限制規則。
• 將 JA4 與其他條件結合，以便在事件期間進行精準緩解。 例如，對特定的 JA4 指紋 和 你未提供服務給使用者的 ASN，或 JA4 指紋 和 請求 URI 採取速率限制，而不是封鎖。
• 請求元件的服務標籤與大小限制。

在事件發生時，有兩個重要的做法：

• 為已知合法流量建立 允許 匹配規則，以減少誤報，並賦予它們比封鎖和速率限制規則更高的優先權（數值較低）。 請記得，允許規則可以繞過其他 WAF 檢查，但 不會 繞過 HTTP DDoS 規則集。
• 規則評估會在除 Log 以外的任何動作時停止，優先順序號碼必須是唯一的。 保留一段低優先權號碼供緊急規則使用，這樣在遭受攻擊時就能插入一條規則，而不必重新編號。

受管規則並非針對 DDoS 防禦，但它們能防範其他常見攻擊，應該持續啟用。 請參閱管理規則（Azure Front Door）或管理規則（應用閘道）。

保護起源

• 鎖定來源端的公共 IP 存取，並限制入站流量，只有 Azure Front Door 或 Application Gateway 能存取。 請遵循有關保護 Azure Front Door 原始伺服器的流量的指引。
• 確保應用閘道的虛擬網路中沒有公開暴露的 IP 位址。
• 在 Azure Front Door 上啟用快取。 快取回應會在邊緣吸收流量高峰，並降低到達來源站的請求速率，而這往往就是效能下降與服務中斷之間的差別。
• 為原始伺服器擴展容量並保留空餘空間。 自動化與人工減災措施需要時間才能啟動;備用容量則填補了這個空缺。

回應主動攻擊

1. 確認這是攻擊，不是有機生長。 檢查 WAF 和存取日誌，看看請求率、用戶端 IP 數量、地理組合、使用者代理分布和請求的 URI 是否有突然變動。
2. 檢查哪些措施已在發揮緩解作用。 確認 HTTP DDoS 規則集是否有效，並依規則名稱檢視其封鎖。 在應用程式閘道上，也請檢查 [懲罰盒大小] 和 [懲罰盒區塊] 這兩個計量，因為記錄中只會顯示每個 IP 位址的第一個封鎖事件。 檢視費率上限規則的匹配。
3. 將地理分布與你的基準比較。 一個平時僅占少量流量的國家，若突然占據主導地位，便是明確且高度可信的攻擊訊號。 它也會告訴你應該先收緊哪一級的利率限制規則。
4. 在制定新規則前，先提高敏感度。 提高 HTTP DDoS 規則集的敏感度或降低現有速率限制門檻，比在壓力下撰寫新規則更快更安全。
5. 挑戰而非封鎖流量混合區。 對受影響的 HTML 路由套用 JavaScript 挑戰，對敏感流程套用 CAPTCHA。
6. 只有在你確定出一個持久簽名後，才撰寫針對性的規則：ASN、客戶端指紋、標頭組合、地理位置或 URI 模式。 如果模式也與真實使用者相符，請先在日誌動作中部署。
7. 在調整時確保來源站受到保護：確認快取已啟用、確認來源站已鎖定存取，然後進行橫向擴展。
8. 事件發生後，請 根據新的交通數據重新設定你的速率上限門檻，並且在日誌模式下保留正確的緊急規則，以免它們持續被執行。

分析 WAF 與存取日誌

利用 Azure WAF 日誌監控流量異常，並用以識別發送異常大量請求、異常使用者代理字串或異常查詢字串模式的可疑 IP 位址。

Azure Front Door

AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"

Azure 應用程式閘道

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"

攻擊視窗上的頂尖通話者與頂尖用戶代理（顯示為 Azure Front Door;替代ApplicationGatewayAccessLog應用閘道）：

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by clientIp_s
| top 20 by Requests desc

AzureDiagnostics
| where Category == "FrontdoorAccessLog"
| where TimeGenerated > ago(1h)
| summarize Requests = count() by userAgent_s, requestUri_s
| top 20 by Requests desc

欲了解更多資訊，請參閱 Azure WAF with Azure Front Door 及 Azure WAF with Azure 應用程式閘道。

相關內容

• HTTP DDoS ruleset： Azure Front Door WAF | Application Gateway WAF
• WAF 例外列表：Azure Front Door WAF | Application Gateway WAF
• 速率限制：Azure Front Door WAF | Application Gateway WAF
• WAF 設定：Azure Front Door | Application Gateway
• Azure WAF JavaScript challenge
• Azure Front Door WAF CAPTCHA
• Azure Front Door 上的 DDoS 防護
• Azure DDoS Protection 參考架構
• Azure DDoS 防護概述