Introduction to Azure Network Security Groups (NSGs)

 

Table of contents

1.  Creating a Network Security Group (NSG)

2.  Network Security Group Rules

3.  Service Tags & Application Security Groups

4.  Other Network Security Group Tips

5.  Wrap-Up

Microsoft Azure and other public clouds are changing the way which enterprises deploy and secure their distributed services. One of the main benefits of deploying in the public cloud is the ability to quickly allows users or applications to connect to your service from anywhere in the world, providing them with a scalable and highly-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 which 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.

Microsoft’s solution to simplify virtual network security is through a management layer known as a Network Security Group (NSG) which allows 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 Network Security Group 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 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 which 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 rules in each Network Security Group, including:

Inbound	Priority	Source	Source ports	Destination	Destination ports	Protocol	Access
AllowVNetInBound	65000	VirtualNetwork	0-65535	VirtualNetwork	0-65535	All	Allow
AllowAzureLoad BalancerInBound	65001	AzureLoad Balancer	0-65535	0.0.0.0/0	0-65535	All	Allow
DenyAllInbound	65500	0.0.0.0/0	0-65535	0.0.0.0/0	0-65535	All	Deny
Outbound	Priority	Source	Source ports	Destination	Destination ports	Protocol	Access
AllowVnetOutBound	65000	VirtualNetwork	0-65535	VirtualNetwork	0-65535	All	Allow
AllowInternet OutBound	65001	0.0.0.0/0	0-65535	Internet	0-65535	All	Allow
DenyAllOutBound	65500	0.0.0.0/0	0-65535	0.0.0.0/0	0-65535	All	Deny

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 NSGs, 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. A current list from Microsoft is available here.

Microsoft Azure also allows the security groups to be managed at the application-level, further simplifying management by abstracting the IP address(es) from an application. 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 the load balancer itself. You must also make sure that the 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.

Wrap-Up

In conclusion, you should love 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!