Edit

Share via

Azure Firewall threat intelligence-based filtering

You can enable Threat intelligence-based filtering for your firewall to alert and deny traffic from/to known malicious IP addresses, FQDNs, and URLs. The IP addresses, domains and URLs are sourced from the Microsoft Threat Intelligence feed, which includes multiple sources including the Microsoft Cyber Security team. Intelligent Security Graph powers Microsoft threat intelligence and uses multiple services including Microsoft Defender for Cloud.

Firewall threat intelligence

If you've enabled threat intelligence-based filtering, the firewall processes the associated rules before any of the NAT rules, network rules, or application rules.

When a rule triggers, you can choose to just log an alert, or you can choose alert and deny mode.

By default, threat intelligence-based filtering is in alert mode. You can’t turn off this feature or change the mode until the portal interface becomes available in your region.

You can define allowlists so threat intelligence doesn't filter traffic to any of the listed FQDNs, IP addresses, ranges, or subnets.

For a batch operation, you can upload a CSV file with list of IP addresses, ranges, and subnets.

Logs

The following log excerpt shows a triggered rule:

{
    "category": "AzureFirewallNetworkRule",
    "time": "2018-04-16T23:45:04.8295030Z",
    "resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/AZUREFIREWALLS/{resourceName}",
    "operationName": "AzureFirewallThreatIntelLog",
    "properties": {
         "msg": "HTTP request from 10.0.0.5:54074 to somemaliciousdomain.com:80. Action: Alert. ThreatIntel: Bot Networks"
    }
}

Testing

  • Outbound testing - Outbound traffic alerts should be a rare occurrence, as it means that your environment is compromised. To help test outbound alerts are working, a test FQDN exists that triggers an alert. Use testmaliciousdomain.eastus.cloudapp.azure.com for your outbound tests.

    To prepare for your tests and to ensure you don't get a DNS resolution failure, configure the following items:

    • Add a dummy record to the hosts file on your test computer. For example, on a computer running Windows, you could add 1.2.3.4 testmaliciousdomain.eastus.cloudapp.azure.com to the C:\Windows\System32\drivers\etc\hosts file.
    • Ensure that the tested HTTP/S request is allowed using an application rule, not a network rule.

  • Inbound testing - You can expect to see alerts on incoming traffic if the firewall has DNAT rules configured. You'll see alerts even if the firewall only allows specific sources on the DNAT rule and traffic is otherwise denied. Azure Firewall doesn't alert on all known port scanners; only on scanners that also engage in malicious activity.

Next steps