Managing Azure Network Traffic with Network Security Groups

Azure Network Security Groups (NSG) are a core tool that enables you to control the network traffic flow within an Azure Virtual Network. A Network Security Group is a collection of stateful layer 3/4 allow/deny rules, that can be associated with either subnets or individual network interfaces. In this post I hope to cover the basics of how NSGs can be used to manage the traffic within an Azure environment and provide segmentation as part of a zero trust solution.

An NSG rule compromises of 10 parameters:

1. Source – this is where the network traffic originated from
2. Source Port – This is the port the traffic comes from. Normally this is set to any.
3. Destination – this is where the network traffic going to.
4. Destination Port – this is the port the traffic is going to-and is normally the only port you are concerned about.
5. Protocol – this is the network protocol used, and can be either TCP, UDP or ICMP.
6. Direction
7. Action – this is simply either Allow or Deny
8. Priority
9. Name
10. Description

Traffic is matched to a rule using the first 5 of these parameters.

Source and Destination can be one of a few types

• Any
• IP Address – either a single address, a CIDR range or a comma separated list
• Application Security Group (ASG)
• Service Tag

Rule assessment

NSG rules are assessed in priority order from the lowest priority to the highest priority. If there are NSGs associated with both the subnet and the NIC of a virtual machine then the NSGs are evaluated in the following order:

• inbound traffic – subnet based rules then NIC based rules
• outbound traffic – NIC rules then subnet based rules.

The following chart shows the actual evaluation process.

Inbound Traffic

Outbound traffic

Service Tags

“A service tag represents a group of IP address prefixes from a given Azure service. Microsoft manages the address prefixes encompassed by the service tag and automatically updates the service tag as addresses change, minimizing the complexity of frequent updates to network security rules.”

Service tags provide a way to include core Microsoft services and common IP address ranges in the NSG rules. There are a couple of common and important tags to be aware of.

Virtual Network

This service tag includes the virtual network address space (all IP address ranges defined for the virtual network), all connected on-premises address spaces, peered virtual networks, virtual networks connected to a virtual network gateway, the virtual IP address of the host, and address prefixes used on user-defined routes. It is important to note that this tag might also contain default routes if they are added via a custom Route Table.

Internet

By using this service tag you are including the IP address space that’s outside the virtual network and reachable by the public internet. (i.e. excluding 10.0.0.0/8, 100.64.0.0/10 172.16.0.0/12 and 192.168.0.0/16)

Further details about Service Tags con be found in the Microsoft documentation (https://docs.microsoft.com/en-us/azure/virtual-network/service-tags-overview)

Application Security Groups (ASG)

“Application security groups enable you to configure network security as a natural extension of an application’s structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses. ”

ASGs are a great way to group associated network interfaces together to help reduce the complexity of managing NSG rules, however they have a number of limitations which make them not so great.

• They can only have Network interfaces associated. You cannot use these to manage lists of IP addresses.
• All the network interface within a single ASG must be in the same vNet.

Further details on Application Service Groups can be found in the Microsoft documentation (https://docs.microsoft.com/en-us/azure/virtual-network/application-security-groups).

Default Rules

When an NSG is first created there are some default rules, which cannot be removed. These rules are, in my opinion, not very helpful especially if you are trying to implement a zero trust approach.

In addition to these default rules it is also important to be are of what are ‘hidden’ implicit rules which are needed for the Azure infrastructure to function, DNS traffic to the DNS servers listed in the Virtual Network (VNet) configuration is always permitted as is DHCP traffic to the Azure DHCP service. This is fairly obvious if you think about it as without either of these services. connectivity to any resource within the subnet would be broken.

In order to achieve a zero trust, segmented network you will need to include a default deny all rule at the highest available priority, this will essentially remove the default rules and start you with a deny by default approach (with the exception of DNS & DCHP as discussed above).

Inbound rule

Outbound rule