Share via

Introduction to Network Security Groups in Azure

  • Article

Recently submitting this as an article and wanted to share it on my blog in case it might help anyone.

Back in November of 2014 Microsoft announced the availability of Network Security Groups. In my day job I still find many people not knowing about Network Security Groups or not using them. Prior to network security groups all Access Control Rules (ACLs) were defined on the virtual machine itself. Network Security Groups came in providing a way to segment within a Virtual Network and control traffic that comes in and out of Virtual Machines but also subnets. This is critical when talking about multi-tiered applications. You can see the general idea in Figure 1. In this example the end user has access through the internet to the DMZ Subnet. This subnet would contain your front end web applications that the end users connect to. Data into this subnet would be filtered within an NSG, most likely you would allow http, and https traffic into this subnet, but not allow other ports that would not be necessary. From there the systems in the DMZ subnet can talk to the application subnet systems, these are your application servers that host your business processes and logic and the applications that talk directly to the database. Finally, the systems in the Application Subnet can talk to the systems in the data subnet, this would be port 1433 for example to talk to a SQL backend. In this diagram we show that there is blocked traffic between the DMZ subnet and the data subnet, this keeps the different components of the application separated. This also ensures that end users can not directly talk to the systems in the data subnet.

clip_image002

Figure 1 NSG Example

The rules defined on an NSG are comprised of multiple components:

Source IP – This is a single IP or a range subnet of IPs in CIDR notation that the traffic will be allowed or denied from.

Source Port – A single port or multiple ports from the source that will be allowed or denied

Destination IP - This is a single IP or a range subnet of IPs in CIDR notation that the traffic will be allowed or denied to.

Destination Port – A single port or multiple ports to the destination that will be allowed or denied

Protocol – The protocol to be allowed or denied (i.e TCP or UDP)

Priority – This is the order in which the rule will be applied, similar to Group Policy Objects if you are familiar with those.

These components along with traffic direction and access will be defined on all of the rules configured within a Network Security Group.

One thing to note with NSG’s is that are tied to a region so if you have resources in multiple regions you must create multiple NSGs.

Ok so now that you know a little bit about Network Security Groups, let’s create one!

First thing we must do is make sure we have the latest Azure PowerShell cmdlets which can be downloaded from here. https://azure.microsoft.com/en-us/downloads/. At the time of writing this article the version should be 1.0.4.

Another item to keep in mind while following these instructions is I have opted to leverage Azure Resource Manager or ARM to deploy my resources, this is the new format that will be used and is taking the place of the older Service Management cmdlets. These cmdlets are denoted with “RM” in the cmdlet. (i.e Add-AzureRMAccount)

Once the module has been downloaded it is time to start making some magic. Run the following PowerShell commands in a script or PowerShell ISE. You will replace the Subscription name with your own subscription name. This PowerShell code will launch a login screen and allow you to login. One thing to keep in mind this is specific for Public Azure, if you are using Azure for Government you will have to add the Environment yourself (not covered in this article).

# Imports Azure Module

Import-Module Azure -Force

# Gets the environment for Public Azure

$env = Get-AzureRMEnvironment -Name AzureCloud

# Prompts for credentials based on that environment

Add-AzureRMAccount -Environment $env

# Selects the subscription to use.

Select-AzureRMSubscription -SubscriptionName "<Your Subscription Name Here>"

Now that you are in PowerShell and logged into your subscription we can continue, first thing we should do is create a Resource Group. Give the resource group a name and choose a location, this location as mentioned prior is important as the NSG we create will need to live in the same region.

# Creates a Resource Group to put our NSG in.

New-AzureRmResourceGroup -Name "ExampleVNETRG" -Location "East US"

Now we will create the Virtual Network, to keep your Azure environment clean we will create a new Virtual Network in our new resource group so it can be easily removed once you are done. Define your subnets, in this case my Virtual Network only has two subnets. The second command this piece of code does it create the virtual network with the subnets defined in the Subnet configs.

# Creates config for sample Subnet

$subnet1 = New-AzureRmVirtualNetworkSubnetConfig -Name "Subnet1" `

-AddressPrefix "192.168.1.0/25" `

$subnet2 = New-AzureRmVirtualNetworkSubnetConfig -Name "Subnet2" `

-AddressPrefix "192.168.1.128/25" `

# Creates Virtual Network in Resource Group with subnet defined prior

New-AzureRmVirtualNetwork -Name ExampleVnet `

-ResourceGroupName ExampleVNETRG `

-Location "East US" `

-AddressPrefix "192.168.1.0/24" `

-Subnet $subnet1,$subnet2

Now we have our Virtual Network defined with two different subnets we can start to work on our Network Security Group rules. We will create 2 rules one for http traffic and one for https traffic, rules work for individual ports or port ranges, hence the reason for the two rules.

#First rule for http traffic

$httprule = New-AzureRmNetworkSecurityRuleConfig `

-Name "FrontEnd_HTTP" `

-Description "HTTP Exception for Web frontends" `

-Protocol Tcp `

-SourcePortRange "80" `

-DestinationPortRange "80" `

-SourceAddressPrefix "*" `

-DestinationAddressPrefix "192.168.1.0/25" `

-Access Allow `

-Direction Inbound `

-Priority 200

# Second rule for https traffic

$httpsrule = New-AzureRmNetworkSecurityRuleConfig `

-Name "FrontEnd_HTTPS" `

-Description "HTTPS Exception for Web frontends" `

-Protocol Tcp `

-SourcePortRange "443" `

-DestinationPortRange "443" `

-SourceAddressPrefix "*" `

-DestinationAddressPrefix "192.168.1.0/25" `

-Access Allow `

-Direction Inbound `

-Priority 201

Now that we have the configs created for the 2 rules we can create the NSG with the two security rules defined prior with the code below.

# Creates a NSG based on the rules defined prior

$nsg = New-AzureRmNetworkSecurityGroup -ResourceGroupName ExampleVNETRG -Location "East US" -Name "NSG-Example" `

-SecurityRules $httprule,$httpsrule

Creating the NSG is just one step we also have to apply the NSG to a subnet. The below code grabs the Virtual Network we created earlier and applies the NSG to the Virtual network, specifically Subnet1.

# Gets the Virtual network and applies the rules to the subnet created earlier.

$vnet = Get-AzureRmVirtualNetwork -ResourceGroupName ExampleVNETRG -Name ExampleVnet

Set-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name "Subnet1" `

-AddressPrefix 192.168.1.0/24 -NetworkSecurityGroup $nsg

The changes to the virtual network we created in the previous step just made the changes offline, we not have to update the virtual network with the following command

# Updates the Virtual Network in Azure

Set-AzureRmVirtualNetwork -VirtualNetwork $vnet

And that’s it, now any virtual machine that you put in Subnet1 will get the rules we defined above, you could add more rules and apply them later. Keep in mind if you define endpoints on your virtual machine NSG rules will override them, so for instance if you open up port 80 on an endpoint in a virtual machine, and have an NSG applied to the VM or the Subnet the VM is in and there is no allow rule for 80 traffic will not make it to the virtual machine.

Now that we have created the resources, let’s take a quick look at our Resource Group in the new Azure Portal. Here you can see the Resource Group with the NSG.

clip_image004

And next if we look into our NSG and look at the inbound rules and can see the rules we created.

clip_image006

Once you are done you can easily remove everything we created by running the following command. This is one of the best parts of deploying resources with Resource Manager, is the ease of removing and adding resources.

Remove-AzureRmResourceGroup -Name ExampleVNETRG -Force

Comments

  • Anonymous
    April 10, 2016
    Great article. Thanks. Question about RDP. Can we change the source port on RDP to a random port, then leave the destination as 3389 to minimize attacks on port 3389? Or does it not work like that? Thanks.
  • Anonymous
    April 10, 2016
    Yeah that is a great point. And yes you can and would ultimately suggest you do. Many folks I am sure probe 3389. That is the default setup for rdp acls on the virtual machine.
  • Anonymous
    April 11, 2016
    Thanks George. For RDP on VMs, does the RDP port in Windows registry have to be changed first? I tried making an inbound rule with a random source port, and destination port 3389 and it did not work. Only source port * works.
  • Anonymous
    April 11, 2016
    Apologize, I led you astray.. I spoke without thinking about it.. So in v1 times you changed endpoints on the vm itself.. In v2 arm world you would need to create a load balancer, and create a nat rule that has your source port as whatever you want and the destination be 3389. In the NSG you will already have a allow load balancer rules included so no extra rules needed, though you could add more rules if need be. Does this make sense.. I needed to be much clearer.. so first your vm needs to be added to an availability set even it its by itself. then you need to create a load balancer and create a nat rule that converts your source to destination.. and assign it to the availability set / vm. And leave the standard AllowAzureLoadBalancerInBound rule alone or lock it down to the port you want.
  • Anonymous
    April 11, 2016
    Hi George, this is great. Thanks for the extra information!
  • Anonymous
    April 11, 2016
    Hi George, I got it working with your steps listed, with the additional step of creating another NSG incoming rule with the source as Internet, and port as *. I got the tip fromhttps://azure.microsoft.com/en-us/documentation/articles/virtual-networks-nsg/ "Notice how the source address range for this rule is Internet, and not the VIP for the load balancer; the source port is ***, not 500001. Do not get confused between NAT rules/load balancing rules and NSG rules. The NSG rules are always related to the original source and final destination of traffic, NOT the load balancer between the two."

    Thanks.
  • Anonymous
    April 11, 2016
    Great to hear Darren, I will write up something to talk about all of this as its a very confusing subject. On the link you posted I am going to do more testing but I have never seen the need to add a * to * internet rule. My current setup has my load balancer with my nat rule .. and my nsg only has allowvnet, allowlb and deny all inbound and it works perfectly.. and I don't have the whole internet having access to my nsg.. Ill dig and try to replicate but I have no issues without defining the open internet rule you stated.
  • Anonymous
    April 12, 2016
    Nice to see you posting Darren! I love those kinds of insights from you! That was totally useful! Keep it, going. Regards,http://dslrbiz.com">Song Zhang
  • Anonymous
    April 12, 2016


    yours idea is really good and innovative , these resources are really awesome thanks for sharing those information and i got more in formation about this concept.