Azure firewall is a new managed, cloud-based network security service in Azure that offers stateful native firewall capabilities for Virtual Network resources. The main advantage is that it has built-in high availability and scalability being a managed service.
- July 12 2018 – Preview Announcement
- Stateful firewall as a Service
- Built-in high availability with unrestricted cloud scalability
- FQDN filtering
- Network traffic filtering rules
- Outbound SNAT support
- Centrally create, enforce, and log application and network connectivity policies across Azure subscriptions and VNETs
- Fully integrated with Azure Monitor for logging and analytics
- Azure Firewall public preview supports outbound filtering only. Inbound protection for non-HTTP/S protocols (ex: RDP, SSH, FTP) is tentatively planned for Azure Firewall GA.
- Soft limit of 1000 TB/firewall/month (can be extended by reaching out to MS Support)
- Limit of 10k application rules and 10k network rules
- Minimum allowed size for the “AzureFirewallSubnet” is a “/25“
- Using Azure firewall in a central VNET is subject to VNET peering limitations: max of 50 spoke VNETs
- Regional vnet peering limitation (peering traffic only allowed as long as they are in the same region as the Azure firewall). This means that at least one firewall deployment is needed per region.
- Lots!! See my thoughts below
- No inbound functionality or filtering (e.g. DNAT)
- No Live packet capture
- No quota configuration or management
- Single public IP address (for ephemeral ports that will be used for SNAT/PAT)
- Azure Firewall has a fixed cost + variable cost.
- Fixed fee: $1.25/firewall/hour (approx $900 per month)
- Variable fee: $0.03/GB processed by the firewall (ingress or egress)
- Watch the above video for more explanation of the operations of this resource and a demo of how to register for the preview and how to deploy
- First, you need to enable preview using the PowerShell script below. The process takes approximately 25 minutes:
# Register Register-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network Register-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network # Verify Get-AzureRmProviderFeature -FeatureName AllowRegionalGatewayManagerForSecureGateway -ProviderNamespace Microsoft.Network Get-AzureRmProviderFeature -FeatureName AllowAzureFirewall -ProviderNamespace Microsoft.Network # After the registration is complete, run the following command: Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Network
- Deployment options for now are: Azure Portal, Azure PowerShell, REST API, or ARM Templates
- Two rule types are supported:
- Application rules
- Allows the configuration of Fully Qualified Domain Names (FQDNs) that can be accessed from a subnet
- Network rules
- Allows the configuration of rules containing source address, protocol, destination port, and destination address
- Application rules
- There is a built-in rule collection for infrastructure FQDNs that are allowed by default. Anything not in the infrastructure rule collection is denied by default. These FQDNs are required for the Azure platform services to function properly. These include:
- Compute access to storage Platform Image Repository (PIR)
- Managed disks status storage access
- Windows Diagnostics
- We can override this build-in infrastructure rule collection by creating a deny all application rule collection which is processed last. It will always be process before the infrastructure rule collection.
- For outbound traffic, it uses a static public IP address for your virtual network resources allowing outside connections to identify traffic originating from your virtual network
- Service Endpoint Integration
- Service endpoint can be enabled for the Azure Firewall subnet
- Can be used with NSGs
- Can be integrated with Log Analytics for monitoring
From an HA perspective, this is a great move by Microsoft BUT looking at the security features that are in this preview and even the features planned for GA, this is not even close to being enterprise ready in light of the security threat landscape that any enterprise has to protect itself against. There are only two security features offered by the Azure firewall service – FQDN filtering and Network traffic filtering. That’s it! No deep packet inspection with IDS/IPS, no malware protection against legitimate sites, no certificate validation, no file type filtering by mime-type, extension and active content types, e.t.c.
Microsoft recognizes this and the announcement page states the following:
Azure Firewall is a basic firewall service that can address certain customer scenarios. We expect customers to have a mix of 3rd party NVAs and Azure Firewall and are working with our partners on multiple better together opportunities.
An example of a great NVA appliance to use is the Sophos XG firewall. Also, from a scalability perspective, more details around how to work around the current single public IP address is needed. If limited to a single IP, how is ephemeral port exhaustion handled? (especially if the architecture recommendation is to use a central firewall for multiple vNets)