Deploy and configure Azure Firewall Premium

Article
02/28/2022

Azure Firewall Premium is a next generation firewall with capabilities that are required for highly sensitive and regulated environments. It includes the following features:

TLS Inspection - decrypts outbound traffic, processes the data, then encrypts the data and sends it to the destination.
IDPS - A network intrusion detection and prevention system (IDPS) allows you to monitor network activities for malicious activity, log information about this activity, report it, and optionally attempt to block it.
URL filtering - extends Azure Firewall’s FQDN filtering capability to consider an entire URL. For example, www.contoso.com/a/c instead of www.contoso.com.
Web categories - administrators can allow or deny user access to website categories such as gambling websites, social media websites, and others.

For more information, see Azure Firewall Premium features.

You'll use a template to deploy a test environment that has a central VNet (10.0.0.0/16) with three subnets:

a worker subnet (10.0.10.0/24)
an Azure Bastion subnet (10.0.20.0/24)
a firewall subnet (10.0.100.0/24)

Important

Hourly pricing starts from the moment that Bastion is deployed, regardless of outbound data usage. For more information, see Pricing and SKUs. If you're deploying Bastion as part of a tutorial or test, we recommend that you delete this resource after you finish using it.

A single central VNet is used in this test environment for simplicity. For production purposes, a hub and spoke topology with peered VNets is more common.

The worker virtual machine is a client that sends HTTP/S requests through the firewall.

Prerequisites

If you don't have an Azure subscription, create a free account before you begin.

Deploy the infrastructure

The template deploys a complete testing environment for Azure Firewall Premium enabled with IDPS, TLS Inspection, URL Filtering, and Web Categories:

a new Azure Firewall Premium and Firewall Policy with predefined settings to allow easy validation of its core capabilities (IDPS, TLS Inspection, URL Filtering, and Web Categories)
deploys all dependencies including Key Vault and a Managed Identity. In a production environment, these resources may already be created and not needed in the same template.
generates self-signed Root CA and deploys it on the generated Key Vault
generates a derived Intermediate CA and deploys it on a Windows test virtual machine (WorkerVM)
a Bastion Host (BastionHost) is also deployed and can be used to connect to the Windows testing machine (WorkerVM)

Test the firewall

Now you can test IDPS, TLS Inspection, Web filtering, and Web categories.

Add firewall diagnostics settings

To collect firewall logs, you need to add diagnostics settings to collect firewall logs.

Select the DemoFirewall and under Monitoring, select Diagnostic settings.
Select Add diagnostic setting.
For Diagnostic setting name, type fw-diag.
Under log, select AzureFirewallApplicationRule, and AzureFirewallNetworkRule.
Under Destination details, select Send to Log Analytics workspace.
Select Save.

IDPS tests

To test IDPS, you should deploy your own internal test Web server with an appropriate server certificate. This test includes sending malicious traffic to a Web server, so it isn't advisable to do this to a public Web server. For more information about Azure Firewall Premium certificate requirements, see Azure Firewall Premium certificates.

You can use curl to control various HTTP headers and simulate malicious traffic.

To test IDPS for HTTP traffic:

On the WorkerVM virtual machine, open an administrator command prompt window.
Type the following command at the command prompt:

curl -A "HaxerMen" <your web server address>
You'll see your Web server response.
Go to the Firewall Network rule logs on the Azure portal to find an alert similar to the following message:
```
{ “msg” : “TCP request from 10.0.100.5:16036 to 10.0.20.10:80. Action: Alert. Rule: 2032081. IDS: 
USER_AGENTS Suspicious User Agent (HaxerMen). Priority: 1. Classification: A Network Tojan was 
detected”}
```
Note

It can take some time for the data to begin showing in the logs. Give it at least a couple minutes to allow for the logs to begin showing the data.
Add a signature rule for signature 2032081:
1. Select the DemoFirewallPolicy and under Settings select IDPS.
2. Select the Signature rules tab.
3. Under Signature ID, in the open text box type 2032081.
4. Under Mode, select Deny.
5. Select Save.
6. Wait for the deployment to complete before proceeding.
On WorkerVM, run the curl command again:

curl -A "HaxerMen" <your web server address>

Since the HTTP request is now blocked by the firewall, you'll see the following output after the connection timeout expires:

read tcp 10.0.100.5:55734->10.0.20.10:80: read: connection reset by peer
Go to the Monitor logs in the Azure portal and find the message for the blocked request.

To test IDPS for HTTPS traffic

Repeat these curl tests using HTTPS instead of HTTP. For example:

curl --ssl-no-revoke -A "HaxerMen" <your web server address>

You should see the same results that you had with the HTTP tests.

TLS Inspection with URL filtering

Use the following steps to test TLS Inspection with URL filtering.

Edit the firewall policy application rules and add a new rule called AllowURL to the AllowWeb rule collection. Configure the target URL www.nytimes.com/section/world, Source IP address *, Destination type URL, select TLS Inspection, and protocols http, https.
When the deployment completes, open a browser on WorkerVM and go to https://www.nytimes.com/section/world and validate that the HTML response is displayed as expected in the browser.
In the Azure portal, you can view the entire URL in the Application rule Monitoring logs:

Some HTML pages may look incomplete because they refer to other URLs that are denied. To solve this issue, the following approach can be taken:

If the HTML page contains links to other domains, you can add these domains to a new application rule with allow access to these FQDNs.
If the HTML page contains links to sub URLs then you can modify the rule and add an asterisk to the URL. For example: targetURLs=www.nytimes.com/section/world*

Alternatively, you can add a new URL to the rule. For example:

www.nytimes.com/section/world, www.nytimes.com/section/world/*

Web categories testing

Let's create an application rule to allow access to sports web sites.

From the portal, open your resource group and select DemoFirewallPolicy.
Select Application Rules, and then Add a rule collection.
For Name, type GeneralWeb, Priority 103, Rule collection group select DefaultApplicationRuleCollectionGroup.
Under Rules for Name type AllowSports, Source *, Protocol http, https, select TLS Inspection, Destination Type select Web categories, Destination select Sports.
Select Add.
When the deployment completes, go to WorkerVM and open a web browser and browse to https://www.nfl.com.

You should see the NFL web page, and the Application rule log shows that a Web Category: Sports rule was matched and the request was allowed.

Share via