Azure Firewall vs Network Security Group (NSG)

                              

An important security measure when running workloads in Azure or any Cloud service is to control the type of traffic that flows in and out of resources.  The resources can be virtual machines running a SQL database, web applications or domain services.

In Azure, there are two security features that can be used to manage both inbound and outbound traffic to resources:  Azure Firewall and Network Security Groups (NSGs).  In this article, I’m going to show how the two compare to each other and can be used together to protect traffic to resources in Azure.

Azure Firewall and NSG Overview
Lets start with Network Security Groups.  An NSG filters traffic at the network layer and consists of security rules that allows or denies traffic based on 5-tuple information:
1. Protocol – such as TCP, UDP, ICMP
2. Source – IP address,
3. Source port
4. Destination
5. Destination port

You can associate an NSG with a subnet or the network interface of an Azure VM.  Fun fact – in your mother’s Azure (the old classic model), it was possible to link an NSG to a VM as well as subnet.  In accordance with Best practices, it’s recommended to scope NSGs at the subnet level or network interface, not both. This can make it complicated when having to troubleshoot network issues.  Also, the same NSG can be applied to multiple subnets.

You can probably imagine how NSG rules can become difficult to manage in large environments that contain multiple subnets and virtual machines. Who wants to manually input rules allowing traffic to individual IP addresses?  This is where Application Security Groups (ASGs) come to the rescue.  An ASG is a logical grouping of virtual machines that allows you to apply security rules at scale.  For example, if you have a group of VM’s serving a web application, the VM’s can be placed in an ASG called “webappvms”.  The webappvms group can then be added to a rule within an NSG allowing HTTP (TCP) traffic over port 80.  This alleviates the need to add individual IP addresses to the security rule.

Azure Firewall is a highly available, managed firewall service that filters network and application level traffic.  It has the ability to process traffic across subscriptions and VNets that are deployed in a hub-spoke model.  Azure Firewall is priced in two ways: 1) $1.25/hour of deployment, regardless of scale and 2) $0.016/GB of data processed.

Azure Firewall and NSG Comparison
An NSG is a firewall, albeit a very basic one.  It’s a software defined solution that filters traffic at the Network layer.  However, Azure Firewall is more robust.  It’s a managed firewall service that can filter and analyze L3-L4 traffic, as well as L7 application traffic.  Azure Firewall provides the same capabilities as an NSG, plus more. The following chart offers a comparative illustration of each solution:

Here are some definitions if you’re not familiar with all of the features listed in the above chart:

• Service Tags – these are labels that represent a range of IP addresses for particular services such as Azure Key Vault, Data Lake, Container Registry, etc.  These are managed by Microsoft and cannot be customized.  You can learn more about them here. As an example, here’s a Service tag I have configured for Event Hub in an outbound NSG rule.  This same rule can also be created in Azure Firewall.
  
• FQDN Tags – represent a group of fully qualified domain names of Microsoft services such as Windows Update or Azure Backup.  Like Service tags, they are maintained by Microsoft and cannot be customized.  There are a significantly fewer number of  FQDN tags than Service tags.  Go here to see the list of FQDN tags. Here’s an example of FQDN tag I have for Windows Update in my Azure Firewall application rule.  This allows you to avoid creating multiple application rules for each of the numerous Windows Update endpoints.  One tag to rule them all!
  
• SNAT – Source Network Address Translation is a feature of Azure Firewall. It’s possible to configure Azure Firewall with a Public IP address (PIP) that can be used to masked the IP address of Azure Resources that are sending out via the Firewall.
• DNAT – Source Destination Address Translation is used to translate incoming traffic to the firewall’s Public IP to the Private IP addresses of the VNet.

Azure Firewall and NSG in Conjuction
NSGs and Azure Firewall work very well together and are not mutually exclusive or redundant.  You typically want to use NSGs when you are protecting network traffic in or out of a subnet.  An example would be a subnet that contains VMs that require RDP access (TCP over 3389) from a Jumpbox. Azure Firewall is the solution for filtering traffic to a VNet from the outside.  For this reason, it should be deployed in it’s own VNet and isolated from other resources.  Azure Firewall is a highly available solution that automatically scales based on its workload.  Therefore, it should be in a /26 size subnet to ensure there’s space for additional VMs that are created when it’s scaled out.

A scenario to use both would be a Hub-spoke VNet environment with incoming traffic from the outside.  Consider the following diagram:

The above model has Azure Firewall in the Hub VNet which has peered connections to two Spoke VNets.  The Spoke Vnets are not directly connected, but their subnets contain a User Defined Route (UDR) that points to the Azure Firewall, which serves as a gateway device.  Also, Azure Firewall is public facing and is responsible for protecting inbound and outbound traffic to the VNet.  This is where features like Application rules, SNAT and DNaT come in handy.  If you have a simple environment, then NSGs should be sufficient for network protection.

*Updates*
– Threat intelligence-based filtering with Azure Firewall is no longer in Pubic Preview
– Azure Firewall is fully integrated with Azure Monitor for logging and analytics

The following links are to Microsoft docs that provide detailed information about Azure Firewall and Network Security Groups and were used as source material for this article:
https://docs.microsoft.com/en-us/azure/virtual-network/security-overview
https://docs.microsoft.com/en-us/azure/firewall/overview
https://docs.microsoft.com/en-us/azure/firewall/integrate-lb