Secure Your Azure Network Using NSGs and ASGs

What are Azure NSGs (Network Security Groups)? 

Azure Network Security Groups (NSGs) are used to filter network traffic to and from Azure resources in an Azure virtual network (Vnet). In simple terms, it’s used for rules that your network follows. 

A NSG contains a group of security rules that restrict or permit inbound network traffic to or outbound network traffic access to Azure resources. You can specify the source and destination, port, and protocol for each rule. 

What are NSGs used for? 

Network Security Groups (NSGs) in Azure are used to control network traffic at the TCP/IP level. They isolate specific resources in their container and also enable route management, allowing you to control which traffic is allowed in and which is allowed out. 

Furthermore, they are the first line of defence. You can't rely on NGS's only, you need Application Layer Gateway (ALG) to inspect traffic that you allow with NSG's.

Understanding Network Security Groups in Azure 

In Azure, network security groups can be applied at the subnet level, VM level or both. This determines how traffic flows to your resources and which traffic is blocked. 

NSG Placement and Traffic Control 

Imagine you have a standard Azure Virtual Network (VNet) with three subnets, each of which receives traffic from the public internet.

You don’t want unrestricted access; not only do attackers frequently scan IP addresses for openings, but who wants to expose everything on their networks? 

To protect the Azure VNet and resources, we can configure NSGs in different ways to permit traffic between the internet and resources, for example, over TCP port 80. This is shown in the diagram below: 

• VM1: NSGs are chained; NSG 1 is attached to Subnet 1 and evaluates all traffic from the internet to that subnet. NSG 2 is attached to VM1 and only evaluates the traffic allowed through by NSG 1. 
• VM2: For VM2, there's only NSG 1 as the VM doesn't have a network security group attached specifically.  
• VM3: VM3 in Subnet 2 has NSG 2 associated with it but at the subnet doesn't have any.  
• VM4: VM4 is left unprotected, at least when it comes to NSGs. All traffic will reach VM4.  

This example shows how NSG placement impacts security. Associating NSGs with subnets, VMs, or both determines which traffic gets filtered (and which doesn’t). 

Securing Subnets with NSGs 

Breaking down your network security groups into subnets allows NSGs to manage traffic between different tiers of your network.  

A typical configuration might look like this, with 3 subnets: 

Each subnet has a network security group, which defines how traffic is going to go in and out. 

1. Web tier: It’s public-facing, so your customers can reach your website.
2. Business tier: Talks to those web servers — for e.g. if you have a bunch of VMs doing application tasks, you don't want your clients to be able to see this tier directly, so you would have a network security group only to allow traffic from the web servers (whether it’s APIs or whatever you are using it for in your business). 
3. Data tier: Holds sensitive resources like SQL databases; fully isolated, only accessible through controlled paths like a Bastion host or jump box. 

The way you set up your network security groups is based on your business functionality. 

When designing your virtual network, ensure that you create subnets within it and place resources with the same business function in those subnets.  

Follow a business principle for each tier (like business tiers limited to internal communication, and data tiers kept isolated).

Security Rules of NSG 

Network security groups protect resources by the following eight rules you have to configure: 

Now, rules are processed one after another, according to their priority. And when one matches the traffic, the processing stops. You can create as many rules as you want, up to a thousand, but it can quickly get overwhelming. 

NSGs vs Firewalls 

At this point, you might wonder how Azure NSGs are different from Azure firewalls and when you should use each. Simply put: 

• Network Security Groups (NSGs): NSGs are meant for filtering traffic within a single virtual network. Use NSGs for VNets and individual VMs.  
• Firewalls: Used to protect networks across applications, networks and even subscriptions. Use firewalls for large infrastructure applications and projects. 

What are Application Security Groups? 

Azure Application Security Groups help simplify NSG management. Without ASGs, you would need to assign static IPs to each server in your rules manually. 

Consider again the scenario from before, with a multi-tier setup (with web, business, and data tiers).  

Previous example 

In this setup, the final configuration allows internet traffic to reach the web services while blocking access to the logic server from outside. Only web applications can connect to the logic server, which handles business processes. Similarly, internet traffic to the database server is restricted, allowing only the business logic servers to communicate with it, while direct access from the web servers is blocked. 

This creates a precise flow: Internet traffic only reaches our web servers → web servers communicate with the business logic servers → business logic servers communicate with the database 

Yet, achieving this using NSGs requires the use of static IPs for those machines in each rule and managing this manually, which is a lot of effort. You can solve this challenge by using Application Security Groups (ASGs).  

With ASGs, you can group your servers by role or business purpose and reference these groups in your network security rules, rather than individual IP addresses. This saves a significant amount of time and manual work. 

How to create NSGs in Azure? 

Creating NSGs in Azure is not rocket-science. Let’s show you how to create NSGs in the Azure Portal, step-by-step.

1. First, head to the Azure Portal and search NSG and open it. 

2. Click on create:

3. Select your resource group, and provide a name and pick your region:

4. You should see the following:

5. Then, click on create and you should see the following:

And that’s all. You’ve now created a NSG in Azure through the portal. 

To see all your NSGs, search for Network security group and you should find your NSGs: 

You can see the details of the NSG: 

Next, assign a subnet to link with this NSG. On the left-hand menu, click Subnets. 

To associate the NSG, click + Associate, then choose your virtual network and the specific subnet. Click OK to complete the association.

Create and Configure NSG Rules 

The default rules allow: 

• Inbound traffic from Vnets and Azure load balancers, while blocking all other incoming traffic.  
• Default outbound rules allow access to other virtual networks and the internet but deny everything else. 

For many scenarios, this setup is too permissive. We need more control over who can access the web VMs, which is why we’ll allow web traffic from the client VNet but block all other incoming web traffic. 

To do this, we must modify the inbound rules for this example: 

Create new rules to allow inbound web traffic on ports 80 and 443: 

1. Go to Inbound Security Rules and click Add a Rule. 
2. Select a Source IP address, either a single IP or a block of IPs. Add the block assigned to your client subnet. 
3. Leave Source Port Range as any. Leave Destination as any. 
4. Set Service to HTTP, which automatically selects Destination Port Range 80.
   
    
5. Keep Action as Allow and change the Priority to 1000. Priorities can range from 100 to 4096. Leave gaps to insert future rules if needed.
6. We can name the rule Allow Client HTTP Inbound, add a description (optional), and click Add. 
   

Repeat the same process for HTTPS (Port 443) with a slightly higher priority, e.g., 1010. 

Until now, we haven’t accomplished anything yet. Technically, traffic to ports 80 and 443 from our subnet is already allowed by rule 65000, which permits all ports and protocols between v-nets.  

Hence, we now need blocking rules: 

1. Add a new rule. 
2. Set source and destination to Any. 
3. Select service as HTTP, action as Deny, and keep the priority below your allow rules. 
   
4. Add another rule for HTTPS traffic with the same settings. 

Rules are processed top to bottom and stop when matched. This setup allows web traffic from the client subnet while blocking all other traffic. Without the deny rules, default rules would allow traffic from any VNet. 

This example shows how to prioritise NSG rules to allow and block traffic effectively 

Check out Microsoft’s documentation for creating NSGs in Azure for more.