A Comprehensive Guide to Implementing Azure Network Security Groups
Learn the key concepts and best practices for implementing Azure network security groups to effectively manage and secure network traffic in your Azure virtual network.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content
Azure network security groups (NSGs) filter traffic between Azure resources in an Azure virtual network. NSGs are a basic firewall that controls the network traffic based on administrator-defined rules. These rules specify whether to allow or deny traffic based on:
- Source IP address
- Destination IP address
- Port number
- Protocol (TCP, UDP, etc.)
- Traffic direction (inbound or outbound)
Azure network security groups can be associated directly with VMs, network interfaces, (NICs), or a subnet in a virtual network. Effective NSG planning is essential to avoid overlapping rules, exposed VMs, or an administrative burden for your teams. This article explores the main components of Azure network security groups and provides best practices for implementing NSGs in your Azure environment.
Summary of Key Azure Network Security Group Concepts
The table below summarizes seven essential Azure NSG concepts this article will explore in more detail.
| Concepts | Description |
| Plan your VNets | Segregate your VNets into multiple subnets and assign NSGs to each. This practice isolates network traffic and improves manageability. |
| Default rule set | The NSG default rule set is overly permissive and does not set a firewall for egress traffic. However, it provides a good example of naming security rules to provide as much context as possible. |
| Network security group rules prioritization | Rules are processed in priority order, with lower numbers having a higher priority. Space priority numbers so that you can more easily assign future rules. |
| Service tags | Azure provides a service tag for a group of IP addresses assigned to a given service. Service Tags simplify defining security rules for Azure services because Microsoft manages the address prefixes. |
| Application security groups | Application security groups enable VMs to be grouped by workload and used in NSGs. ASGs simplify rule management, mainly when multiple VMs belong to the same workload. |
| Traffic flow logging | Logging IP traffic flowing through a network security group is vital for understanding your network. Microsoft provides a Power BI template to help you visualize network flow logs. |
| Comparing Azure network security groups to Azure Firewall | NSGs control access to networks based on allow and block rules. Azure Firewall provides advanced features like real-time threat detection and packet inspection. NSGs and Azure Firewall are complementary services that can provide a layered approach to security. |
Plan Your VNets
A common approach to migrating on-premise applications to the cloud is via N-tier architectures because they minimize refactoring. An N-tier architecture has multiple tiers, each providing a subset of the entire application’s functionality. Each tier has one or more subnets within the virtual network (VNet). These subnets segment the VNet and provide a security boundary.
The network diagram above shows an N-tier architecture with network security groups associated with each tier. The NSGs control access between tiers. For example, the business tier only allows access from the web tier, and the data tier only allows access from the business tier.
The following universal design principles will help you plan VNets in Azure:
- Divide your VNets into smaller subnets based on security, application, or environment requirements.
- Define a private address space that is large enough to accommodate future growth.
- In hybrid environments, ensure your VNet address space does not overlap with on-premise network address ranges.
- Secure your virtual networks by assigning NSGs to the subnets beneath them.
Manage, Monitor & Recover AD, Azure AD, Office 365
Unified Console
Use a single tool to administer and secure AD, Azure AD, and Office 365
Track Threats
Monitor AD for unwanted changes – detect for security or critical functions
Instant Recovery
Recover global enterprise-wide Active Directory forests in minutes, not days
Subnet and Azure Network Security Group Design Patterns
The table below considers the advantages and disadvantages of some common design patterns for using subnets and associating NSGs.
| Scenario | Diagram | Advantages | Disadvantages |
| A single subnet with NSGs per application layer and application. |  | There is only one subnet to manage. | Multiple NSGs are necessary to isolate each application. |
| One subnet per application with NSGs per application layer. In this example, NSG1 is associated with the front end application layer for both app1 and app2. |  | There are fewer NSGs to manage. | There are multiple subnets to manage. |
| One subnet per application layer, NSGs for application (app1 and app2). |  | It provides a balance between the number of subnets and NSGs. | Maximum of 100 NSGs. 50 apps if each app requires 2 distinct NSGs. |
| One subnet per application layer, per app, NSGs per subnet. |  | Possibly a smaller number of NSGs. | Multiple subnets to manage. |
Table showing common subnet and NSG design patterns. (Source)
Default Rule Set
Each Azure network security group has the following default rule set. The default rule set demonstrates the 5-tuple definition of a rule. That is, each rule has a
- Source
- Source port
- Destination
- Destination port
- Protocol
For further information on the network security group rule properties.
| Name | Priority | Source | Source ports | Destination | Destination ports | Protocol | Access |
| Inbound | |||||||
AllowVNet InBound | 65000 | Virtual Network | 0-65535 | Virtual Network | 0-65535 | Any | Allow |
AllowAzure LoadBalancer InBound | 65001 | AzureLoad Balancer | 0-65535 | 0.0.0.0/0 | 0-65535 | Any | Allow |
DenyAll Inbound | 65500 | 0.0.0.0/0 | 0-65535 | 0.0.0.0/0 | 0-65535 | Any | Deny |
| Outbound | |||||||
AllowVnet OutBound | 65000 | Virtual Network | 0-65535 | Virtual Network | 0-65535 | Any | Allow |
AllowInternet OutBound | 65001 | 0.0.0.0/0 | 0-65535 | Internet | 0-65535 | Any | Allow |
DenyAll OutBound | 65500 | 0.0.0.0/0 | 0-65535 | 0.0.0.0/0 | 0-65535 | Any | Deny |
Manage, Monitor & Recover AD, Azure AD, M365, Teams
| Platform | Admin Features | Single Console for Hybrid (On-prem AD, Azure AD, M365, Teams) | Change Monitoring & Auditing | User Governance (Roles, Rules, Automation) | Forest Recovery in Minutes |
| Microsoft AD Native Tools | ✓ | ||||
| Microsoft AD + Cayosoft | ✓ | ✓ | ✓ | ✓ | ✓ |
Inbound Rules
- AllowVNetInbound – this rule allows all inbound traffic within the VNet. It enables your VMs to communicate.
- AllowAzureLoadBalancerInBound – this rule allows traffic from an Azure Load Balancer and your VNet and VMs.
- DenyAllInbound – the rule denies all inbound traffic, 0.0.0.0/0 in the Source or Destination columns represents all IP Addresses. It has the lowest priority.
Outbound Rules
- AllowVNetOutbound – this rule allows all outbound traffic within the VNet. It enables your VMs to communicate.
- AllowInternetOutBound – this rule allows all outbound traffic to the internet. This rule may be overly permissive.
- DenyAllOutbound – this rule denies all outbound traffic, and it has lower priority.
Naming Rules for Azure Network Security Groups
The default rule set provides a good example of a well-defined rule naming strategy. The name of each security rule can be used to determine its purpose. For example, AllowAzureLoadBalancerInBound clearly states what the rule does and what it is for. When naming rules, consider whether another administrator will be able to determine what the rule is for from the name alone.
Azure Network Security Group Rules are Stateful
NSG rules are stateful, so if you define an outbound security rule to any address over port 80, it is unnecessary to specify an inbound security rule to respond to the outbound traffic. The opposite is also true. If inbound traffic is allowed over a port, specifying an outbound security rule to respond to traffic over the outbound port is unnecessary.
Azure Network Security Group Rules Prioritization
Network security rules are processed in priority order, with lower numbers having a higher priority than higher numbers. The default rules above have the highest number and, therefore, lowest priority, and this ensures that your custom rules are always processed first. For example, if your security configuration requires that you deny port 80 traffic to the internet, you will have to configure a higher priority rule:
| Name | Priority | Source | Source ports | Destination | Destination ports | Protocol | Access |
| Outbound | |||||||
Deny Outbound Port 80 | 100 | 0.0.0.0/0 | 80 | Internet | 80 | Any | Deny |
Prioritize Rules Logically
Custom NSG rules can have a priority from 100 to 4096, and once traffic matches a rule, the processing is stopped. It is best practice to leave spaces between rule priority numbering so administrators can add future rules without changing existing rules. For example, use a rule spacing like 120, 220, 320, etc.
For the N-tier architecture example, the default rule set allows communication between all VMs within the VNet, so higher priority rules are required to isolate the subnets. For example, the web tier should not directly communicate with the data tier, so a rule is required on the NSG associated with the data tier that:
- Denies all inbound traffic from the virtual network using the VirtualNetwork service tag, isolating the data tier from the other tiers.
- Allow inbound traffic from the business tier subnet.
- Allow inbound traffic from the data tier subnet to ensure the SQL servers can communicate for data replication and failover.
Create rules 2 and 3 with higher priority than the first rule. You must also consider how your database administrators will connect with the SQL servers for administration and maintenance. In the N-tier architecture example, the bastion host acts as a jumpbox to enable administrators to communicate with the other VMs.
Service Tags
As Azure services evolve, their IP addresses may change. If you are defining rules to access Azure services using the Azure IP Ranges, we recommend you replace them with service tags. Microsoft automatically updates the IP addresses associated with the service tags, which reduces your maintenance efforts.
For example, you can use service tags to isolate your Azure resources from the general internet but still access Azure services with public endpoints as shown in the network diagram below. A rule denies all outbound traffic to the internet, but a higher priority rule can be used to allow traffic to specific Azure services based on service tags, e.g. Storage or Sql.EastUS.
Azure publishes a list of available service tags, and the published JSON files also include a changeNumber. The list is updated weekly, and services updated between weeks can be identified by finding an increased changeNumber.
Application Security Groups
The N-tier architecture example divided an application into logical tiers, and a network security group was associated with each tier. This means that if a new VM is added to the web tier, it will inherit the same rules as the existing VMs.
An architecture like the one below does not follow an N-tier architecture. VMs 1, 2, 3, and 4 are all covered by NSG1, which is associated with subnets 1 and 2. The NICs of each VM have been associated with application security groups. NIC1 and NIC2 are associated with AsgWeb. NIC3 is a member of AsgLogic, and NIC4 is a member of AsgDb.
By using ASGs, you can group VMs that provide the same application functionality. NSG1 uses the ASGs in the security rules as follows:
| Name | Priority | Source | Source ports | Destination | Destination ports | Protocol | Access |
| Inbound | |||||||
| Allow-HTTP-Inbound-Internet | 100 | Internet | * | AsgWeb | 80 | TCP | Allow |
| Allow-Database-BusinessLogic | 110 | AsgLogic | * | AsgDb | 1433 | TCP | Allow |
| Deny-Database-All | 120 | * | * | AsgDb | 1433 | Any | Deny |
Here is what each rule does:
- Allow-HTTP-Inbound-Internet – Allows traffic from the internet to the web servers, VM1 and VM2, grouped by AsgWeb. This rule takes priority over the DenyAllInbound rule.
- Allow-Database-BusinessLogic – Allows traffic from the AsgLogic application security group to the AsgDb VM.
- Deny-Database-All – Denies traffic from all other VMs in the VNet and is needed to overrule the AllowVNetInBound default security rule.
In this example, using application security groups eases the use of one Azure network security group instead of multiple NSGs. This demonstrates how administrators can use ASGs to simplify the definition and management of Azure network security group rules.
Watch demo video of Cayosoft’s hybrid user provisioning
Traffic Flow Logging
Flow logging helps you to understand the current state of your networks. NSG flow logging is part of Azure Network Watcher and provides tools to monitor, diagnose, and view metrics associated with IP traffic flowing through a network security group.
In the image above, NSG flow logging is configured for two NSGs: nsg01 and nsg02. The recorded flow logs are being sent to Azure storage in JSON format.
There are two versions available:
- Version 1 records contain the network interface (NIC) to which the flow applies, 5-tuple information, and the traffic decision.
- Version 2 includes all the version 1 properties and in addition, records flow states, which can be used to determine bandwidth. An example of a version 2 NSG flow log is shown below.
{
"records": [
{
"time": "2018-11-13T12:00:35.3899262Z",
"systemId": "a0fca5ce-022c-47b1-9735-89943b42f2fa",
"category": "NetworkSecurityGroupFlowEvent",
"resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/FABRIKAMRG/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/FABRIAKMVM1-NSG",
"operationName": "NetworkSecurityGroupFlowEvents",
"properties": {
"Version": 2,
"flows": [
{
"rule": "DefaultRule_DenyAllInBound",
"flows": [
{
"mac": "000D3AF87856",
"flowTuples": [
"1542110402,94.102.49.190,10.5.16.4,28746,443,U,I,D,B,,,,",
"1542110424,176.119.4.10,10.5.16.4,56509,59336,T,I,D,B,,,,",
"1542110432,167.99.86.8,10.5.16.4,48495,8088,T,I,D,B,,,,"
]
}
]
},
{
"rule": "DefaultRule_AllowInternetOutBound",
"flows": [
{
"mac": "000D3AF87856",
"flowTuples": [
"1542110377,10.5.16.4,13.67.143.118,59831,443,T,O,A,B,,,,",
"1542110379,10.5.16.4,13.67.143.117,59932,443,T,O,A,E,1,66,1,66",
"1542110379,10.5.16.4,13.67.143.115,44931,443,T,O,A,C,30,16978,24,14008",
"1542110406,10.5.16.4,40.71.12.225,59929,443,T,O,A,E,15,8489,12,7054"
]
}
]
}
]
}
},
{
"time": "2018-11-13T12:01:35.3918317Z",
"systemId": "a0fca5ce-022c-47b1-9735-89943b42f2fa",
"category": "NetworkSecurityGroupFlowEvent",
"resourceId": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/FABRIKAMRG/PROVIDERS/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/FABRIAKMVM1-NSG",
"operationName": "NetworkSecurityGroupFlowEvents",
"properties": {
"Version": 2,
"flows": [
{
"rule": "DefaultRule_DenyAllInBound",
"flows": [
{
"mac": "000D3AF87856",
"flowTuples": [
"1542110437,125.64.94.197,10.5.16.4,59752,18264,T,I,D,B,,,,",
"1542110475,80.211.72.221,10.5.16.4,37433,8088,T,I,D,B,,,,",
"1542110487,46.101.199.124,10.5.16.4,60577,8088,T,I,D,B,,,,",
"1542110490,176.119.4.30,10.5.16.4,57067,52801,T,I,D,B,,,,"
]
}
]
}
]
}
}
]
}
Example JSON format of a version 2 NSG flow log. (Source)
Taking one of the flowsTuples lines as an example:
"1542110379,10.5.16.4,13.67.143.117,59932,443,T,O,A,E,1,66,1,66"
The line contains the following properties:
- 1542110379 – timestamp in UNIX epoch format.
- 10.5.16.4 – source IP address
- 13.67.143.117 – destination IP address
- 59932 – source port
- 443 – destination port
- T – protocol (T for TCP or U for UDP)
- O – traffic flow direction (O for Outbound or I for Inbound)
- A – traffic decision (A for Allowed or D for Denied)
- E – flow state (version 2)
- 1 – packets sent (version 2)
- 66 – bytes sent (version 2)
- 1 – packets received (version 2)
- 66 – bytes received (version 2)
Microsoft provides a Network Watcher Power BI flow logs template to visualize version 1 NSG flow logs and understand what is recorded. This data can be imported into your security information and event management (SIEM) or intrusion detection system (IDS) to identify unknown or undesired traffic.
Comparing Azure Network Security Groups to Azure Firewall
Azure network security groups are often compared to Azure Firewall. These two services are not mutually exclusive and provide different functionality. NSGs operate OSI layers 3 and 4 and filter network traffic based on rules. NSGs do not provide application layer inspection or authenticated access controls. Azure Firewall provides layer 3, 4, and 7 filtering and includes packet inspection to provide threat intelligence. A typical use of Azure Firewall is to protect your enterprise network from incoming traffic via the internet.
The table below compares the features of NSGs and Azure Firewall.
| Comparison | Azure NSG | Azure Firewall |
| OSI Layers | 3 – Network Transport4 – Transport | 3 – Network4 – Transport7 – Application |
| Stateful | Yes | Yes |
| Service tag support | Yes | Yes |
| ASG support | Yes | No |
| Protocol-based traffic filtering | Yes | Yes |
| Fully Qualified Domain Name Support | No | Yes |
| Network Address Translation support | No | Source Network Address TranslationDestination Network Address Translation |
| Threat monitoring | No | Yes |
| Pricing | Free | Per deployment hour and data processing fees. Three tiers:BasicStandardPremium |
Use Azure network security groups and Azure Firewall together to provide a layered approach to security. NSGs provide host-level network traffic filtering, whereas Azure Firewall can provide traffic filtering and threat detection at the virtual network level.
Learn why U.S. State’s Department of Information Technology (DOIT) chose Cayosoft
Last Thoughts on Azure Network Security Groups
Network security groups (NSGs) filter network traffic between Azure resources in a virtual network. They can be associated directly with VMs, network interfaces (NICs), or a subnet. NSGs consist of security rules that allow or deny network traffic based on a 5-tuple definition. NSG flow log data helps visualize network traffic and determine whether security rules behave as expected. Ensure that you use descriptive names for your security rules that explain their purpose.
Service tags simplify defining network security group rules for Azure services. Instead of defining and updating the IP address prefixes for a given Azure service, service tags provide an abstraction of the IP address prefixes. Application security groups allow you to group VMs and define network security policies based on those groups. Be sure to name application security groups clearly so others can understand their content and purpose.Azure NSGs and Azure Firewall are complementary services that can help achieve zero-trust network security and provide multiple layers of defense. Cayosoft Guardian can further enhance your zero-trust security strategy for hybrid AD environments by protecting against cyberattacks, malware, accidental deletions, and misconfigurations.
Like This Article?
Subscribe to our LinkedIn Newsletter to receive more educational content