适用于： ✔️应用网关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） |
| 原产地保护 | 这样可以防止攻击流量直接到达你的计算系统 | 缓存、起源锁定、自动缩放 |
基线配置检查清单
在被攻击之前完成这些步骤。 调整它们以符合你的申请要求。
- 部署Azure WAF，配合Azure Front Door Premium或Application Gateway WAF v2，以防范L7应用层攻击。
- 将WAF策略切换到 预防模式。 检测模式下的策略只记录流量，不会阻断流量。 先针对生产流量验证并调优策略，以减少误报，然后再启用防护。
- 分配HTTP DDoS规则集（在Azure Front Door Premium和Application Gateway WAF v2上都支持），这样自动化缓解就是在你需要流量基线之前就学会了。
- 启用 机器人管理器管理的规则集 ，以识别并处理已知的恶意机器人。
- 至少配置一条 包罗万用的速率限制规则 （参见 速率限制）。
- 把你的原始 实例数量扩大到有足够的空闲容量，并设置应用网关自动扩展，但不强制限制最低最大实例数。
- 在 Azure Front Door 上启用缓存，这样突发流量高峰将由边缘节点消化，而不是由源站承受。
- 覆盖 L3/L4 的范围，具体因平台而异。 参见 平台DDoS防护因平台而异。 锁定你的源站，使其仅接受来自 Azure Front Door 或 Application Gateway 的流量。
- 在Log Analytics中开启诊断日志，并在Analyze WAF中构建查询，并在事件发生前访问日志。
平台的DDoS防护因平台而异
只有在底层公网 IP 地址能扛住流量型攻击时，L7 防御才有意义，而两种 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 服务可以访问这些 IP。 位于未受保护且可被公网访问的源站前面的受保护前端，并不能算是受保护的。
欲了解更多信息，请参阅 Azure DDoS 防护概述和“用 Azure DDoS 网络保护保护您的应用网关”。
HTTP DDoS 规则集的自动防护（预览）
静态控制措施（如 IP 过滤器、地理位置过滤和固定速率限制）往往难以应对分布式僵尸网络：阈值往往只是估算出来的，它们始终处于启用状态，而且你还必须随着流量模式的变化不断重新调整。 HTTP DDoS 规则集是 Azure WAF 首个自动化的第7层保护模型，能够在最小用户配置下学习、检测并防御。 它已在这两者 Azure Front Door Premium 和 Application Gateway WAF v2 上提供预览版。 一旦部署，它会持续建立正常流量基线；当流量激增表明遭受攻击时，会选择性地屏蔽恶意客户端，而无需进行紧急调优。
两个平台的设计在最重要的方面是一致的：
- 两个阈值，一起评估。 该规则集既会学习到全局阈值（针对每个 Front Door 配置文件或每个应用程序网关），也会学习到基于各个 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 小时学习阶段内未接收到足够的流量来建立可靠的基线，则规则集在建立起可靠基线之前将无法检测或阻止攻击 |
| 缓解措施 | 违规IP地址会被放入 罚分框 ，并在罚分期间被屏蔽 | 违规IP地址会被放入 罚分箱 并屏蔽15分钟 |
| 规则标识符 | 500100（客户端请求率），500110（疑似机器人） | 500100（客户端请求率），500110（疑似机器人） |
| 其他指标 | Web 应用程序防火墙 HTTPDDoSRuleset 已激活 | 罚球区大小，罚球区阻挡次数 |
规则集规则
规则集目前包含两条规则。 每条规则维护其独立的流量基线，并可配置其敏感性和操作：
| 规则 | Description |
|---|---|
| 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会验证客户端为非机器人，并继续评估剩余规则;失败的请求会被阻止。 把它当作普通网络流量的默认挑战。 对挑战端点的请求不会转发到后端，也不计入速率限制。
- 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 服务器上。
- 速率限制规则仅支持记录和阻止操作；允许不受支持。
- 通过匹配长度大于 0 的
Host标头，将规则应用于所有流量，因为发往 Azure Front Door 的每个有效请求都具有该标头。
应用程序网关 WAF v2
速率限制使用 滑动窗口 算法。 所有匹配的流量都会在首次超过阈值的时间窗口内被丢弃。 从第二个窗口开始，允许不超过阈值的流量通过，因此对于命中的客户端，产生的是限流效果，而不是完全中断服务。
规则需要一个 GroupByUserSession，用于控制请求的计数方式。 这个功能允许你用客户端IP以外的方式限制速率：
按变量分组 在以下情况下使用 ClientAddr（默认值）正常情况下，每个源IP有独立计数器 ClientAddrXFFHeader你的网关位于CDN或代理后面，真实客户端IP就在里面 X-Forwarded-ForGeoLocation你希望在地理集中洪水期间限制各国/地区的交通量 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 的组合实施速率限制。
- 服务标签 和请求组件 的大小约束 。
在事件发生时，有两个重要的做法：
- 为已知合法流量创建 允许 匹配规则，以减少误报，并将其优先级设置得高于阻止规则和限速规则（即数值更低）。 请记住，允许规则会绕过其他 WAF 检查，但 不会 绕过 HTTP DDoS 规则集。
- 规则评估遇到除 Log 之外的任何操作时都会停止，且优先级编号必须唯一。 为紧急规则预留一组较低优先级的编号，以便在遭受攻击时插入一条规则而无需重新编号。
托管规则并非针对DDoS防御，但它们能防御其他常见攻击，应保持启用状态。 参见托管规则（Azure Front Door）或托管规则（Application Gateway）。
保护起源
- 锁定源端公共IP的访问，并限制入站流量，只有Azure Front Door或应用网关能访问。 请遵循有关保护发往 Azure Front Door 源站的流量的指导。
- 确保应用网关的虚拟网络中没有公开暴露的IP地址。
- 启用 Azure Front Door 缓存。 缓存响应会吸收边缘的峰值流量，降低到达源端的请求率，这往往是性能下降和断线之间的区别。
- 按留白空间缩放原点。 自动化和人工减灾措施需要时间启动;空缺容量弥补了这一空白。
应对主动攻击
- 确认这是攻击，而不是自然生长。 检查WAF和访问日志，查找请求率、客户端IP数量、地理位置、用户代理分布和请求URI的突然变化。
- 查看哪些措施已经在起到缓解作用。 确认 HTTP DDoS 规则集已启用，并按规则名称查看其拦截记录。 在 Application Gateway 上，也请检查 封禁列表大小 和 封禁列表拦截数 指标，因为日志中只会显示每个 IP 地址的第一次封锁。 查看速率限制规则匹配情况。
- 将地理分布与你的基线进行比较。 一个通常流量占比较小的国家突然主导整体流量，是一个可快速识别且高置信度的攻击信号。 它还会告诉你应该先收紧哪个级别的利率限制规则。
- 在制定新规则前提高敏感度。 提高HTTP DDoS规则集敏感性或降低现有速率限制阈值，比在压力下制定新规则更快更安全。
- 挑战而不是阻挡 交通混合的地方。 对受影响的HTML路由应用JavaScript挑战，对敏感流程应用验证码。
- 只有在识别出稳定特征后，才编写定向规则：ASN、客户端指纹、请求头组合、地理区域或 URI 模式。 如果模式也与真实用户匹配，建议先在日志操作中部署。
- 在进行调优时保护好源站：验证已启用缓存，确认源站访问已锁定，并进行横向扩展。
- 事故发生后，根据 新的交通数据重新设定速率上限阈值，并保留日志模式中准确的紧急规则，以防它们持续执行。
分析WAF和访问日志
使用Azure WAF日志监控流量异常，并用以识别发送异常大量请求、异常用户代理字符串或异常查询字符串模式的可疑IP地址。
Azure Front Door
AzureDiagnostics
| where Category == "FrontdoorWebApplicationFirewallLog"
Azure 应用程序网关
AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
攻击期间的主要通信方和主要用户代理（此处显示 Azure Front Door；对于 Application Gateway，请替换为 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 上的 DDoS 保护
- Azure DDoS Protection 参考架构
- Azure DDoS 防护概述