Understanding NSGs & Recommendations

Network security groups (NSGs) provide a way to filter and control network traffic as it transits across an Azure Virtual Network. Access control Lists (ACLs) within the NSG evaluate network traffic based on priority, source, destination, port, and protocol.

When deployed, the default settings of a standard Azure NSG created with a virtual machine can be inherently insecure. Azure customers are responsible for the security and protection of any applications or data they store in the cloud. Azure’s Shared Responsibility Model outlines this clearly, including the need for strategy, planning, and management.

Azure’s shared responsibility model: division of responsibilities (source)

Executive summary

The following table outlines this article's key concepts and recommendations to help you understand NSGs.

Topic	Description
Access control lists	Rules that allow or deny access based on priority, direction, source and destination, and port and protocol.
Default rulesets	Default rules that cannot be changed but can be overridden.
Priority	Using higher priority rules, you can override the default rules, spacing priority numbers you assign to allow future flexibility.
Naming strategy	Assigning a name that defines the NSG’s purpose is essential for longer-term management.
Service tags	A group of IP address prefixes managed by Microsoft to allow or deny access to a given Azure service.
Application security groups (ASGs)	Group network interface cards into applications or services for easier management.
Network watcher	Provides tools that can be used for monitoring, alerting, and troubleshooting.
Automation	Use automation tools and principles like infrastructure as code and CI/CD pipelines for deployment and ongoing management.

Getting started with NSGs

A fundamental building block of many services running within Microsoft Azure is the Azure Virtual Network (VNet). A VNet enables Azure resources to communicate privately with each other, services on different private networks (either within the public cloud or on-premises), and of course, the internet. For security reasons, it is standard practice to control traffic flowing across these networks using a firewall, which enforces access control rules. Within Azure, the NSG provides this basic functionality.

The image shows a basic NSG filtering incoming traffic to a Windows IIS server

Below is a breakdown of NSGs and how they work.

Security rules

Security rules within an NSG are set either inbound or outbound and have five additional properties to determine how to handle network traffic:

• Source: This could be an IP address, IP subnet, service tag, or application security group (ASG; discussed later in this article).
• Source port: The ports or range of ports that initiate network traffic. This setting is usually set to “any” port.
• Destination: As with the Source, this could be an IP address, IP subnet, service tag, or application security group.
• Destination port: The ports or range of ports to connect to the destination, such as port 443 for HTTPS traffic inbound to a web server.
• Protocol: This can be set to TCP, UDP, ICMP, or Any when using the Azure portal, though two additional protocols (ESP and AH) are available when deploying through ARM templates.

Security rules are loaded based on a priority set when creating them. Each rule can either allow or deny network traffic.

Default rules

When initially deployed, a set of default rules is assigned to the NSG, allowing all incoming and outgoing traffic across the Azure Virtual Network and all outgoing traffic to the internet. Note that you cannot delete these rules, but you can set new rules with a higher priority to supersede them.

The screenshot shows default NSG rules, but with additional rules added above, which take priority

Stateful security rules

NSGs are stateful, meaning that approved traffic is added to a state table and monitored on its complete journey across the network. As a result, the firewall will automatically permit return traffic to the client when it initiates a connection to a server, e.g. an SSH connection to a Linux server for management. Likewise, the firewall will automatically allow return traffic inbound for any outbound traffic initiated by the server and allowed through the firewall.

The image shows the stateful application of security rules

Assigning NSGs

You can assign an NSG to a network interface, virtual network subnet, or both:

• A virtual network subnet or interface can only have one NSG, but an NSG can be assigned to many subnets or interfaces.
• Traffic transiting an Azure Virtual Network will be processed by the NSG in a specific order depending on whether it is inbound to a network interface or outbound from a network interface:
  • Inbound rules are processed first by any NSG applied at the subnet level, then by NSGs assigned to the network interface.
  • Outbound rules are processed first by NSGs assigned to the network interface, followed by any NSG set at the subnet level.
• If NSGs are not applied at either level, all traffic is permitted inbound and outbound.

The image shows layered processing of security rules in NSGs (source)

There is a limit of 5,000 NSGs per Azure subscription, and each NSG can have a maximum of 1,000 security rules.

Recommendations

Network security groups are one of the simplest resources to deploy within the Azure ecosystem, but correctly configuring them is key to securing the resources that host your applications and data. Here are seven recommendations to accelerate that process.

Take control!

When creating a network security group with a VM, the default rules will allow inbound SSH or RDP traffic from the internet. Ideally, restrict access to just the public IPs of the users or systems that require it. Alternatively, consider using the Azure Bastion service, which means no external inbound access is required.

Likewise, all outbound traffic is allowed on any port to anywhere on the internet by default. This is rarely a requirement—in most cases, enabling external HTTP and HTTPS for outbound internet browsing is sufficient. Consider using a NAT gateway for outbound connectivity and Azure PrivateLink to access other Azure resources securely.

Prioritize your rules correctly

The priority order of the security rules is crucial for ensuring that the correct traffic arrives and leaves your Azure resource. The best example is the difference between a blacklist and a whitelist. For a whitelist, the highest priority rule should allow only the IP addresses you specify, while a lower rule should deny all traffic. In contrast, for a blacklist, the highest priority rule should deny traffic from the IP addresses you want to block, and a lower rule should allow traffic from everywhere else.

Combining these two concepts will block specific IP addresses or ranges within an IP subnet block without allowing access from everywhere. Remember to leave spaces between rule priority numbers to give flexibility for future rules without having to manually renumber each rule further down the priority list.

Name your rules purposefully

A naming strategy allows easier identification of an NSG without requiring an administrator to examine the ruleset. Though it might be tempting to name NSGs after the allocated resource (e.g., the subnet or VM), this does not explain the purpose of the NSG. It also complicates matters in the future if that NSG is assigned to another resource.

It is also recommended to name each security rule to give an idea of its purpose. Some rules might be obvious—such as allowing all outbound HTTPS to the internet—but other custom rules may use a combination of ports and IP addresses to give access to a specific application or service. Naming the rule allows other administrators to understand its purpose and minimize the risk of it being removed or amended.

Reduce Complexity

Where possible, reduce the number of NSGs in use to ensure more flexibility in deployment and easier management. For example, you can apply an NSG to multiple subnets, virtual machines, or a combination of the two. By applying default security rules at the subnet level and more specific rules for each application type at the network interface level, it’s possible to create NSG layers and minimize the number of NSGs required to secure your Azure systems.

Additionally, use augmented security rules to define more complicated security policies with fewer security rules. An augmented security rule combines multiple ports, IP addresses, and IP ranges into a single security rule. A basic example could be a subnet dedicated to hosting multiple websites. Creating one NSG with a single augmented security rule allows HTTP and HTTPS traffic inbound to all IP addresses within the subnet.

Finally, combine these suggestions with application security groups and service tags. ASGs allow you to group multiple network interfaces as a single entity to apply network security policies. An example would be creating one NSG and three ASGs: one for web servers (“web”), one for the business logic application (“logic”), and one for the database server (“db”). Next, assign the network interfaces of the web servers to the web ASG, the network interface of the business logic server to the logic ASG, and the network interface of the database server to the db ASG. This will control inbound HTTP access to the web servers and SQL access between the logic application and the database server, restricting all other activity (see image below). Associating future web servers with the web ASG will automatically provide them with the correct access without any additional changes to the NSG.

Application security groups combined with network security groups (source)

Service tags represent Azure services such as Azure SQL Database, Azure Storage, and Azure Backup. They consist of a group of IP address prefixes managed by Microsoft that provide access to these services. Service tags help achieve network isolation and protect Azure resources from exposure to the internet while providing access to Azure services with public endpoints.

Apply resource locks

Resource locks prevent accidental misconfigurations or deletions. Resource lock application to an NSG sets either the deletion of an NSG or makes it read-only. For the former, administrators with appropriate permissions can still make changes to security rules within an NSG but cannot delete the NSG. Changes to the NSG are impossible without removing the resource lock for the latter. NSGs that provide sensitive access should be locked down using resource locks. Examples of NSGs you might consider locking down are those that give remote management access to a system or default NSGs that should not be changed.

Monitor and govern your NSGs

Strategies and procedures for correctly implementing NSGs are critical, but ensuring that they remain configured according to your standards is just as important. It may also be necessary to troubleshoot any unexpected issues that come about as a result of a change in the policies. Azure Network Watcher provides monitoring, alerting, and troubleshooting tools to help you achieve this:

• Connection Monitor will actively monitor the connection between a VM and another endpoint, such as between a web server and a database. It will proactively provide alerts if it detects issues such as DNS resolution problems, resource issues on the VM, or an NSG security rule concern. It can also monitor minimum, average, and maximum latency on the connection.
• IP Flow Verify is a troubleshooting tool that can verify communication between two IP addresses, specifying the port, protocol, and direction of the traffic. It will also provide details of the NSG security rule that allowed or denied the traffic.
• Effective Security Rules list the combination of all security rules that will apply to a network interface, considering the rules applied at both the network interface and subnet levels.
• NSG Flow Logs will log the activity of traffic flowing through an NSG, including details on source and destination IP addresses, ports, protocols, and whether traffic was permitted or denied. These logs are available for analysis in tools such as Power BI and Traffic Analytics, which provide detailed and easy-to-read visualizations for more efficient analysis.

Some of the rich visualizations that can be achieved using traffic analytics and NSG flow logs (source)

Automate your deployments

For smaller environments containing just a few virtual machines or App Service plans, manually deploying and managing your security groups is manageable. However, as your infrastructure scales, you will find you cannot maintain this practice. Automation becomes increasingly necessary for consistent deployments, complex change management, and compliance enforcement:

• Infrastructure as code (IaC) tools such as Azure Bicep make it easier to automate the deployment of standard NSG resources within Azure using templates or modules. Intricate changes are simplified, and they facilitate the compliance of applications efficiently.

• Continuous integration and development (CI/CD) pipelines, such as those found in Azure DevOps, provide a means for automated reviews, tests, and vulnerability assessments before deployment. They also enable fast backout processes in case of unexpected issues or outages.

Conclusion

NSGs are fundamental to securing inbound and outbound network traffic for virtual machines and network subnets within an Azure Virtual Network. When used correctly, they form one of the first layers of defense to protect application integrity and reduce the risk of data loss prevention.

However, your security strategy shouldn’t end there. The layer 3 and layer 4 port-based protection that NSGs provide has significant limitations. Encrypted protocols such as SSH and HTTPS can contain other forms of malicious attacks undetected by this type of protection. Consider other network security tools, such as Azure Firewall and Web Application Firewall (WAF), for any devices presented externally to the internet or other private networks. Azure Monitor and Azure Sentinel provide additional monitoring and compliance tools, providing greater defense in depth and protection for your data.