Azure Network Security Group—A look back and a look forward.

Hello, and welcome to my blog post! As we enter the new year, I want to take a moment to wish you a Happy New Year 2025! This post will explore Azure Network Security Groups (NSGs), their functions, significance, and some interesting trivia surrounding them. I hope this blog will be shorter than my usual one. We’ll discuss how NSGs work, the key features they offer, and why they are critical for maintaining secure and efficient cloud environments.

Azure Network Security Groups (NSGs) are crucial in managing and controlling network traffic within Microsoft Azure virtual networks. As a virtual firewall, NSGs regulate both inbound and outbound traffic to Azure resources. NSG was introduced in 2014, and they have been pivotal in enhancing network security for nearly a decade.

NSGs enable segmentation within a Virtual Network (VNet) and allow users to gain complete control over the traffic that flows to and from virtual machines (VMs) within that VNet. By applying a set of network access control lists (ACLs). These rules can be applied to all traffic entering or exiting either a subnet or the network interface of a VM. NSGs can be associated with individual subnets or VMs, enhancing your cloud infrastructure’s security posture.

Network Security Groups provide control over network traffic flowing in and out of your services running in Azure cloud.

  • The rules in NSG contains a five tuple framework.
    • NSGs can enforce rules based on a comprehensive five-tuple framework, which includes source IP address, source port, destination IP address, destination port, and protocol.
  • Access Control Rules
    • Description and Rule name for network traffic rules in NSG. This helps on identifying the rules with Definition and purpose.
    • Prioirity – NSG rules are processed in priority order; the lower the number, the higher the priority.
  • Types of rules
    • Ingress – On the ingress path, rules are applied before traffic enters the VM.
    • Egress –  On the egress path, rules are applied after traffic leaves the VM
  • NSG Association
    • Association with individual virtual machines.
    • Association with subnets in the same region.

All Network Security Group (NSG) is equipped with predefined rules that facilitate seamless communication within the Virtual Network, ensuring that resources can interact without hindrance. Additionally, these default rules permit outbound traffic to the Internet, allowing for necessary external connections. Users can create and customize their own rules, which can override the default settings, providing greater control over the flow of traffic and enhancing security according to specific requirements.

The rules in Network Security Groups (NSG) are stateful, meaning that if an inbound rule permits traffic on a particular port, it is unnecessary to establish a corresponding outbound rule for that same port for packets to flow. This simplifies configuration, as the stateful nature of NSGs automatically allows return traffic without additional outbound rules..

  • VMs or Resources of NSG when associated with a subnet has effect on all VMs or resoruces within the subnet
  • While update or change of rules in NSG will be immediate application of changes and it affect all VMs or resources in the subnet at once.
  • Each rule has a priority (from 100 to 4096). Lower numbers indicate higher priority, meaning rules are evaluated in ascending order.
  • Users can define custom rules specifying priority, source, destination, protocol, port, and action (allow or deny).
  • NSG has a feature called service tags, which helps to simplify rule creation by representing Azure services (e.g., Storage, SQL) without needing IP addresses.

Lets take an example of below NSG rules:

The first rule in the Network Security Group (NSG) is configured to block Remote Desktop traffic on port 3389, regardless of the protocol. The rule name is : Deny-Any-RDP-Inbound.
This means that if anyone attempts to access the windows virtual machines (VMs) from a subnet where this NSG is applied, the VMs will be unable to use the Remote Desktop Protocol (RDP). Specifically, Rule 110 in the NSG is responsible for blocking this traffic.

  1. When both a Network Security Group (NSG) and a User-Defined Route (UDR) are applied in a subnet, NSG inbound rules are processed for incoming traffic. NSG outbound rules are processed for outgoing traffic and then the user-defined route rules.
  2. VMs in the same subnet can communicate by default due to a default NSG rule. If you add a rule to NSG that denies all traffic, VMs in the subnet cannot communicate.
  3. All network traffic is allowed from VMs or resources when a network security group isn’t associated with the network interface attached to the virtual machine or Subnet.
  4. When applying Network Security Groups (NSGs) to both a network adapter (NIC) and a subnet for a virtual machine (VM), the processing order is as follows:
    • The subnet-level NSG is first evaluated for inbound traffic, followed by the NIC-level NSG.
    • The NIC-level NSG is first evaluated for outbound traffic, followed by the subnet-level NSG.
  5. Each NSG supports up to 1000 rules per NSG, including default rules.

Azure offers a Network Watcher to monitor and diagnose the Azure network. With tools for security and performance insights, you can identify and resolve network issues. For instance, NSG flow logs show traffic in and out of an NSG, allowing you to verify proper deployment and detect unauthorized IP access.

You can use Azure Network Watcher’s IP flow verify feature to check whether communication to or from a network interface is allowed or denied and identify the network security rule responsible for the decision.

Thanks for taking the time to read my blog post. Until next time, Take care.