Azure Front Door WAF Design

Azure Front Door Web Application Firewall (WAF) is a cloud-native service that provides centralized protection for web applications from common attacks like SQL injection, cross-site scripting (XSS), and HTTP protocol violations. It integrates seamlessly with Azure Front Door, acting as a reverse proxy that inspects incoming HTTP/HTTPS requests before they reach the origin server. The WAF operates at the edge of Microsoft's global network, close to the client, which reduces latency for legitimate traffic and blocks attacks before they enter the Azure backbone.

The primary reason for using Azure Front Door WAF is to offload security management from the application layer. Instead of implementing custom security logic in each web application, you define a unified set of rules that applies to all traffic passing through Front Door. This simplifies compliance, reduces application complexity, and ensures consistent protection across multiple origins.

Azure Front Door WAF uses a rule engine that evaluates each incoming request against a set of managed or custom rules. The evaluation happens in the following order:

4. Rule Actions: Each rule can have one of three actions: - Allow: The request is allowed to pass through to the origin. - Block: The request is rejected with a 403 Forbidden response. - Log: The request is logged but still allowed (useful for testing). - Redirect: The request is redirected to a specified URL (custom rules only).

- Source IP address or range - Request URI, query string, headers, body - Request method (GET, POST, etc.) - Size of request parts - Geo-location (country code) - Rate limiting thresholds

- Microsoft_DefaultRuleSet_2.1 (latest version as of 2024) - OWASP_3.2 (CRS 3.2) - Bot Manager rule set (to detect and block malicious bots) - Custom Rules: User-defined rules with specific match conditions and actions. You can create up to 100 custom rules per policy. - Rate Limiting: A custom rule type that limits requests from a single client IP over a duration (e.g., 100 requests per 5 minutes). The default rate limit duration is 1 minute, but you can configure it from 1 to 60 minutes. - Default Action: If no rule matches, the default action is 'Allow'. You can change it to 'Block' to deny all traffic except what matches an 'Allow' rule. - TLS Inspection: Front Door terminates TLS at the edge, so the WAF sees the decrypted HTTP request. This allows inspection of the full request body. - Request Body Size Limit: The WAF inspects the first 128 KB of the request body by default. You can increase this to 2 MB using the 'RequestBodyCheck' setting. - Logging: WAF logs are sent to Azure Monitor, Log Analytics workspaces, or storage accounts. You can also stream logs to Event Hubs.

To create a WAF policy via Azure CLI:

az network front-door waf-policy create \
  --resource-group myResourceGroup \
  --name myWAFPolicy \
  --sku Premium_AzureFrontDoor \
  --mode Prevention

To associate the policy with a Front Door frontend:

az network front-door update \
  --resource-group myResourceGroup \
  --name myFrontDoor \
  --frontend-endpoints myFrontendEndpoint \
  --set wafPolicy.id=/subscriptions/.../providers/Microsoft.Network/frontDoorWebApplicationFirewallPolicies/myWAFPolicy

To verify the policy is applied:

az network front-door show --resource-group myResourceGroup --name myFrontDoor --query "frontendEndpoints[?name=='myFrontendEndpoint'].wafPolicy"

To check WAF logs in Log Analytics:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "FrontdoorWebApplicationFirewallLog"
| where action_s == "Block"
| project TimeGenerated, clientIp_s, ruleName_s, action_s

A large e-commerce company uses Azure Front Door WAF to protect its website from SQL injection and XSS attacks. They have multiple origin servers across regions (US, Europe, Asia) behind Front Door. They enable the OWASP 3.2 managed rule set in Prevention mode. Additionally, they create custom rules to block requests from known malicious IPs (using a threat intelligence feed) and to enforce geo-blocking for countries where they don't operate. They set up rate limiting to prevent brute-force login attempts: 100 requests per 5 minutes per IP on the /login endpoint. In production, they monitor WAF logs in Azure Sentinel and have automated playbooks to update IP block lists. A common issue is false positives: legitimate requests that match managed rules. They tune the rules by setting specific rules to 'Log' mode temporarily and then adjusting conditions or excluding certain parameters.

A bank exposes REST APIs through Azure Front Door for mobile banking apps. They use WAF with Bot Manager rule set to block scrapers and automated scripts. They also enforce TLS 1.2 minimum and require client certificates for authentication (Front Door supports mutual TLS). The WAF policy includes custom rules to validate that the request body contains expected JSON structure and to block requests with unusually large payloads (over 1 MB). They set the WAF mode to 'Detection' initially to test traffic patterns, then switch to 'Prevention' after two weeks of tuning. Performance is critical: they ensure the request body inspection size is set to 128 KB to avoid latency. A misconfiguration they encountered: forgetting to exclude health probe requests from rate limiting, causing Front Door health probes to be blocked and triggering origin unhealthy alerts.