AzureFeeds

In this part, we’ll cover:

·        Initial setup: Authentication and prerequisites

·        Creating DNAT Rules to expose internal resources securely

·        Enabling IDPS (Intrusion Detection and Prevention System) with Signature Overrides and           Bypass Rules

·        Using Web Categories to simplify and strengthen application rules

·        Creating FQDN Filtering Rules to allow or deny traffic based on domain names

·        Creating URL Filtering Rules to allow or deny traffic based on URLs

·        Associating Multiple Public IPs with Azure Firewall for better scalability

·        Enabling Diagnostic Settings for detailed logging and monitoring

·        Customizing SNAT Private IP Address Ranges for precise outbound traffic control

By the end of this part, you’ll have a deeper understanding of how to leverage Azure Firewall’s full potential to meet real-world enterprise security needs— using REST API.

Initial Setup: Authentication and Prerequisites:

After downloading and setting up Bruno as the REST API client, creating a new collection as described in Part I, you will do the following:

• Service Principal Creation: 

Using Azure CLI, create a Service Principal in the correct subscription as shown below:

az ad sp create-for-rbac –name “BrunoClient” –role Contributor –scopes /subscriptions/{subscription-id}

         Make a note of the following:

1. App ID (client_id)


2. Tenant ID


3. Password (client_secret)

• Request a Bearer Token:

Using BRUNO, get the Bearer Token using the following PUT request and details we derived from the above Service Principal Creation.

POST: https://login.microsoft.com/{TenantID}/oauth2/token

Body (x-www-form-urlencoded):

1. grant_type: client_credentials


2. client_id: {App ID}


3. client_secret: {Password}


4. resource: https://management.azure.com

• Add Authorization Header for API Requests:

Once you get the Bearer Token, you need to add this to every Request as shown below:

We also need to refresh the Bearer Token each time it expires and update it in the Token field for every request. Typically, it expires every 1 hour, however, the exact expiration time can vary depending on the API and its configuration.

• Get Your Subscription ID: Retrieve the Subscription ID for the Azure subscription where your Azure Firewall instance is deployed

Using AZ CLI, get the Subscription ID to be used in the API requests:

az account show –query id -o tsv

Azure Firewall Configurations via REST API:

 In Part I of this series, we discussed how to use REST API to configure the Azure Firewall resource and the Firewall Policy. Now, let’s delve into the advanced features.

Configuring DNAT Rule:

This example demonstrates how to configure a DNAT (Destination Network Address Translation) rule using Azure Firewall’s REST API. It uses the ‘FirewallPolicyNatRuleCollection’ type to redirect traffic from a public IP and port to an internal FQDN and port.

Request:

 

Request Body:

{
“properties”: {
“priority”: 100,
“ruleCollections”: [
{
“ruleCollectionType”: “FirewallPolicyNatRuleCollection”,
“priority”: 100,
“name”: “Example-Nat-Rule-Collection”,
“action”: {
“type”: “DNAT”
},
“rules”: [
{
“ruleType”: “NatRule”,
“name”: “nat-rule1”,
“translatedFqdn”: “internalhttp.server.net”,
“translatedPort”: “8080”,
“ipProtocols”: [
“TCP”,
“UDP”
],
“sourceAddresses”: [
“2.2.2.2”
],
“sourceIpGroups”: [],
“destinationAddresses”: [
“{Firewall IP}”
],
“destinationPorts”: [
“8080”
]
}
]
}
]
}
}

When the PUT request is successful, the following rule is created under DNAT Rule Collection Group as shown below:

Enabling Intrusion Detection (IDPS):

 When using Azure Firewall Premium, enabling Intrusion Detection and Prevention (IDPS) helps monitor, detect and respond to suspicious activities, enhancing security. Below is a simple example that shows how to use the PUT method to update your Firewall policy with an IDPS configuration such as enabling it, applying signature overrides and bypassing certain trusted traffic from the IDPS rules.

💡 Note: Make sure your Azure Firewall SKU is Premium, as IDPS is only available in that tier.

Request:

 

Request Body:

{
“tags”: {
“key1”: “value1”
},
“location”: “westus”,
“properties”: {
“threatIntelMode”: “Alert”,
“threatIntelWhitelist”: {
“ipAddresses”: [],
“fqdns”: [“*.microsoft.com”]
},
“snat”: {
“privateRanges”: [“IANAPrivateRanges”]
},
“sql”: {
“allowSqlRedirect”: true
},
“sku”: {
“tier”: “Premium”
},
“intrusionDetection”: {
“mode”: “Alert”,
“configuration”: {
“signatureOverrides”: [
{
“id”: “2000105”,
“mode”: “Off”
}
],
“bypassTrafficSettings”: [
{
“name”: “BypassCustomRule1”,
“protocol”: “TCP”,
“sourceAddresses”: [“192.168.1.0/24”],
“destinationAddresses”: [“10.1.1.4”],
“destinationPorts”: [“443”]
}
]
}
}
}
}

When the PUT request is successful, IDPS is enabled in Alert mode (you can also set it to Alert & Deny if needed) as shown below. In this example:

• Signature ID 2000105 is overridden and set to Off, which appears as Disabled in the Azure Portal.


• A custom bypass rule is configured to exclude specific traffic (based on source IP, destination IP, and port) from IDPS filtering.

This configuration provides flexibility to fine-tune your threat detection settings while allowing exception/safe traffic to pass without inspection.

Creating Web Categories Rule:

Azure Firewall supports filtering outbound web traffic based on web categories, allowing administrators to block or allow access to entire categories of websites (e.g., Social Networking, Gambling, Adult Content). This provides a scalable way to enforce corporate internet usage policies without needing to specify individual domains.

💡 Note: While this feature is available in both Azure Firewall Standard and Premium, the Premium SKU offers more granular control by matching categories based on the entire URL for both HTTP and HTTPS traffic.

Below is an example of how to configure a web category-based application rule using REST API:

Request:

 

Request Body:

Request Body:
{
“properties”: {
“priority”: 200,
“ruleCollections”: [
{
“name”: “WebCategoryRuleCollection1”,
“ruleCollectionType”: “FirewallPolicyFilterRuleCollection”,
“priority”: 200,
“action”: {
“type”: “Deny”
},
“rules”: [
{
“ruleType”: “ApplicationRule”,
“name”: “blockWebCategories”,
“description”: ” Block social networking and travel-related websites”,
“protocols”: [
{
“protocolType”: “Https”,
“port”: 443
},
{
“protocolType”: “Http”,
“port”: 80
}
],
“sourceAddresses”: [
“10.0.0.0/24”
],
“webCategories”: [
“SocialNetworking”,
“Travel” ]
}
]
}
]
}
}

When this PUT request is successful, the rule denies outbound traffic to websites categorized under Social Networking and Travel from the source IP address range 10.0.0.0/24, for both ports 80 & 443 as shown below:

Creating FQDN Filtering Rule:

In many enterprise scenarios, it’s important to control which websites users can access. Azure Firewall supports FQDN-based application rules that allow you to filter outbound traffic based on fully qualified domain names (FQDNs), such as www.instagram.com or www.expedia.com.

These rules work by inspecting the Server Name Indication (SNI) field during the TLS handshake (for HTTPS traffic) or the Host header in HTTP requests. This makes it possible to apply access control without decrypting the full traffic stream — which means FQDN filtering works even without TLS inspection and is supported in both Standard and Premium SKUs.

Request:

Request Body:

{
“properties”: {
“priority”: 100,
“ruleCollections”: [
{
“name”: “AppRuleCollection1”,
“ruleCollectionType”: “FirewallPolicyFilterRuleCollection”,
“priority”: 100,
“action”: {
“type”: “Deny”
},
“rules”: [
{
“ruleType”: “ApplicationRule”,
“name”: ” blockSpecificFQDNs”,
“description”: ” Block specific websites by FQDN”,
“protocols”: [
{
“protocolType”: “Https”,
“port”: 443
}
],
“sourceAddresses”: [
“10.0.0.0/24”
],
“targetFqdns”: [
“www.instagram.com”,
“www.expedia.com”
]
}
]
}
]
}
}

Creating URL Filtering Rule:

If you want to control not just which domains users can access, but also specific URLs or paths within those domains, you can use the URL filtering capabilities.

To enable this, you must turn on TLS inspection. With HTTPS traffic, only the domain name (e.g., example.com) is visible during the TLS handshake via SNI (Server Name Indication). The full URL path (e.g., /downloads/malware.exe) remains encrypted. To inspect it, the firewall must decrypt the traffic, apply your rules, and then re-encrypt it before forwarding it to the destination.

This capability gives you granular control for scenarios like:

• Blocking access to specific file download paths


• Restricting parts of websites while allowing others


• Enforcing strict security policies without over blocking

💡 Note: URL path-based filtering is available only in Azure Firewall Premium.

💡 Note: Ensure TLS inspection is enabled for URL filtering to work on HTTPS traffic.

Request:

 

Request Body:

Request Body:
{
“properties”: {
“priority”: 100,
“ruleCollections”: [
{
“name”: “AppRuleCollection1”,
“ruleCollectionType”: “FirewallPolicyFilterRuleCollection”,
“priority”: 100,
“action”: {
“type”: “Deny”
},
“rules”: [
{
“ruleType”: “ApplicationRule”,
“name”: ” blockSpecificURLs”,
“description”: ” Block specific websites by FQDN”,
“protocols”: [
{
“protocolType”: “Https”,
“port”: 443
}
],
“sourceAddresses”: [
“10.0.0.0/24”
],
“terminateTLS”: true,
“targetUrls”: [
“www.example.com/downloads/malware.exe”,
“www.example.com/blockedpath/”]
}
]
}
]
}
}

When this PUT request is successful, the following rule will be created to block access to the specified target FQDNs from the 10.0.0.0/24 source IP address range, as shown below:

 

Associating Multiple Public IP’s: 

When managing Azure Firewall at scale, assigning multiple public IP addresses can help support higher availability and throughput, especially for SNAT or DNAT scenarios. We will walk through how to use the PUT method in Azure Firewall’s REST API to deploy and associate multiple IP configurations efficiently.

💡 Note:  When configuring multiple public IP addresses, ensure that you use Standard SKU public IP addresses, as Basic SKU public IPs are not supported with Azure Firewall.

💡 Note:  Associating multiple public IP addresses with your firewall increases the available SNAT ports, enhancing scalability.

Request:

 

Request Body:

{
“location”: “westus”,
“properties”: {
“ipConfigurations”: [
{
“name”: “ipConfig1”,
“properties”: {
“publicIPAddress”: {
“id”: “/subscriptions/{SubscriptionID}/resourceGroups/{ResourceGroupName}/ providers/Microsoft.Network/publicIPAddresses/{PublicIPName} ”
},
“subnet”: {
“id”: “/subscriptions/{SubscriptionID}/resourceGroups/{ResourceGroupName}/providers/Microsoft.Network/virtualNetworks/{VnetName}/subnets/{SubnetName}”
}
}
},
{
“name”: “ipConfig2”,
“properties”: {
“publicIPAddress”: {
“id”: “/subscriptions/{SubscriptionID}/resourceGroups/{ResourceGroupName}/ providers/Microsoft.Network/publicIPAddresses/{PublicIPName} ”
}
}
}
]
}
}

When this PUT request is successful, the specified public IP addresses will be associated with the Azure Firewall, as shown below:

Enable Diagnostic Logging:

Using the REST API, you can configure Azure Firewall to capture important log categories such as Application Rules, Network Rules, and DNS Proxy logs, as well as performance metrics and more.

💡 Note: A Log Analytics workspace must be set up beforehand to store the logs generated by the API configuration below.

Below is an example of how to set up diagnostic settings by linking the firewall to a Log Analytics workspace:

Request:

 

Request Body:

{
“properties”: {
“workspaceId”: “/subscriptions/{SubscriptionID}/resourceGroups/{Resourcegroupname}/providers/Microsoft.OperationalInsights/workspaces/FirewallLogs”,
“logs”: [
{
“category”: “AzureFirewallApplicationRule”,
“enabled”: true,
“retentionPolicy”: {
“enabled”: false,
“days”: 0
}
},
{
“category”: “AzureFirewallNetworkRule”,
“enabled”: true,
“retentionPolicy”: {
“enabled”: false,
“days”: 0
}
},
{
“category”: “AzureFirewallDnsProxy”,
“enabled”: true,
“retentionPolicy”: {
“enabled”: false,
“days”: 0
}
}
],
“metrics”: [
{
“category”: “AllMetrics”,
“enabled”: true,
“retentionPolicy”: {
“enabled”: false,
“days”: 0
}
}
],
“logAnalyticsDestinationType”: “Dedicated”
}
}

When the PUT request is successful, the following logs and metrics will be enabled, and these logs will be sent to the Log Analytics Workspace specified here:

Configuring SNAT Exclusions:

Azure Firewall provides SNAT capability for all outbound traffic to public IP addresses. If your organization uses registered IP address ranges outside of IANA RFC 1918 or IANA RFC 6598 for private networks, Azure Firewall SNATs the traffic to one of the firewall’s private IP addresses in AzureFirewallSubnet. You can configure Azure Firewall to not SNAT your public IP address range. For example, specify an individual IP address as x.x.x.x or a range of IP addresses as x.x.x.x/24.

Below is an example of how to configure SNAT exclusions using REST API:

Request

 

Request Body:

{
“tags”: {
“key1”: “value1”
},
“location”: “westus”,
“properties”: {
“threatIntelMode”: “Alert”,
“threatIntelWhitelist”: {
“ipAddresses”: [
],
“fqdns”: [
“*.microsoft.com”
]
},
“snat”: {
“privateRanges”: [
“1.2.3.4”,
“5.6.7.8”,
“IANAPrivateRanges”
]
},
“sql”: {
“allowSqlRedirect”: true
},
“sku”: {
“tier”: “Premium”
}
}
}

When this PUT request is successful, the following SNAT exclusion is added alongside the default private IP ranges as shown below:

Conclusion:

In this part of the series, we explored how to take Azure Firewall deployments to the next level by configuring advanced features through the REST API. From setting up DNAT rules and enabling IDPS with fine-grained control, to applying web category-based filtering, FQDN filtering, URL filtering, associating multiple public IP addresses, enabling diagnostic logging, and customizing SNAT behaviors — you now have a comprehensive toolkit to secure complex environments at scale. By using the REST API, you can automate firewall management, enforce consistent security policies, and quickly adapt to changing network requirements — all critical capabilities for modern cloud-native architectures.