Front Door WAF policy: How to get logs when "Block by ASN"

Question

Front Door WAF policy: How to get logs when "Block by ASN"

Matthias Müller 0

I've created a "Front Door WAF policy" which blocks requests by ASN.

I can see in the logs, that requests are blocked.
Because I want to assess, whether the blocks are correct, I need to see the actual ASN of the blocked requests.

So my question: Where would I see the ASN in the logs?

AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"

0 comments

2 answers

Your answer

Answer 1

Azure Front Door WAF logs do not include an ASN field; identify the IP evaluated by the ASN rule from socketIP_s or clientIP_s, then perform a separate IP-to-ASN lookup.

Identify the evaluated IP

The WAF log schema exposes SocketIP, ClientIP, RuleName, and related request data, but not ASN. ^1^

Use this query for the blocked custom rule:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.CDN"
| where Category == "FrontDoorWebApplicationFirewallLog"
| where action_s =~ "Block"
| where ruleName_s == "<your-ASN-rule-name>"
| project TimeGenerated, ruleName_s, action_s,
          clientIP_s, socketIP_s, requestUri_s,
          trackingReference_s
| order by TimeGenerated desc

Choose the IP column according to the ASN rule’s match variable:

SocketAddr → use socketIP_s. This is the address on the TCP connection seen by Front Door; when a proxy is involved, it is the proxy address.
RemoteAddr → use clientIP_s. This represents the original client IP derived from X-Forwarded-For.

Front Door resolves that selected IP to an ASN internally before applying AsnMatch. ^2^

If the expected columns do not appear under those names, inspect one record because the destination/table schema can affect column presentation:

AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| where action_s =~ "Block"
| where ruleName_s == "<your-ASN-rule-name>"
| take 1

Retrieve the ASN separately

If Microsoft Sentinel is enabled for the workspace and the caller is authorized to invoke the Microsoft.SecurityInsights enrichment endpoint, submit the evaluated IP to its geolocation API:

GET https://management.azure.com/subscriptions/[Subscription ID]/resourceGroups/[Resource Group] Group]/providers/Microsoft.SecurityInsights/enrichment/ip/geodata/?ipaddress={ipAddress}&api-version={api-version}
Authorization: Bearer {access-token}

Read the ASN field from the response. The API also returns the organization and carrier, and is limited to 100 calls per user per hour. ^3^

This enrichment reconstructs the likely current ASN for the logged IP. It does not reveal the exact ASN value that Front Door evaluated at request time; mappings can change, and Front Door does not emit its resolved ASN in the documented WAF log.

For repeated analysis, populate a Sentinel watchlist with evaluated IPs as the search key and their ASN as another column, then enrich the WAF events:

let AsnMap =
    _GetWatchlist('ip-to-asn')
    | project SearchKey, ASN, Organization;
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| where action_s =~ "Block"
| where ruleName_s == "<your-ASN-rule-name>"
| extend EvaluatedIP = socketIP_s   // Use clientIP_s for RemoteAddr
| lookup kind=leftouter AsnMap on $left.EvaluatedIP == $right.SearchKey
| project TimeGenerated, EvaluatedIP, ASN, Organization,
          ruleName_s, requestUri_s

The watchlist must first be created and populated with an IP-to-ASN mapping; SearchKey should contain the evaluated IP. Sentinel recommends using SearchKey for watchlist joins. ^4^

References

Answer 2

The existing answer above is correct on the schema and the watchlist enrichment pattern. However, I want to add a few practical points from running similar detections in production, because watchlist joins are one of the most common sources of silent failures in Sentinel rules.

Normalize both sides of the join

The most frequent reason a watchlist enrichment appears to "not work" is formatting mismatch. CSVs exported from IP-to-ASN providers often have trailing spaces or mixed casing. Always normalize:

let AsnMap = _GetWatchlist('ip-to-asn')
    | project SearchKey = tolower(trim(@"\s", SearchKey)),
              ASN, Organization;
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| where action_s == "Block"
| where resourceName_s == "<your-FrontDoor-resource>"
| extend EvaluatedIP = tolower(trim(@"\s", socketIP_s))
| lookup kind=leftouter AsnMap on $left.EvaluatedIP == $right.SearchKey
| project TimeGenerated, EvaluatedIP, ASN, Organization,
          action_s, ruleName_s, requestUri_s

lookup vs join vs in

Use lookup (as shown above) when you want to enrich logs with watchlist columns (ASN, Organization).

Use 'in' when you only need to filter (e.g., "is this IP on my blocklist?"). 'in' is significantly more performant on large log tables because it avoids the shuffle that join/lookup triggers.

Avoid 'join kind=inner' for enrichment — it will drop log rows that don't match the watchlist, which is usually not what you want for a WAF analysis.

Watchlist refresh cadence

ASN-to-IP mappings drift. If you're populating this watchlist via a Logic App or API, set it to refresh at least weekly. A stale watchlist will give you confident but wrong ASN labels, which is worse than no label at all.

Debugging tip

If the lookup returns empty ASN columns, run this sanity check first:

_GetWatchlist('ip-to-asn') | take 5

Check for leading spaces in SearchKey — this is the #1 cause I've seen in the field.

Hope this helps. Happy to clarify if you hit any schema quirks with your specific Front Door instance.