Using PowerShell to create Azure NSGs

Introduction

Microsoft Azure is quickly becoming the platform of choice for deploying virtual machines in the cloud. But early versions of Azure infrastructure-as-a-service (IaaS) offerings were somewhat clunky as far as configuration was concerned, especially in the area of access control. As a result Microsoft has introduced a better way of configuring secure access to Azure virtual machines. This new approach is called Network Security Groups (NSGs) and although NSGs have been around awhile now they’re still not very well understood, especially by customers who are still using “classic” Azure virtual machines.

This article is intended to remedy this lack of understanding concerning NSGs, and to accomplish this feat I’ve asked George Wallace, an expert at Microsoft, to walk us through what NSGs are and how you can create them. George is a Consultant with Microsoft focusing on all things cloud. He has worked both on the operational side and Engineering side of technology including but not limited to System Center and Azure. George has a development background as focusing on .Net and JavaScript. George has been regularly speaking at internal Microsoft conferences. You can find other posts on many different topics like Cloud, System Center and Azure on his blog. Let’s now hear from George…

Why Network Security Groups?

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.

An NSG example

You can see the general idea in Figure 1 below. 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 an 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.

Image
Figure 1: NSG Example

NSG components

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

  • 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.

Creating an NSG

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 https://azure.microsoft.com/en-us/downloads/. At the time of writing this article the version should be 1.0.4.

Another thing to keep in mind while following these instructions is I have opted to leverage Azure Resource Manager (ARM) to deploy my resources. This is the new format that will be taking the place of the older Service Management cmdlets. The new ARM 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 below PowerShell commands in a script or PowerShell ISE. You should 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, so 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”

Next 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 is 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

We now have our Virtual Network defined with two different subnets so we can start to work on our Network Security Group rules. We will create two 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 two 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, and 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.

Examining the result

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

Image
Figure 2: The Resource Group with the NSG

And next if we look into our NSG and look at the inbound rules and can see the rules we created here in Figure 3:

Image
Figure 3: The rules we created

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

Additional Resources

For more information on Azure NSGs see the following resources:

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top