Azure Front Door WAF规则949110误判排查及模式切换咨询

一、排查949110规则误判的步骤 #

规则Microsoft_DefaultRuleSet-2.0-BLOCKING-EVALUATION-949110是OWASP核心规则集的异常分数累加触发规则——它并非单一恶意特征匹配触发，而是多个子规则的异常分数累加超过阈值后触发，所以日志里details_matches_s为空。针对静态资源（.html/.js/.jpeg等）的误判，可按以下步骤排查：

• 分析请求全维度特征：不要仅关注requestUri_s，重点检查被拦截请求的其他属性：
  • 请求方法：静态资源是否使用了POST/PUT等非GET方法？这类非常规请求容易被子规则标记加分。
  • 请求头：User-Agent是否有异常格式（如缺失、包含特殊字符），Referer是否不符合业务逻辑，Cookie是否有畸形内容。
  • 请求参数：静态资源URL是否携带了奇怪的查询参数（如含SQL注入/XSS特征的字符）。
  • 请求频率：是否存在短时间内同一IP/会话发起大量静态资源请求，触发速率类子规则加分。
• 开启WAF详细匹配日志：默认的AzureDiagnostics日志未记录触发949110的具体子规则，需在WAF策略的日志设置中开启「详细日志」选项。开启后，后续日志会列出所有累加分数的子规则及对应分数，直接定位根源。
• 复现请求验证：选取一条被拦截的requestUri_s，用curl/Postman模拟完全相同的请求（包括请求头、参数、IP），触发日志后查看详细子规则匹配记录，明确是哪些规则导致分数超限。
• 提炼误判共性：统计所有被拦截请求的共同特征，比如来自特定IP段、使用特定爬虫User-Agent、请求路径包含特定字符等，针对性排查这些特征是否被规则误识别。

二、防护模式切换的建议 #

检测模式下标记为Block的请求，切换到防护模式后会被实际拦截，直接切换会影响正常业务（尤其是这些静态资源可能是用户正常访问的内容），建议按以下流程操作：

1. 先完成上述排查，定位触发949110的具体子规则，针对性处理：
   • 若子规则针对静态资源属于误判，可添加自定义规则，对静态资源路径（比如*.html/*.js）禁用该子规则；
   • 若为请求频率导致，可调整速率限制规则的阈值，或添加针对合法爬虫/用户IP的允许规则。
2. 小范围测试验证：先将WAF切换到防护模式，同时针对静态资源路径添加允许的自定义规则，观察1-2天，确认正常业务不受影响后再取消临时规则。
3. 临时应急方案（不推荐长期使用）：若无法快速定位子规则，可临时将949110规则设置为「仅检测」或「禁用」，但这会降低整体防护能力，需尽快找到根源并恢复规则。

内容的提问来源于stack exchange，提问作者Rajesh