Network Security Group What Are They and Do I Want One?

You’re probably wondering how to secure your network in Azure now that you’ve made the leap for IaaS. You’ve heard about it, but What is a Network Security Group (NSG), and Why would you need one?

Network admins worldwide are used to using traditional firewalls to secure their networks, but what happens when the network is outside of your building?

That’s where Azure Network Security Groups step in.

Prerequisites

If you plan to follow along with this tutorial, you'll need the following prerequisites in place.

• An Azure subscription - a free one will work just fine here.

• A vNet - this tutorial uses an address space of 10.0.0.0/16

  Related: Introduction to Azure Networking

• Two subnets - this tutorial uses 2 subnets 10.0.0.0/24 and 10.0.1.0/24

• Two VMs - Any spec will do, but this tutorial uses Windows Server 2019. One of the VMs is connected to the default subnet, 10.0.0.0/24, and the other VM is connected to 10.0.1.0/24

What Is a Network Security Group?

All Azure VMs have at least one Network Interface Card (NIC) attached to a vNet and a subnet. Your VM connects to the network through the NIC to access File Servers and Domain Controllers resources.

Inside Azure, your data can flow between subnets within the same vNet without any restrictions, but what happens when you do not want this to happen? NSGs step in to save the day.

Understanding Where an NSG Can Help

An NSG could be defined as a firewall, but it is a basic one at best. The NSG operates at Layer 3 & 4 of the OSI model.

The NSG could be thought of as an ACL on a file or folder, as it is fairly dumb and has to be configured at the address and port number to allow data in and out.

What Do You Need To Know To Configure an NSG?

NSGs are a collection of security rules that are configured either through the GUI, PowerShell, or Azure CLI, and to configure a rule within an NSG, you must know a few key things

1. Name
2. Priority
3. Source and Destination
4. Protocol
5. Direction
6. Port Number/Range
7. Action

The rules within an NSG are evaluated "from the top down" using the smallest priority number first, going all the way to the largest number.

As soon as the combination of criteria is matched, Azure stops reviewing the rest of the rules and carries out the action that the first match dictates.

By way of an example, if a rule denies outbound traffic on port 80, but another rule, lower down in the priority, allows the traffic, the net effect is a deny will take place.

The key parts of the security rules within an NSG are:

1. Source address
2. Source port
3. Destination address
4. Destination port
5. Protocol (TCP, UDP, ICMP, ESP, AH, or Any)

These five components of a security rule are called the five-tuple hash, and every rule that exists in an NSG must contain these core pieces of information, and they must be unique.

You can't create two security rules with the same five components.

Default Security Rules Within a NSG

Azure automatically creates some default rules in each NSG to aid the flow of data across the network.

These default rules are:

Default inbound rules in an Azure Network Security Group

OUTBOUND

Default outbound rules in an Azure Network Security Group

Azure's Network Security Groups contains default rules that allow inbound and outbound traffic within your own vNet and allow traffic out to the internet.

These default rules work very well for the novice IT admin who just "wants it to work". But as soon as you grow and scale, you will immediately be thinking about controlling the flow to traffic between your VMs in the vNet.

Creating a Network Security Group

Network Security Groups (NSG) can be created within Azure, using any method that suits your admin style. Typically, this could be the GUI, PowerShell, or Azure CLI. Let's create an NSG, populate it with some basic rules, and test connectivity between some empty VMs in different subnets.

Using the GUI to Create a Network Security Group

Let's start the process off by creating two NSGs, one in each of your two subnets, and connect some VMs to them.

1. Open your favorite web browser and navigate to the Azure Portal.

2. Open the search box and search for Network Security Groups to open the NSG blade. Click on Create to start the process of creating an NSG.

   

3. Click Create new to create a Resource Group which will contain your networking resources.

   

4. Enter NSG-EUS-01 and click Review + Create to specify the name for your NSG.

   

5. Click Create on you have reviewed and confirmed that the details have been entered correctly.

After a few moments you'll receive confirmation that the NSG has been successfully deployed.

Repeat this process once more using the name NSG-EUS-02 to create a second NSG.

Attaching Your NSG to Your vNet

Now that you've got two empty NSGs and a vNet, you need to connect them. NSGs are connected to the subnet layer of the Virtual Network, so let's start this process off by connecting NSG-EUS-01 to the default subnet of VN-CORE-VNET-01.

1. Assuming that you still have your browser window open on the Azure Portal, click into NSG-EUS-01 to open the Network Security Group blade, and click on Subnets.

   

2. Click on Associate to begin the process of connecting your NSG to your vNet.

   

3. Click in Virtual network and select VN-CORE-VNET-01 to connect the vNet, then select default as the subnet before clicking OK to complete.

   

4. Next, open NSG-EUS-02 blade, click subnets —> Associate —> VN-CORE-VNET-01 —> second_subnet —> OK to connect your second NSG into the second subnet.

Adding test rules to your Network Security Group

Now that you have your two NSGs associated to the relevant subnets, it's time to add a few basic rules. These rules are for demonstration purposes only and should NEVER be used in production unless you actually want to deny connectivity between two subnets as well as opening up a huge security weakness in your network.

With that warning in mind, let's continue.

1. Click into NSG-EUS-01 —> Inbound Security Rules —> Add to start the process of adding a new security rule.

2. Add IP Addresses —> 10.0.1.0/24 —> IP Addresses —> 10.0.0.0/24

   

3. Click ICMP —> Deny —> Enter a name for the rule Deny_Ping and a descriptive description. Click Add to complete this blade.

   

4. Let's repeat the process, but this time we're adding a dangerous rule. Click Add and enter 3389 to the destination port range, and TCP protocol.

   

5. Click Allow, set the priority as 110, Give the rule a name of Allow_RDP and a description reminding yourself NOT TO DO THIS IN PRODUCTION... I've probably stated that enough now.

   

6. Review the resultant security rules noting the warning triangle next to the dangerous rule.

Let's repeat the same process now, but only add the dangerous rule 110 to NSG-EUS-02.

Confirming that the NSG works

Now that you've spent the time connecting your vNets to your NSGs, it finally comes time to test the connectivity between the subnets. To do this successfully, create two VMs and place each of them in a different subnet.

Testing connectivity between VMs

The screenshots below show RDP connections to two VMs at the same time. The VM on the left is VM01, and the VM on the right is imaginatively named VM02.

Let's start off by confirming that there's nothing up my sleeve. Both screenshots show the same relative commands. They both confirm their hostname, they both issue with ipconfig command and then use this information to ping the other.

Adding an extra deny rule

Let's confirm that there's nothing untoward happening here by adding an extra rule to one of the NSGs and retest the same ping command.

1. Click back into the Azure Portal and open NSG-EUS-02. Click Inbound Security Rules —> to start the process of adding another security rule.

2. Add IP Addresses —> 10.0.0.0/24 —> IP Addresses —> 10.0.1.0/24

   

3. Click ICMP —> Deny —> Enter a name for the rule Deny_Ping and a descriptive description. Click Add to complete this blade.

   

4. Now, switch back to your two RDP connections, focus on VM01 and click the up arrow to reissue that last command.

   

   You'll see that the connection that did once successfully get a response from the other VM is now failing.

   You can test this further by going back into NSG-EUS-01 and deleting the security to deny ping traffic. Repeat the ping tests and note the success.

Removing the Uneeded Resources

Now that you've completed the tutorial, it's important that you now secure your environment, as well as your wallet, by deleting the VMs and the associated NSGs due to the wide-open security hole that you included.

Conclusion

In this tutorial, you've learned the basics of what Network Security Groups are, how they relate to and are connected to, the Virtual Network and how they work on a basic level. But there's still a lot more that you can do with NSGs.

Now that you have created your first set of NSGs, why not extend the use of them to implement a rudimentary DMZ? Create some additional subnets and NSGs and block all of the traffic except for a particular port number? The options are limitless.