Azure Front Door not applying the expected block-action

Question

In Azure Front Door, we have a Front Door WAF policy with a custom (example) rule that blocks all IP addresses starting with 111.222.:

(where 10 is the lowest Priority, so first to be applied)

When querying the Front Door Logs with the following KQL:

AzureDiagnostics| where clientIP_s startswith "111.222." or clientIp_s startswith "111.222."| project clientIP_s, clientIp_s, ruleName_s, action_s, httpStatusCode_s| take 10

we get the following results:

clientIP_s	clientIp_s	ruleName_s	action_s	httpStatusCode_s
	111.222.3.4			429
	111.222.5.6			429
111.222.7.8		StackOverflowExample	Block
111.222.9.0		StackOverflowExample	Block
	111.222.9.0			429

In case an IP address is matched as a clientIp_s (lower case p), it is not picked up by the rule StackOverflowExample. Only when matched as a clientIP_s (upper case P) is it picked up by StackOverflowExample and correctly blocked. Note that there is another rate-limiting rule that matches the URL for the clientIp_s requests and returns a 429.

Some observations:

• there are IP addresses that only occur as a clientIP_s (111.222.3.4 and 111.222.5.6)
• there are IP addresses that only occur as a clientIp_s (111.222.7.8)
• there are IP addresses that occur as both a clientIP_s and clientIp_s (111.222.9.0)

How come the clientIp_s are not matched by the rule StackOverflowExample?

Answer 1

Hi @Erwin Verbruggen (Q42)

Please note, there are couple of things going on here, and is a multi-step question. Let's take it step-by-step.

Firstly, there are similar fields for clientIP because:

• clientIP_s: This field is typically used in the FrontdoorAccessLog category. It captures the IP address of the client making the request to Azure Front Door
• clientIp_s: This field is used in the FrontdoorWebApplicationFirewallLog category. It also captures the client's IP address but is specifically related to logs generated by the Web Application Firewall (WAF) associated with Azure Front Door

These fields help in tracking and analyzing the source of requests and any potential security threats. Now, depending on which license SKU of Azure Front door you are using, you'd see difference if you rin the followng queries.

Front Door

Diagnostic logs Category == "FrontdoorAccessLog" or Category == "FrontdoorWebApplicationFirewallLog“

Log field clientIp_s for client IP info

Log field trackingReference_s for all WAF + Access logs related to a single HTTP request

Front Door Premium

Diagnostic logs Category == "FrontDoorWebApplicationFirewallLog" or Category == "FrontDoorAccessLog“

Log field clientIP_s for client IP info

Application Gateway

Diagnostic logs Category == "ApplicationGatewayAccessLog" or Category == "ApplicationGatewayFirewallLog“

Log field clientIp_s for client IP info

So, the fact there is already another filter rule you applied that returns a 429 on field clientIp_s might clash with your StackOverFlow example.

Here are options you can try

1. Make a case-insensitive query

Change your query to something like this:

AzureDiagnostics
| where tolower(clientIp_s) startswith "111.222."
| project clientIp_s, ruleName_s, action_s, httpStatusCode_s
| take 10

2. Create the custom rule on PowerShell

To modify your custom rule to match both clientIP_s and clientIp_s, you would need to add a match condition for each in your WAF policy rule.

Here’s an example of how you can do this using Azure PowerShell. Running these, will create your custom rule.

# Define match conditions for clientIP_s and clientIp_s
$clientIP = New-AzFrontDoorWafMatchConditionObject -MatchVariable clientIP_s -OperatorProperty IPMatch -MatchValue "111.222."
$clientIp = New-AzFrontDoorWafMatchConditionObject -MatchVariable clientIp_s -OperatorProperty IPMatch -MatchValue "111.222."

# Add these match conditions to your custom rule
$customRule = New-AzFrontDoorWafCustomRuleObject -Name "StackOverflowExample" -RuleType MatchRule -MatchCondition $clientIP,$clientIp -Action Block -Priority 1

You may also use Azure CLI (for instance in Linux) as:

# Define the WAF policy name and resource group
waf_policy_name="your-waf-policy-name"
resource_group="your-resource-group-name"

# Define the custom rule name and priority
custom_rule_name="StackOverflowExample"
priority=100

# Define the IP address prefix to block
ip_prefix="111.222."

# Create the match conditions for clientIP_s and clientIp_s
match_condition_clientIP="clientIP_s=IPMatch=$ip_prefix"
match_condition_clientIp="clientIp_s=IPMatch=$ip_prefix"

# Create the custom rule with the match conditions
az network front-door waf-policy rule create \
dockerfile
--policy-name $waf_policy_name \
--resource-group $resource_group \
--name $custom_rule_name \
--priority $priority \
--action Block \
--rule-type MatchRule \
--match-condition $match_condition_clientIP $match_condition_clientIp

I'd also suggest reading here:

Policy settings for Web Application Firewall in Azure Front Door

---

I hope that this response has addressed your query and helped you overcome your challenges. If so, please mark this response as Answered. This will not only acknowledge our efforts, but also assist other community members who may be looking for similar solutions.