Security with Network Security Groups (NSGs) in Azure Virtual WAN

Introduction to NSGs and Virtual WAN

Azure Virtual WAN is a networking service that brings together networking, security, and routing capabilities into a single operational interface. Network Security Groups (NSGs) are a fundamental component of Azure's network security. They act as a distributed firewall, enabling you to filter network traffic to and from Azure resources in an Azure Virtual Network (VNet), an ExpressRoute circuit, or Azure Virtual WAN Hub.

For Virtual WAN, NSGs are crucial for defining granular access control policies for resources connected to the Virtual WAN hub, as well as for spokes VNets. This allows you to enforce security policies at various points within your wide area network.

Applying NSGs in Virtual WAN

In the context of Azure Virtual WAN, NSGs can be applied in two primary locations:

• On Network Interfaces (NICs) or Subnets within Spoke VNets: This is the traditional application of NSGs to protect individual resources or entire subnets within your connected VNets. Traffic entering or leaving these resources/subnets will be subject to the NSG rules.
• On the Virtual WAN Hub: While direct application of NSGs to the Virtual WAN hub's NICs is not exposed to the user, the Virtual WAN hub has intrinsic security features and integrates with Azure Firewall for advanced threat protection. For specific traffic filtering at the hub level, Azure Firewall is the recommended solution. However, NSGs on spoke subnets implicitly protect traffic passing through the hub.

It's important to understand that NSGs are stateless, meaning they track the state of active network connections and only allow inbound traffic in the established state. This is different from stateful firewalls which track connections.

Understanding NSG Rules

NSGs contain a list of security rules that allow or deny inbound network traffic to a resource or deny outbound traffic from it. Each rule has the following properties:

• Priority: Rules are processed in order of priority, from lowest to highest.
• Source: IP addresses, CIDR blocks, service tags, or application security groups.
• Source port ranges: The range of source ports for the traffic.
• Destination: IP addresses, CIDR blocks, service tags, or application security groups.
• Protocol: TCP, UDP, ICMP, ESP, AH, or any.
• Action: Allow or Deny.
• Direction: Inbound or Outbound.

Each NSG also has default rules that cannot be deleted but can be overridden by user-defined rules. These include rules to deny all inbound traffic and allow all outbound traffic.

Example NSG Rule (Allowing HTTP traffic)

{
    "name": "AllowHTTPInbound",
    "properties": {
        "priority": 100,
        "access": "Allow",
        "direction": "Inbound",
        "protocol": "Tcp",
        "sourceAddressPrefix": "*",
        "sourcePortRange": "*",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "80"
    }
}
            

Best Practices

• Use Service Tags: Instead of hardcoding IP addresses, use Azure service tags (e.g., AzureLoadBalancer, VirtualNetwork) for source and destination prefixes. This simplifies management and ensures your rules automatically adapt to Azure's infrastructure changes.
• Leverage Application Security Groups (ASGs): Group resources with similar security requirements into ASGs. This allows you to define NSG rules based on these groups, making your security policies more manageable and readable, especially in large deployments.
• Principle of Least Privilege: Configure rules to allow only the necessary traffic. Deny by default and explicitly allow what's needed.
• Review and Audit Regularly: Periodically review your NSG rules to ensure they are still relevant and effective. Remove any redundant or outdated rules.
• NSGs on Hub vs. Spoke: While NSGs are applied to spokes, consider Azure Firewall at the hub for advanced inspection, threat intelligence, and centralized policy management for traffic flowing between spokes, or to/from on-premises networks.
• Order of Operations: Be mindful of rule priorities. A higher priority rule (lower number) takes precedence.

Common Security Scenarios

Scenario 1: Isolating Web Servers

In a spoke VNet hosting web servers, you can apply an NSG to the web server subnet to:

• Allow inbound TCP traffic on port 80 (HTTP) and 443 (HTTPS) from the internet (using a service tag like Internet) or from specific trusted IP ranges.
• Deny all other inbound traffic.
• Allow outbound traffic for necessary updates or communication.

Scenario 2: Securing Database Servers

For a subnet containing database servers:

• Allow inbound TCP traffic on the database port (e.g., 1433 for SQL Server) only from specific application subnets or ASGs (e.g., application servers).
• Deny all other inbound traffic.
• Deny all outbound traffic unless absolutely necessary.

Conclusion

Network Security Groups are an essential tool for securing resources within Azure Virtual WAN. By understanding how to apply and configure NSG rules effectively, you can implement granular network segmentation and enforce security policies that protect your sensitive data and applications. For advanced threat protection and centralized security management, consider integrating Azure Firewall with your Virtual WAN hub.