When you create virtual networks and subnets in Microsoft Azure, the default configuration allows all traffic to flow between the subnets within a virtual network. As you create virtual machines (VM) and place them on subnets, the virtual machines are configured with Internet facing public endpoints for Remote Desktop and Windows Remote Management (WinRM) connections. The virtual machines are also configured with outbound Internet access allowed.
The resulting traffic flow configuration results in all VMs within a virtual network able to communicate with each other on all protocols and ports, inbound RDP and WinRM from the Internet, and unrestricted outbound Internet access. Figure 1 is a visual representation of the default traffic flow in Microsoft Azure for a typical three-tier application.
Figure 1: Default network traffic flow for a three-tier application in Microsoft Azure
For most three-tier enterprise applications, this default traffic flow is not desired. A typical three-tier application, as shown in Figure 1, consists of the following layers:
- Tier 1 is the front end user interface (UI) to the application
- Tier 2 is the application logic
- Tier 3 is the application data storage (for example, SQL Server in Figure 1)
An Internet user connects to the front end UI tier to interact with the application. The UI tier then communicates to the application logic tier to determine what information to present to the user. The application tier processes user actions and selections, retrieves data from the data storage tier and provides information back to the UI for presentation to the user. The data storage tier stores all of the static data and the dynamic data for a user session.
In this configuration, the following traffic flow is typically desired:
- Tier 1 (UI) servers are in a DMZ and only allow inbound connections from the Internet on specific server ports
- Tier 1 servers in the DMZ only communicate to Tier 2 (Application) servers on specific defined application ports
- Tier 2 servers only communicate to Tier 3 (Data Storage) servers on the database server ports
- Tier 3 servers cannot initiate communications to Tier 1 or Tier 2 servers
- None of the servers can initiate outbound communications to the Internet
Figure 2 shows a visual representation of the typical desired traffic flow restrictions and standard ports that are used for tier-to-tier communications.
Figure 2: Desired traffic flow for a typical three-tier application
In most corporate network environments, the restricted traffic flow would be achieved by placing firewalls between the subnets and between the DMZ subnet and the Internet. Firewall rules would then be implemented to define allowed protocols and ports that can pass through the firewall and where traffic is allowed to flow.
Network Security Group Basics
Microsoft recently released a new feature called Network Security Groups (NSG) to enable the control of traffic between virtual machines and subnets. Unlike the Windows Firewall that is controlled at the operating system (OS) level, a NSG is controlled at the network layer and is independent of the OS that is running in the virtual machine.
Network Security Groups are containers that can be assigned to a subnet or a virtual machine. Within the Network Security Group container, you define access control rules. Each access control rule is a 5-tuple that contains the following information:
- Source IP Address
- Destination IP Address
- Action – Allow or Deny
Each rule also has a priority assigned when you create it that determines the order that the rules are evaluated. The priority is defined as an integer from 100 to 4096 with the rules with smaller number having the highest priority.
Rules can be assigned for inbound traffic and outbound traffic. Rules are also stateful, therefore if a rule is defined for inbound traffic on port 443, any response to that inbound packet will not be blocked by default on the return trip. This saves from having to define a corresponding outbound rule to allow traffic to return.
When you create an NSG, a set of default rules are automatically created and cannot be deleted. These default rules have the lowest priority so you can easily override them with new rules. The default rules include:
- Allow all ports and protocols within the virtual network address space
- Allow outbound access to the Internet on all ports and protocols
- Deny all inbound traffic from the Internet on all ports and protocols
- Allows an Microsoft Azure load balancer to probe the health of a VM
The default rules are implemented using a defined set of tags instead of specific IP addresses:
- VIRTUAL_NETWORK – represents the virtual network and local network address space that are accessible within the subscription
- AZURE_LOADBALANCER – represents the source address of a Microsoft Azure load balancer
- INTERNET – represents the address space outside the virtual network that is reachable by the public Internet.
Network Security Group Restrictions and Limits
Within a Microsoft Azure subscription, that are a set of limits and restrictions that you must consider when using network security groups:
- A maximum of 100 network security groups can be defined within a single Microsoft Azure subscription
- Within each network security group, a maximum of 200 access control rules can be defined
- A subnet or a virtual machine can have only a single network security group assigned to it
- You can assign a single network security group to multiple virtual machines or subnets
In addition to these restrictions and limits, a network security group access control rule can only contain a single port or protocol in its definition. Therefore, when attempting to migrate existing firewall rules from an on premise implementation of the application to a Microsoft Azure instance, be sure to count every port and protocol as a separate rule.
Also, be aware that a NSG can only be created and managed using Azure PowerShell or the Azure REST APIs. There is no user interface to manage NSG in the current Microsoft Azure Portal.
Network Security Group Scope
Network Security Groups can be assigned to a VM or a subnet. When assigned to a VM, the NSG access control rules affect all inbound traffic before it reaches the VM and all outbound traffic after it leaves the VM. When assigned to a subnet, the NSG access control rules affect all inbound traffic coming into the subnet before it reaches any VM in the subnet and all outbound traffic from any VM in the subnet after it leaves the VM.
It is possible to assign a NSG to a subnet and a VM on the same subnet. This provides two levels of access control rules and is typically used when a VM has unique traffic flow requirements than all of the other VMs on the subnet. In this case, all inbound traffic would pass through the subnet access control rules, and then the VM access control rules before it reaches the VM. On the outbound side, the reverse process happens. In other words, the traffic leaves the VM and passes through the VM specific access control rules, then passes through the subnet access control rules before it leaves the subnet.
During application of the rules, the rule with the highest priority in the rule path will affect the port and protocol, and no other rules for that port or protocol will be applied. For example, the default rule that allows outbound Internet access has a priority of 65001 which can be overridden by any rule that denies outbound Internet access, as long as the new rule has a higher priority. To be clear, a higher priority is defined using a smaller numeric value than an existing rule.
Creating a Network Security Group using PowerShell
Since there is no interface in the Microsoft Azure Portal to manage NSG, you can use PowerShell to create new network security groups. The PowerShell cmdlet that creates a NSG is called New-AzureNetworkSecurityGroup. This cmdlet requires a name and location (region), and an optional descriptive Label.
For example, to create NSGs to assign to a VM and subnet independently, you can use the following cmdlets:
New-AzureNetworkSecurityGroup -Name “MyFirstSubnetNSG” -Location uswest
-Label “My First Subnet NSG in West US”
New-AzureNetworkSecurityGroup -Name “MyFirstVMNSG” -Location uswest -Label “My First VM NSG in West US”
You must create the NSG in the same location as the virtual network which contains the subnet or VM to which you want to assign it. If desired, you can create a series of NSGs prior to creating and configuring the rules within them.
Creating a Network Security Group Rule using PowerShell
In order to create or update a rule in an NSG, you must obtain an NSG object and then you can create the rule in the inbound or outbound rule set using the 5-tuple of information.
For example, to create a rule that allows the inbound traffic on port 443 to a subnet with a priority of 400, you can use the Set-AzureNetworkSecurityRule cmdlet:
$NSG = Get-AzureNetworkSecurityGroup -Name “MyFirstSubnetNSG”
Set-AzureNetworkSecurityRule –NetworkSecurityGroup $NSG -Name ‘Inbound 443’ -Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix ‘INTERNET’ -SourcePortRange ‘*’ -DestinationAddressPrefix ‘*’ -DestinationPortRange ‘*’ -Protocol TCP
You can create additional rules, but the priority value must be unique for each rule created within the inbound and outbound rule sets of the NSG.
Assigning a Network Security Group to a Subnet
Once you have created the network security group and defined rules, you can assign the NSG to a subnet in the vNet using the Set-AzureNetworkSecurityGroupToSubnet cmdlet:
$NSG = Get-AzureNetworkSecurityGroup -Name “MyFirstSubnetNSG”
Set-AzureNetworkSecurityGroupToSubnet –NetworkSecurityGroup $NSG -VirtualNetworkName ‘VNetUSWest’ -SubnetName ‘DMZ’
Within moments after the NSG assignment to the subnet, all traffic is filtered to every VM within the subnet. You can now change or add rules to the NSG without having to reassign the NSG to the subnet.
Assigning a Network Security Group to a VM
You can assign the NSG to a VM using the Set-AzureNetworkSecurityGroupConfig cmdlet and then Update-AzureVM cmdlet:
$VM = Get-AzureVM -ServiceName “MyWebsite” -Name “FrontEndUI”
$NSG = Get-AzureNetworkSecurityGroup -Name “MyFirstVMNSG”
Set-AzureNetworkSecurityGroupConfig -NetworkSecurityGroupName “$NSG” –VM $VM
Update-AzureVM –VM $VM
Here also, within moments after the NSG assignment to the VM, all traffic to the VM is filtered. You can now change or add rules to the NSG without having to reassign the NSG to the subnet.
Retrieving the Rule Set of a Network Security Group
Once you have created a set of rules for a NSG, you can track the set of rules and associated priorities. The Get-AzureNetworkSecurityGroup cmdlet will allow you to retrieve the detail of the rule set:
Get-AzureNetworkSecurityGroup -Name “MyFirstSubnetNSG” -Detailed
This provides a detailed list of associated inbound and outbound rules sorted by priority level.
Microsoft Azure offers that ability to restrict traffic flow between subnets and VMs using Network Security Groups and access control rules. NSGs will allow a two-tier level of traffic filtering on inbound and outbound flow. However, based on current limitations to the number of network security groups created in a subscription, and the number of rules within a single NSG, the complexity of the traffic security should be carefully planned. With network security groups, Microsoft Azure provides the ability to implement a traffic flow firewall policy that is maintained at the network level instead of the OS level.