So been working a lot with Azure Firewall lately and wanted to adress some of the current limitations that is has. Azure Firewall is a layer 4 stateful firewall offering in Azure as a complete PaaS service. Using a native PaaS service for firewall management (outside of NSG rules) in Azure has some advantages.
- Automatic Scaling of the service based upon troughput – Azure firewall is essentially setting up mulitple instances behind an standard load balancer and wrapping this as a service.
- Easy Management – Since it is a service it is easy manageable and easy to automize using either ARM/Terraform or other API solutions.
- Azure AD based management – Since this is a native Azure service you can manage it using Azure AD based access.
Now since Azure Firewall is part of your virtual network it can easily be used as the main hub for all inboud and outbound traffic within Azure. Firewall supports the following services.
- Application rules which allows you do restrict access to FQDN without requirering SSL termination. This can be used to deny access to Google.com or Microsoft.com for instance
- Network rules which are simple 5-tuple firewall rules to deny/allow access based upon IP/Port/Protocol.
- DNAT rules which can be used to define port mapping to a particular endpoint within your virtual endpoint.
- Threat Inteligence – which allows Microsoft to inspect inbound or outbound traffic against known malicious IP addresses and domains. The IP addresses and domains are sourced from the Microsoft Threat Intelligence feed
- Something that was also an known limitation was that you could not use it with multiple public IP addresses but this limitation has now been lifted –> https://docs.microsoft.com/en-us/azure/firewall/deploy-multi-public-ip-powershell
So in which scenarios should you be using Azure Firewall and when should you be using a 3.party solution running as an NVA? Microsoft themselves state the following
Azure Firewall is a basic firewall service that can address certain customer scenarios. It’s expected that you’ll have a mix of third-party NVAs and Azure Firewall. Working better together is a core priority.
So what are the current limitations that you should be aware of?
1: IPS Support: Many companies might have security requirements that require you to either have an IDS or IPS solution which is not something that Azure Firewall can provide. The threat inteligence integration provides some capabilitiies but that is only looking at the IP or Domain and not looking into the payload ot the data itself.
2: Application rules using Azure Public DNS: When there is a session going outbound from the Azure Firewall to Google.com, the Azure Firewall will use Azure Public DNS servers to lookup that domian and see if it maps a rule in the applications rules. However this means that if you want to allow/deny access to internal domain or FQDN you cannot configure Azure Firewall to use internal DNS servers yet.
3: Requires Public Internet Access: Azure Firewall requires public internet access to have connectivity to management layer. So Azure Firewall doesn’t currently support forced tunneling. If your configuration requires forced tunneling to an on-premises network and you can determine the target IP prefixes for your Internet destinations, you can configure these ranges with the on-premises network as the next hop via a user defined route on the AzureFirewallSubnet. Or, you can use BGP to define these routes.
4:Protocol support: Since Azure Firewall is running behind a Azure Load Balancer it only supports UDP/TCP protocols. This can be for instance support for protocols such as ESP.
5: Lacking support for other Microsoft Services. A big issue I see is that many are using Cloud App Security and integration with Firewall vendors to provide insight into which URL’s people are access to do SaaS app discovery, this is not support for Azure Firewall and the same applies for instance to Azure Sentinel and the URL detonation mechanism which Azure firewall does not support.
6: Lack of geoblocking. A Simple way to handle outbound or inbound traffic filtering is to block different geos from the firewall, this is something that Azure Web application firewall supports, but is not a feature that is available on azure firewall.
7: Outbound SNAT and Public IP Addresses. As it is now Azure firewall does not support forced tunneling against public IP addresses, a lot of organizations within education sector are using public ip addresses on their local network and with that Azure Firewall cannot handle since it will not route traffic but do SNAT connections to those enviroments instead.
8: Filtering against specific content: This is also something that many firewall vendors have is the ability to handle access to certain content, which is no something that Azure Firewall has.
9: Missing advanced routing mechanisms: As it is now there is no current way to view the log table for an Azure firewall instance. For many network administrators which are usually used to having ways to view rounting tables or have more advanced VRF’s to do routing between different networks and also tracers to be able to see traffic in real-time to see iwhere traffic is going. Azure Firewall uses Azure Monitor for logging and with the delay of ingesting data it will take some time before you are able to analyse why the traffic was allowed or denied.
10: Missing management capabilities. Most Firewall vendors provide a common management plane across their appliances. Azure Firewall is currently a solution which you manage individually, NOTE: Azure Firewall Manager is in preview which will allow you to do centralized management of your Azure Firewall instances.
As you can see from the above, it is important to remember that Azure Firewall is a simple firewall service which is service which you can utilize where you want a centralized way to handle firewall rules. Network Security Groups can also be used to augment the rules but NSG does not provide FQDN based rules or Threat Integillience. However it is still a leap from Azure Firewall to 3.party NVA’s. Again an issue which might occur there is how the NVA’s are supported running on Microsoft Azure, most large vendors such as Checkpoint and Palo Alto have a pretty decent integration with Azure and high-availability features and should be considered where you need more functionality that the native services can provide.