Module 06 — Custom Rules, Rate Limiting & Geo-Filtering¶

When Managed Rules Are Not Enough¶

Managed rules—DRS 2.1 and the OWASP Core Rule Set—do an excellent job of catching generic web attacks like SQL injection and cross-site scripting. However, every application has its own business logic, and that logic creates threat surfaces that no generic ruleset can anticipate.

Consider a few real-world examples:

• An e-commerce checkout API that should only accept traffic from your own front-end domain, never from unknown sources.
• A partner portal that must be reachable only from a handful of known corporate IP ranges.
• A login endpoint that needs rate limiting to stop credential-stuffing campaigns.
• An application that must comply with data-residency regulations and therefore must block requests originating from certain countries.

Custom rules address all of these gaps. They sit in front of the managed-rule engine, so any request that matches a custom rule is resolved immediately—either allowed, blocked, logged, or (on Front Door) redirected or challenged—without ever reaching the managed ruleset evaluation.

Custom Rule Components¶

Every custom rule is built from four fundamental pieces: match conditions, a priority, an action, and an optional rule type (match or rate-limit).

Match Conditions¶

A match condition specifies what to inspect, how to compare it, and what value to look for. You can attach multiple conditions to a single rule; when you do, they are combined with AND logic—every condition must match for the rule to fire.

Priority¶

Priority is an integer from 1 to 100. Lower numbers evaluate first. If two rules could both match a request, the one with the lower priority number wins.

Action Types¶

The action tells the WAF what to do when the rule fires:

Action	Application Gateway	Front Door	Description
Allow			Stop evaluation — permit the request
Block			Return 403 Forbidden
Log			Record the match, continue evaluation
Redirect			302 redirect to a specified URL
JSChallenge			Issue a JavaScript challenge (NEW 2025)

Match Variables Reference¶

The table below lists every match variable available in custom rules, together with the operators you can pair with each one.

Operators¶

IP Allow/Block Lists¶

One of the most common custom-rule scenarios is restricting access to a known set of source IPs. You might need this for an internal admin portal, a staging environment, or a B2B API that only your partner's network should reach.

Blocking a list of malicious IPs¶

The following rule blocks requests coming from two suspicious CIDR ranges and assigns them priority 10 (very high).

az network application-gateway waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockMaliciousIPs \
  --priority 10 \
  --rule-type MatchRule \
  --action Block

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockMaliciousIPs \
  --match-variables RemoteAddr \
  --operator IPMatch \
  --values "203.0.113.0/24" "198.51.100.0/24"

az network front-door waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name wafPolicyFD \
  --name BlockMaliciousIPs \
  --priority 10 \
  --rule-type MatchRule \
  --action Block

az network front-door waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name wafPolicyFD \
  --name BlockMaliciousIPs \
  --match-variables RemoteAddr \
  --operator IPMatch \
  --values "203.0.113.0/24" "198.51.100.0/24"

Allowing only trusted IPs (allow-list pattern)¶

To restrict an admin path to your corporate network, create an Allow rule at a high priority and then a catch-all Block rule for everything else on that path.

# Rule 1 — Allow corporate network
az network application-gateway waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name AllowCorpNetwork \
  --priority 5 \
  --rule-type MatchRule \
  --action Allow

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name AllowCorpNetwork \
  --match-variables RemoteAddr \
  --operator IPMatch \
  --values "10.1.0.0/16" "172.16.0.0/12"

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name AllowCorpNetwork \
  --match-variables RequestUri \
  --operator BeginsWith \
  --values "/admin"

# Rule 2 — Block everyone else on /admin
az network application-gateway waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockAdminOthers \
  --priority 6 \
  --rule-type MatchRule \
  --action Block

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockAdminOthers \
  --match-variables RequestUri \
  --operator BeginsWith \
  --values "/admin"

Geo-Filtering¶

Geo-filtering leverages the GeoMatch operator on RemoteAddr (or SocketAddr) to allow or deny requests based on the country of origin. Azure WAF resolves the source IP to a country using a continuously updated IP geolocation database.

Blocking specific countries¶

az network application-gateway waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name GeoBlockCountries \
  --priority 20 \
  --rule-type MatchRule \
  --action Block

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name GeoBlockCountries \
  --match-variables RemoteAddr \
  --operator GeoMatch \
  --values "CN" "RU" "KP"

Allowing only specific countries (negate)¶

If your application is meant exclusively for users in Brazil and the United States, you can negate the GeoMatch condition: "if the country is not BR and not US, then block."

az network application-gateway waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name GeoAllowBRUS \
  --priority 25 \
  --rule-type MatchRule \
  --action Block

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name GeoAllowBRUS \
  --match-variables RemoteAddr \
  --operator GeoMatch \
  --negate \
  --values "BR" "US"

Rate Limiting Rules¶

Rate-limit rules are a special type of custom rule that counts matching requests over a sliding window and takes action only when a threshold is exceeded. They are your first line of defense against credential stuffing, API abuse, and application-layer DDoS.

Core Concepts¶

When GroupBy is set to None, the threshold applies to the aggregate of all matching traffic—useful for protecting a single endpoint against floods from distributed botnets.

Rate-limit flow¶

flowchart LR
    A[Incoming Request] --> B{Matches rule\nconditions?}
    B -- No --> C[Pass to next rule]
    B -- Yes --> D[Increment counter\nfor group-by key]
    D --> E{Counter ≥\nthreshold?}
    E -- No --> C
    E -- Yes --> F[Execute action\nBlock / Log / Redirect]

CLI example — Rate-limit login endpoint¶

az network application-gateway waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name RateLimitLogin \
  --priority 30 \
  --rule-type RateLimitRule \
  --rate-limit-duration FiveMinutes \
  --rate-limit-threshold 50 \
  --group-by-user-session "ClientAddr" \
  --action Block

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name RateLimitLogin \
  --match-variables RequestUri \
  --operator BeginsWith \
  --values "/auth/login"

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name RateLimitLogin \
  --match-variables RequestMethod \
  --operator Equal \
  --values "POST"

az network front-door waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name wafPolicyFD \
  --name RateLimitLogin \
  --priority 30 \
  --rule-type RateLimitRule \
  --rate-limit-duration FiveMinutes \
  --rate-limit-threshold 50 \
  --group-by-user-session "SocketAddr" \
  --action Block

az network front-door waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name wafPolicyFD \
  --name RateLimitLogin \
  --match-variables RequestUri \
  --operator BeginsWith \
  --values "/auth/login"

az network front-door waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name wafPolicyFD \
  --name RateLimitLogin \
  --match-variables RequestMethod \
  --operator Equal \
  --values "POST"

Request Size Constraints¶

Oversized request bodies can be used to exploit buffer-overflow vulnerabilities, upload malicious files, or simply overwhelm your backend. A custom rule with a GreaterThan operator on the RequestBody length lets you reject requests before they reach your application.

az network application-gateway waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockLargeBody \
  --priority 15 \
  --rule-type MatchRule \
  --action Block

az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockLargeBody \
  --match-variables RequestBody \
  --operator GreaterThan \
  --values "102400" \
  --transforms ""

In this example any request whose body exceeds 100 KB is immediately blocked. Adjust the threshold according to your application's expected payload sizes— a file-upload endpoint might need a more generous limit than a JSON API.

Combining Conditions¶

Within a single custom rule, every match condition is joined by AND logic: all conditions must be true for the rule to fire. To express OR logic between values, list multiple values in a single condition—the WAF treats them as "match any of these."

Example — Block suspicious user-agents on the API path¶

This rule fires only when both of the following are true:

1. The request URI starts with /api/.
2. The User-Agent header contains one of the suspicious strings.

az network application-gateway waf-policy custom-rule create \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockSuspiciousUA \
  --priority 35 \
  --rule-type MatchRule \
  --action Block

# Condition 1 — URI starts with /api/
az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockSuspiciousUA \
  --match-variables "RequestUri" \
  --operator BeginsWith \
  --values "/api/"

# Condition 2 — User-Agent contains any of these strings (OR within condition)
az network application-gateway waf-policy custom-rule match-condition add \
  --resource-group rg-waf-workshop \
  --policy-name waf-policy-appgw \
  --name BlockSuspiciousUA \
  --match-variables "RequestHeaders['User-Agent']" \
  --operator Contains \
  --values "python-requests" "curl/" "sqlmap" "nikto" \
  --transforms Lowercase

Custom Rule Priority & Evaluation Order¶

Understanding evaluation order is critical for building a correct rule set. The diagram below shows how the WAF engine processes every inbound request.

flowchart TD
    A[Incoming HTTP Request] --> B[Custom Rules\nevaluated by priority\nlowest number first]
    B --> C{Custom rule\nmatched?}
    C -- "Yes — Allow" --> D[Request ALLOWED\nSkip managed rules]
    C -- "Yes — Block" --> E[Request BLOCKED\n403 returned]
    C -- "Yes — Log" --> F[Log the match\nContinue to managed rules]
    C -- No match --> G[Managed Rules\nDRS 2.1 / Bot Manager]
    F --> G
    G --> H{Anomaly score\n≥ threshold?}
    H -- Yes --> E
    H -- No --> I[Request forwarded\nto backend]
    D --> I

Key points to remember:

1. Allow stops everything. If an Allow rule matches, neither subsequent custom rules nor managed rules are evaluated.
2. Block stops everything. The request is rejected immediately.
3. Log is transparent. The match is recorded, but the request continues through the rest of the pipeline.
4. Priority ties are undefined. Always assign unique priority values to guarantee a deterministic evaluation order.

Putting It All Together — A Complete Rule Set¶

The table below shows a realistic, layered rule set for a production web application. Notice how the priority numbers create a logical evaluation order.

This layered approach ensures that known-good traffic is cleared first (priorities 1–5), then known-bad traffic is rejected (priorities 10–35), then size constraints are enforced (priority 40), and finally the managed ruleset catches any remaining attack patterns.

Related Labs¶

• LAB04 — Exclusions & Tuning
• LAB08 — Rate Limiting

Key Takeaways¶

1. Custom rules fill the gaps that managed rules cannot cover—IP restrictions, geo-filtering, rate limiting, and application-specific logic.
2. Custom rules evaluate before managed rules, in ascending priority order.
3. Allow and Block actions stop all further evaluation; Log lets the request continue.
4. Use AND logic within a rule (multiple conditions) and separate rules for OR logic.
5. Rate-limit rules support sliding windows of 1 or 5 minutes, with grouping by client IP, socket IP, geo-location, or the new XFF header.
6. Always assign unique, well-spaced priority numbers so you can insert new rules later without renumbering.

References¶

• Azure WAF custom rules overview — Microsoft Learn
• Configure WAF rate-limit rules — Microsoft Learn
• Geo-filtering on Azure Front Door — Microsoft Learn
• az network application-gateway waf-policy custom-rule — CLI Reference
• az network front-door waf-policy custom-rule — CLI Reference