Network Security Groups

IntermediateTopic20 min5 min readAzure

AZ-104 notes: Network Security Groups. Covers key concepts for the Azure Administrator Associate exam.

This lesson explains how Azure secures traffic inside and outside virtual networks using:

Azure Network Security Group Azure Virtual Network

1️⃣ What Is a Network Security Group (NSG)?

An NSG is:

  • A Layer 4 (TCP/UDP) stateful firewall
  • Used to control inbound and outbound traffic

Applied at:

  • Subnet level
  • NIC level

It protects:

  • Traffic from internet
  • Traffic from peered VNets
  • Traffic from on-prem
  • Even traffic within same subnet

2️⃣ Why NSGs Are Needed

Azure VNets can have:

  • Public IP connectivity
  • VNet Peering
  • Hybrid VPN
  • Internal subnet communication
  • Without NSGs: All allowed traffic routes would be reachable.

NSGs enforce:

  • Allow / Deny

based on:

  • Source
  • Destination
  • Port
  • Protocol
  • Direction
  • Priority

3️⃣ Where Can NSGs Be Applied?

Option 1️⃣ Subnet Level

Affects all NICs inside subnet

Good for centralized policy

Option 2️⃣ NIC Level

  • Affects only that VM
  • Good for granular control
  • You can combine both.

4️⃣ Default NSG Rules (System Rules)

Every NSG includes built-in rules (priority 65000+):

Default Inbound:

  • Allow VNet traffic
  • Allow Azure Load Balancer
  • Deny all other inbound

Default Outbound:

  • Allow VNet traffic
  • Allow Internet
  • Allow Azure services

User-defined rules:

  • Have priority 100–4096
  • Lower number = higher priority

5️⃣ Demonstration Summary

Scenario:

  • Ubuntu VM
  • Public IP assigned
  • NGINX installed
  • Want HTTP access (port 80)

Initially:

  • HTTP blocked
  • Because no NSG rule allowed it

Action Taken:

Added inbound rule:

  • Source: Any
  • Destination: Any
  • Protocol: TCP
  • Port: 80
  • Action: Allow
  • Priority: 110

Result:

  • HTTP traffic allowed NGINX webpage accessible

6️⃣ Stateful Firewall Behavior (Very Important)

  • NSGs are stateful.

This means:

If inbound rule allows HTTP:

  • Return outbound traffic is automatically allowed.
  • You DO NOT need to create reverse outbound rule.
  • State tracking is automatic.

7️⃣ NSG Rule Components

Each rule defines:

8️⃣ Priority Rules

Rules are evaluated:

  • 1️⃣ Lowest priority number first 2️⃣ First match wins 3️⃣ Stops evaluation

Example:

  • Priority 100 → Deny HTTP Priority 200 → Allow HTTP
  • Result: Traffic denied (100 wins)

9️⃣ Internal Traffic Impact

Important concept:

Even VM-to-VM traffic in same subnet:

  • Leaves VM
  • Hits virtual router
  • Comes back

NSG rules apply to:

  • East-West traffic
  • Not just internet traffic

🔟 Monitoring with NSG Flow Logs

NSG supports monitoring via:

  • Flow logs
  • Traffic analytics
  • Storage account integration

Useful for:

  • Security auditing
  • Troubleshooting
  • Compliance

Flow logs show:

  • Allowed traffic
  • Denied traffic
  • Source/destination
  • Ports

11️⃣ Subnet vs NIC Scope Comparison

Best Practice: Use subnet-level NSGs primarily.

12️⃣ Common Enterprise Pattern

Frontend Subnet:

  • Allow HTTP/HTTPS
  • Deny everything else

Backend Subnet:

  • Allow only frontend subnet
  • No internet access

Database Subnet:

  • Allow only backend subnet

13️⃣ Common Exam Concepts (AZ-104 / AZ-700)

🚩 NSGs are stateless → False 🚩 NSG applied at VNet level → False 🚩 Return traffic requires explicit rule → False 🚩 Lower priority number wins → True 🚩 NSGs control Layer 7 → False (Layer 4 only)

14️⃣ Troubleshooting Checklist

If traffic blocked:

  • Check NSG inbound rules
  • Check NSG outbound rules
  • Verify priority order
  • Check subnet + NIC both
  • Review effective security rules

If rule not working:

  • Confirm rule priority
  • Confirm correct direction
  • Confirm protocol matches

15️⃣ Security Best Practices

✔ Use Standard public IPs ✔ Avoid “Allow Any Any” rules ✔ Space priorities (100, 200, 300) ✔ Use service tags where possible ✔ Log traffic using flow logs ✔ Apply least privilege principle

16️⃣ Reference Documentation

  • NSG Overview
  • Default Security Rules
  • NSG Flow Logs
  • Effective Security Rules

Final Conceptual Summary

NSGs:

  • Control traffic at subnet/NIC
  • Stateful Layer 4 firewall
  • Inbound + Outbound rules
  • Priority-based evaluation
  • Return traffic automatically allowed
  • They are the **primary traffic control mechanism inside Azure **VNets.

If you'd like next:

  • 🧠 30 scenario-based NSG exam questions
  • 📊 NSG vs Azure Firewall comparison
  • 🏗 Secure 3-tier architecture design
  • 📄 One-page AZ-104 networking cheat sheet
  • Tell me your target certification.

Hands-on: Build NSG Rules for a Two-Tier App

Goal: Allow public web traffic while keeping the app subnet private.

  1. Create or use a VNet with web-subnet and app-subnet.
  2. Create NSG az104-web-nsg.
  3. Add inbound rule:
    • Priority: 100
    • Source: Internet
    • Destination port: 80
    • Protocol: TCP
    • Action: Allow
  4. Associate az104-web-nsg with web-subnet.
  5. Create NSG az104-app-nsg.
  6. Add inbound rule:
    • Priority: 100
    • Source: web-subnet CIDR
    • Destination port: your app port, such as 8080
    • Protocol: TCP
    • Action: Allow
  7. Add a lower-priority deny rule for internet-sourced app traffic if you want to make the intent explicit.
  8. Associate az104-app-nsg with app-subnet.
  9. Open a VM NIC and review Effective security rules.
  10. Test connectivity from web to app, then from the internet to app, and confirm only the intended path works.

Hands-on: Troubleshoot a Blocked Port

  1. Pick a VM with an NSG attached.
  2. Add an inbound deny rule for TCP 80 with priority 100.
  3. Try browsing to the VM public IP and confirm access fails.
  4. Open Network Watcher > IP flow verify.
  5. Enter source, destination, protocol, and port.
  6. Confirm the deny rule is reported as the blocking rule.
  7. Remove or lower the priority of the deny rule to restore access.

More in Microsoft Azure