Azure Web 应用程序防火墙（WAF）可保护 Web 应用程序免受常见的 HTTP 层攻击，例如 SQL 注入、跨站点脚本（XSS）和路径遍历。 与 Azure 防火墙 不同，后者会检查第 3 到第 7 层的流量，以检测网络层面的威胁；而 WAF 仅在第 7 层运行，并理解 HTTP 语义，包括请求标头、查询字符串、请求正文和 Cookie。 将 WAF 以关联到 Azure 应用程序网关（区域）或 Azure Front Door（全局边缘）二者之一的策略形式进行部署，使保护范围与应用程序架构相匹配。
本文介绍的内容
本文介绍使用 Azure Web 应用程序防火墙 的 HTTP 层保护。 了解以下内容：
- 应用程序网关 v2 上的 WAF 与 Azure Front Door 上的 WAF 之间的平台比较。
- 基于 OWASP 的规则集，包括默认规则集（DRS）和核心规则集（CRS）。
- 检测模式与预防模式以及何时使用每个模式。
- WAF 策略范围选项：全局、每个站点和每个侦听器关联。
- 速率限制、地理筛选和特定于应用程序的逻辑的自定义规则。
- WAF（第 7 层 HTTP）和Azure 防火墙（第 3-7 层网络）之间的区别。
谁需要本文
当工作负荷满足以下一个或多个条件时部署 WAF：
- 面向公众的 Web 应用程序： 您的应用程序接收来自互联网的入站 HTTP/HTTPS 流量，因此会面临 OWASP Top 10 漏洞风险，包括注入攻击、对失效身份验证的利用以及敏感数据泄露尝试。
- 合规性要求： PCI DSS（支付卡行业数据安全标准）等监管框架在处理支付卡数据的任何应用程序前强制实施 Web 应用程序防火墙。
- API 保护： API 是可公开访问的，需要防范网络防火墙不检查的请求走私、超大有效负载和协议级攻击。
- 机器人缓解： 你需要对自动流量进行分类和控制，同时阻止恶意机器人，同时允许合法的爬网程序和监视服务。
不需要 HTTP 请求检查的网络级流量筛选（IP、端口和协议）的组织应改用Azure 防火墙或 NSG。
直接转移焦点： 许多重新托管的内部应用没有 Internet 入口，不需要 WAF。 仅在迁移期间或迁移后向 Internet 公开 Web 应用时添加 WAF。
现代化重点：对于面向客户的 Web 应用，可针对全球应用在 Azure Front Door 上使用 WAF，或者针对单区域应用在 Application Gateway 上使用 WAF，这应与您选择 Front Door 还是 Traffic Manager 作为交付方案保持一致。
跨云重点：对于已迁移的公共 Web 应用程序，在辐射网络中的应用程序网关上部署第 7 层 WAF，并将其他云中的 Web 防护功能（例如 Google Cloud Armor）对应到 Azure WAF。
Azure WAF 平台比较
Azure WAF 在两个平台上可用。 每个平台都会将 WAF 检查集成到流量流中的不同点。
| Capability | 应用程序网关 v2 上的 WAF | Azure Front Door上的 WAF |
|---|---|---|
| 部署范围 | 区域（单个 Azure 区域） | 全球（全球拥有 192+ 个边缘 PoP 节点） |
| 检查点 | 流量到达您的地区后 | 在边缘 PoP 处，在流量到达源站之前 |
| 支持的规则集 | DRS 2.2、DRS 2.1、CRS 3.2 | DRS 2.2、DRS 2.1、DRS 2.0 |
| 自定义规则 | ✔ | ✔ |
| 机器人防护 | ✔ | ✔ （仅限高级层） |
| 速率限制 | ✔ | ✔ |
| Geo-filtering | ✔ | ✔ |
| 每个站点的策略 | ✔（每个侦听器、每个路径） | ✔（每个端点） |
| 托管规则集 | ✔ | ✔ （仅限高级层;标准仅支持自定义规则） |
| 请求正文检查 | 最多 128 KB（可配置） | 最多 128 KB（可配置） |
| 专用链接 源站支持 | N/A （与应用网关内联） | ✔ （私有源站连通性） |
| 最适用于 | 单区域应用、L7 负载均衡 + WAF | 多地域应用，全局加速 + WAF |
注释
Azure Front Door 有两个层：标准层和高级层。 托管规则集（包括 DRS 和机器人保护）仅在 Front Door Premium 上可用。 Front Door Standard 仅支持自定义规则。 Front Door （经典版）仅支持 DRS 1.1 或更早版本。
如何选择 WAF 平台
使用以下决策条件：
- 当应用程序部署在单个区域中，且你已经使用 Application Gateway 进行第 7 层负载均衡、TLS 终止或基于路径的路由时，请选择 Application Gateway 上的 WAF。 WAF 以内联方式提供 HTTP 检测，无需引入额外的服务跳转。
- 当应用程序跨越多个区域、需要全局负载均衡或内容分发网络（CDN）加速的好处时，请在Azure Front Door上选择 WAF。 Front Door WAF 在最近的边缘接入点 (PoP) 检查流量。 该服务会在恶意请求通过 Azure 骨干网到达源站之前将其拦截。 此方法可减少攻击面暴露并吸收边缘第 7 层的体积攻击。
- 当 Front Door 提供的多区域应用程序也需要每个后端不同的区域 WAF 策略时，请选择这两种策略（分层）。 Front Door 提供第一道全局防护，而 Application Gateway WAF 则在更靠近工作负载的位置应用区域特定的自定义规则。
设计注意事项
直接迁移 WAF 设计焦点
- 对于仅限内部使用且没有来自互联网的入站路径的重新托管工作负载，可跳过 WAF；当您将应用发布到互联网时，再重新评估。
- 当您确实需要对外暴露 Web 应用时，先以检测模式启动 WAF，为流量建立基线；然后在调优以排除误报后，再切换到防护模式。
- 将应用程序网关 WAF 用于已使用应用程序网关进行第 7 层路由的单区域重新托管 Web 应用。
- 将本地部署的 Web 防护规则（例如 OWASP 覆盖）的设计意图沿用为起始策略。
推动 WAF 设计现代化
- 对于面向客户的应用，应从一开始就以预防模式运行 WAF，并采用最新的托管规则集，使防护覆盖范围能够自动跟进 OWASP 中出现的新威胁。
- 启用机器人管理，以区分针对您的公共应用的合法爬虫和恶意自动化。
- 以代码方式管理 WAF 策略，使双活区域后端通过部署流水线保持同步。
- 将边缘 WAF 与中心防火墙配对以进行深度防御，并通过在 VNet 上启用 DDoS 网络保护来启用应用程序网关 WAF 计费折扣。
跨云 WAF 设计重点
- 在辐射型 VNet 中的应用程序网关上部署第 7 层 WAF，以便在不将公共 IP 直接分配给虚拟机的情况下，对公共 Web 流量进行检查。
- 将现有 Web 保护从其他云（例如 AWS WAF 或 Google Cloud Armor）映射到Azure WAF 托管规则集，以便覆盖范围。
- 通过 WAF 检查面向公众的流量，并将东西向和跨云传输流量检查保留在 虚拟 WAN 中心防火墙上。
- 在切换期间，先将 WAF 运行在检测（学习）模式下，确认正常流量模式后，再切换为强制执行模式。
先决条件
在部署Azure Web 应用程序防火墙之前，请确保具备：
- 应用程序网关 v2 或 Azure Front Door 资源：WAF 以关联到这些平台之一的策略形式部署。 在创建并关联 WAF 策略之前，必须先拥有一个已预配的 Application Gateway v2 实例或 Azure Front Door 配置文件。
- 面向公众的 HTTP/HTTPS 工作负载： 应用程序必须接收入站 HTTP/HTTPS 流量。 WAF 会检查请求级语义，并且对非 HTTP 工作负荷或纯粹的内部服务没有好处。
- 了解 HTTP 流量模式： 熟悉应用程序的正常请求模式（标头、查询参数和正文内容），有助于在检测到预防模式转换期间配置排除项和优化规则，以最大程度地减少误报。
规则集和规则处理
WAF 使用规则集来检测 HTTP 请求中的恶意模式。 了解规则层次结构和处理顺序有助于优化特定应用程序的 WAF。
托管规则集
Microsoft基于 OWASP 核心规则集（CRS）模式维护托管规则集。 新部署的建议规则集是 DRS 2.2 （默认规则集）。 DRS 2.2 基于 OWASP CRS 3.3.4 构建，并添加了Microsoft威胁智能签名。
| 规则集 | 基于 | 平台支持 | Recommendation |
|---|---|---|---|
| DRS 2.2 | OWASP CRS 3.3.4 + Microsoft威胁 Intel | 应用网关 v2，Front Door Premium | 建议用于新部署 |
| DRS 2.1 | OWASP CRS 3.3 | 应用网关 v2，Front Door Premium | 上一代；两个平台均支持 |
| DRS 2.0 | OWASP CRS 3.2 | 仅限 Front Door 高级版 | 受支持；Front Door N-2 版本 |
| CRS 3.2 | OWASP CRS 3.2 | 仅限应用网关 v2 | 支持;将 DRS 2.2 用于新部署 |
DRS 和 CRS 规则集使用 异常评分。 每条匹配规则都会贡献一个分值，而不是立即阻止该请求。 当累积异常分数超过可配置阈值时，WAF 会采取相应操作（阻止或记录日志）。 与基于单条规则的拦截相比，这种方法可减少误报，因为单次低置信度匹配不会触发拦截。
自定义规则
自定义规则在托管规则 之前 执行，并使用优先级数字来控制评估顺序（较低的数字 = 更高的优先级）。 对以下项使用自定义规则：
- 速率限制： 限制时间范围内每个客户端 IP 的请求，以缓解凭据填充和暴力攻击。
- 地理筛选： 根据客户端的源国家或地区允许或拒绝流量。
- IP 允许列表和拒止列表： 在托管规则进行评估之前，允许已知合作伙伴的 IP 或阻止已知的恶意行为者。
- 请求标头检查： 强制实施特定于应用程序的要求，例如必需的 API 密钥或预期的内容类型。
机器人保护规则集
这两个平台都提供了一个机器人保护规则集，该规则集将自动流量分类为良好的机器人（经验证的搜索引擎）、错误的机器人（已知的恶意扫描程序）和未知机器人。 为每个类别配置操作：允许良好的机器人、阻止错误的机器人，以及使用速率限制或 CAPTCHA 挑战未知机器人。
检测模式与预防模式
WAF 策略采用以下两种模式之一运行，确定系统如何处理匹配的请求：
| Mode | Behavior | 用例 |
|---|---|---|
| 检测 | 记录匹配到的请求，但不拦截这些请求。 请求将继续发送到后端。 | 初始部署和规则优化。 监控哪些规则会被触发，且不影响生产流量。 |
| 预防 | 阻止匹配的请求并返回 403 响应。 将被阻止的请求记入日志。 | 规则优化完成后的生产工作负荷。 主动防范攻击。 |
推荐的调优工作流程
- 在检测模式下部署： 在检测模式下使用所选规则集启用 WAF。 将生产流量通过 WAF 转发。
- 分析日志： 查看 WAF 日志以识别误报。 确定会在合法的应用程序流量中触发的规则。
- 创建排除项： 对于生成误报的规则，请定义指定请求字段（标头、Cookie 和查询参数）的排除项，以跳过特定规则。
- 切换到防护模式： 在检测日志连续 1-2 周保持干净且误报率处于可接受范围内后，切换到防护模式以实施主动拦截。
- 持续监视： 切换到“防护”模式后继续监视日志。 新的应用程序功能或 API 更改可能会引入新的误报模式。
Important
始终在预防模式下运行生产工作负荷。 检测模式不提供保护。 它仅记录潜在的攻击。 仅在初始优化阶段或排查特定误报问题时使用检测模式。
WAF 策略范围和关联
WAF 策略是一个独立的Azure资源，其中包含模式选择、规则集配置、自定义规则和排除项。 将策略与一个或多个目标相关联，以控制保护范围。
应用程序网关 WAF 策略范围
在应用程序网关上，将 WAF 策略关联到三个粒度级别：
- 全局（网关范围）： 该策略适用于应用程序网关上的所有侦听器和路径规则。 当网关后面的所有应用程序共享相同的保护要求时，请使用全局范围。
- 侦听器级别： 不同的 WAF 策略适用于特定的侦听器（主机名和端口组合）。 当多个应用程序共享网关但需要不同的规则优化或排除时，请使用侦听器级范围。
- 路径规则级别： WAF 策略适用于侦听器中的特定 URL 路径规则。 使用路径规则范围对具有不同后端敏感度的应用程序进行精细控制。
当多个作用域适用于单个请求时，最具体的策略优先：路径规则优先于侦听器级策略，而侦听器级策略又优先于全局策略。
Front Door WAF 策略范围
在 Front Door 中，WAF 策略可在终结点级别或路由级别关联。 每个 Front Door 终端节点都可以拥有各自的 WAF 策略。 这种方法支持在单个 Front Door 实例中使用特定于应用程序的保护配置文件。
跨资源共享策略
在多个应用程序网关实例或 Front Door 终结点之间共享同一个 WAF 策略。 Azure 防火墙管理器 可跨所有 WAF 策略提供集中查看和管理能力，无论使用何种平台。 当多个资源需要相同的保护来简化管理和保持一致的安全态势时，请使用共享策略。
与 Azure 防火墙 的区别
WAF 和Azure 防火墙保护网络堆栈的不同层，并提供互补角色。 部署这两者以进行深度防御。
| Attribute | Web 应用程序防火墙 | Azure 防火墙 |
|---|---|---|
| OSI 层 | 第 7 层（仅限 HTTP/HTTPS） | 第 3-7 层（网络和应用程序） |
| 流量类型 | 对 Web 应用程序的入站 HTTP/HTTPS 请求 | 所有交通方向（南北、东西） |
| 检查重点 | HTTP 语义：标头、正文、Cookie、URI | IP 地址、端口、协议、FQDN、URL |
| 规则引擎 | 基于 OWASP 的模式匹配 + 异常评分 | 网络规则、应用程序规则、NAT 规则 |
| 部署模型 | 与应用网关或 Front Door 集成 | 使用 UDR 路由在中心子网中独立 |
| 典型攻击被阻止 | SQL 注入，XSS，CSRF，路径遍历 | 端口扫描、C2 回调、DNS 外泄 |
使用 WAF 进行 HTTP 应用程序保护和Azure 防火墙进行集中式网络流量检查。 在中心辐射型体系结构中，从 Internet 到 Web 应用程序的流量通常流经Azure 防火墙（用于 DNAT 和网络级别检查），然后通过具有 WAF 的应用程序网关（用于 HTTP 层检查）。 有关网络级组件，请参阅Azure 防火墙 和流量检查。
安全注意事项
以下安全做法可帮助你从 WAF 获得最大的保护：
- 用于生产的防护模式： 切勿将生产工作负荷保留在检测模式下。 检测模式提供可见性，但没有强制实施，使应用程序暴露在攻击中。
- 规则优化正在进行中： 应用程序不断发展。 新的 API 终结点、参数和内容类型可能会在现有规则集中触发误报。 部署后定期查看 WAF 日志。
- Log Analytics集成：将 WAF 诊断日志发送到Log Analytics工作区。 使用 WAF 工作簿可视化被阻止的请求、触发的规则和异常分数分布。
- DDoS 和 WAF 一起： WAF 可防范第 7 层应用程序攻击，但不会缓解卷状网络层 DDoS 攻击。 将 WAF 与 Azure DDoS 防护配对，实现全堆栈覆盖。
- 原点锁定： 使用 Front Door WAF 时，请将源配置为仅接受来自 Front Door 服务标记的流量。 如果没有源锁定，攻击者可以绕过 Front Door 并将请求直接发送到源 IP 地址。
- 敏感数据保护： WAF 日志可能包含请求数据。 配置日志清理规则以屏蔽 WAF 诊断日志中的敏感字段（授权标头、Cookie 或正文内容）。
相关文章
以下文章介绍了相关的网络安全主题：
- Internet 入口和流量路由：面向公众的应用程序的入口模式。
- 应用程序传递服务：应用程序网关和 Front Door 作为传递平台。
- Azure 防火墙和流量检查：对 WAF 第 7 层防护形成补充的网络级检查。
- DDoS 防护：公共 IP 地址的批量攻击保护。
Learn more
- Azure Web 应用程序防火墙概述
- 应用程序网关上的 WAF
- Azure Front Door上的 WAF
- WAF 策略概述
- Web 应用程序防火墙 CRS 规则组和规则
- 调整 Azure Front Door 的 Web 应用程序防火墙
后续步骤
Tip
自行探索？ 返回到 概述导航器 ，按功能查找下一篇文章。
接下来是直接迁移过程中的下一步：
为迁移的网络设置监视：配置 Web 应用程序防火墙后验证连接和性能。
现代化之旅的下一步：
为公共终结点启用 DDoS 保护：保护公共 IP 资源免受分布式拒绝服务攻击。
跨云之旅的下一步：
交付已迁移的应用程序：将 AWS 和 Google Cloud 中的负载均衡器映射到 Azure 中的对应服务，以支持您的跨云工作负载。