
close
close
This post will show you how to use Azure Resource Manager (ARM) or a CSP subscription to deploy network security and policy enforcement in the form of network security groups (NSGs).
I recently wrote another post, “What Are Network Security Groups in Azure Resource Manager?” I went into great detail about what an NSG is and how it works, but here is a quick reminder.
An NSG is a collection of rules that describe what traffic is allowed in our out. The rules specify source and destination address, the protocol, and the source and destination port. We can associate an NSG with a subnet (best practice) which affects all virtual machines on a subnet. Or we can associate an NSG with a virtual NIC (not a virtual machine), which affects that connection of a virtual machine.
advertisment
I have configured a small environment in Azure with a single subnet in a virtual network in a resource group called web-rg. There are two virtual machines, each with a single virtual NIC. Both machines will be web servers. I am going to create an NSG that I will assign to the subnet that will:
Open the Azure Portal (https://portal.azure.com) and sign in. Click New, search for “network security group”, select Network Security Group (published by Microsoft in Networking), and click Create. A blade will open to allow you to create a new NSG.
You will have to enter some information:
Creating a new network security group in Azure ARM [Image Credit: Aidan Finn]
The NSG should be ready to work with after a couple of minutes. Open the NSG and go to All Settings. There you can see options for Inbound Security Rules (inbound traffic) and Outbound Security Rules (outbound traffic). Click on Inbound Security Rules.
The settings of an Azure ARM network security group (NSG) [Image Credit: Aidan Finn]
The default inbound rules in an Azure network security group (NSG) [Image Credit: Aidan Finn]
advertisment
In the settings of the NSG you can see options for associating the policy with network interfaces (machine virtual NICs) or (virtual network) subnets. It is a best practice to associate NSGs with subnets, so I will do that. Click Subnets, click Associate, choose a virtual network, and then select the subnet that you want to associate the NSG with.
Associating an Azure ARM NSG with a virtual network subnet [Image Credit: Aidan Finn]
The default DenyAllInBound rule is preventing my webservers from being accessible on the Internet. I need to allow access for HTTP and HTTPS traffic from the Internet.
Open the settings of the NSG, click Inbound Security Rules, and click Add. You can configure a new inbound security rule with the blade that opens.
My first rule will allow all TCP traffic from the Internet that is destined to TCP 80 (HTTP) on my virtual network. Note how Source and Destination allow options to:
I give the rule a weight of 100, which is the highest priority and outweighs and overrides the default rules. This means that TCP 80 is allowed in (under the above conditions), but all other inbound traffic is blocked.
Allowing TCP 80 inbound in an Azure network security group [Image Credit: Aidan Finn]
The new inbound rules on the Azure NSG [Image Credit: Aidan Finn]
Return to the settings of the NSG, click Outbound Security Rules, and click Add to create an outbound rule to control what traffic can leave the web server subnet. I will use this kind of rule to prevent traffic leaving the web servers, for example, data leakage after an attack or browsing by admins from the servers.
Note: this rule is a sledge hammer and you should evaluate, test, and question the usage of this kind of rule.
The rule (priority of 100) overrides the default AllInternetOutBound rule (priority of 65001). The destination (tag of Internet) to all ports from the source (tag of VirtualNetwork) on all ports and protocols is denied, as shown below.
A new “block all traffic to the Internet” rule in an Azure NSG [Image Credit: Aidan Finn]
advertisment
The NSG has been associated with the subnet that the web servers are connected to. If I browse to the web servers using HTTP or HTTPS (if the servers are configured for HTTPS), then I can still browse the website, despite blocking all traffic from the web servers to the Internet (stateful inspection).
I can still, thanks to my TCP 3389 inbound rule, remote desktop into my virtual machines. But when I do log in, I quickly find out that I cannot access the Internet from my virtual machines. I tried to browse the Internet from one of the web servers in the below screenshot.
The NSG blocks traffic to the Internet that is sourced from my virtual machines [Image Credit: Aidan Finn]
More from Aidan Finn
advertisment
Petri Newsletters
Whether it’s Security or Cloud Computing, we have the know-how for you. Sign up for our newsletters here.
advertisment
More in Cloud Computing
Use Azure ExpressRoute Private Peering & Azure Virtual WAN to Connect Privately to Microsoft 365
Apr 21, 2022 | Flo Fox
Microsoft to Make Changes to Cloud Licensing Restrictions after Customer Complaints
Apr 18, 2022 | Rabia Noureen
Most popular on petri
Log in to save content to your profile.
Article saved!
Access saved content from your profile page. View Saved
Join The Conversation
Create a free account today to participate in forum conversations, comment on posts and more.
Copyright ©2019 BWW Media Group