In this blog, I am going to be summarising how you can secure your Virtual network (vNET) with a combination of Azure Firewall and Network Security Group (NSG)
Considerations for this will be that the environment will be a hub-spoke setup, link to test environment of this deployment is found at the bottom of this blog post
As part of this deployment, which else will need to be considered?
- Azure Routing
- Azure Application Security Groups (ASGs) and how they are deployed along with a NSG
Lets look at these additional considerations
Azure Routing
Whenever you create a vNET with multiple subnets; each subnet will automatically be assigned default system routes. Additional system routes cannot be added nor current ones edited but with the creation of a User Defined Routetable (UDR) – will override any default system route with your created UDR.
The default system routes:-
Source | Address Prefix | Next hop |
---|---|---|
Default | Unique to the virtual network | Virtual network |
Default | 0.0.0.0/0 | Internet |
Default | 10.0.0.0/8 | None |
Default | 172.16.0.0/12 | None |
Default | 192.168.0.0/16 | None |
Default | 100.64.0.0/10 | None |
Next hop…
The next hop represents how Azure routes specific traffic to the destination address, hops above explained:-
- Virtual Network: Traffic destined to an address range within the vNET will be routed within the virtual network.
- Internet: When destination traffic is Internet-bound, the traffic flow will use the default route of 0.0.0.0/0 providing no User Defined Routes are in place or this will be overwritten if a UDR matches.
- None: Traffic being routed to none, Azure will drop the traffic. As shown above, Azure creates these routes for private IP addresses found in RFC 1918 & RFC 6598
Additional reading
Azure Application Security Groups (ASGs) and how they are deployed along with a NSG
ASGs are used within a NSG to apply a network security rule to a specific workload or group of VMs – defined by ASG worked as being the “network object” & expilicit IP addresses are added to this object.
This provides the capability to group VMs into associated groups or workloads, simplifying the NSG rule definition process.
Another great use of this is for scalability, creating the virtual machine and assigning the newly created virtual machine to its ASG will provide it with all the NSG rules in place for that specific ASG – zero distribution to your service!
Additional reading
Why deploy both Azure Firewall & NSG?
Azure NSGs complement the Azure Firewall Service. Azure Firewall is a fully stateful, network firewall-as-a-service application that provides network and application level protection from usually a centralised network (Hub-Spoke)
Whereas NSGs are used to provide the required network traffic filtering to limit traffic within a Virtual Network, including on a subnet level. Assigning the NSG to each Virtual Machine rather than Subnet will allow you to restrict network access on a per VM basis
Together they become “one” to provide a “defense in depth” security strategy, in this strategy – you would have the Azure Firewall configured at the perimeter of your network to control inbound/outbound traffic where NSG would been configured to control inbound/outbound traffic within your Virtual Network on a Virtual Machine-level basis
What should I use Azure Firewall for?
Azure Firewall as mentioned should be used as the perimeter protection, any traffic that may need to enter or leave a vNET, whether than be to another vNET via Peering or to the internet, its next hop should be the Azure Firewall.
Apart from firewall rules, what else can the Azure Firewall do?
- Stateful firewall as a service
- Highly availability and cloud scale:- Scales when required, no user interaction needed!
- Policies:- Multiple policies can be created for filtering traffic including outbound HTTP(s) and additional network filtering controls
- FQDN filtering
- Intelligent near real-time security:- Microsoft built-in threat intelligence-based filtering
- DNAT/SNAT configuration
- Centralised logging and analytics:- Fully integrated, built in monitoring
What should I use Network Security Groups for?
As Azure Firewall will be monitoring the perimeter of your network, consider using NSGs for the inter-VM traffic inside your Virtual Network.
You may want to have one NSG per Virtual Network or depending on the requirements and controls you have in place – one NSG per environment can be suffice as well ( rule maximum restriction(s))
Consider applying the NSG to the Virtual Machine NIC rather than the subnet, this will allow you to restriction inter-VM traffic on a per Virtual Machine level rather than per subnet.
Also use Application Security Groups where possible as well, I have blogged about this previously here
Service endpoint restrictions have also been implemented into NSG deployments – read further here
There is also diagnostic logging that can be enabled to view NSG flow logs and additional network information that can assist in troubleshooting connectivity
How can I see both deployed?
I’ve created a test hub-spoke environment that includes both Azure Firewall and NSG/ASG Integration using PowerShell found here
The test environment will give you an indication into how to configure Azure Firewall / NSG in a hub-spoke environment.
Got additional queries – give me a shout on Twitter or contact me via this blog
Hi Thomas, if you have a large number of VMs associated to one vNET, is it more efficient to assign one NSG at the subnet level to support all your VMs, rather than creating individual NSGs at the VM NIC level. Or does it depend on the current Azure environment you have setup? Thanks
Hi Anthony, it would depend on a few things:-
Considerations for per VM assignment
– it would be one NSG that can be assigned to all VMs
– utilising ASGs will mitigate the amount of rules needed
– per VM allows the NSG rulelist to work on a per VM basis, allowing connectivity to be blocked between VMS in same subnet, if you assign on a subnet level you don’t have this
For subnet level assignment:-
– probably less rules as it will be subnet to subnet connectivity
– you cannot restrict per VM on same subnet (VM level firewall software would apply here)
– not as restrictive as per VM
yeah that’s the way to go one single NSG