Skip to main content

Troubleshooting Lab: Configure rule sets for WAF on Azure Front Door

Diagnostic Scenarios​

Scenario 1 — Root Cause​

A team configured a WAF Policy associated with an Azure Front Door Premium to protect an e-commerce application. The WAF is in Prevention mode with the managed rule set Microsoft_DefaultRuleSet_2.1 enabled. No custom rules have been added.

After deployment, the testing team reports that requests from an internal vulnerability scanner are being blocked, which was expected. However, a group of legitimate users in Germany also starts reporting sporadic blocks when trying to access the checkout page. The logs show:

{
  "category": "FrontDoorWebApplicationFirewallLog",
  "properties": {
    "clientIP": "85.214.132.117",
    "requestUri": "/checkout?promo=SAVE10&ref=email_campaign_march",
    "ruleName": "Microsoft_DefaultRuleSet-2.1-LFI-930110",
    "action": "Block",
    "details": {
      "message": "Path Traversal Attack (/../)",
      "data": "SAVE10/../"
    }
  }
}

Additional information:

  • Front Door Premium was deployed three weeks ago without incidents
  • The marketing team launched a promotional campaign the previous week with automatically generated coupon codes
  • The custom domain certificate was renewed two days before the blocks started
  • The ref URL parameter is email campaign tracking and is never processed by the backend
  • There are no rule exclusions in the WAF Policy

What is the root cause of the problem?

A) The custom domain certificate renewal changed how Front Door inspects URL parameters, generating false positives in the LFI rule.

B) The automatically generated coupon code by the marketing team contains the sequence /../ that matches the Path Traversal pattern detected by rule LFI-930110, generating false positives for users with this coupon.

C) The ref email campaign tracking parameter is being interpreted by the WAF as an injection vector, causing the sporadic blocks.

D) The managed rule set Microsoft_DefaultRuleSet_2.1 has elevated sensitivity for European IPs after an automatic update performed the previous week.

Scenario 2 — Diagnostic Sequence​

An administrator reports that after migrating a WAF Policy from Azure Front Door Classic to Azure Front Door Premium, some requests that previously passed freely are now being blocked in production. The WAF is in Prevention mode with the managed rule set Microsoft_DefaultRuleSet_2.1 and a set of custom rules manually migrated.

The available investigation steps are:

  1. Compare the migrated custom rules with the originals to verify that priorities, conditions, and actions were preserved correctly.
  2. Check the WAF logs to see which specific rules are generating the blocks and if they are from the managed rule set or custom rules.
  3. Confirm that the WAF Policy is correctly associated with the Front Door Premium profile and not another resource.
  4. Verify if the managed rule set Microsoft_DefaultRuleSet_2.1 has equivalent rules to those active in Front Door Classic and if default behavior changed between versions.
  5. Analyze Front Door logs to confirm that traffic is reaching Front Door before being evaluated by the WAF.

What is the correct investigation sequence?

A) 3 → 5 → 2 → 4 → 1

B) 5 → 3 → 2 → 1 → 4

C) 2 → 1 → 4 → 3 → 5

D) 3 → 2 → 4 → 1 → 5

Scenario 3 — Root Cause​

A company configured a WAF Policy on Azure Front Door Premium with the following custom rules to protect an internal API:

Rule 1 — Priority 5
  Name: AllowInternalMonitoring
  Type: MatchRule
  Condition: IPMatch — 10.0.0.0/8
  Action: Allow

Rule 2 — Priority 20
  Name: BlockScanners
  Type: MatchRule
  Condition: RequestHeader "User-Agent" contains "Nmap" OR "Nikto" OR "sqlmap"
  Action: Block

Rule 3 — Priority 30
  Name: RateLimitAPI
  Type: RateLimitRule
  Condition: RequestUri starts with "/api/"
  Limit: 100 requests per minute per IP
  Action: Block

The managed rule set Microsoft_DefaultRuleSet_2.1 is also active.

The internal monitoring team reports that their health check tools, running from the 10.0.0.0/8 range, are being intermittently blocked. The logs indicate that the block is generated by the RateLimitAPI rule. The health check tool makes 150 requests per minute to /api/health.

Additional information:

  • The health check tool was configured six months ago without changes
  • The security team updated the blocked User-Agents list the previous week
  • The range 10.0.0.0/8 was confirmed as correct for the entire internal network
  • Front Door Premium is on the latest version

What is the root cause of the problem?

A) The blocked User-Agents list update the previous week inadvertently included the health check tool's User-Agent, causing blocks by the BlockScanners rule.

B) The AllowInternalMonitoring rule with Allow action stops evaluation of other custom rules but doesn't prevent application of the managed rule set, which is blocking the health check.

C) The RateLimitAPI rule with priority 30 is evaluated for IPs in the 10.0.0.0/8 range because the Allow action of the priority 5 rule doesn't stop evaluation of custom RateLimitRule type rules in recent Front Door Premium versions.

D) The health check tool exceeds the limit of 100 requests per minute configured in the RateLimitAPI rule, and the AllowInternalMonitoring rule with Allow action only stops evaluation of managed rule set rules, not other custom rules.

Scenario 4 — Action Decision​

The team identified that the managed rule set Microsoft_DefaultRuleSet_2.1 is blocking requests from a partner application that sends JSON payloads with field names containing brackets, such as filter[status] and filter[date]. Rule MS-ThreatIntel-WebShells-99005 is being triggered for these fields.

The cause was confirmed: the bracket naming pattern in JSON fields corresponds to a WebShell detection signature in the rule set.

Context and restrictions:

  • The environment is production with an SLA agreed with the partner
  • The partner application cannot be modified to change the field format
  • The team has write permission on the WAF Policy
  • There is a change management process that requires approval for managed rule set changes, with a minimum 48-hour timeframe
  • The impact has been occurring for 6 hours and the partner is monitoring the situation
  • Disabling the complete managed rule set would violate company compliance requirements

What is the correct action to take at this moment?

A) Temporarily disable the managed rule set Microsoft_DefaultRuleSet_2.1 to restore integration with the partner while initiating the change management process.

B) Immediately initiate the change management process to approve creating a specific rule exclusion for rule MS-ThreatIntel-WebShells-99005 applied to fields filter[status] and filter[date], and communicate the estimated resolution timeframe to the partner.

C) Create a custom rule with higher priority than the managed rule set to explicitly allow requests from the partner's IP, bypassing the block without altering the managed rule set.

D) Change the WAF Policy to Detection mode immediately to restore integration functionality and initiate the change management process in parallel.

Answer Key and Explanations​

Answer Key — Scenario 1​

Answer: B

The log is the central and decisive clue. The data field in the log explicitly shows SAVE10/../, indicating that the WAF concatenated the promo parameter value with other URL elements and identified the /../ sequence as a Path Traversal pattern. The coupon code SAVE10 contains the sequence that, when processed by rule LFI-930110, corresponds to the attack pattern. The timing of blocks coinciding with the marketing campaign launch confirms the temporal correlation.

Information about certificate renewal is irrelevant. WAF on Front Door Premium operates at the application layer after TLS termination; certificate changes don't affect URL parameter inspection logic.

The most dangerous distractor is C, as it directs attention to the ref parameter, which is mentioned in the scenario and visible in the URL. However, the log clearly shows the problematic data is in the promo parameter, not ref. Investigating the wrong parameter would lead to an incorrect rule exclusion that wouldn't resolve the block.

Answer Key — Scenario 2​

Answer: A

The correct sequence is 3 → 5 → 2 → 4 → 1.

Diagnosis should start by confirming the WAF Policy is associated with the correct resource (step 3), as incorrect association after migration would explain unexpected behaviors without needing to investigate rules. Next, confirm traffic is reaching Front Door (step 5) validates the transport layer before investigating WAF. With this confirmed, WAF logs (step 2) indicate if blocking comes from the managed rule set or custom rules, directing the investigation. If blocking comes from the managed rule set, comparing versions and default behaviors (step 4) is the next logical step. Only lastly does it make sense to compare migrated custom rules (step 1), as the previous context will have already narrowed down if this is the relevant path.

Distractor C starts directly with log analysis without first verifying that association and routing are correct. WAF logs only make sense after confirming traffic is reaching the right resource.

Answer Key — Scenario 3​

Answer: D

In Azure Front Door WAF, when a custom MatchRule type rule has an Allow action, it stops evaluation of other rules of the same MatchRule type and prevents evaluation of the managed rule set. However, RateLimitRule type rules are evaluated independently and are not interrupted by the Allow action of a MatchRule. Therefore, even though the health check tool is allowed by the AllowInternalMonitoring rule, the RateLimitAPI rule is still evaluated and blocks the 150 requests per minute that exceed the limit of 100.

The clue is in the rule types: the Allow rule is type MatchRule and the rate limit rule is type RateLimitRule. These two types have distinct behaviors in the evaluation chain.

Information about the User-Agents list update is irrelevant. The log indicates blocking comes from the RateLimitAPI rule, not the BlockScanners rule, and the health check tool's User-Agent wasn't mentioned as a scanner.

The most dangerous distractor is C, as it contains the technically correct statement that RateLimitRule is evaluated independently, but attributes this to "recent Front Door Premium versions," suggesting this is a recent behavior change. This misleads the reader to look for release notes or an update as the cause, instead of understanding the fundamental behavior of rule types.

Answer Key — Scenario 4​

Answer: B

The context presents three restrictions that eliminate other alternatives: the change management process with a minimum 48-hour timeframe, the prohibition of disabling the complete managed rule set due to compliance, and the impossibility of modifying the partner application. The only action that respects all restrictions is to immediately initiate the correct process (specific rule exclusion) within the formal approval channel and communicate the timeframe to the partner.

Distractor A directly violates the compliance requirement that prohibits disabling the complete managed rule set.

Distractor C seems like a creative solution, but a custom Allow rule for the partner's IP with high priority would bypass not only the problematic rule but the entire managed rule set for that IP, which may also violate compliance requirements and creates an unmanaged attack surface if the partner's IP is compromised.

Distractor D changes the entire WAF to Detection, removing protection from all rules for the entire application, which is disproportionate to the problem and may equally violate compliance requirements.

Troubleshooting Tree: Rule Set Configuration for WAF on Azure Front Door​

100%
Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Color legend:

ColorNode type
Dark blueInitial symptom (entry point)
Medium blueDiagnostic question
RedIdentified cause
GreenRecommended action or resolution
OrangeIntermediate validation or verification

When facing a real problem with WAF rule sets on Azure Front Door, start at the root node and answer each question based on what is directly verifiable: WAF Policy association, presence of logs, type of rule that generated the block, and configuration of exclusions or priorities. The orange validation nodes signal moments when additional information needs to be collected from logs before continuing. Follow the path to the red identified cause node and apply the corresponding green action. If the action doesn't completely resolve the issue, return to the previous validation node and explore the remaining alternative path.