Azure Network Security Group Defaults

I’ve had several conversations over the years with people using Azure Network Security Groups (NSG) who are intending to lock down network traffic to and from their resources but are accidentally failing to do so. Admins are happily adding rules to the NSG, but the unwanted traffic is still getting through because there are default rules that cannot be removed.

Here is an example environment. We have two peered Virtual Networks (VNETs), VNET one has two subnets and VNET two has a further one. Each subnet contains a Virtual Machine (VM), and there is an NSG associated with the first subnet.

In this post I will use this environment to demonstrate how the default rules leave your network open, and how to counter this to create secure microsegmented services. We want an environment where only the network traffic we choose is allowed and everything else is blocked.

Default Rules

The NSG is associated with Subnet-01-A, and therefore governing the traffic in and out of VM-1A in this environment. With nothing but the default rules in place traffic can flow to and from VM-1A to both the other VMs.

Normally with firewalls you’d expect the default to be “Deny All”, and there is a built-in “Deny All” rule in the NSG, but it is superseded by the AllowVNETInbound and AllowVNETOutbound security rules. These rules allow traffic flow to and from other resources in the VNET and any peered VNETs.

Deny All

To rectify this, the first step is to add in a second “Deny All” rule, but above the three default rules. Remember there are both Incoming and Outgoing lists on the NSG.

Now VM-1A - or anything else in the subnet associated with the NSG - can’t communicate with either of the other two VMs in either direction. Resources in the same subnet as VM-1A can also no longer communicate with it.

Allow selected

Now all traffic is blocked I can add specific rules for our services. In this example VM-2A should be able to talk to VM-1A and VM-1A should be able to talk to VM-1B, but not in the other directions. This could represent a 3-tier application where the Web tier needs to talk to the Application tier and that needs to talk to the Data tier.

The NSG security rules for this configuration would look like this, with the priority numbers placing them above the custom “Deny All” rule.

Remember that VM-1B and VM-2A are not themselves restricted by the NSG in this example (except when communicating with resources in the associated Subnet 01-A) and would need to be associated with an NSG with appropriate rules themselves.

To summarise, Azure Network Security Groups are a powerful tool for micro-segmentation of your virtual networks and securing your cloud resources. However, as with all firewalls, it’s important to understand the effect of the assigned rules and use them carefully to only allow approved network traffic.