What Are Network Security Groups in Azure Resource Manager?

In this post I will explain how network security groups (NSGs) can offer network security and policy enforcement for virtual networks in an Azure Resource Manager (ARM) or CSP deployment.

What Are Network Security Groups?

You can think of an NSG as being a simple form of distributed firewall that you create and that Microsoft applies within the Azure network fabric. You can create a policy and associate it with a virtual machine NIC or a subnet. Any rules that you create within the policy are applied to the associated resources.
Note: Classic/Azure V1/Service Management deployments allowed you to associate NSGs with virtual machines or subnets. ARM changes how networking is done, so you associate NSGs with NICs or subnets only.
The purpose of a NSG is to control traffic either by allowing or blocking it. We can create inbound security rules:

• NSG associated with subnet: Blocked traffic is stopped before it enters the subnet.
• NSG associated with a NIC: Blocked packets will be stopped at the NIC, even if it is allowed on the subnet.

We can also create outbound rules:

• NSG associated with a NIC: Traffic is dropped before it leaves the virtual machine.
• NSG associated with subnet: Packets are stopped at the subnet, even if the transmitting NIC is allowed to send it.

What does this mean? You can create a single NSG and impact all machines on a subnet (recommended), or you can create an NSG that applies to a single NIC (not recommended). Microsoft is encouraging Azure customers to create a subnet for each tier of security in the network, which will make network design and troubleshooting much easier.

NSG Rules

An NSG contains rules which enforce our network policies. The construction of the rules is pretty familiar:

• Name: What you call the rule. I recommend something pretty descriptive.
• Protocol: TCP, UDP or *. Note that * includes ICMP for internal traffic only.
• Source address prefix: Identify the single IP address, network address, or tag (more later) that is transmitting the traffic.
• Source port range: Specify a port or range of ports for the source of the traffic you want to allow/block.
• Destination address prefix: Identify the single IP address, network address, or tag (more later) that is the recipient of the traffic.
• Destination port range: Specify a port or range of ports for the destination of the traffic you want to allow/block.
• Direction: Specify if this is an inbound or outbound rule.
• Priority: A number between 100 and 4096 that allows you to create a granular set of rules.

There are three predefined tags that can be used to specify some common sources/destinations of traffic:

• Internet: Any traffic coming from or going to the Internet or other sources in Azure external to your own.
• Virtual Network: Any address within the subnets of the current virtual network.
• Azure Load Balancer: Traffic from the probe of a load balancer that is testing for availability of load balanced virtual machines. This does not include load balanced or NATed traffic.

There are three default inbound rules in a network security group:

• All traffic is allowed within the virtual network. This rule has the side-effect of allowing ICMP (ping) traffic within the virtual network.
• The probes of Azure load balancers have unrestricted access.
• All external traffic is blocked from entering the network by default.

You can create rules with higher priorities that override the default rules. For example, I might create a rule, with a priority of 100, to allow TCP 80 inbound, which will override the default DenyAllInBound rule, which has a lower system priority of 65500.

There are also three default outbound rules, which you can also override. Note that all traffic within a VNet is allowed, and all outbound traffic to the Internet is also allowed.

Application Layer Security
NSGs provide a simple means for controlling traffic based on protocol, source/destination address, and source/destination port number. NSGs do not offer a mechanism for performing application layer inspection and filtering. If you need that level of security, then you should consider implementing a DMZ architecture with a virtual appliance from the Azure Marketplace. Microsoft recommends that the virtual appliance reside in its own small subnet (within the virtual network), and you can enforce usage of the firewall using user-defined routing and NSGs.