Azure Web Application Firewall (WAF) Deployment Guide

Comprehensive guide to designing, implementing, and configuring WAF on Azure

Table of Contents

1. Azure WAF Overview & Architecture

graph TB A[Internet Users] --> B[Azure Front Door/CDN] A --> C[Application Gateway] B --> D[WAF Policy - Global] C --> E[WAF Policy - Regional] D --> F[Rule Sets
- OWASP Core
- Microsoft Default
- Bot Protection] E --> G[Rule Sets
- OWASP Core
- Microsoft Default
- Custom Rules] F --> H[Backend Services] G --> I[Web Applications] H --> J[App Service] H --> K[VM Scale Sets] I --> L[IIS Servers] I --> M[Container Apps] style D fill:#e1f5fe style E fill:#e8f5e8 style F fill:#fff3e0 style G fill:#fff3e0
Architecture Overview: This diagram shows the two primary deployment scenarios for Azure WAF. Azure Front Door provides global edge protection with CDN capabilities, while Application Gateway provides regional load balancing with WAF protection. Both can use similar rule sets but serve different architectural purposes. Front Door is ideal for global applications with multiple regions, while Application Gateway is perfect for regional deployments with more granular control.

WAF Capabilities Overview

Feature Azure Front Door WAF Application Gateway WAF
Geographic Coverage Global Edge Locations Regional Deployment
OWASP Rule Sets ✓ Core Rule Set 3.2 ✓ Core Rule Set 3.0, 3.1, 3.2
Bot Protection ✓ Advanced Bot Rules ✓ Basic Bot Protection
Custom Rules ✓ IP, Geo, Rate Limiting ✓ Full Custom Rule Support
SSL Termination ✓ Edge Termination ✓ Gateway Termination

2. Requirements Mapping to WAF Features

graph LR A[Security Requirements] --> B[WAF Features] A1[SQL Injection Protection] --> B1[OWASP Core Rules] A2[XSS Prevention] --> B1 A3[DDoS Mitigation] --> B2[Rate Limiting Rules] A4[Bot Protection] --> B3[Bot Management Rules] A5[Geo Blocking] --> B4[Geographic Rules] A6[IP Allowlist/Blocklist] --> B5[Custom IP Rules] A7[Protocol Validation] --> B6[Protocol Anomaly Rules] B1 --> C1[Rule Group: REQUEST-941-APPLICATION-ATTACK-XSS] B1 --> C2[Rule Group: REQUEST-942-APPLICATION-ATTACK-SQLI] B2 --> C3[Custom Rule: Rate Limit per IP] B3 --> C4[Microsoft Bot Protection Rules] B4 --> C5[Custom Rule: Geo Match Conditions] B5 --> C6[Custom Rule: IP Match Conditions] style A fill:#ffebee style B fill:#e8f5e8 style C1 fill:#fff3e0 style C2 fill:#fff3e0 style C3 fill:#e3f2fd style C4 fill:#e3f2fd style C5 fill:#e3f2fd style C6 fill:#e3f2fd
Requirements to Features Mapping: This diagram illustrates how common security requirements map to specific WAF features and rule implementations. Each security requirement (left) corresponds to specific WAF capabilities (center) which are implemented through particular rule groups or custom rules (right). This mapping helps in designing a comprehensive WAF policy that addresses all security concerns.

Detailed Requirements Analysis

Critical Security Requirements:
  • OWASP Top 10 Protection: Core rule sets provide protection against injection attacks, broken authentication, sensitive data exposure, XML external entities, broken access control, security misconfigurations, cross-site scripting, insecure deserialization, components with known vulnerabilities, and insufficient logging.
  • Application-Specific Rules: Custom rules tailored to your application's specific attack vectors and business logic.
  • Performance Requirements: Rule optimization to minimize latency while maintaining security posture.

3. WAF Deployment Design

graph TB subgraph "Multi-Region WAF Design" A[Global Users] --> B[Azure Front Door WAF] B --> C[Traffic Manager] C --> D[Region 1: West US 2] C --> E[Region 2: East US 2] C --> F[Region 3: West Europe] D --> G[Application Gateway WAF - West US 2] E --> H[Application Gateway WAF - East US 2] F --> I[Application Gateway WAF - West Europe] G --> J[Backend Pool 1] H --> K[Backend Pool 2] I --> L[Backend Pool 3] J --> M[App Service Plan] K --> N[VM Scale Set] L --> O[Container Instances] end subgraph "WAF Policy Hierarchy" P[Global WAF Policy] --> Q[Regional WAF Policies] Q --> R[Environment-Specific Policies] R --> S[Application-Specific Rules] end style B fill:#e3f2fd style G fill:#e8f5e8 style H fill:#e8f5e8 style I fill:#e8f5e8 style P fill:#fff3e0
Multi-Region WAF Design: This architecture shows a comprehensive multi-region deployment where Azure Front Door provides the first layer of global WAF protection, with regional Application Gateway WAF instances providing additional security and load balancing. The policy hierarchy ensures consistent security posture across all regions while allowing for regional customizations. This design provides redundancy, optimal performance, and comprehensive security coverage.

Design Considerations

Important Design Decisions:
  • Front Door vs Application Gateway: Use Front Door for global applications with CDN requirements, Application Gateway for regional applications with more complex routing needs.
  • Policy Inheritance: Design policies hierarchically - global baseline with regional and application-specific overrides.
  • Performance Impact: Each WAF layer adds latency - balance security with performance requirements.

4. Detection vs Prevention Modes

graph LR A[Incoming Request] --> B{WAF Mode Check} B -->|Detection Mode| C[Log Threat] B -->|Prevention Mode| D[Block/Allow Decision] C --> E[Forward Request] D --> F{Rule Match?} F -->|Match & Block Action| G[Block Request - 403] F -->|Match & Allow Action| H[Forward Request] F -->|No Match| H E --> I[Backend Application] H --> I G --> J[WAF Block Page] C --> K[WAF Logs & Metrics] D --> K style C fill:#fff3e0 style D fill:#ffebee style G fill:#ffcdd2 style H fill:#c8e6c9 style K fill:#e1f5fe
WAF Modes Workflow: This diagram illustrates the decision flow for WAF modes. In Detection mode, threats are logged but requests continue to the backend, making it ideal for testing and tuning. In Prevention mode, matching rules can block malicious requests, providing active protection. The logging component is crucial for both modes to monitor threats and tune rules effectively.

Mode Configuration Strategy

Deployment Strategy:
  1. Phase 1 - Detection Mode: Deploy with all rules in detection mode for 2-4 weeks to establish baseline and identify false positives.
  2. Phase 2 - Selective Prevention: Enable prevention mode for high-confidence rules (SQL injection, XSS) while keeping others in detection.
  3. Phase 3 - Full Prevention: Enable prevention mode for all rules after tuning and false positive elimination.

5. WAF Configuration on Azure Front Door

sequenceDiagram participant User participant FD as Azure Front Door participant WAF as WAF Policy participant Rules as Rule Engine participant Backend as Backend Pool User->>FD: HTTP Request FD->>WAF: Apply WAF Policy WAF->>Rules: Evaluate Rules alt Rule Match - Block Rules->>WAF: Block Action WAF->>FD: Block Response FD->>User: 403 Forbidden else Rule Match - Allow/Log Rules->>WAF: Allow/Log Action WAF->>FD: Continue Processing FD->>Backend: Forward Request Backend->>FD: Response FD->>User: Response + Cache else No Rule Match WAF->>FD: Continue Processing FD->>Backend: Forward Request Backend->>FD: Response FD->>User: Response + Cache end
Front Door WAF Request Flow: This sequence diagram shows how requests are processed through Azure Front Door with WAF protection. Each request is evaluated against the WAF policy before reaching the backend. Blocked requests receive immediate responses, while allowed requests continue to the backend and benefit from Front Door's CDN capabilities.

Azure Front Door Configuration Objects Flow

flowchart TD A[Resource Group
rg-waf-frontdoor-prod] --> B[Front Door Profile
fd-webapp-prod] A --> C[WAF Policy
wafpol-frontdoor-prod] B --> D[Front Door Endpoint
webapp-prod-endpoint] B --> E[Custom Domain
webapp-custom-domain] C --> F[Managed Rule Sets] C --> G[Custom Rules] C --> H[Policy Settings] F --> F1[Microsoft Default RuleSet
Version 2.1] F --> F2[Bot Manager RuleSet
Version 1.0] G --> G1[Rate Limit Rule
Priority 100
100 req/min] G --> G2[Geo Block Rule
Priority 200
Block CN,RU,KP] G --> G3[Custom Allow Rule
Priority 50
API Clients] H --> H1[Mode: Detection/Prevention] H --> H2[State: Enabled] H --> H3[Request Body Check] I[Security Policy
webapp-security-policy] --> D I --> E I --> C J[Origin Group
Backend Services] --> K[Origin
App Service/VM] L[Route
Traffic Routing] --> D L --> J M[Diagnostic Settings
waf-diagnostics] --> C M --> N[Log Analytics Workspace
law-waf-monitoring] style A fill:#e3f2fd style C fill:#fff3e0 style I fill:#e8f5e8 style F1 fill:#ffebee style F2 fill:#ffebee style G1 fill:#fce4ec style G2 fill:#fce4ec style G3 fill:#fce4ec
Front Door Configuration Objects: This diagram shows the complete configuration object hierarchy for Azure Front Door WAF. The Resource Group contains the Front Door Profile and WAF Policy. The Security Policy acts as the bridge linking the WAF Policy to specific Front Door Endpoints and Custom Domains. Managed Rule Sets provide OWASP protection, while Custom Rules add application-specific security. Origin Groups define backend services, and Routes control traffic flow. Diagnostic Settings enable monitoring and logging.

Step 1: Create Resource Group and Front Door Profile

1
Create Resource Group
az group create \ --name "rg-waf-frontdoor-prod" \ --location "East US 2" \ --tags environment=production service=security
Resource Group Creation: This creates a dedicated resource group for Front Door WAF resources. The naming convention follows Azure best practices (rg = resource group, service type, environment). Tags help with cost management and resource organization.

Parameters:
  • --name: Resource group name (must be unique within subscription)
  • --location: Azure region for metadata storage
  • --tags: Key-value pairs for resource management
2
Create Front Door Profile
az afd profile create \ --profile-name "fd-webapp-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --sku "Standard_AzureFrontDoor" \ --tags application=webapp environment=production
Front Door Profile: The profile is the top-level container for Front Door resources. Standard SKU provides WAF capabilities with good performance, while Premium SKU offers additional security features like Private Link support.

SKU Options:
  • Standard_AzureFrontDoor: Basic WAF, standard rules, good for most applications
  • Premium_AzureFrontDoor: Advanced WAF, private link, enhanced security

Step 2: Create WAF Policy for Front Door

3
Create Base WAF Policy
az network front-door waf-policy create \ --name "wafpol-frontdoor-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --mode "Detection" \ --enabled true \ --tags policy-type=frontdoor environment=production
WAF Policy Creation: This creates the WAF policy that will be associated with Front Door endpoints. Starting in Detection mode allows you to monitor threats without blocking legitimate traffic initially.

Key Parameters:
  • --mode: "Detection" or "Prevention" - start with Detection for tuning
  • --enabled: Policy state (true/false)
  • --name: Must be unique within resource group

Step 3: Configure Managed Rule Sets

4
Add OWASP Core Rule Set
az network front-door waf-policy managed-rules add \ --policy-name "wafpol-frontdoor-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --type "Microsoft_DefaultRuleSet" \ --version "2.1" \ --action "Block"
Default Rule Set: Microsoft's default rule set provides comprehensive protection against OWASP Top 10 threats. Version 2.1 is the latest stable version with optimized rules for reduced false positives.

Available Rule Sets:
  • Microsoft_DefaultRuleSet: OWASP-based rules optimized by Microsoft
  • Microsoft_BotManagerRuleSet: Bot protection and management
5
Add Bot Protection Rules
az network front-door waf-policy managed-rules add \ --policy-name "wafpol-frontdoor-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --type "Microsoft_BotManagerRuleSet" \ --version "1.0" \ --action "Block"
Bot Manager Rule Set: Provides protection against malicious bots, scrapers, and automated attacks while allowing legitimate bots (search engines, monitoring tools). The rule set uses advanced heuristics and machine learning.

Bot Categories Protected:
  • Bad bots: Scrapers, attackers, spam bots
  • Unknown bots: Unidentified automated traffic
  • Good bots: Search engines, monitoring (configurable)

Step 4: Create Custom Rules

6
Rate Limiting Rule
az network front-door waf-policy rule create \ --policy-name "wafpol-frontdoor-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --name "RateLimitRule" \ --priority 100 \ --rule-type "RateLimitRule" \ --action "Block" \ --rate-limit-threshold 100 \ --rate-limit-duration-in-minutes 1 \ --match-conditions '[{ "matchVariable": "RemoteAddr", "operator": "IPMatch", "matchValue": ["0.0.0.0/0"] }]'
Rate Limiting: This rule protects against DDoS and brute force attacks by limiting requests per IP address. The rule blocks IPs that exceed 100 requests per minute from any IP address.

Rate Limit Parameters:
  • --rate-limit-threshold: Maximum requests allowed (1-2000)
  • --rate-limit-duration-in-minutes: Time window (1-60 minutes)
  • --priority: Rule evaluation order (lower numbers = higher priority)
7
Geographic Blocking Rule
az network front-door waf-policy rule create \ --policy-name "wafpol-frontdoor-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --name "GeoBlockRule" \ --priority 200 \ --rule-type "MatchRule" \ --action "Block" \ --match-conditions '[{ "matchVariable": "RemoteAddr", "operator": "GeoMatch", "matchValue": ["CN", "RU", "KP"], "negateCondition": false }]'
Geographic Blocking: This rule blocks traffic from specific countries based on business requirements or threat intelligence. The example blocks China (CN), Russia (RU), and North Korea (KP).

Geographic Options:
  • operator: "GeoMatch" for country-based blocking
  • matchValue: Array of ISO country codes
  • negateCondition: false=block listed countries, true=allow only listed countries

Step 5: Create Front Door Endpoint and Associate WAF

8
Create Front Door Endpoint
az afd endpoint create \ --endpoint-name "webapp-prod-endpoint" \ --profile-name "fd-webapp-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --enabled-state "Enabled"
Front Door Endpoint: The endpoint is the public-facing URL that clients will access. It acts as the entry point for your application traffic and where WAF policies are applied.

Endpoint Configuration:
  • Endpoint name becomes part of the FQDN: {endpoint-name}.{profile-hash}.azurefd.net
  • Custom domains can be added later
  • Endpoints can be enabled/disabled independently
9
Associate WAF Policy with Endpoint
az afd security-policy create \ --profile-name "fd-webapp-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --security-policy-name "webapp-security-policy" \ --domains '[{ "id": "/subscriptions/{subscription-id}/resourceGroups/rg-waf-frontdoor-prod/providers/Microsoft.Cdn/profiles/fd-webapp-prod/afdEndpoints/webapp-prod-endpoint" }]' \ --waf-policy '{ "id": "/subscriptions/{subscription-id}/resourceGroups/rg-waf-frontdoor-prod/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/wafpol-frontdoor-prod" }'
Security Policy Association: This links the WAF policy to specific Front Door endpoints. Multiple endpoints can share the same policy, or each can have its own policy for granular control.

Association Benefits:
  • Centralized policy management across multiple endpoints
  • Ability to apply different policies to different domains
  • Easy policy updates without endpoint reconfiguration

6. WAF Configuration on Application Gateway

graph TB subgraph "Application Gateway WAF Flow" A[Client Request] --> B[Application Gateway] B --> C[WAF Engine] C --> D{Rule Evaluation} D --> E[OWASP Core Rules] D --> F[Custom Rules] D --> G[Bot Protection] E --> H{SQL Injection Check} E --> I{XSS Check} E --> J{File Upload Check} F --> K{Rate Limiting} F --> L{IP Filtering} F --> M{Geo Blocking} G --> N{Bot Detection} H --> O{Action Decision} I --> O J --> O K --> O L --> O M --> O N --> O O -->|Block| P[403 Response] O -->|Allow| Q[Backend Pool] O -->|Log| R[Continue + Log] Q --> S[App Service] Q --> T[Virtual Machines] R --> Q end style C fill:#ffebee style O fill:#fff3e0 style P fill:#ffcdd2 style Q fill:#c8e6c9
Application Gateway WAF Processing: This diagram shows the detailed request processing flow through Application Gateway WAF. Each request goes through multiple rule evaluations including OWASP core rules, custom rules, and bot protection. The action decision determines whether to block, allow, or log the request. Unlike Front Door, Application Gateway WAF provides more granular control and can inspect the full request payload.

Application Gateway Configuration Objects Flow

flowchart TD A[Resource Group
rg-waf-frontdoor-prod] --> B[Virtual Network
vnet-appgw-prod] A --> C[Public IP
pip-appgw-prod] A --> D[Application Gateway
appgw-webapp-prod] A --> E[WAF Policy
wafpol-appgw-prod] B --> B1[Application Gateway Subnet
subnet-appgw
10.0.1.0/24] D --> D1[Frontend IP Configuration
Links to Public IP] D --> D2[Frontend Port
Port 80/443] D --> D3[HTTP Listener
Port + Protocol + Domain] D --> D4[Backend Pool
Target Servers] D --> D5[HTTP Settings
Port + Protocol + Affinity] D --> D6[Routing Rule
Listener → Backend Pool] D --> D7[Health Probe
Backend Health Check] E --> E1[Policy Settings] E --> E2[Managed Rule Sets] E --> E3[Custom Rules] E --> E4[Rule Exclusions] E1 --> E1A[Mode: Detection/Prevention] E1 --> E1B[Request Body Check: True] E1 --> E1C[Max Body Size: 128KB] E1 --> E1D[File Upload Limit: 100MB] E2 --> E2A[OWASP Core Rule Set
Version 3.2] E2 --> E2B[Microsoft Default Rules
Bot Protection] E3 --> E3A[SQL Injection Block
Priority 100
PostArgs: union select] E3 --> E3B[Rate Limit Rule
Priority 200
50 req/min per IP] E3 --> E3C[API Client Allow
Priority 50
User-Agent + URI] E4 --> E4A[ViewState Exclusion
RequestArgNames = viewstate] E4 --> E4B[Cookie Exclusions
ASP.NET Session Cookies] F[WAF Policy Association
firewallPolicy.id] --> D F --> E G[SSL Certificate
Key Vault/Managed] --> D3 H[NSG Rules
Allow 80/443] --> B1 I[Diagnostic Settings
appgw-diagnostics] --> D I --> J[Log Analytics Workspace
law-appgw-monitoring] style A fill:#e3f2fd style D fill:#e8f5e8 style E fill:#fff3e0 style F fill:#ffebee style E2A fill:#fce4ec style E2B fill:#fce4ec style E3A fill:#f3e5f5 style E3B fill:#f3e5f5 style E3C fill:#f3e5f5
Application Gateway Configuration Objects: This comprehensive diagram shows all configuration objects required for Application Gateway WAF deployment. The Virtual Network provides network isolation with a dedicated subnet. The Application Gateway contains multiple components: Frontend IP/Port configuration, HTTP Listeners for protocol handling, Backend Pools for target servers, HTTP Settings for backend communication, Routing Rules for traffic direction, and Health Probes for monitoring. The WAF Policy is separately configured with Policy Settings (global behavior), Managed Rule Sets (OWASP protection), Custom Rules (application-specific), and Rule Exclusions (false positive mitigation). The WAF Policy Association links the policy to the Application Gateway, while SSL Certificates secure communications and NSG Rules control network access.

Step 1: Create Application Gateway with WAF

10
Create Virtual Network
az network vnet create \ --name "vnet-appgw-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --location "East US 2" \ --address-prefixes "10.0.0.0/16" \ --subnet-name "subnet-appgw" \ --subnet-prefixes "10.0.1.0/24"
Virtual Network for Application Gateway: Application Gateway requires a dedicated subnet within a virtual network. The subnet must be /24 or larger and cannot contain other resources.

Network Requirements:
  • Minimum subnet size: /24 (256 IP addresses)
  • Reserved IPs: Azure reserves 5 IPs per subnet
  • No other resources allowed in the Application Gateway subnet
11
Create Public IP for Application Gateway
az network public-ip create \ --name "pip-appgw-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --location "East US 2" \ --allocation-method "Static" \ --sku "Standard" \ --dns-name "webapp-prod-appgw"
Public IP Configuration: Application Gateway requires a static public IP for inbound connections. Standard SKU provides better availability and security features compared to Basic SKU.

Public IP Options:
  • Static: IP address doesn't change (required for production)
  • Standard SKU: Zone redundant, more secure than Basic
  • dns-name: Creates FQDN {dns-name}.{region}.cloudapp.azure.com
12
Create Application Gateway with WAF
az network application-gateway create \ --name "appgw-webapp-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --location "East US 2" \ --vnet-name "vnet-appgw-prod" \ --subnet "subnet-appgw" \ --public-ip-address "pip-appgw-prod" \ --sku "WAF_v2" \ --capacity 2 \ --http-settings-cookie-based-affinity "Disabled" \ --frontend-port 80 \ --http-settings-port 80 \ --http-settings-protocol "Http" \ --routing-rule-type "Basic"
Application Gateway Creation: This creates Application Gateway v2 with WAF capabilities. The WAF_v2 SKU provides autoscaling, zone redundancy, and advanced WAF features.

Key Configuration:
  • WAF_v2: Latest version with enhanced performance and features
  • capacity: Minimum instances (can autoscale up to 125)
  • cookie-based-affinity: Session persistence setting

Step 2: Configure WAF Policy for Application Gateway

13
Create WAF Policy
az network application-gateway waf-policy create \ --name "wafpol-appgw-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --location "East US 2" \ --type "OWASP" \ --version "3.2" \ --mode "Detection" \ --state "Enabled"
Application Gateway WAF Policy: Unlike Front Door, Application Gateway WAF policies are regional resources. OWASP 3.2 is the latest core rule set with improved accuracy and reduced false positives.

OWASP Versions:
  • 3.2: Latest with paranoia level support and better accuracy
  • 3.1: Stable version with comprehensive coverage
  • 3.0: Legacy version (not recommended for new deployments)
14
Configure Custom Rules
az network application-gateway waf-policy custom-rule create \ --policy-name "wafpol-appgw-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --name "BlockSQLInjection" \ --priority 100 \ --rule-type "MatchRule" \ --action "Block" \ --match-conditions '[{ "matchVariables": [{"variableName": "PostArgs", "selector": "*"}], "operator": "Contains", "matchValues": ["union select", "drop table", "exec sp_"], "negationCondition": false }]'
Custom SQL Injection Rule: This rule provides additional protection beyond OWASP core rules by detecting specific SQL injection patterns in POST parameters. Custom rules allow for application-specific threat detection.

Match Variables:
  • PostArgs: POST request parameters
  • QueryString: URL query parameters
  • RequestHeaders: HTTP headers
  • RequestBody: Request payload
15
Create Rate Limiting Rule
az network application-gateway waf-policy custom-rule create \ --policy-name "wafpol-appgw-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --name "RateLimitPerIP" \ --priority 200 \ --rule-type "RateLimitRule" \ --action "Block" \ --rate-limit-threshold 50 \ --rate-limit-duration-in-minutes 1 \ --match-conditions '[{ "matchVariables": [{"variableName": "RemoteAddr"}], "operator": "IPMatch", "matchValues": ["0.0.0.0/0"], "negationCondition": false }]'
Rate Limiting Configuration: This rule limits each IP to 50 requests per minute, providing DDoS protection at the application layer. The threshold can be adjusted based on your application's normal traffic patterns.

Rate Limiting Best Practices:
  • Monitor normal traffic patterns before setting thresholds
  • Consider different limits for different endpoints
  • Use exclusions for legitimate high-volume clients

Step 3: Associate WAF Policy with Application Gateway

16
Associate WAF Policy
az network application-gateway waf-config set \ --gateway-name "appgw-webapp-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --enabled true \ --firewall-mode "Detection" \ --rule-set-type "OWASP" \ --rule-set-version "3.2"
WAF Configuration Association: This command enables WAF on the Application Gateway and associates it with the configured policy. The firewall mode can be changed to "Prevention" after testing in Detection mode.

Association Process:
  1. WAF policy is created independently
  2. Policy is associated with Application Gateway
  3. Policy settings override Application Gateway WAF config
  4. Changes to policy automatically apply to associated gateways
17
Link WAF Policy to Application Gateway
az network application-gateway update \ --name "appgw-webapp-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --set firewallPolicy.id="/subscriptions/{subscription-id}/resourceGroups/rg-waf-frontdoor-prod/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/wafpol-appgw-prod"
Policy Linking: This command creates the association between the Application Gateway and the WAF policy. Once linked, all traffic through the gateway is subject to the policy rules.

Policy Management:
  • One policy can be associated with multiple Application Gateways
  • Policy changes apply to all associated gateways
  • Policies can be updated without gateway downtime

7. WAF Policy Implementation

graph TB subgraph "WAF Policy Structure" A[WAF Policy] --> B[Managed Rule Sets] A --> C[Custom Rules] A --> D[Policy Settings] B --> E[OWASP Core Rules] B --> F[Bot Protection Rules] B --> G[Microsoft Default Rules] C --> H[Rate Limiting Rules] C --> I[Geographic Rules] C --> J[IP Allow/Block Rules] C --> K[Application-Specific Rules] D --> L[Mode: Detection/Prevention] D --> M[Request Body Inspection] D --> N[File Upload Limits] D --> O[Logging Configuration] end subgraph "Rule Evaluation Order" P[Custom Rules - Priority 1-100] --> Q[Managed Rules - Priority 101-1000] Q --> R[Default Action] end style A fill:#e3f2fd style P fill:#fff3e0 style Q fill:#e8f5e8 style R fill:#ffebee
WAF Policy Architecture: This diagram shows the comprehensive structure of a WAF policy including managed rule sets, custom rules, and policy settings. The evaluation order is critical - custom rules with lower priority numbers are evaluated first, allowing you to override or supplement managed rules with application-specific logic.

Advanced Policy Configuration

18
Configure Policy Settings
az network application-gateway waf-policy policy-setting update \ --policy-name "wafpol-appgw-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --state "Enabled" \ --mode "Prevention" \ --request-body-check true \ --max-request-body-size-in-kb 128 \ --file-upload-limit-in-mb 100
Policy Settings Configuration: These settings control global policy behavior including request body inspection, file upload limits, and overall policy mode. Request body inspection is crucial for detecting attacks in POST data.

Key Settings:
  • request-body-check: Enables inspection of POST/PUT request bodies
  • max-request-body-size-in-kb: Maximum body size to inspect (1-128 KB)
  • file-upload-limit-in-mb: Maximum file upload size (1-750 MB)
19
Configure Rule Exclusions
az network application-gateway waf-policy managed-rule exclusion add \ --policy-name "wafpol-appgw-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --rule-set-type "OWASP" \ --rule-set-version "3.2" \ --exclusion-match-variable "RequestArgNames" \ --exclusion-selector-match-operator "Equals" \ --exclusion-selector "viewstate"
Rule Exclusions: Exclusions allow legitimate traffic that might otherwise be blocked by WAF rules. This example excludes ASP.NET ViewState parameters from OWASP rule evaluation, preventing false positives.

Common Exclusions:
  • RequestArgNames: Specific parameter names
  • RequestHeaders: HTTP headers (e.g., User-Agent)
  • RequestCookieNames: Cookie names
  • RequestBodyPostArgNames: POST parameter names
20
Create Application-Specific Custom Rule
az network application-gateway waf-policy custom-rule create \ --policy-name "wafpol-appgw-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --name "AllowAPIClients" \ --priority 50 \ --rule-type "MatchRule" \ --action "Allow" \ --match-conditions '[{ "matchVariables": [{"variableName": "RequestHeaders", "selector": "User-Agent"}], "operator": "Contains", "matchValues": ["MyApp-API-Client/1.0"], "negationCondition": false }, { "matchVariables": [{"variableName": "RequestUri"}], "operator": "BeginsWith", "matchValues": ["/api/"], "negationCondition": false }]'
Application-Specific Allow Rule: This rule allows trusted API clients to bypass certain WAF rules. Multiple match conditions create an AND logic - both User-Agent and URI path must match for the rule to trigger.

Rule Logic:
  • Multiple match conditions = AND logic (all must match)
  • Multiple match values within one condition = OR logic
  • Lower priority numbers = higher precedence
  • Allow rules can bypass subsequent block rules

8. Policy Association and Management

graph TB subgraph "Policy Association Architecture" A[WAF Policies] --> B[Front Door Policies] A --> C[Application Gateway Policies] B --> D[Security Policy 1] B --> E[Security Policy 2] C --> F[Regional Policy West] C --> G[Regional Policy East] D --> H[Front Door Endpoint 1] D --> I[Front Door Endpoint 2] E --> J[Front Door Endpoint 3] F --> K[App Gateway West US] G --> L[App Gateway East US] H --> M[Domain: webapp.com] I --> N[Domain: api.webapp.com] J --> O[Domain: admin.webapp.com] K --> P[Backend Pool 1] L --> Q[Backend Pool 2] end subgraph "Policy Inheritance" R[Base Security Policy] --> S[Environment Policies] S --> T[Application Policies] T --> U[Endpoint-Specific Rules] end style A fill:#e3f2fd style R fill:#fff3e0
Policy Association and Inheritance: This diagram shows how WAF policies can be associated with different Azure services and how policy inheritance works. Front Door uses security policies to associate WAF policies with endpoints, while Application Gateway directly links to WAF policies. The inheritance model shows how to structure policies from base security requirements down to specific endpoint needs.

Policy Association Commands

21
Create Custom Domain and Associate Policy
az afd custom-domain create \ --custom-domain-name "webapp-custom-domain" \ --profile-name "fd-webapp-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --host-name "www.webapp.com" \ --certificate-type "ManagedCertificate"
Custom Domain Configuration: This creates a custom domain for your Front Door endpoint with managed SSL certificate. The domain will inherit WAF protection from associated security policies.

Certificate Options:
  • ManagedCertificate: Azure manages certificate lifecycle
  • CustomerCertificate: Use your own certificate from Key Vault
  • Domain validation required for managed certificates
22
Update Security Policy with Custom Domain
az afd security-policy update \ --profile-name "fd-webapp-prod" \ --resource-group "rg-waf-frontdoor-prod" \ --security-policy-name "webapp-security-policy" \ --domains '[{ "id": "/subscriptions/{subscription-id}/resourceGroups/rg-waf-frontdoor-prod/providers/Microsoft.Cdn/profiles/fd-webapp-prod/customDomains/webapp-custom-domain" }, { "id": "/subscriptions/{subscription-id}/resourceGroups/rg-waf-frontdoor-prod/providers/Microsoft.Cdn/profiles/fd-webapp-prod/afdEndpoints/webapp-prod-endpoint" }]'
Security Policy Update: This updates the security policy to include both the custom domain and the original endpoint. All domains in the policy will have the same WAF protection applied.

Domain Management:
  • Multiple domains can share the same security policy
  • Each domain can have its own policy for granular control
  • Policy changes apply to all associated domains immediately

Policy Monitoring and Management

23
Enable Diagnostic Logging
az monitor diagnostic-settings create \ --name "waf-diagnostics" \ --resource "/subscriptions/{subscription-id}/resourceGroups/rg-waf-frontdoor-prod/providers/Microsoft.Network/frontdoorwebapplicationfirewallpolicies/wafpol-frontdoor-prod" \ --workspace "/subscriptions/{subscription-id}/resourceGroups/rg-waf-frontdoor-prod/providers/Microsoft.OperationalInsights/workspaces/law-waf-monitoring" \ --logs '[{ "category": "FrontdoorWebApplicationFirewallLog", "enabled": true, "retentionPolicy": { "enabled": true, "days": 30 } }]' \ --metrics '[{ "category": "AllMetrics", "enabled": true, "retentionPolicy": { "enabled": true, "days": 30 } }]'
Diagnostic Settings: This enables comprehensive logging for WAF events, which is crucial for security monitoring, incident response, and rule tuning. Logs are sent to Log Analytics workspace for analysis.

Logging Benefits:
  • Security incident investigation and forensics
  • Rule effectiveness analysis and tuning
  • False positive identification and remediation
  • Compliance reporting and audit trails

9. Command Execution Order and Dependencies

graph TD A[1. Resource Group Creation] --> B[2. Network Infrastructure] B --> C[3. WAF Policy Creation] C --> D[4. Rule Configuration] D --> E[5. Service Deployment] E --> F[6. Policy Association] F --> G[7. Monitoring Setup] subgraph "Network Infrastructure" B1[Virtual Network
az network vnet create] --> B2[Public IP
az network public-ip create] B2 --> B3[Front Door Profile
az afd profile create] end subgraph "WAF Policy Creation" C1[Front Door WAF Policy
az network front-door waf-policy create] --> C2[App Gateway WAF Policy
az network application-gateway waf-policy create] end subgraph "Rule Configuration" D1[Managed Rules
az network front-door waf-policy managed-rules add] --> D2[Custom Rules
az network front-door waf-policy rule create] D2 --> D3[Rule Exclusions
az network application-gateway waf-policy managed-rule exclusion add] end subgraph "Service Deployment" E1[Application Gateway
az network application-gateway create] --> E2[Front Door Endpoint
az afd endpoint create] E2 --> E3[Custom Domain
az afd custom-domain create] end subgraph "Policy Association" F1[Security Policy
az afd security-policy create] --> F2[WAF Config
az network application-gateway waf-config set] F2 --> F3[Policy Link
az network application-gateway update] end subgraph "Monitoring Setup" G1[Log Analytics Workspace
az monitor log-analytics workspace create] --> G2[Diagnostic Settings
az monitor diagnostic-settings create] end B --> B1 C --> C1 D --> D1 E --> E1 F --> F1 G --> G1 style A fill:#e3f2fd style B fill:#e8f5e8 style C fill:#fff3e0 style D fill:#fce4ec style E fill:#f3e5f5 style F fill:#e0f2f1 style G fill:#fafafa
Command Execution Flow: This diagram shows the complete execution order for deploying WAF across Azure services. Each phase has dependencies on the previous phases, and the subgraphs show the specific commands within each phase. Following this order ensures all resources are created with proper dependencies and configurations.

Execution Summary

Deployment Phases:
  1. Foundation (Steps 1-3): Resource group, network infrastructure, and Front Door profile
  2. WAF Policies (Steps 4-7): Create and configure WAF policies with managed and custom rules
  3. Services (Steps 8-12): Deploy Application Gateway and Front Door endpoints
  4. Integration (Steps 13-17): Associate WAF policies with services
  5. Customization (Steps 18-22): Advanced configuration, custom domains, and exclusions
  6. Operations (Step 23): Enable monitoring and diagnostics