Azure Network Security Groups: Controlling Traffic Flow

In any Azure cloud environment, controlling the flow of network traffic is fundamental to maintaining security. Just as a physical office uses locked doors, access badges, and reception desks to control who enters which areas, Azure uses Network Security Groups (NSGs) to control which network traffic is permitted to reach your cloud resources and which is blocked. Without properly configured NSGs, your Azure virtual machines, databases, and applications are exposed to the entire internet — a security posture that no responsible UK business should accept.

Network Security Groups are one of the most important security controls available in Microsoft Azure, yet they are also one of the most frequently misconfigured. A common pattern we see in Azure environments belonging to UK businesses is NSGs that were configured hastily during initial deployment, with overly permissive rules that allow far more traffic than necessary. Rules allowing inbound traffic from "Any" source to "Any" destination on "Any" port are unfortunately widespread — effectively negating the purpose of having an NSG at all.

This guide provides a comprehensive explanation of how Azure Network Security Groups work, how to design effective security rules, common mistakes to avoid, and best practices for maintaining secure, well-governed network traffic control in your Azure environment. Whether you are running a single virtual machine or a complex multi-tier application, the principles covered here will help you implement NSGs that genuinely protect your workloads.

What Are Network Security Groups?

A Network Security Group is a set of security rules that filter network traffic to and from Azure resources within an Azure Virtual Network. Each rule specifies a source, destination, port, protocol, and action (allow or deny). When network traffic reaches a resource protected by an NSG, the rules are evaluated in priority order — lowest number first — and the first matching rule determines whether the traffic is permitted or blocked.

NSGs can be associated with two types of Azure resources: subnets and network interfaces. When associated with a subnet, the NSG rules apply to all resources within that subnet. When associated with a network interface, the rules apply only to the specific virtual machine attached to that interface. You can use both simultaneously — a subnet-level NSG for broad rules and a network interface-level NSG for granular, per-VM rules — though this layered approach adds complexity and should be used carefully.

Every NSG includes a set of default rules that cannot be deleted but can be overridden by higher-priority custom rules. The default inbound rules allow traffic from within the virtual network and from Azure load balancers, and deny all other inbound traffic. The default outbound rules allow traffic to the virtual network and to the internet, and deny all other outbound traffic. These defaults provide a reasonable starting point but almost always need to be supplemented with custom rules tailored to your specific requirements.

Designing Effective NSG Rules

The fundamental principle of NSG rule design is the principle of least privilege: allow only the specific traffic that is required for your application to function, and deny everything else. This means being as specific as possible in your rules — specifying exact source IP ranges rather than "Any," exact destination ports rather than "Any," and exact protocols rather than "Any." Every "Any" in an NSG rule represents a potential attack surface that you are leaving unnecessarily exposed.

Consider a typical two-tier web application running in Azure: a front-end web server and a back-end database server. The NSG rules for the web server should allow inbound HTTPS traffic (port 443) from the internet, allow inbound SSH or RDP traffic from your office IP address for management, and deny all other inbound traffic. The NSG rules for the database server should allow inbound database traffic (for example, port 1433 for SQL Server) only from the web server's subnet, allow inbound management traffic from your office IP, and deny all other inbound traffic — including traffic from the internet, which should never reach your database directly.

This tiered approach ensures that even if an attacker compromises the web server, they cannot directly access the database from the internet. They would need to first compromise the web server and then pivot through the internal network — a significantly more difficult attack that gives you additional time and opportunities to detect and respond to the intrusion.

Common NSG Mistakes and How to Avoid Them

Mistake 1: Allowing RDP or SSH from the Internet. This is perhaps the most dangerous and most common NSG misconfiguration. Remote Desktop Protocol (port 3389) and SSH (port 22) are prime targets for brute-force attacks. If these ports are open to the internet, your virtual machines will be subjected to thousands of login attempts per day from automated attack tools. Instead, restrict management access to specific IP addresses (your office or VPN), or better yet, use Azure Bastion — a fully managed PaaS service that provides secure RDP and SSH access to your VMs without exposing any management ports to the internet.

Mistake 2: Using "Any" as the source for application rules. If your web application should only be accessed from the United Kingdom, restrict the source to UK IP ranges. If it serves only internal users, restrict the source to your corporate network. Even for genuinely public-facing applications, consider using Azure Front Door or Application Gateway with Web Application Firewall (WAF) in front of your VMs, and restricting the NSG to allow traffic only from the Front Door or Application Gateway IP addresses.

Mistake 3: Forgetting about outbound rules. Many administrators focus exclusively on inbound rules and neglect outbound traffic filtering. This is a mistake because it means that if a virtual machine is compromised, it can freely communicate with command-and-control servers, exfiltrate data, and participate in attacks against other targets. Good practice is to restrict outbound traffic to only the destinations required for the application to function — for example, allowing outbound HTTPS to specific API endpoints and Azure services, and denying outbound traffic to the internet on all other ports.

Mistake 4: Not using Application Security Groups (ASGs). Application Security Groups allow you to group virtual machines and define NSG rules based on those groups rather than specific IP addresses. This dramatically simplifies rule management in environments with many VMs, because you can write rules like "Allow traffic from WebServers ASG to DatabaseServers ASG on port 1433" rather than maintaining lists of individual IP addresses that change every time you add or remove a VM.

NSG Flow Logs and Monitoring

Configuring NSG rules is only half the battle — you also need to monitor how those rules are being applied in practice. Azure NSG Flow Logs capture information about every connection attempt that passes through an NSG, including the source and destination IP addresses, ports, protocol, whether the traffic was allowed or denied, and the volume of data transferred. This data is invaluable for security monitoring, troubleshooting connectivity issues, and verifying that your rules are working as intended.

NSG Flow Logs can be stored in an Azure Storage Account and analysed using Azure Traffic Analytics, which provides visual dashboards showing traffic patterns, top communicating hosts, blocked traffic attempts, and geographic distribution of traffic sources. For UK businesses concerned about compliance, flow logs provide an audit trail demonstrating that network access controls are in place and functioning correctly — useful evidence for Cyber Essentials certification, ISO 27001 audits, and GDPR compliance assessments.

Enable NSG Flow Logs for all NSGs in your environment, and configure retention periods appropriate to your compliance requirements. A minimum of 90 days is recommended for most UK businesses, though specific regulations or contractual obligations may require longer retention. Review flow log data regularly — at least monthly — to identify unusual traffic patterns, verify rule effectiveness, and detect potential security incidents.

Azure Service Tags and Simplifying Rules

Azure Service Tags are predefined groups of IP addresses for Azure services, managed by Microsoft and updated automatically as service IP ranges change. Using service tags in your NSG rules eliminates the need to track and update individual IP addresses for Azure services, significantly simplifying rule management and reducing the risk of rules becoming stale.

Common service tags include Internet (all public internet IP addresses), VirtualNetwork (all address space within the virtual network, including peered networks), AzureLoadBalancer (the Azure infrastructure load balancer), Storage (Azure Storage service IP ranges), Sql (Azure SQL Database IP ranges), and AzureActiveDirectory (Azure AD IP ranges). Region-specific variants are also available — for example, Storage.UKSouth for Azure Storage in the UK South region.

Using service tags is strongly recommended over hardcoding IP addresses. Microsoft updates service tag IP ranges as infrastructure changes, and your NSG rules automatically reflect these updates without any action on your part. This is particularly important for services like Azure Storage and Azure SQL, whose IP ranges change periodically as Microsoft expands its infrastructure.

NSGs and UK Compliance Requirements

For UK businesses subject to regulatory requirements, NSGs play an important role in demonstrating compliance with network segmentation and access control obligations. Under GDPR, businesses must implement appropriate technical measures to protect personal data — and network security controls such as NSGs are a fundamental component of those measures. The ICO expects organisations processing personal data to demonstrate that network access is restricted to authorised traffic and that monitoring is in place to detect unauthorised access attempts.

For businesses pursuing Cyber Essentials or Cyber Essentials Plus certification, NSGs help satisfy the "Firewalls" control requirement by providing boundary protection between the internet and your Azure resources. Ensure that your NSG rules deny all inbound traffic by default and explicitly allow only the specific traffic required, with no management ports open to the internet.

For businesses pursuing ISO 27001 certification, NSGs contribute to several controls within Annex A, including A.13.1 (Network Security Management) and A.13.2 (Security of Network Services). Auditors will want to see documented NSG rules, evidence of regular review, and flow log data demonstrating that rules are enforced in practice.