Skip to main content
Azure
  • 8 min read

Azure Firewall Premium now in preview

Announcing the preview release of Azure Firewall Premium. Azure Firewall Premium provides next-generation firewall capabilities that are required for highly sensitive and regulated environments.

This post was co-authored by Gopikrishna Kannan, Principal Program Manager, Azure Networking, and Suren Jamiyanaa, Program Manager, Azure Networking.

Announcing the preview release of Azure Firewall Premium.

Azure Firewall Premium provides next-generation firewall capabilities that are required for highly sensitive and regulated environments.

With this Azure Firewall Premium release, you can now use the following new capabilities:

TLS Inspection: Azure Firewall Premium terminates outbound and east-west TLS connections. Inbound TLS inspection is supported in conjunction with Azure Application Gateway allowing end-to-end encryption. Azure Firewall performs the required value-added security functions and re-encrypts the traffic which is sent to the original destination.

IDPS: Azure Firewall Premium provides signature-based intrusion detection and prevention system (IDPS) to allow rapid detection of attacks by looking for specific patterns, such as byte sequences in network traffic, or known malicious instruction sequences used by malware.

Web Categories: Allows administrators to filter outbound user access to the internet based on categories. For example, social networking, search engines, gambling, and so on, reducing the time spent on managing individual FQDNs and URLs. This capability is also available for Azure Firewall Standard based on FQDNs only.

URL Filtering: Allows administrators to filter outbound access to specific URLs, not just FQDNs. This capability works for both plain text and encrypted traffic if TLS inspection is enabled.

Azure Firewall Premium uses Firewall Policy, a global resource that can be used to centrally manage your firewalls using Azure Firewall Manager. Starting with this release, all new features can be configured with Firewall Policy only. This includes TLS Inspection, IDPS, URL Filtering, Web categories, and more. Firewall Rules (Classic) continues to be supported and can be used for configuring existing features of Standard Firewall. Firewall Policy can be managed independently or using Azure Firewall Manager. A firewall policy associated with a single firewall has no charge.

Creating a new premium firewall

To enjoy these new premium capabilities, a new premium firewall must be created. This can be done from the Azure portal as shown in Figure 1 below:

Figure 1 – Create a new premium firewall.

You can decide whether to create a new policy for this firewall or use an existing firewall policy and attach it to the firewall. Premium Firewall is fully compatible with both Standard and Premium policies. However, you must use a Premium policy if you want to use the new premium capabilities such as TLS Inspection, IDPS, and so on.

TLS Inspection

Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), is the standard security technology to establish an encrypted link between a client and a server. This link ensures that all data passed between the client and server remain private and encrypted.

Azure Firewall Premium intercepts and inspects TLS connections via full decryption of network communication, it performs the required value-added security functions and re-encrypts the traffic which is sent to the original destination.

There are several advantages of performing TLS Inspection with Azure Firewall Premium:

1. Enhanced visibility: logs and metrics are available for all decrypted traffic.

2. URL Filtering: A URL, as opposed to an FQDN, is not accessible to the Firewall when traffic is encrypted. URLs provide stricter outbound traffic filtering for domains that are common for different customers (for example, OneDrive.live.com).

3. IDPS: while some detections can be done for encrypted traffic, TLS inspection is important to utilize the best of IDPS.

Azure Firewall Premium TLS inspection capability is an ideal solution for the following use cases:

1. Outbound TLS termination.

2. Spoke to Spoke TLS termination (East-West).

3. Inbound TLS termination is available on Application Gateway. Firewall can be deployed behind Application Gateway and inspect decrypted traffic. When Application Gateway is configured with end-to-end encryption, Firewall can decrypt traffic received from Application Gateway for further inspection and re-encrypt before forwarding to the target web server. Learn more information about the various Inbound TLS termination use cases.

These use cases allow customers to embrace a zero trust model and complete network segmentation in their deployments via end-to-end encryption.

To enable TLS inspection in your Premium Firewall, select the Enable radio button, select your CA certificate in Azure Key Vault, and configure the Azure Firewall Policy as shown in Figure 2 below:

Figure 2 – Enable TLS inspection.

 

Azure Key Vault is a platform-managed secret store that you can use to safeguard secrets, keys, and TLS/SSL certificates. Azure Firewall Premium supports integration with Key Vault for server certificates that are attached to a Firewall Policy.

You can either create or reuse an existing user-assigned managed identity, which Azure Firewall uses to retrieve certificates from Key Vault on your behalf. For more information, see What is managed identities for Azure resources?

In a typical deployment, three types of certificates can be used:

  1. Root CA Certificate (Root Certificate). A self-signed certificate authority that can issue multiple intermediate CA certificates which in turn can issue multiple certificates in the form of a tree structure. A root certificate is the top-most certificate of the tree.
  2. Intermediate CA Certificate (CA Certificate). When a server presents a certificate to a client, for example, your web browser, during the SSL/TLS handshake, the client attempts to verify the signature against a list of ‘known good’ signers. Web browsers normally come with lists of CAs that they implicitly trust to identify hosts. If the authority is not in the list, as with some sites that sign their own certificates, the browser alerts the user that the certificate is not signed by a recognized authority and asks the user if they wish to continue communications with the unverified site.
  3. Server Certificate (Website certificate). A certificate associated with a specific domain name. If a website has a valid certificate, it means that a certificate authority has taken steps to verify that the web address belongs to that organization. When you type a URL or follow a link to a secure website, your browser checks the certificate for the following characteristics:
  • The website address matches the address on the certificate.
  • The certificate is signed by a certificate authority that the browser recognizes as a “trusted” authority.

As shown in Figure 3, Azure Firewall Premium can intercept outbound HTTP/S traffic and auto-generate a server certificate for www.website.com. This certificate is generated using the Intermediate CA certificate provided by the customer. End-user browser and client applications must trust your organization's Root CA certificate or intermediate CA certificate for this procedure to work.

Figure 3 – Enable TLS inspection.

 

Once TLS Inspection configuration is done, you can define new application rules where TLS inspection will take place, as seen in Figure 4 below.

Figure 4 – Enabling TLS inspection in application rules.

 

IDPS

A network intrusion detection and prevention system (IDPS) allow you to monitor network activities for malicious activity, log information about this activity, report it, and optionally attempt to block it.

Azure Firewall Premium provides signature-based IDPS to allow rapid detection of attacks by looking for specific patterns, such as byte sequences in network traffic, or known malicious instruction sequences used by malware. This capability works for all ports and protocols. When dealing with outbound HTTPS traffic, it is best utilized with TLS termination enabled. For inbound HTTPS traffic, consider using it in conjunction with Azure WAF.

To setup IDPS in your Premium Firewall, turn it on by selecting the required mode as shown in Figure 5 below. You can further customize the IDPS mode per signature ID to disable noisy signatures or move them to alert only. You can also configure a bypass list to skip detection for specific network segments if required by your organization.

Figure 5 – Configure IDPS mode.

 

Web Categories

Web Categories in Azure Firewall Policy allow administrators to allow or deny user access to the internet based on categories. For example, social networking, search engines, gambling, and so on, reducing the time spent on managing individual FQDNs and URLs.

You can use Web Categories as an application rule destination type in both the Azure Firewall Standard and Azure Firewall Premium SKUs. The primary difference is that Premium SKU is more fine-tuned to categorize traffic based on the full URL via TLS inspection whereas the Standard SKU categorizes traffic based on the FQDN. Administrators can use Web Categories for logging and visibility into an organization’s Internet traffic usage. This feature is also useful for work from home scenarios and client-based internet browsing such as Windows Virtual Desktop, or Remote Desktop Protocol (RDP).

Figure 6 below shows Azure Firewall policy application rules utilizing Web Categories as a destination type.

Figure 6 – Allow outbound access based on web categories.

 

URL Filtering

With URL filtering administrators can filter outbound access to specific URLs, not just FQDNs. This capability works for both plain text and encrypted traffic if TLS termination is enabled.

This functionality can also be used in conjunction with Web Categories to “extend” a given category by adding more URLs explicitly when needed or to allow/deny access to URLs within your organization's intranet.

When a URL is used as a destination type, you can use the asterisk as a wildcard on the left and right side of the URL, but not in the middle, as shown in the following examples:

1. URL=*.contoso.com will match both www.contoso.com and any.contoso.com

2. URL=www.contoso.com/test/* will match www.contoso.com/test/anything

Figure 7 – Configure URL filtering in application rules.

 

Firewall Policy Updates

This release introduces a new firewall policy tier for Firewall Premium configuration as well as an integrated experience in the Azure Firewall resource page.

Firewall policy comes in two tiers: Standard and Premium. By default, all policies created prior to this release are Standard. Standard tier policies can be associated with Azure Firewall Standard and can be inherited by Premium tier policies. Inheritance facilitates sharing configurations between both Azure Firewall Standard and Azure Firewall Premium deployments.

You can now create and associate a Firewall Policy at the time you create Azure Firewall in the portal. Firewall Classic rules continue to be supported and can be used for configuring features released prior to this release. However, it's recommended that you migrate to Firewall Policy to take advantage of the new preview capabilities. Azure Firewalls configured by classic rules can be easily migrated to Firewall Policy with the Migrate to Firewall Policy option from the Azure Firewall resource page. Migrating to Firewall Policy does not incur any downtime but it is recommended that you migrate during maintenance hours. Firewall Policy Standard tier is Generally Available and provides a full SLA. When associated with a single deployment, Firewall Policy is free of charge.

In addition to supporting premium configuration, there are several benefits provided by Firewall Policy including centralized management with Firewall Manager, reuse configuration through inheritance, and associating policy to more than one Azure firewall, custom RBAC for CI/CD pipeline integration, and many more. For more information, see the firewall policy documentation page.

Figure 8 – Migrate classic rules to Firewall Policy.

 

Next steps

For more information on everything we covered in this blog post, see the following: