mcpField
A
azure-waf

azure-waf

github.com/vinayaklatthe安全17842 次安装19 周前更新
代码仓库

关于 azure-waf

azure-waf 是用于规划和运营 Azure Web Application Firewall 部署的技能，面向安全与应用团队。它涵盖托管服务选型、策略调优，以及 Web 应用和 API 的防护运营。

主要功能

  1. 01Front Door 与 Application Gateway 选型
  2. 02检测模式到防护模式迁移
  3. 03按 URI 和参数调整排除项
  4. 04编写自定义规则与限速策略
  5. 05规划日志分析与运营责任

适用场景

  1. 01为新建公网应用选择 WAF 托管服务
  2. 02逐条将策略从检测模式转为防护模式
  3. 03排查误报并制定排除项审查流程

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill azure-waf

安装后在 Claude Code 中输入/azure-waf确认已加载。

详细介绍

Azure Web Application Firewall（WAF）

Azure WAF 是一款符合 OWASP 标准的应用层防火墙，可通过两种托管服务使用：

  • Azure Front Door（Premium / Standard）——全球分布、任播、边缘层服务，适合需要边缘节点和内置缓存的面向互联网应用和 API。
  • Azure Application Gateway（WAF v2）——区域性服务，与后端池集成，适合应用内部或绑定到 VNet 的工作负载，以及已在 App Gateway 终止连接的场景。

适用场景

保护公共 Web 应用和 API 免受第 7 层攻击：SQLi、XSS、RCE 模式、自动化扫描器、撞库、爬取和机器人滥用。使用此技能进行主机选择、策略编写、排除项调优和运营责任管理。

以下情况不适用此技能：第 3/4 层 DDoS（azure-ddos-protection）、东西向／非 HTTP 流量（azure-firewall）或非 HTTP 协议。

选择主机

主机最适合
Front Door Premium WAF需要全球边缘节点、高级机器人管理器、JS/JSON 挑战和专用链接后端的互联网应用／API
Front Door Standard WAF对成本敏感，且使用托管 Default Rule Set 和自定义规则的互联网应用
App Gateway WAF v2已使用 App Gateway 的区域性应用、VNet 内部应用，以及需要自带证书／可用区的场景

经验法则： 面向互联网的新建应用 → Front Door Premium。已有 App Gateway，且因各种原因必须保留的棕地应用 → App Gateway WAF。

方法

  1. 先使用 Detection（审计）模式。 始终如此。在切换到 Prevention 之前，至少观察两周的生产流量（季节性应用需要更长时间）。

  2. 应用 Microsoft 的 Default Rule Set（DRS）。 新部署优先使用当前版本，而不是较旧的 OWASP CRS。在 Front Door Premium 上启用 Bot Manager 规则集。

  3. 优先设置了解身份验证场景的规则。

    • 对匿名端点（登录、搜索、注册）进行速率限制——登录端点的典型设置为每 IP 每分钟 100 次。
    • 按地理位置封锁你不提供服务的国家／地区，但要将 VPN 集中器或合作伙伴所在区域加入允许列表。
    • 对可疑机器人评分启用 JSON / JS 挑战（Premium）——可静默过滤无头浏览器。

  4. 逐步调整排除项。 这是核心运营工作，也是大多数 WAF 最终“永远停留在检测模式”的原因。处理流程：

    1. 从 AzureDiagnostics / AGCWAFLogs 中提取 Detection 模式下的命中记录。
    2. 按规则 ID、URI 和参数分组。
    3. 确认流量是否合法（例如，合法 SOAP 请求正文中包含 < 字符，或 API 确实需要 SQL 关键字）。
    4. 针对该规则及 URI／参数添加范围明确的排除项——绝不要全局禁用整条规则。
    5. 每周重新建立基线。

  5. 逐条规则切换到 Prevention，不要一次性全部启用。从高置信度、低误报率的规则开始（RCE 模式、命令注入）。等排除项稳定后，再启用误报较多的规则（XSS、协议违规）。

  6. 使用自定义规则处理业务逻辑。 示例：

    • 在渗透测试期间封锁特定用户代理。
    • 允许合作伙伴 CIDR 绕过速率限制。
    • 要求内部 API 必须包含特定标头。
    • 对管理路径仅允许预期国家／地区的流量。

  7. 日志记录与分析。 将 WAF 日志发送到 Log Analytics（以及 Sentinel）。创建以下内容：

    • 被拦截次数最多的规则和最可能的误报（作为待处理工作）。
    • 被拦截流量的地理分布。
    • 各端点的速率限制命中次数。
    • 机器人管理器分类趋势。

  8. 明确运营责任。 未指定应用团队负责人时，WAF 配置会逐渐退化。每月执行：

    • 检查 Microsoft 发布的规则集更新（默认自动应用；检查日志差异）。
    • 在应用部署导致请求形态变化后，重新建立排除项基线。
    • 验证 Prevention 覆盖情况（确保没有规则在不知情的情况下被禁用）。

  9. 在前门公共 IP／App Gateway 公共 IP 上配合使用 DDoS Protection。WAF 防护第 7 层；DDoS 防护第 3/4 层。对于高价值公共工作负载，两者始终都要使用。

防护原则

  • 第一天不要启用 Prevention 模式。 误报可能导致工作时间内服务中断。
  • 不要为了处理单个误报而全局禁用规则。 应针对实际触发规则的 URI／参数／Cookie／标头配置排除项。
  • 地理位置封锁是粗粒度工具。 旅行者、VPN 用户和移动运营商 IP 都会漫游。对于终端用户路径，优先采用速率限制、Bot 管理器和身份验证策略，而不是硬性地理位置拒绝。
  • Bot 管理器的评分不是非此即彼。 使用评分区间模型（低 → JS 挑战，中 → CAPTCHA，高 → 拦截）。硬性拦截中间区间会误伤真实用户。
  • 对共享 NAT 后的 IP 进行速率限制（运营商、企业网络）会影响过多真实用户。应结合 Cookie／会话，并相应调整限制。
  • API 前面的 WAF 不能取代 API 身份验证／授权。 WAF 是纵深防御措施，而不是主要控制措施。
  • 串联多个 WAF（第三方 CDN WAF + Azure WAF） 会导致所有配置都要调整，并让工程师不堪其扰。应选定一个作为权威 WAF。
  • 默认规则集更新可能引入新规则。 每季度审查变更，避免规则更新意外拦截生产流量。

常见反模式

  • “第一天就启用 Prevention 模式”——导致服务中断；团队随后完全禁用 WAF，且再也不启用。最终什么防护都没有。
  • “因为某个 URI 产生误报，就禁用了规则 942100”——整个规则类别都被关闭。应使用排除项。
  • “全局速率限制 = 1000 次／分钟”——对登录端点毫无用处，对静态资源端点却影响严重。应按端点调整。
  • “到处都进行地理位置封锁”——会流失客户，却无法阻止有决心的攻击者。
  • “将 Bot 管理器设置为拦截所有‘中’评分请求”——会拦截合法的浏览器变体和合作伙伴集成。
  • “WAF 日志没有发送到 Sentinel”——日志不可见。
  • “30 个应用使用相同的 WAF 策略”——排除项将变得无法管理。每个应用或应用系列应使用单独的策略。
  • “跳过默认规则集更新”——攻击不断演变，防护能力却停滞不前。

示例提示词

  • 将面向公众的电商应用从第三方 WAF 迁移到 Azure Front Door Premium WAF——设计和切换计划。
  • 构建排除项调整工作流：日志查询、每周审查、应用团队审批。
  • 编写自定义规则：对 /login 设置 30 次／分钟／IP 的速率限制；对 bot-score 为 medium 的 /api/search 发起 JS 挑战；对 /admin 封锁除 US/CA 以外的所有地区。
  • 将 Detection 模式的 WAF 策略逐条规则提升为 Prevention 模式，并设置回滚触发条件。
  • Sentinel 工作簿：拦截次数最多的规则、最可能产生误报的规则、地理分布、Bot 管理器趋势。
  • 比较面向区域性银行应用的 Front Door WAF 和 App Gateway WAF。
  • 为 Foundry 托管的 AI API 设计 WAF + DDoS + 专用链接后端。

Microsoft Learn

评论

支持 Markdown