Last week at TechEd Europe we announced the general availability of Network Security groups, a key addition to the Azure Networking stack. Network Security Groups provides segmentation within a Virtual Network (VNet) as well as full control over traffic that ingresses or egresses a virtual machine in a VNet. It also helps achieve scenarios such as DMZs (demilitarized zones) to allow users to tightly secure backend services such as databases and application servers.

 

Use cases and Scenarios

Building multi-tier applications is a common pattern in realizing business workflows in the cloud. Typically, entities in the FrontEnd tier such as Web Proxies and DNS servers are placed in a DMZ that is exposed to the Internet. Functionality in the other tiers such as Application servers and Back end instances need a higher level of security and hence are isolated from the DMZ. These tiers receive traffic only from certain instances in the Front-end and typically have no outbound connectivity to the Internet. With Network Security Groups, these multi-tier application architectures can be hosted in Azure.

The below diagram depicts a sample multi-tier application deployment:

 

Network Security Groups provide control over network traffic flowing in and out of your services running in Azure. Network Security Groups can also be applied to a subnet in a Virtual network thus they provide an efficient mechanism to administer access control rule updates across multiple VMs. Access control rules on hundreds or even thousands of machines can be changed in seconds, without any update or changes in the VM.

In addition to segmenting Intranet traffic, Network Security Groups can also be used to control traffic going to and coming from the Internet. Using a single access control rule, users can deny connectivity to the Internet for an entire subnet.

 

VM and Subnet ACLs

A Network Security Group consists of a set of access control rules that describe traffic filters. These can be associated with a virtual machine or a subnet in the same region. The rules defined in the Network Security Group act as filters. On the ingress path they are applied before traffic enters the VM. On the egress path, they are applied after traffic leaves the VM. In short these rules are applied at the infrastructure level which can’t be altered by user processes or even the OS running in the VM. When the Network Security Group is associated with a subnet it applies to all the VMs in the subnet. Any change made on the Network Security Group is immediately is applied to all VMs in the subnet.

Some important aspects of the Network Security groups include:

• The rules contain a 5 tuple (Source IP, Source port, Destination IP, Destination port, protocol).
• The rules are stateful. This means if there is an inbound rule that allow traffic on a port (e.g. port 80), a matching rule on the outbound side is not required for the packets to flow on the same port.
• Every Network Security Group contains default rules that allow connectivity within the Virtual Network and Outbound access to Internet . These default rules can be overridden by the user rules.
• The rules are processed based on priority. Rules with small (meaning higher priority) values are processed before rules with larger (meaning lower priority) values.
• Azure provides defaults tags such as INTERNET and VIRTUAL_NETWORK that refers to the Public IP Address space outside the Virtual Network and customer’s entire network address space respectively. The tags can be used as part of an access control rule.

 

Network Security Groups can be applied to a VM or subnet, and in some cases to both. In situations where traffic pattern amongst VMs in a subnet is very different, it may be better to have individual Network Security groups attached to VM with precise rules for controlling traffic to that VM. In situations where VMs in a subnet have identical traffic patterns (which is the case usually) it may be better to have a Network Security group attached to the subnet with traffic control rules to manage ingress and egress of the entire subnet. In some situations a hybrid of the two approaches may be the best if majority of the traffic is identical but if some fine grain control is required on a VM or two.

 

As the above picture depicts, on the Ingress path the rules from the Network Security Group attached to the subnet will be applied followed by rules from the Network Security Group attached to the VM if any. It will be the reverse in the egress path.

Also, it is well suited for a Network administrator to define the Network Security Group rules for a subnet and for a developer (owner of the VM) to describe the Network Security Group rules for a VM.

 

Limits

Network Security Groups strives to provide granular access control over network traffic for services running in the VNet, and aligning with that goal a subscription is allowed to have up to 100 Network Security Groups with each Network Security Group having as many as 200 rules. The limits can be increased by contacting Microsoft support if there is a genuine use case that requires more rules or groups.

Network Security Group is available only for VMs in a regional VNet.  Please refer to the FAQ section below for other inter operability items.

 

Usage

Network Security groups is currently exposed only through power shell and REST API.

 

#Create a Network Security Group
New-AzureNetworkSecurityGroup -Name "MyVNetSG" -Location uswest -Label "Security group for my Vnet in West US"

#Add, Update Rules to a NSG
Get-AzureNetworkSecurityGroup -Name "MyVNetSG" | Set-AzureNetworkSecurityRule -Name WEB -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '*' -Protocol TCP

#Delete a rule from NSG
Get-AzureNetworkSecurityGroup -Name "MyVNetSG" | Remove-AzureNetworkSecurityRule -Name WEB

#Associate a NSG to a Virtual machine
Get-AzureVM -ServiceName "MyWebsite" -Name "Instance1" | Set-AzureNetworkSecurityGroupConfig -NetworkSecurityGroupName "MyVNetSG"

#Remove a NSG from a VM
Get-AzureVM -ServiceName "MyWebsite" -Name "Instance1" | Remove-AzureNetworkSecurityGroupConfig -NetworkSecurityGroupName "MyVNetSG"

#Associate a NSG to a subnet
Get-AzureNetworkSecurityGroup -Name "MyVNetSG" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'VNetUSWest' -SubnetName 'FrontEndSubnet'

#Remove a NSG from the subnet
Get-AzureNetworkSecurityGroup -Name "MyVNetSG" | Remove-AzureNetworkSecurityGroupFromSubnet -VirtualNetworkName 'VNetUSWest' -SubnetName 'FrontEndSubnet'

#Delete a NSG
Remove-AzureNetworkSecurityGroup -Name "MyVNetSG"

#Get Details of Network Secuirty group along with rules
Get-AzureNetworkSecurityGroup -Name "MyVNetSG" -Detailed

Please refer to content in MSDN for additional details.

 

FAQ

1. I already use Endpoint ACLs on my VM endpoints, can I also use Network Security Groups?

No, you can use only either of Endpoint ACLs or Network Security Groups. You can remove the endpoint ACLs from the VM and associate the VM to a Network Security Group.

2. I have multiple NICs in my VM, will the Network Security Group rules apply to traffic on all the NICs?

No, the Network Security Group rules apply only to the traffic in primary NIC. In future we will add capability to associate a Network Security Group to a NIC directly.

3. I created a Network Security Group, what are my next steps?

After you have created a Network Security group, look at the default rules by running the command:

Get-AzureNetworkSecurityGroup -Name "MyVNetSG" -Detailed

This shows you the default rules. As a next step associate the Network Security group to a VM or subnet. Add more rules to control the network traffic on the entity. Watch the rules to take effect within a few minutes (it is usually seconds).

4. I have defined RDP endpoint for my VM and I am using a Network Security Group do I need  a Access control rule to connect to the RDP port from Internet?

Yes, the default rules in Network Security Group does not allow access to any port from Internet, the users have to create a specific rule to allow RDP traffic.