NSG Best practice
security rules that allow or deny network traffic to resources
A network security group (NSG) contains a list of security rules that allow or deny network traffic to resources connected to Azure Virtual Networks (VNet). NSGs can be associated to subnets or individual network interfaces (NIC) attached to VMs. When an NSG is associated to a subnet, the rules apply to all resources connected to the subnet. Traffic can further be restricted by also associating an NSG to a VM or NIC.
NSG naming convention
When you put a virtual machine on an Azure Virtual Network, you’ll notice that the virtual machine can connect to any other virtual machine on the same Azure Virtual Network, even if the other virtual machines are on different subnets. The reason why this is possible is that there is a collection of system routes that are enabled by default that allow this type of communication. These default routes allow virtual machines on the same Azure Virtual Network to initiate connections with each other, and with the Internet (for outbound communications to the Internet only).
While the default system routes are useful for many deployment scenarios, there are times when you want to customize the routing configuration for your deployments. These customizations will allow you to configure the next hop address to reach specific destinations.
We recommend that you configure User Defined Routes when you deploy a virtual network security appliance, which we’ll talk about in a later best practice.
Note
user Defined Routes are not required and the default system routes works in most instances.
NSG resource
| Property | Description | Constraints | Considerations |
|---|---|---|---|
| Name | Name for the NSG | Must be unique within the region. Can contain letters, numbers, underscores, periods, and hyphens. Must start with a letter or number. Must end with a letter, number, or underscore. Cannot exceed 80 characters. |
Since you may need to create several NSGs, make sure you have a naming convention that makes it easy to identify the function of your NSGs. |
| Region | Azure region where the NSG is created. | NSGs can only be associated to resources within the same region as the NSG. | To learn about how many NSGs you can have per region, read the Azure limits article. |
| Resource group | The resource group the NSG exists in. | Although an NSG exists in a resource group, it can be associated to resources in any resource group, as long as the resource is part of the same Azure region as the NSG. | Resource groups are used to manage multiple resources together, as a deployment unit. You may consider grouping the NSG with resources it is associated to. |
| Rules | Inbound or outbound rules that define what traffic is allowed or denied. | See the NSG rules section of this article. |
Note: Endpoint-based ACLs and network security groups are not supported on the same VM instance. If you want to use an NSG and have an endpoint ACL already in place, first remove the endpoint ACL.
NSG rules
| Property | Description | Constraints | Considerations |
|---|---|---|---|
| Name | Name for the rule. | Must be unique within the region. Can contain letters, numbers, underscores, periods, and hyphens. Must start with a letter or number. Must end with a letter, number, or underscore. Cannot exceed 80 characters. |
You may have several rules within an NSG, so make sure you follow a naming convention that allows you to identify the function of your rule. |
| Protocol | Protocol to match for the rule. | TCP, UDP, or * | Using * as a protocol includes ICMP (East-West traffic only), as well as UDP and TCP, and may reduce the number of rules you need. At the same time, using * might be too broad an approach, so it's recommended that you use * only when necessary. |
| Source port range | Source port range to match for the rule. | Single port number from 1 to 65535, port range (example: 1-65535), or * (for all ports). | Source ports could be ephemeral. Unless your client program is using a specific port, use * in most cases. Try to use port ranges as much as possible to avoid the need for multiple rules. Multiple ports or port ranges cannot be grouped by a comma. |
| Destination port range | Destination port range to match for the rule. | Single port number from 1 to 65535, port range (example: 1-65535), or * (for all ports). | Try to use port ranges as much as possible to avoid the need for multiple rules. Multiple ports or port ranges cannot be grouped by a comma. |
| Source address prefix | Source address prefix or tag to match for the rule. | Single IP address (example: 10.10.10.10), IP subnet (example: 192.168.1.0/24), default tag, or * (for all addresses). | Consider using ranges, default tags, and * to reduce the number of rules. |
| Destination address prefix | Destination address prefix or tag to match for the rule. | Single IP address (example: 10.10.10.10), IP subnet (example: 192.168.1.0/24), default tag, or * (for all addresses). | Consider using ranges, default tags, and * to reduce the number of rules. |
| Direction | Direction of traffic to match for the rule. | Inbound or outbound. | Inbound and outbound rules are processed separately, based on direction. |
| Priority | Rules are checked in the order of priority. Once a rule applies, no more rules are tested for matching. | Number between 100 and 4096. | Consider creating rules jumping priorities by 100 for each rule to leave space for new rules you might create in the future. |
| Access | Type of access to apply if the rule matches. | Allow or deny. | Keep in mind that if an allow rule is not found for a packet, the packet is dropped. |
How NSG rules are processed
Default tags
Default tags are system-provided identifiers to address a category of IP addresses. You can use default tags in the source address prefix and destination address prefix properties of any rule. There are three default tags you can use:
- VirtualNetwork (Resource Manager) (VIRTUAL_NETWORK for classic): This tag includes the virtual network address space (CIDR ranges defined in Azure), all connected on-premises address spaces, and connected Azure VNets (local networks).
- AzureLoadBalancer (Resource Manager) (AZURE_LOADBALANCER for classic): This tag denotes Azure’s infrastructure load balancer. The tag translates to an Azure datacenter IP where Azure Load Balancer's health probes originate.
- Internet (Resource Manager) (INTERNET for classic): This tag denotes the IP address space that is outside the virtual network and reachable by public Internet.
Default rules
All NSGs contain a set of default rules. The default rules cannot be deleted, but because they are assigned the lowest priority, they can be overridden by the rules that you create.
The default rules allow and disallow traffic as follows:
- Virtual network: Traffic originating and ending in a virtual network is allowed both in inbound and outbound directions.
- Internet: Outbound traffic is allowed, but inbound traffic is blocked.
- Load balancer: Allow Azure Load Balancer to probe the health of your VMs and role instances. If you override this rule, Azure Load Balancer health probes will fail which could cause impact to your service.
Inbound default rules
| Name | Priority | Source IP | Source Port | Destination IP | Destination Port | Protocol | Access |
|---|---|---|---|---|---|---|---|
| AllowVNetInBound | 65000 | VirtualNetwork | * | VirtualNetwork | * | * | Allow |
| AllowAzureLoadBalancerInBound | 65001 | AzureLoadBalancer | * | * | * | * | Allow |
| DenyAllInBound | 65500 | * | * | * | * | * | Deny |
Outbound default rules
| Name | Priority | Source IP | Source Port | Destination IP | Destination Port | Protocol | Access |
|---|---|---|---|---|---|---|---|
| AllowVnetOutBound | 65000 | VirtualNetwork | * | VirtualNetwork | * | * | Allow |
| AllowInternetOutBound | 65001 | * | * | Internet | * | * | Allow |
| DenyAllOutBound | 65500 | * | * | * | * | * | Deny |
Associating NSGs
You can associate an NSG to VMs, NICs, and subnets, depending on the deployment model you are using, as follows:
- VM (classic only): Security rules are applied to all traffic to/from the VM.
- NIC (Resource Manager only): Security rules are applied to all traffic to/from the NIC the NSG is associated to. In a multi-NIC VM, you can apply different (or the same) NSG to each NIC individually.
- Subnet (Resource Manager and classic): Security rules are applied to any traffic to/from any resources connected to the Subnet.
You can associate different NSGs to a VM (or NIC, depending on the deployment model) and the subnet that a NIC or VM is connected to. Security rules are applied to the traffic, by priority, in each NSG, in the following order:
-
Inbound traffic
-
NSG applied to subnet: If a subnet NSG has a matching rule to deny traffic, the packet is dropped.
-
NSG applied to NIC (Resource Manager) or VM (classic): If VM\NIC NSG has a matching rule that denies traffic, packets are dropped at the VM\NIC, even if a subnet NSG has a matching rule that allows traffic.
-
-
Outbound traffic
-
NSG applied to NIC (Resource Manager) or VM (classic): If a VM\NIC NSG has a matching rule that denies traffic, packets are dropped.
-
NSG applied to subnet: If a subnet NSG has a matching rule that denies traffic, packets are dropped, even if a VM\NIC NSG has a matching rule that allows traffic.
-
Note: Although you can only associate a single NSG to a subnet, VM, or NIC; you can associate the same NSG to as many resources as you want.
Limits
| Resource | Default limit | Maximum Limit |
|---|
| Network Security Groups (NSG) | 100 | 5000 |
| NSG rules per NSG | 200 | 1000 |
Design considerations
VNet and subnet design
Since NSGs can be applied to subnets, you can minimize the number of NSGs by grouping your resources by subnet, and applying NSGs to subnets. If you decide to apply NSGs to subnets, you may find that existing VNets and subnets you have were not defined with NSGs in mind. You may need to define new VNets and subnets to support your NSG design and deploy your new resources to your new subnets. You could then define a migration strategy to move existing resources to the new subnets.
Special rules
If you block traffic allowed by the following rules, your infrastructure can't communicate with essential Azure services:
- Virtual IP of the host node: Basic infrastructure services such as DHCP, DNS, and health monitoring are provided through the virtualized host IP address 168.63.129.16. This public IP address belongs to Microsoft and is the only virtualized IP address used in all regions for this purpose. This IP address maps to the physical IP address of the server machine (host node) hosting the VM. The host node acts as the DHCP relay, the DNS recursive resolver, and the probe source for the load balancer health probe and the machine health probe. Communication to this IP address is not an attack.
- Licensing (Key Management Service): Windows images running in VMs must be licensed. To ensure licensing, a request is sent to the Key Management Service host servers that handle such queries. The request is made outbound through port 1688.
ICMP traffic
The current NSG rules only allow for protocols TCP or UDP. There is not a specific tag for ICMP. However, ICMP traffic is allowed within a VNet by the AllowVNetInBound default rule, that allows traffic to and from any port and protocol within the VNet.
Subnets
- Consider the number of tiers your workload requires. Each tier can be isolated by using a subnet, with an NSG applied to the subnet.
- If you need to implement a subnet for a VPN gateway, or ExpressRoute circuit, do not apply an NSG to that subnet. If you do so, cross-VNet or cross-premises connectivity may fail.
- If you need to implement a network virtual appliance (NVA), connect the NVA to its own subnet and create user-defined routes (UDR) to and from the NVA. You can implement a subnet level NSG to filter traffic in and out of this subnet. To learn more about UDRs, read the User-defined routes article.
Load balancers
- Consider the load balancing and network address translation (NAT) rules for each load balancer used by each of your workloads. NAT rules are bound to a back-end pool that contains NICs. Consider creating an NSG for each back-end pool, allowing only traffic mapped through the rules implemented in the load balancers. Creating an NSG for each back-end pool guarantees that traffic coming to the back-end pool directly (rather than through the load balancer), is also filtered.
- In classic deployments, you create endpoints that map ports on a load balancer to ports on your VMs or role instances. You can also create your own individual public-facing load balancer through Resource Manager. The destination port for incoming traffic is the actual port in the VM or role instance, not the port exposed by a load balancer. The source port and address for the connection to the VM is a port and address on the remote computer in the Internet, not the port and address exposed by the load balancer.
- When you create NSGs to filter traffic coming through an Azure Load Balancer, the source port and address range applied are from the originating computer, not the load balancer frontend. The destination port and address range are those of the destination computer, not the load balancer frontend.
- If you block the AzureLoadBalancer tag, the health probes from Azure Load Balancer will fail and your service may be impacted.
Other
- Endpoint-based access control lists (ACL) and NSGs are not supported on the same VM instance. If you want to use an NSG and have an endpoint ACL already in place, first remove the endpoint ACL.
- In Resource Manager, you can use an NSG associated to a NIC for VMs with multiple NICs to enable management (remote access) on a per NIC basis. Associating unique NSGs to each NIC enables separation of traffic types across NICs.
- Similar to the use of load balancers, when filtering traffic from other VNets, you must use the source address range of the remote computer, not the gateway connecting the VNets.
- Many Azure services cannot be connected to VNets. If an Azure resource is not connected to a VNet, you cannot use an NSG to filter traffic to the resource.