Introduction to Azure Network Security Groups (NSGs)

Microsoft Azure and other public clouds are changing the way which enterprises deploy and secure their distributed services, including network services with Azure Network Security Groups (NSGs). One of the main benefits of deploying in the public cloud is the ability to quickly allow users or applications to connect to your service from anywhere in the world, providing them with a scalable and high-availability virtual networking infrastructure. Since these networks are the entry points to your application, they should be the first line of defense from threats, only accepting traffic from users, applications, or protocols that have been explicitly approved. Securing these networks can be challenging because they may contain diverse virtual appliances and a dynamic network infrastructure while not giving admins access to any of the underlying physical networking infrastructure.

What Are Network Security Groups in Azure?

Microsoft’s solution, the Network Security Group (NSG), simplifies virtual network security by  allowing administrators to easily organize, filter, and route different types of network traffic. Any Azure virtual network can be placed into a security group where different inbound and outbound rules can be configured to allow or deny certain types of traffic. This blog will review some of the capabilities and best practices for Azure NSGs.

Creating a Network Security Group (NSG)

Microsoft Azure provides a simple interface to create the Azure Network Security Groups from both a modern (recommended) and “classic” view. From the Network Security Group interface, it is easy to add a new security group, where you will specify the name, subscription, Azure resource group, and location where it will be configured. The following screenshot shows the creation of an Azure NSG from the modern interface.

Figure 1 – Creating a new Azure Network Security Group (NSG)

Network Security Group Rules

After creating this Azure NSG, you will have the ability to manage its individual rules. A rule is used to define whether the network traffic is safe and should be permitted through the network, or denied.

A rule consists of the following components:

• Name – A unique name that should be easy for administrators to use to find the rule.
• Priority – This is an integer between 100 and 4096, which should be unique. This value defines the processing order of the rule, with rules containing lower values (higher priority) being executed first.
• Source or destination – This field indicates which application or user(s) the rule is applicable for. This can be an IP Address, IP Address range, or Azure resource.
• Protocol – The TCP, UDP, or ICMP protocol which will be analyzed.
• Direction – This indicates whether the traffic is inbound or outbound.
• Port Range – This will specify which port or range of ports the rule is applicable for.
• Action – Setting either Allow (the traffic through) or Deny (and block the traffic) will specify the action to be taken by the NSG when network traffic matching the rule is identified.

Whenever traffic is permitted, a record is created to keep track of the network traffic, and these records can be used by network traffic analytics tools for further threat inspection and analysis. A best practice for network security rules is to start by denying all traffic, and then creating rules only for traffic which is known to be safe. Microsoft Azure automatically creates a few default Azure NSGS rules in each Network Security Group, including:

The following screenshot shows a network security group for a database resource, and you can see that all inbound and outbound traffic is explicitly denied, with the exception of a few rules.

Figure 2 – A production Network Security Group with its rules configured

Service Tags & Application Security Groups

Once you begin using the Azure network security group, you will likely find that managing the IP Addresses at scale becomes challenging, requiring the creation and management of many rules. To simplify this, Microsoft Azure introduced a concept of a “service tag” which is a pre-defined collection of IP Addresses associated with a specific resource. Currently, there are service tags available for Azure virtual networks, load balancers, cloud, traffic manager, storage, SQL, Cosmos DB, key vault, event hub, service bus, container registry, app service, app service management, API management, connectors, gateway manager, data lake, Active Directory, monitor, service fabric and machine learning resources, plus many more. A current list from Microsoft is available here.

Microsoft Azure also allows the network security groups in Azure to be managed at the application-level, further simplifying management by abstracting the IP address(es) from an application. You can create Application Service Groups (ASGs), say one for your front end IaaS VMs called FrontEnd and another for your backend databases called BackEnd and you can now refer to these (instead of IP addresses) in your NSG rules. This also means as you add more front end VMs you just have to associate them with the FrontEnd ASG and they’ll automatically use the right rules. 

This means that an Azure application may be used in a rule as a source or destination. It is a best practice to use either service tags or application security groups to simplify management.

Other Network Security Group Tips

When planning your NSGs, you only have to worry about the IP Address which are assigned to your business, which means that you can ignore anything assigned to an Azure infrastructure service, such as DNS, DHCP, etc. Similarly, if you are using load-balancers, you only need to worry about the source and destination of the computer or service, not the IP Addresses used by the load balancer itself. You must also make sure that any VM within the security group has a valid license for its guest operating system. Finally, be careful about denying all outbound internet traffic for VMs which use extensions, as these extensions may become blocked, causing the VM to appear like they are frozen in an ‘updating’ state.

Azure Network Security Groups Best Practices

• Microsoft offers basic infrastructure services configured in virtual networks. You can override these basic infrastructure communications such as DCHP, DNS, and IMDS by creating a security rule to deny traffic using the service tags on your NSGs. 
• You must note the Key Management Services (KMS) and in order for VMs to be licensed, they must be able to communicate outbound to port 1688.
• With load-balanced pools, the source port and address range are applied from the originating computer, not the load balancer. The destination port and address range are for the destination computer and not the load balancer. These facts need to be considered when building Azure NSGs.
• Service instances get deployed at the virtual network level. IT admins need to familiarize themselves with the requirements of the Azure service instances and design Azure network security groups accordingly.
• Familiarize yourself with the requirements of SMTP relays if you desire to send outbound emails. Depending on when your Azure subscription was created, you may or may not be able to send an email directly over port 25. 
• Keep in mind the priority setting for Azure network security group rules. NSGs process the lowest-numbered priority rules first before the rest. 

Wrap-Up

In conclusion, you’ll like Azure network security groups for their ability to let you quickly and easily manage network security. While configuration may be tedious at first, by taking advantage of service tags and application security groups, you can streamline the process. Make sure that NSG planning and management is considered with your standard Azure operating procedures moving forward to help secure and protect your Microsoft cloud infrastructure.

What about you? Have you tried using NSGs in Azure yet? Do you have any questions or concerns? Let us know in the comments form below!

Thanks for reading our post covering Azure NSGs, what they are, and how to use them!