应用（第7层）DDoS防护

适用于： ✔️应用网关v2 ✔️前门高级版

Azure Web 应用程序防火墙（WAF）包含多种防御机制，帮助防止分布式阻断服务（DDoS）攻击。 DDoS 攻击可以同时针对网络层（L3/L4）和应用层（L7）。 Azure DDoS 防护可帮助您抵御大规模网络层流量攻击。 Azure WAF，在第 7 层运行，可保护 Web 应用程序免受 HTTP 洪水等 L7 DDoS 攻击。 这些防御措施共同防止攻击者访问您的应用程序，从而影响其可用性和性能。

应用层攻击发起成本低，且难以与合法流量区分：每个请求单独看起来都很有效，只有汇总速率、分发和客户端组合才能揭示攻击。 因此，有效的L7防御更多依赖于攻击 开始前 已存在的分层配置，而非单一控制。

选择你的防御层

规划L7 DDoS防护时，请使用以下型号。 每一层都会捕获其上一层未捕获到的流量。

层	它的作用是什么	在哪里配置
平台DDoS防护	在 Azure 边缘和源站公网 IP 上缓解 L3/L4 容量型攻击	Azure Front Door 默认内置;需要对应用网关的公共 IP 和起源公共 IP 进行 Azure DDoS 网络保护
自动化 L7 层缓解	能够识别您的正常流量，并在流量激增时对异常客户端进行限流，无需紧急调优	Azure Front Door Premium 和 Application Gateway WAF v2 上的 HTTP DDoS 规则集（预览版）
客户端验证	在屏蔽前，将人类和合法客户与自动化攻击流量区分开	Bot Manager 规则集， JavaScript 挑战， 验证码
速率限制	限制任何客户端、地理位置或终端能发送的请求数量	前门和应用网关的速率限制自定义规则
针对性的自定义规则	在事件发生时屏蔽已知的攻击特征	匹配自定义规则（地理位置、IP、ASN、客户端指纹、标头、URI）
原产地保护	这样可以防止攻击流量直接到达你的计算系统	缓存、起源锁定、自动缩放

基线配置检查清单

在被攻击之前完成这些步骤。 调整它们以符合你的申请要求。

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. 启用 机器人管理器管理的规则集 ，以识别并处理已知的恶意机器人。
5. 至少配置一条 包罗万用的速率限制规则 （参见 速率限制）。
6. 把你的原始 实例数量扩大到有足够的空闲容量，并设置应用网关自动扩展，但不强制限制最低最大实例数。
7. 在 Azure Front Door 上启用缓存，从而使突发流量高峰由边缘节点消化，而不是由源站承担。
8. 覆盖你的 L3/L4 暴露，具体因平台而异。 参见 平台DDoS防护因平台而异。 将源站限制为仅接受来自 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 的边缘防护已具备。
• 如果你使用的是 Application Gateway，但尚未启用 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策略分配给多个前门配置文件或多个网关，服务会分别计算每个阈值。
• 敏感度。 每条规则提供三种敏感度等级。 更高的灵敏度会应用较低的阈值;灵敏度越低，阈值越高。 中等是默认且推荐的设置。
• 评估顺序。 WAF首先评估HTTP DDoS规则集，甚至在自定义规则之前。 带有 允许 操作的自定义规则可以绕过所有其他WAF检查，但不会绕过HTTP DDoS规则集。
• 绕过可信流量的规则集。 带有 允许 操作的自定义规则在这里帮不上忙——它绕过了所有其他规则集，但绕过了HTTP DDoS规则集。 改用 WAF例外 ，你可以将例外范围限制在特定的规则、规则组，或整个托管规则集，包括HTTP DDoS规则集。 参见使用例外规则豁免受信任流量。
• 需要持续的交通。 规则集只有在掌握可靠基线后才能行动。 如果某个资源在学习阶段未获得足够的流量，规则集将不会对其进行检测或提供保护，直到其获得足够流量为止。 具体要求请参见平台表。

平台差异

特性	Azure Front Door 高级版	应用程序网关 WAF v2
学习阶段	基线基于滚动时间窗口计算；对于在过去七天中至少有 50% 的时间收到流量的配置文件，将在 24至 36 小时内开始检测	基线至少需要学习 24 小时；规则集要等到 24 小时学习阶段完成后才会进行检测或阻止
流量不足	如果某个配置文件在过去七天中获得流量的时间不足 50%，则规则集在有足够的流量来建立可靠基线之前，不会进行检测或阻断	如果网关在 24 小时学习阶段未接收到足够的流量来建立可靠的基线，规则集在建立起可靠基线之前将不会检测或阻止攻击
Mitigation	违规IP地址会被放入 罚分框 ，并在罚分期间被屏蔽	违规IP地址会被放入 罚分箱 并屏蔽15分钟
规则标识符	500100（客户端请求率），500110（疑似机器人）	500100（客户端请求率），500110（疑似机器人）
其他指标	Web 应用程序防火墙 HTTPDDoSRuleset 已激活	惩罚框大小，惩罚框块

规则集规则

规则集目前包含两条规则。 每条规则维护其独立的流量基线，并可配置其敏感性和操作：

规则	说明
500100：检测到客户端请求率过高异常	为 Front Door 配置文件或策略所附加到的应用程序网关上的所有流量建立基线。 当客户端超过学习阈值时，配置的动作触发，违规IP地址被放入罚分框。
500110：疑似机器人发送高频率请求	为被 Microsoft 威胁情报归类为机器人程序的流量维持单独且通常严格得多的基线。 被归类为高风险的机器人一旦突破全球门槛，将立即被屏蔽。

点球框

两个平台都通过惩罚区来缓解。 当来自某个客户端的流量超过该规则集中某条规则的阈值时，该客户端 IP 地址将被加入惩罚名单，并在惩罚期内被 WAF 阻止；在 Application Gateway 上，此持续时间为 15 分钟。 当该期限结束时，IP 地址将重新获得访问权限；但如果再次超出阈值，则会被重新置于惩罚区。

这种设计对遥测数据的读取很重要：只记录初始规则命中。 在IP地址已经进入惩罚框时，额外被阻断的请求不会在Front Door上记录，因此基于日志的计数低估了被阻断请求的数量。 在 Application Gateway 上，使用 惩罚盒拦截次数 指标来查看实际拦截次数，使用 惩罚盒大小 来查看当前受到惩罚的 IP 地址数量。

预览期间的监控

当某个 IP 地址超过阈值时，系统会记录一条日志，对 HTTP DDoS 规则集执行 阻止 操作，并且 WAF 的 托管规则匹配 指标会增加。

• Frontdoor：使用按规则名称过滤的 Web 应用程序防火墙 请求计数指标来计数块数，以及 Web 应用程序防火墙 HTTPDDoSRuleset Is Active 指标，该指标在学习完成且规则集准备对超出学习阈值的流量采取行动时进行报告1。
• 应用程序网关： 来自被施加惩罚的 IP 地址的后续每个被阻止的请求都会增加“托管规则匹配”指标，而 惩罚箱大小 和 惩罚箱拦截次数 指标则会直接跟踪惩罚箱。

通过例外规则豁免受信任流量

健康探测、合成监控、负载测试、合作伙伴集成和内部批处理作业都会产生看似洪水但实际上并非洪水的流量。 历史上，没有办法将它们从DDoS规则集中豁免，因为自定义 的允许 规则绕过了默认规则集、核心规则集和机器人保护规则集，但故意不绕过HTTP DDoS规则集。

WAF 例外规则弥补了这一缺口。 对于匹配特定属性、范围为单一规则、规则组或整个管理规则集的请求，例外绕过了 WAF 检查。 你可以对HTTP DDoS规则集以及DRS、CRS和机器人防护应用异常。

例外匹配于：

• 远程 IP 地址（等于或 IP 匹配），这通常用于将已知监控、负载测试或合作伙伴来源 IP 范围排除在 DDoS 规则集之外
• 请求 URI
• 请求头名称和值，匹配方式为等于、开头为、结尾为或包含

在 DDoS 规则集中使用例外的指南：

• 范围尽可能狭窄。 更倾向于采用每条规则例外，而不是豁免整个规则集。 范围过宽的例外规则会给攻击者提供一条有据可循的途径，使其能够绕过你的自动化缓解措施。 如果负荷发电机仅需免于遵守规则500100，就不要连规则500110也一并豁免。
• 豁免来源，而不是路径。 针对已知测试框架的基于 IP 的例外情况受到限制。 基于URI的公共端点例外对任何找到它的人来说都是一扇敞开的大门。
• 定期查看它们。 新增的一次性负载测试例外条款可能在一年后仍然有效。
• 注意界限。 每个WAF策略最多支持60个例外，每个前门在所有相关策略中总共支持60个例外。 单个例外最多可包含600个IP地址、10个URI或10个请求头。
• 例外情况需要下一代WAF引擎和管理规则集版本 DRS 2.1或更高版本。

针对不同情况使用合适的工具：排除项 会跳过检查请求中的某个元素（如干扰性的 Cookie 或标头），同时仍检查其余部分；例外 会对匹配的请求跳过特定规则或规则集；自定义 Allow 规则 会绕过除 HTTP DDoS 规则集外的所有内容。

Important

WAF 例外和 HTTP DDoS 规则集在 Azure Front Door 和 Application Gateway WAF v2 上均处于预览阶段。 请参阅 Microsoft Azure 预览版的补充使用条款 。

在你阻止之前先进行质询

在 L7 攻击期间，封禁是一种简单粗暴的手段：攻击流量往往来自那些同样承载真实用户流量的 IP 地址和地区。 挑战机制让你能将自动化与人工区分开，避免直接封锁带来的附带损害，它们是Azure WAF处理L7洪泛处理方式上相较于仅限块速率策略的最大变化。

• JavaScript 挑战 是一个无形挑战，不需要人工干预。 如果浏览器成功计算挑战，WAF会验证客户端为非机器人，并继续评估剩余规则;失败的请求会被阻止。 将其用作常规 Web 流量的默认挑战。 对挑战端点的请求不会转发到后端，也不计入速率限制。
• CAPTCHA 是一种需要用户参与的交互式验证挑战，最好仅用于登录、注册和结账等高价值流程，因为在这些流程中，自动化滥用的成本较高，因此让用户多花几秒钟是可以接受的。 挑战cookie的有效期可在策略设置中配置，时间为5至1440分钟，默认为30分钟。 验证码还会产生额外的基于使用量的费用。

在部署这两个功能之前，请先考虑它们各自的局限性并做好规划：

• 不支持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

• 速率限制按 套接字 IP 地址 适用，即向 Azure Front Door 发起 TCP 连接的客户端地址；该地址可能是代理的地址，而不是最终用户的地址。
• 阈值是在一个或五分钟的固定时间窗口内进行评估的。 一旦阈值被突破，Azure Front Door 会在窗口剩余时间内阻断所有符合规则的流量。 利用 五分钟的时间窗口 来缓解HTTP洪水：攻击者在第一分钟内被阻挡，剩余四分钟内保持被封锁状态。
• 最大窗口和最小可接受阈值是最有效的反DDoS配置。 更大的窗口和更大的阈值也会强制更接近配置的阈值。 在阈值非常低时（大约低于每分钟 200 个请求），部分超过阈值的请求仍可能通过，因为某个客户端发出的请求可能会落在计数器尚未刷新的 Front Door 服务器上。
• 速率限制规则仅支持 Log 和 Block 操作；不支持 Allow。
• 通过匹配长度大于 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或更高版本），在空隔云中不支持。

• 应用程序网关会对该策略所附加到的 每个端点 独立计数阈值。 应用于五个侦听器的单个策略会维护五组计数器。

• 阈值并不严格执行，所以不要用速率限制来做细致的交通控制。 利用它来缓解异常率并保持可用性。 使用宽匹配规则GeoLocationNone时要特别小心;如果阈值选择不当，可能导致合法流量频繁短暂中断。

设定地理感知阈值

一个全球统一的门槛必须宽松到足以适应你业务量最高的国家，这就导致它在其他所有地方都宽松得过头了。 大多数应用在和平时期地理分布明显偏颇——少数国家或地区几乎产生所有合法流量，其余则产生零星流量。 攻击流量很少遵循这种分布。 根据地理范围调整阈值，将这种不对称转化为检测信号和缓解控制。

首先，至少在一周内测量你的和平时期分布，这样工作日、周末和时区的影响就得以体现：

• 在 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
  

然后将结果分组到不同层级，并为每个层级设定阈值：

层	和平时期的分摊	推荐治疗
主要市场	贡献了你大部分流量的国家	每个客户端的阈值都较为宽松，并基于该国自身的 p99 来设定，从而确保真实用户永远不会受到影响
二级市场	有意义但有限的流量	更严格的客户门槛，以该国的p99为准，而非全球标准
长尾地理分布	少量正常流量	激进阈值，或者用挑战动作代替阻挡
你不服务的地区	实际上是零	直接屏蔽，或者重定向到静态页面

如何实现这些层级取决于平台：

• 应用网关WAF v2 ——使用 GroupByVariable: GeoLocation （或 GeoLocationXFFHeader 置于CDN或代理后方）使同一地理位置的所有流量共享计数器，并为每个层创建一个速率限制规则，并带有自己的阈值。 由于泄露会针对该地理区域内的每个客户端，建议保守地调整阈值，并先在日志操作中验证：错误配置的广泛匹配地理规则可能导致合法流量频繁短暂中断。
• Azure Front Door - 计数器是按套接字 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规则，阻挡或限制具有可识别签名的HTTP和HTTPS攻击，如特定用户代理、头部、cookie、查询字符串模式、URI或它们的组合。 除了字符串匹配之外，Azure Front Door WAF 自定义规则还可以根据以下内容进行匹配：

• 地理位置：屏蔽来自服务区域外的流量，或将其重定向到静态页面。
• 客户端 IP 地址（CIDR）和IP 限制列表，用于你识别为恶意的地址和范围。
• 自治系统编号（ASN）：缓解源自托管服务提供商或传输网络、且并非您的合法用户来源的洪泛流量，而无需枚举 IP 范围。
• 客户端指纹 (JA4)：基于 JA4 指纹进行匹配，该指纹是根据客户端的 TLS 握手和 HTTP 特征生成的哈希值。 由于攻击工具和僵尸网络客户端无论发送的IP地址如何都能产生一致的指纹，JA4是分布式攻击中最耐用的签名之一：轮换数千个源IP地址不会改变指纹，封锁或限制指纹只需一条规则就能摧毁整个僵尸网络。 在对其实施强制措施之前，先将该指纹与平时的日志进行核对。 流行的浏览器和常见SDK会在大量合法用户之间共享指纹，因此未经验证的JA4封块可能非常宽泛。 先部署 日志 操作，确认指纹只出现在攻击流量中，然后切换到拦截或速率限制规则。
• 将 JA4 与其他情况结合起来，以便在事故发生时进行手术缓解。 例如，对于特定的 JA4 指纹和你未通过其向用户提供服务的 ASN，或者对于某个 JA4 指纹和请求 URI，可以实施速率限制而不是阻止。
• 服务标签 和请求组件 的大小约束 。

在事件发生时，有两个重要的做法：

• 为已知的合法流量创建 Allow 匹配规则，以减少误报，并将其优先级设为高于阻止规则和速率限制规则（数值更低）。 请记住，允许规则会绕过其他 WAF 检查，但 不会 绕过 HTTP DDoS 规则集。
• 规则评估遇到除 Log 之外的任何操作时都会停止，并且优先级编号必须唯一。 为紧急规则预留一组较低优先级的编号，以便在遭受攻击时插入一条规则而无需重新编号。

托管规则并非针对DDoS防御，但它们能防御其他常见攻击，应保持启用状态。 参见托管规则（Azure Front Door）或托管规则（Application Gateway）。

保护起源

• 锁定源端公共IP的访问，并限制入站流量，只有Azure Front Door或应用网关能访问。 请遵循关于保护流量到Azure Front Door origins的指南。
• 确保应用网关的虚拟网络中没有公开暴露的IP地址。
• 启用 Azure Front Door 缓存。 缓存响应会吸收边缘的峰值流量，降低到达源端的请求率，这往往是性能下降和断线之间的区别。
• 缩放原点与空余空间。 自动化和人工减灾措施需要时间启动;空缺容量弥补了这一空白。

应对主动攻击

1. 确认这是攻击，而不是自然生长。 检查WAF和访问日志，查找请求率、客户端IP数量、地理位置、用户代理分布和请求URI的突然变化。
2. 查看哪些因素已经在起缓解作用。 确认 HTTP DDoS 规则集已启用，并按规则名称查看其拦截情况。 在应用程序网关上，还要检查惩罚框大小和惩罚框块指标，因为日志中仅显示每个 IP 地址的第一个块。 查看速率限制规则匹配项。
3. 将地理分布与你的基线进行比较。 一个流量占比通常较小的国家突然主导了流量，这是一个快速且高置信度的攻击信号。 它还会告诉你应该先收紧哪个级别的利率限制规则。
4. 在制定新规则前提高敏感度。 提高HTTP DDoS规则集敏感性或降低现有速率限制阈值，比在压力下制定新规则更快更安全。
5. 挑战而不是阻挡 交通混合的地方。 对受影响的HTML路由应用JavaScript挑战，对敏感流程应用验证码。
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 质询机制
• Azure Front Door WAF 验证码
• Azure Front Door 上的 DDoS 保护
• Azure DDoS Protection 参考架构
• Azure DDoS 防护概述