8.1 Network Security Groups (NSGs) & Application Security Groups (ASGs)

Network Security Groups (NSGs) & Application Security Groups (ASGs)

In Microsoft Azure Software-Defined Networking (SDN), Network Security Groups (NSGs) serve as the primary Layer 3 and Layer 4 distributed firewall mechanism. Operating directly within the Azure Virtual Filtering Platform (VFP) hypervisor layer, NSGs filter ingress and egress traffic traversing subnets and virtual machine network interfaces (NICs).

Modern cloud network security demands granular access control, high throughput, and zero-trust microsegmentation. By combining NSGs with Application Security Groups (ASGs), Service Tags, and Augmented Security Rules, network architects can construct scalable security perimeters that automatically adapt to dynamic workload lifecycles without requiring tedious, manual IP address reconfigurations.

---

1. NSG Fundamentals & 5-Tuple Stateful Inspection

An NSG contains a list of Access Control List (ACL) rules that allow or deny network traffic based on a 5-tuple inspection model:

1. Source IP Address / Prefix (or Service Tag / Application Security Group)
2. Source Port / Port Range (typically an ephemeral port range such as * or 1024-65535)
3. Destination IP Address / Prefix (or Service Tag / Application Security Group)
4. Destination Port / Port Range (e.g., 80, 443, 1433, 8080-8090)
5. Protocol (TCP, UDP, ICMP, ESP, AH, or Any / *)

+-----------------------------------------------------------------------------+
|                     5-TUPLE STATEFUL PACKET FILTERING                       |
|                                                                             |
|   Inbound Packet Header:                                                    |
|   [ Src IP: 198.51.100.25 ] [ Src Port: 51240 ]                             |
|   [ Dst IP: 10.0.1.4     ] [ Dst Port: 443   ] [ Protocol: TCP ]            |
|                                                                             |
|                          Azure Virtual Filtering Platform                   |
|                                        |                                    |
|                    Matches NSG Rule: Priority 100 (Allow)                   |
|                                        |                                    |
|                                        v                                    |
|                          +---------------------------+                      |
|                          |  VFP State Flow Table     |                      |
|                          |  - Flow: Established      |                      |
|                          |  - Auto-Allow Return Flow |                      |
|                          +---------------------------+                      |
|                                        |                                    |
|                                        v                                    |
|   Outbound Return Packet:                                                   |
|   [ Src IP: 10.0.1.4     ] [ Src Port: 443   ]                              |
|   [ Dst IP: 198.51.100.25 ] [ Dst Port: 51240 ] [ Protocol: TCP ]           |
|   --> AUTOMATICALLY PERMITTED (Bypasses Outbound NSG Rule Evaluation)        |
+-----------------------------------------------------------------------------+

Stateful Connection Tracking

Azure NSGs are fully stateful:

• When an inbound packet is permitted by an NSG rule, the Azure SDN fabric creates an active connection tracking entry in its state flow table.
• All return traffic belonging to that established session is automatically allowed, regardless of any conflicting outbound NSG rules.
• Similarly, if an outbound connection is initiated by a VM and permitted by an outbound NSG rule, all inbound response packets for that flow are automatically allowed, bypassing inbound NSG rules.
• Stateful tracking applies to TCP sessions (tracking SYN, ACK, FIN/RST sequences) and UDP/ICMP pseudo-connections (tracked via source/destination IP and port timers).

[!NOTE] Because NSGs are stateful, you do not need to open high-numbered ephemeral return ports (e.g., ports 1024–65535) in the opposite direction. Doing so introduces severe security vulnerabilities.

---

2. Two-Tier Association & Rule Evaluation Order

Network Security Groups can be associated at two distinct scopes within an Azure Virtual Network:

1. Subnet Scope: Associated directly to a subnet, filtering all traffic entering or leaving any network interface located in that subnet.
2. Network Interface (NIC) Scope: Associated directly to a specific VM network interface, applying filtering exclusively to that individual NIC.

+-----------------------------------------------------------------------------+
|                    TWO-TIER NSG EVALUATION ARCHITECTURE                     |
|                                                                             |
|   INBOUND TRAFFIC FLOW:                                                     |
|   External / VNet Packet                                                    |
|            |                                                                |
|            v                                                                |
|   [ 1. Subnet NSG Inbound ] ---> If DENY ---> [ Packet DROPPED ]            |
|            | (If ALLOW)                                                     |
|            v                                                                |
|   [ 2. NIC NSG Inbound    ] ---> If DENY ---> [ Packet DROPPED ]            |
|            | (If ALLOW)                                                     |
|            v                                                                |
|   [ Virtual Machine OS    ]                                                 |
|                                                                             |
|   -----------------------------------------------------------------------   |
|                                                                             |
|   OUTBOUND TRAFFIC FLOW:                                                    |
|   Virtual Machine OS                                                        |
|            |                                                                |
|            v                                                                |
|   [ 1. NIC NSG Outbound   ] ---> If DENY ---> [ Packet DROPPED ]            |
|            | (If ALLOW)                                                     |
|            v                                                                |
|   [ 2. Subnet NSG Outbound] ---> If DENY ---> [ Packet DROPPED ]            |
|            | (If ALLOW)                                                     |
|            v                                                                |
|   Destination Network / Internet                                            |
+-----------------------------------------------------------------------------+

The Two-Tier Evaluation Sequence

Traffic evaluation depends strictly on the direction of packet traversal:

• Inbound Evaluation Sequence:
  1. The packet first encounters the Subnet-level NSG. Rules are processed in priority order (100–4096). If a matching rule Denies the packet, it is dropped immediately. If allowed, evaluation proceeds to step 2.
  2. The packet then encounters the NIC-level NSG. Rules are processed in priority order. If a matching rule Denies the packet, it is dropped. If allowed by both tiers, the packet reaches the VM operating system.
• Outbound Evaluation Sequence:
  1. The egress packet leaving the VM OS first encounters the NIC-level NSG. If denied, it is dropped immediately.
  2. If permitted by the NIC NSG, the packet encounters the Subnet-level NSG. If denied by the subnet NSG, it is dropped. If permitted by both tiers, the packet departs the subnet.

Intra-Subnet Traffic Evaluation

When two virtual machines reside within the same subnet protected by a Subnet NSG:

• Outbound traffic from VM-1 is evaluated by VM-1's NIC NSG (outbound) -> Subnet NSG (outbound).
• Inbound traffic arriving at VM-2 is evaluated by Subnet NSG (inbound) -> VM-2's NIC NSG (inbound).
• If the Subnet NSG contains a rule blocking intra-subnet communication, packets between VM-1 and VM-2 are dropped at the Subnet NSG tier even though no router or gateway is involved.

3. Default NSG Rules & Priority Processing

Every NSG created in Azure is automatically provisioned with six default security rules (three inbound and three outbound). Default rules ensure basic platform operability and provide a secure fallback posture.

Inbound Default Security Rules

Outbound Default Security Rules

Custom Rule Priorities & Immutability

• Priority Range: Custom security rules can be assigned integer priorities from 100 to 4096.
• Processing Sequence: Rules are evaluated strictly in ascending order (priority 100 is evaluated before priority 200). Once a packet matches a rule's 5-tuple criteria, processing terminates immediately; subsequent rules are ignored.
• Immutability of Default Rules: Default rules (priorities 65000, 65001, 65500) cannot be deleted or modified. However, because custom rules have lower priority numbers (100–4096), you can easily override any default rule by creating a higher-priority custom rule (e.g., a custom outbound rule with Priority 4000 denying all traffic to the Internet service tag overrides rule 65001).

[!CAUTION] Overriding AllowAzureLoadBalancerInBound: If you create a custom inbound Deny rule that inadvertently blocks the AzureLoadBalancer service tag (infrastructure IP 168.63.129.16), health probes from Azure Load Balancer will fail, causing backend pools to mark your VMs unhealthy and terminating traffic routing.

---

4. Augmented Security Rules

Historically, creating complex firewall policies required defining a separate NSG rule for every IP address, port, and protocol combination. This quickly led to sprawling rule sets that exceeded Azure's platform limits (maximum 1,000 rules per NSG).

Augmented Security Rules allow you to bundle complex multidimensional policies into a single, cohesive rule definition:

• Multiple IP Addresses & CIDR Ranges: A single rule can specify multiple comma-separated IP addresses and CIDR prefixes in the source or destination field (e.g., 10.0.1.0/24, 10.0.2.0/24, 192.168.10.50/32, 172.16.0.0/16).
• Multiple Port Ranges: A single rule can specify multiple individual ports and port ranges (e.g., 80, 443, 8080-8085, 9000).
• Combined Service Tags: Multiple service tags can be referenced within a single rule definition.

// Example: Augmented NSG Rule in ARM / Bicep format
{
  "name": "Allow-Web-Management-Ports",
  "properties": {
    "protocol": "Tcp",
    "sourcePortRange": "*",
    "destinationPortRanges": ["80", "443", "8080-8090", "9443"],
    "sourceAddressPrefixes": ["10.10.0.0/16", "192.168.5.0/24", "203.0.113.10/32"],
    "destinationAddressPrefix": "*",
    "access": "Allow",
    "priority": 150,
    "direction": "Inbound"
  }
}

---

5. Application Security Groups (ASGs) & Dynamic Microsegmentation

Application Security Groups (ASGs) provide an abstraction layer that decouples network security policy from physical IP addressing. An ASG is an SDN object that groups virtual machine network interfaces (NICs) under a logical workload identifier.

+-----------------------------------------------------------------------------+
|               APPLICATION SECURITY GROUP (ASG) ARCHITECTURE                 |
|                                                                             |
|   Virtual Network: 10.100.0.0/16                                            |
|                                                                             |
|   +--------------------------+          +--------------------------+        |
|   | ASG: ASG-WebTier         |          | ASG: ASG-AppTier         |        |
|   | - Web-VM1 NIC (10.0.1.4) |          | - App-VM1 NIC (10.0.1.6) |        |
|   | - Web-VM2 NIC (10.0.1.5) |          | - App-VM2 NIC (10.0.1.7) |        |
|   +--------------------------+          +--------------------------+        |
|                |                                      |                     |
|                v                                      v                     |
|   +---------------------------------------------------------------------+   |
|   | NSG Rule (Priority 120): Allow-Web-to-App                           |   |
|   | - Source: ASG-WebTier                                               |   |
|   | - Destination: ASG-AppTier                                          |   |
|   | - Destination Port: 8443 (TCP)                                      |   |
|   | - Action: Allow                                                     |   |
|   +---------------------------------------------------------------------+   |
|                                                                             |
|   Benefit: When Web-VM3 or App-VM3 scales up and joins the ASG,             |
|   security policies apply instantly with ZERO NSG rule changes!             |
+-----------------------------------------------------------------------------+

How ASGs Enable Zero-Trust Microsegmentation

Consider a classic three-tier application (Web, Application, Database) hosted in the same subnet or across multiple subnets:

1. Create three ASGs: ASG-Web, ASG-App, and ASG-DB.
2. Assign the network interfaces of web VMs to ASG-Web, application VMs to ASG-App, and database VMs to ASG-DB.
3. Define granular NSG rules referencing ASGs directly:
   • Rule 110: Inbound Allow from Internet to ASG-Web on ports 80, 443.
   • Rule 120: Inbound Allow from ASG-Web to ASG-App on port 8443.
   • Rule 130: Inbound Allow from ASG-App to ASG-DB on port 1433.
   • Rule 140: Inbound Deny from ASG-Web to ASG-DB on * (Explicit isolation).

ASG Rules and Constraints

• Single VNet Boundary: All network interfaces assigned to an ASG must reside within the same Virtual Network where the ASG is created. You cannot assign NICs from different VNets to the same ASG.
• Multiple ASG Memberships: A single network interface can be assigned to multiple ASGs (up to platform limits, typically 20 ASGs per NIC).
• NSG Rule Scoping: An NSG rule can specify ASGs as both the source and destination, provided both ASGs reside within the same VNet as the network interfaces being protected.
• No Cross-VNet Peering in Rules: You cannot use an ASG in an NSG rule to filter traffic originating from or destined to a peered VNet (cross-VNet filtering requires IP prefixes or service tags).

---

6. Service Tags & Platform Infrastructure VIPs

A Service Tag is a platform-managed label that represents a group of IP address prefixes associated with a specific Azure service or platform function. Microsoft automatically updates the IP prefixes included in a service tag as service topologies change.

Essential Service Tags for AZ-700

[!IMPORTANT] The VirtualNetwork Service Tag Scope: On the AZ-700 exam, remember that VirtualNetwork is not restricted to the single local VNet. It encompasses all address spaces reachable via VNet Peering, Virtual Network Gateways, and active Service Endpoints.