In this post, I will explain what the new Azure Firewall, recently launched in preview, can do and what it cannot at this time.
Firewall Options in Azure
There is no shortage of firewall options in Azure for network security at the transport (Layer-4) and application (Layer-7) layers of the network stack.
The foundational component is the free networks security group (NSG), providing allow/deny filtering for TCP/UDP traffic. NSG policies are deployed no matter what virtual network architecture you design, offering a low-level hard filter. In addition to NSGs, we have:
- Azure Web Application Firewall (WAF): An extra add-on for the web application gateway (WAG) to protect HTTP/S traffic at Layer-7.
- Network Virtualization Appliances (NVAs): Third-party appliances, deployed as Linux virtual machines with firewall software, can provide Layer-4 and Layer-7 security at the edge of a virtual network, and between machines with micro-segmentation architectures based on routing tables.
Azure doesn’t supply an alternative to the third-party NVA, but that is starting to change with a new preview release – which isn’t ready for production yet.
The Azure Firewall is a new preview network security feature in Azure, sitting at the edge of the virtual network to provide additional security beyond what is offered by NSGs.
The features today are:
- High availability (HA): You do not need to deploy multiple instances for high availability as you do with NVAs. The appliance has built-in HA.
- Cloud scalability: Another reason for scaling out the number of NVAs and load balancing them is to increase the scale of throughput. The Azure Firewall will scale to handle your throughput and bandwidth requirements.
- FQDN filtering: You define a whitelist of fully qualified domain names (you can use wildcards) of external URLs that can be reached from your network. This approach will limit data leakage and prevent remote control by malware. This is the set of “where to rules”.
- Network filtering rules: Rules based on source, destination, protocol, and port will limit what kinds of traffic can leave your virtual network. This is the set of “what rules”.
- Outbound SNAT support: The Azure firewall is deployed with a standard-tier public IP address. All traffic leaving the virtual network is identified to the Internet using this address.
- Azure Monitor: All events can be traced in the Azure Monitor, and archived to a storage account, event hub (external systems), or Log Analytics (OMS).
What Azure Firewall Cannot Do
What I first heard of Azure Firewall I thought it would replace NVAs. As it turns out, based on what the Azure Firewall is today in its preview release, it won’t. But the current preview release is a very early one, and I think Microsoft is slowly developing Azure Firewall to get it right, instead of rashly rolling out a bunch of unready features. So, I kind of understand what they are doing.
Today the Azure Firewall is not a solution for protecting a network against inbound threats. You cannot set up NAT rules for inbound traffic. It does not have rules or filters for publishing internal applications either. Today, Azure Firewall only cares about outbound traffic.
There are also a number of known issues with:
- Network security groups on the Azure Firewall’s subnet
- Just-in-time VM access in Azure Security Center
- Hub and spoke architectures using VNet peering are not supported
- Non-TCP/UDP protocols are not supported with SNAT via the Azure Firewall’s public IP address
Azure Firewall is an early preview and is not ready for production. But if the future of Azure Firewall interests you, you should enroll in the preview, deploy it in a test environment, and share your feedback with Microsoft.