Azure Front Door: hoe regels te vinden die blokkeren?

Azure Front Door is een krachtige service om applicaties wereldwijd beschikbaar te maken. Dankzij de ingebouwde Web Application Firewall (WAF) kun je verkeer filteren en beschermen tegen aanvallen. Maar soms gebeurt het dat ook legitiem verkeer wordt geblokkeerd. Hoe achterhaal je dan welke regel hiervoor verantwoordelijk is?

Met Log Analytics kun je dit snel inzichtelijk maken.

1. Zorg voor logging

Om te kunnen analyseren welke regels blokkeren, moet logging aan staan:

• Ga naar je Front Door resource in Azure Portal.
• Onder Diagnostic settings stuur je de logs door naar Log Analytics.
• Schakel minimaal de categorieën FrontdoorAccessLog en FrontDoorWebApplicationFirewallLog in.

Na een paar minuten kun je de eerste loggegevens terugvinden.

2. Welke regels blokkeren?

Met deze KQL query zie je direct welke WAF-regels verkeer blokkeren:

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.CDN"
    and Category == "FrontDoorWebApplicationFirewallLog"
    and action_s == "Block" 
| project
    TimeGenerated,
    clientIP_s,
    requestUri_s,
    ruleName_s,
    action_s,
    timeTaken_s,
    policy_s,
    trackingReference_s
| order by TimeGenerated desc

Belangrijkste velden:

• ruleName_s → de regel die getriggerd is
• policy_s → welke WAF-policy actief was
• trackingReference_s → een unieke code om dit verzoek verder op te sporen

3. Van geblokkeerd request naar regel met trackingReference_s

De waarde trackingReference_s is je beste vriend bij het troubleshooten. Het is een unieke referentie die in alle logs terugkomt. Daarmee kun je een geblokkeerd verzoek uit het AccessLog koppelen aan de specifieke regel in het FrontDoorWebApplicationFirewallLog.

Neem de waarde van trackingReference_s uit de AccessLog en zoek in het WAFLog:

AzureDiagnostics
| where trackingReference_s == '<trackingReference>'
| project TimeGenerated, Category, details_matches_s,ruleName_s, action_s, trackingReference_s
| order by TimeGenerated desc

Zo kun je precies zien welke regel het verkeer tegenhield.

4. Combineren van de log queries

Door de AccessLog te combineren met de FrontDoorWebApplicationFirewallLog met de trackingReference_s kan snel gezien worden welke rules een Block of AnomalyScoring opleveren. Een Block komt soms alleen tot stand door meerdere AnomalyScoring acties.

let access = AzureDiagnostics
| where Category == "FrontDoorAccessLog"
| project accessTime=TimeGenerated, clientIP_s, requestUri_s, trackingReference_s;

let waf = AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
  and (action_s == "Block" or action_s == "AnomalyScoring")
| project wafTime=TimeGenerated, ruleName_s, policy_s, action_s, trackingReference_s;

access
| join kind=inner waf on trackingReference_s
| project accessTime, clientIP_s, requestUri_s, wafTime, ruleName_s, policy_s, action_s,trackingReference_s
| order by accessTime desc

5. Conclusie

Met alleen een melding “Request blocked” kom je er nog niet helemaal. Dankzij een query op basis van de trackingReference_s kun je:

• False positives herkennen en analyseren.
• Regels verfijnen of tijdelijk aanpassen.
• False positives van de actie Block naar Log omzetten of met exclude regels verfijnen.