Is Log Analytics Workspace required to view WAF logs for Azure Front Door? How to identify blocked traffic?

Question

Hi,

I want to use Azure Front Door to protect my applications and domains running on several VMs. I would like to review the WAF logs to understand which traffic has been blocked due to potential threats and anomaly score.

From what I understand, I can enable diagnostic settings for Azure Front Door, but I’m not entirely sure about the role and actual usage of Log Analytics Workspace in this context.

My questions are:

Is Log Analytics Workspace required if I want to view detailed WAF logs (e.g., blocked requests, rule IDs, source IPs)?

What are the steps to set it up properly, and is there a sample Kusto query to identify blocked traffic?

Appreciate any clarification or examples. Thank you!

Answer 1

Hi @Kanie Almasi

To answer your 1st question: Yes, a Log Analytics Workspace is required if you want to view detailed WAF logs for Azure Front Door.

While Azure Front Door offers some basic reporting and metrics in the portal (like "Security Reports" for Premium tier), these are summarized views. To get the granular, per-request details including:

• Blocked requests: The specific action taken by the WAF.
• Rule IDs: Which WAF rule was triggered.
• Source IPs: The client's IP address.
• Anomaly scores: If using anomaly scoring.
• Request URI, HTTP Method, Headers, Body details (if configured): For deeper analysis.
• Tracking references: For end-to-end correlation.

You need to send the diagnostic logs to a destination where they can be stored and queried. Log Analytics Workspace is the ideal destination for this purpose because it allows you to:

• Store logs: Centralized storage for all your Azure resources.
• Query logs: Use Kusto Query Language (KQL) for powerful and flexible analysis.
• Create alerts: Set up alerts based on specific log patterns (e.g., high number of blocked requests from a single IP).
• Build dashboards: Visualize your WAF data.
• Integrate with Azure Sentinel: For advanced SIEM capabilities.

---

Setting up WAF logging to Log Analytics Workspace involves configuring Diagnostic Settings for your Azure Front Door profile.

Reference: Configure logs

Here are the steps:

Create a Log Analytics Workspace (if you don't have one):

• Go to the Azure portal.
• Search for "Log Analytics workspaces" and click "Create."
• Provide details: Subscription, Resource Group, Name, Region.
• Click "Review + create," then "Create."

Enable Diagnostic Settings for your Azure Front Door Profile:

• Go to your Azure Front Door profile in the Azure portal.
• Under the "Monitoring" section in the left-hand menu, select "Diagnostic settings."
• Click on "+ Add diagnostic setting" (or "Add diagnostic setting" if it's the first one).
  • Diagnostic setting name: Give it a name (e.g., AFD-WAF-Logs).
    

Under Logs, you will see different categories. Select:

FrontDoorWebApplicationFirewallLog` (This is the one for WAF logs).

• You might also want to select FrontDoorAccessLog for general traffic information and FrontDoorHealthProbeLog for health check details.
• Under Destination details, select "Send to Log Analytics workspace."
• Choose your Subscription and the Log Analytics Workspace you created (or an existing one).
• Click "Save."

Once configured, it can take a few minutes for the first logs to start appearing in your Log Analytics Workspace.

---

Is there a sample Kusto query to identify blocked traffic?

Reference: WAF logs

The WAF logs for Azure Front Door are typically stored in the AzureDiagnostics table in your Log Analytics Workspace.

The following example query shows the requests that the Azure Front Door WAF blocked:

AzureDiagnostics 
| where ResourceProvider == "MICROSOFT.CDN" and Category == "FrontDoorWebApplicationFirewallLog" 
| where action_s == "Block" 

The following snippet shows an example log entry, including the reason that the request was blocked:

{
  "time": "2020-06-09T22:32:17.8376810Z",
  "category": "FrontdoorWebApplicationFirewallLog",
  "operationName": "Microsoft.Cdn/Profiles/Write",
  "properties": {
    "clientIP": "xxx.xxx.xxx.xxx",
    "clientPort": "52097",
    "socketIP": "xxx.xxx.xxx.xxx",
    "requestUri": "https://wafdemofrontdoorwebapp.azurefd.net:443/?q=%27%20or%201=1",
    "ruleName": "Microsoft_DefaultRuleSet-1.1-SQLI-942100",
    "policy": "WafDemoCustomPolicy",
    "action": "Block",
    "host": "wafdemofrontdoorwebapp.azurefd.net",
    "trackingReference": "08Q3gXgAAAAAe0s71BET/QYwmqtpHO7uAU0pDRURHRTA1MDgANjMxNTAwZDAtOTRiNS00YzIwLTljY2YtNjFhNzMyOWQyYTgy",
    "policyMode": "prevention",
    "details": {
      "matches": [
        {
          "matchVariableName": "QueryParamValue:q",
          "matchVariableValue": "' or 1=1"
        }
      ]
    }
  }
}

If you specifically want to see which rules contributed to an anomaly score (even if the request wasn't ultimately blocked because the score didn't reach the threshold), you'd look for action_s == "AnomalyScoring" or action_s == "Log" and check the ruleName_s and anomalyScoring_s fields.

Example for specific rule ID or source IP:

// Blocked requests for a specific rule ID
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| where action_s == "Block"
| where ruleName_s contains "942440" // Example: a specific SQL Injection rule ID
| project TimeGenerated, clientIP_s, requestUri_s, ruleName_s, action_s

// Blocked requests from a specific source IP
AzureDiagnostics
| where Category == "FrontDoorWebApplicationFirewallLog"
| where action_s == "Block"
| where clientIP_s == "203.0.113.45" // Replace with the specific IP
| project TimeGenerated, requestUri_s, ruleName_s, action_s, details_msg_s

By leveraging Log Analytics Workspace and Kusto queries, you'll have a powerful toolset to monitor, analyze, and troubleshoot your Azure Front Door WAF effectively.

---

Your feedback is important so please take a moment to click 'Accept answer'.

If you still have questions, please let us know what is needed in the 'comments' so the question can be answered.