Azure 香港账号 Azure微软云WAF规则配置

Azure微软云WAF规则配置：别再让WAF成了你网站的‘保安队长兼冤案制造者’

朋友，你有没有经历过这种深夜修仙现场：凌晨两点，客户电话炸响——“我们下单页面打不开！”你火速登录Azure门户，手抖点开Web应用防火墙（WAF）日志，发现一行刺眼记录：Matched rule: 942100 (SQL Injection)。而那个被拦下的请求，只是用户填了个带单引号的收货地址：“张三’s Home”。

恭喜你，已成功解锁Azure WAF经典入门姿势：不是在配规则，就是在配错规则的路上。

一、先搞清：WAF不是魔法盒，是把双刃剑

Azure WAF（基于OWASP Core Rule Set，简称CRS）本质是个“按规则查字典”的守门人。它不理解你的业务逻辑，只认正则和签名。你给它一份《刑法典》（OWASP CRS），它就真敢把“SELECT * FROM”和“小明’s iPhone”一起按在地上摩擦。

所以配置WAF的第一铁律：不求一步封神，但求别亲手给自己埋雷。

二、四步走稳：WAF策略从无到有（实操版）

① 创建WAF策略：别急着点“下一步”，先选对“模式”

进入Azure门户 → 搜索“Web应用防火墙策略” → 新建。关键选项来了：

• 模式（Mode）：选 Detection（检测）还是 Prevention（防护）？
  新手请闭眼选 Detection！这相当于给WAF戴个嘴套——它只记小本本（日志），不真动手拦截。等你看了三天日志、确认没误伤，再切到 Prevention。别笑，我见过三个团队因跳过这步，上线即全站503……
• 规则集版本：目前主流是 OWASP 3.2 或 OWASP 4.0。4.0更激进（比如新增了JS混淆检测），但兼容性略娇气。建议新项目上4.0，老系统先用3.2过渡。

② 绑定策略：不是“关联”，是“钉牢”

策略建好后，去你的应用网关（Application Gateway）或Front Door里找“Web应用防火墙”设置页。重点来了：务必勾选“启用WAF策略”并选择你刚建的那个策略名。常见翻车点：只创建了策略，忘了绑定；或绑了旧策略没刷新。检查方法？看应用网关的“后端健康”状态是否突然变灰——变灰=WAF正在默默吃掉你的流量。

③ 托管规则集：开箱即用，但别全信

Azure默认启用OWASP CRS规则集，覆盖SQLi、XSS、文件包含等高危攻击。但注意：它自带“全家桶”，也自带“误伤包”。

典型问题场景：

• 你的API接口接受JSON，字段值含{"status":"pending"} —— CRS规则932100可能把它当“JSONP劫持”干掉；
• 后台管理页URL带?debug=true&token=abc123 —— 规则920300觉得token=像CSRF令牌泄露，直接403。

解法不是关规则，是“精准降权”：在WAF策略的“托管规则”页，找到对应规则ID（如920300），把操作从Block改成Log。这样既留证据，又放行——温柔且坚定。

Azure 香港账号 ④ 自定义规则：当你的业务需要“特赦令”

遇到规则集无法覆盖的场景？比如：你家APP的上传接口必须允许.exe扩展名（内部工具链刚需），但CRS 933120见.exe就封。这时就得写自定义规则——别怕，它比写SQL还简单。

示例：放行特定路径的exe上传

{
  "name": "Allow-Internal-EXE",
  "priority": 10,
  "action": "Allow",
  "matchConditions": [
    {
      "matchVariable": "RequestUri",
      "operator": "Contains",
      "negationConditon": false,
      "matchValues": ["/api/internal/upload"]
    },
    {
      "matchVariable": "RequestHeader:Content-Type",
      "operator": "Equals",
      "negationConditon": false,
      "matchValues": ["application/octet-stream"]
    }
  ],
  "ruleType": "MatchRule"
}

要点提醒：
• priority数字越小越先执行（10比100优先）；
• Allow规则必须放在Block规则之前，否则永远不生效；
• 测试时用curl -v发个真实请求，别只信UI上的“测试按钮”——那玩意儿常假装自己很懂。

三、救命锦囊：那些文档里不写，但你每天都在查的细节

✅ 排除项（Exclusions）：给WAF递个“免检通行证”

当某个参数总被误杀（比如address字段含撇号），别改全局规则，用排除项：

• 路径：/checkout/submit
• 参数名：shipping_address
• 匹配类型：StartsWith（避免只排除address却放过billing_address）

原理：WAF看到这个参数，直接跳过所有规则检查。比改正则安全十倍。

✅ 日志分析：别只看“Blocked”，要看“Why”

打开Diagnostic Settings，把WAF日志导出到Log Analytics。关键KQL查询：

AWSCustomLog
| where action_s == "Blocked"
| extend ruleId = tostring(parse_json(ruleData_s).ruleId)
| summarize count() by ruleId, clientIP_s, requestUri_s
| top 10 by count_

结果里若942100高频出现，说明SQLi规则太敏感；若全是920350（CSRF token验证失败），赶紧检查前端是否漏传X-CSRF-Token头。

✅ 正则避坑：WAF里的正则，不是JavaScript里的正则

Azure WAF用PCRE引擎，但.*可能匹配换行符导致误判；\d+在某些版本不认。保险写法：
• 数字：用[0-9]+代替\d+
• 字母：用[a-zA-Z]+代替\w+（后者含下划线，常误伤）

四、最后送你一句真·运维箴言

WAF配置没有“完成时”，只有“持续调优进行时”。每月做一次日志巡检，每季度更新一次规则集，每次发版前跑一遍WAF兼容性测试——这不是KPI，是让你半夜能睡踏实的底线。

毕竟，最好的WAF不是挡下所有攻击，而是让真正的攻击者撞墙，让真实的用户丝滑下单。至于那个填了“张三’s Home”的客户？他值得一杯热咖啡，而不是一个403页面。

（完）