Secure Azure Virtual Network using Network Security Groups

1 Jun

The way that Network Virtualization is implemented in Hyper-V and subsequently in Microsoft Azure IaaS, enables explicitly the Routing between Virtual Subnets. This is the reason why the traffic between Virtual Subnets, that are part of the same Virtual Network, is unrestricted unless we have applied Network Security Groups.

Network Security Groups Is a way to control traffic between Virtual Subnets of an Azure Virtual Network as well as the Internet. Moreover, Network Security Groups provide segmentation within Azure Virtual Network, by applying rules according to our needs and design.

Until Network Security Groups became Generally Available, the only way to control traffic was endpoint based Access Control Lists. By applying ACLs to a Virtual Machine’s public endpoint, we have a way to control the ingress traffic to this port of this particular Virtual Machine. Network Security Groups takes this capability a step ahead and enables us to control all inbound as well as outbound traffic of a Virtual Machine or a Virtual Subnet.

How does a Network Security Group (NSG) work ?

A Network Security Group has a name and a descriptive label and is associated to an Azure Region. It contains Inbound and Outbound traffic rules and can be applied to a Virtual Machine, a Virtual Subnet or both.

NSG-01

Associating an NSG to a VM – When an NSG is directly associated to a VM, the Network access rules in the NSG are directly applied to all traffic that is destined to the VM.

Associating an NSG to a Subnet – When an NSG is associated to a subnet, the Network access rules in the NSG are applied to all the VMs in the subnet.

Associating an NSG to a Subnet and a VM – It is possible that you can associate an NSG to a VM and a different NSG to the subnet where the VM resides. This is supported and in this case the VM gets two layers of protection. On the Inbound traffic the packet goes through the access rules specified in the subnet followed by rules in the VM and in the Outbound case it goes through the rules specified in the VM first before going through the rules specified in the subnet.

Priorities and Default Rules

As we mentioned above, an NSG contains Inbound and Outbound traffic Rules that we create according to our needs. These Rules are processed in the order of priority. Rules with lower priority number are processed before those with higher priority number and so on. Default rules are also there for a Network Security Group. These rules cannot be deleted but they have the lowest priority and, normally, they will be overridden.

Azure Virtual Network

Let’s assume that we want to deploy a three-tier application in Microsoft Azure IaaS offering. In this case, we create a Virtual Network as illustrated in the following figure:

By default, Virtual Machines that are deployed to the Virtual Subnets (Front, App, DB) can communicate to each other and can have access to the Internet. This default behavior in some cases is not enough and Security and Access Control needs to be applied. By using Network Security Groups, the Virtual Network’s security is strengthened and Access Control Rules to inbound and outbound traffic are enforced.

Create and use Network Security Groups – Step-By-Step

As a demonstration, we are going to use the Virtual Network that we’ve created in the previous example. Let’s assume that we want to implement a more restrictive scenario, like the one shown in the following figure:

In order to achieve the designed security and access control we should create traffic rules, that they can be summarized in the following table:

[table id=1 /]

Network Security Groups can be created and applied using PowerShell and REST API. In this example we are going to use PowerShell. As always, we will use the latest PowerShell Azure Module which can be downloaded from Azure Portal.

Using the following script we can create and apply Access Control Rules and Network Security Groups

# Setting the variables
$AzureRegion = 'West Europe'
$AzureVNET = 'Three-Tier-VNET'

# ---------------------Database Subnet Rules -------------------------
# Create a Network Security Group for Database Subnet
New-AzureNetworkSecurityGroup -Name "DB-NSG" -Location $AzureRegion -Label "NSG for Database Subnet of $AzureVNET" 

# Adding a Rule to deny Inbound TCP traffic from Front End Subnet
Get-AzureNetworkSecurityGroup -Name "DB-NSG" | Set-AzureNetworkSecurityRule -Name FEDeny -Type Inbound -Priority 100 `
   -Action Deny -SourceAddressPrefix '172.16.1.0/24'  -SourcePortRange '*' -DestinationAddressPrefix '172.16.3.0/24' `
   -DestinationPortRange '*' -Protocol TCP

# Adding a Rule to allow Inbound SQL (TCP/1433) traffic from Application Subnet
Get-AzureNetworkSecurityGroup -Name "DB-NSG" | Set-AzureNetworkSecurityRule -Name SQL -Type Inbound -Priority 110 `
   -Action Allow -SourceAddressPrefix '172.16.2.0/24'  -SourcePortRange '*' -DestinationAddressPrefix '172.16.3.0/24' `
   -DestinationPortRange '1433' -Protocol TCP

# Adding a Rule to allow Inbound RDP (TCP/3389) traffic from Internet, for management
Get-AzureNetworkSecurityGroup -Name "DB-NSG" | Set-AzureNetworkSecurityRule -Name RDP -Type Inbound -Priority 120 `
   -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '172.16.3.0/24' `
   -DestinationPortRange '3389' -Protocol TCP
   
# Assign the Network Security Group to Database Subnet
Get-AzureNetworkSecurityGroup -Name "DB-NSG" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName $AzureVNET -SubnetName "Database"

# Network Security Group Rules and details
Get-AzureNetworkSecurityGroup -Name "DB-NSG" -Detailed

# ---------------------Application Subnet Rules -------------------------

#Create a Network Security Group for Application Subnet
New-AzureNetworkSecurityGroup -Name "APP-NSG" -Location $AzureRegion -Label "NSG for Application Subnet of $AzureVNET" 

# Adding a Rule to deny Inbound TCP traffic from Database Subnet
Get-AzureNetworkSecurityGroup -Name "APP-NSG" | Set-AzureNetworkSecurityRule -Name DBDeny -Type Inbound -Priority 100 `
   -Action Deny -SourceAddressPrefix '172.16.3.0/24'  -SourcePortRange '*' -DestinationAddressPrefix '172.16.2.0/24' `
   -DestinationPortRange '*' -Protocol TCP

# Adding a Rule to allow Inbound WEB (TCP/80) traffic from Front End Subnet
Get-AzureNetworkSecurityGroup -Name "APP-NSG" | Set-AzureNetworkSecurityRule -Name WEB -Type Inbound -Priority 110 `
   -Action Allow -SourceAddressPrefix '172.16.1.0/24'  -SourcePortRange '*' -DestinationAddressPrefix '172.16.2.0/24' `
   -DestinationPortRange '80' -Protocol TCP

# Adding a Rule to allow Inbound RDP (TCP/3389) traffic from Internet, for management
Get-AzureNetworkSecurityGroup -Name "APP-NSG" | Set-AzureNetworkSecurityRule -Name RDP -Type Inbound -Priority 120 `
   -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '172.16.2.0/24' `
   -DestinationPortRange '3389' -Protocol TCP
   
# Assign the Network Security Group to Database Subnet
Get-AzureNetworkSecurityGroup -Name "APP-NSG" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName $AzureVNET -SubnetName "Application"

# Network Security Group Rules and details
Get-AzureNetworkSecurityGroup -Name "APP-NSG" -Detailed

We can get all the details about applied Network Security Groups using the command:

Get-AzureNetworkSecurityGroup -Name "DB-NSG" -Detailed

NSG-05

Get-AzureNetworkSecurityGroup -Name "APP-NSG" -Detailed

NSG-06

References

 

2 Replies to “Secure Azure Virtual Network using Network Security Groups

  1. Hi,
    In the table mid-way through your article, where you summarize the access rules, I believe you have the values on row 3 (where the first column is ‘database subnet’) switched. Database subnet to Frontend subnet should be DENY all. Database subnet to Application subnet should be ALLOW all. Right now it says the opposite.

  2. Hi Lorenzo,

    You have absolutely right on this. I edit the table and now the rules are as they should.

    Thanks for the remark and the correction.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.