Network Security Groups (NSG) in Azure - Deep Dive

Overview - Network Security Groups (NSG)

What is it?

Network Security Groups (NSGs) are like digital gatekeepers for your cloud network. They control which data can enter or leave your virtual machines by using simple rules. These rules allow or block traffic based on things like IP addresses, ports, and protocols. NSGs help keep your cloud resources safe by managing network access.

Why it matters

Without NSGs, your cloud resources would be open to all kinds of network traffic, including harmful attacks or accidental access. This could lead to data breaches, service interruptions, or unauthorized use. NSGs solve this by giving you control over who can talk to your resources and how, making your cloud environment secure and reliable.

Where it fits

Before learning about NSGs, you should understand basic networking concepts like IP addresses, ports, and protocols. After NSGs, you can explore more advanced security tools like Azure Firewall or Azure DDoS Protection. NSGs are a foundational step in securing cloud networks.

Mental Model

Core Idea

NSGs act as traffic controllers that decide which network data can flow in or out of your cloud resources based on simple, clear rules.

Think of it like...

Imagine a building with security guards at every door. These guards check each person’s ID and decide if they can enter or leave based on a list of rules. NSGs are like those guards for your cloud network, controlling who gets in and out.

┌─────────────────────────────┐
│       Network Security       │
│          Group (NSG)         │
├─────────────┬───────────────┤
│   Inbound   │   Outbound    │
│   Rules     │   Rules       │
├─────────────┴───────────────┤
│  Allow or Deny traffic based │
│  on IP, port, protocol       │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Basic Network Traffic

Concept: Learn what network traffic is and how it moves between computers.

Network traffic is the flow of data between devices over a network. It uses addresses called IPs and specific doors called ports to send and receive information. For example, when you visit a website, your computer sends requests to the website's server using these addresses and ports.

Result

You understand that network traffic is data moving between devices using IP addresses and ports.

Knowing how data moves helps you see why controlling this flow is important for security.

2

Foundation

What Are Network Security Groups?

Concept: Introduce NSGs as tools to control network traffic in the cloud.

NSGs are sets of rules that allow or block network traffic to and from cloud resources. Each rule specifies conditions like source IP, destination IP, port, and protocol. NSGs apply these rules to decide if traffic should pass or be stopped.

Result

You know NSGs control network access by applying rules to traffic.

Understanding NSGs as rule sets clarifies how cloud security is managed at the network level.

3

Intermediate

Inbound and Outbound Rules Explained

🤔Before reading on: Do you think inbound and outbound rules control the same traffic or different directions? Commit to your answer.

Concept: Learn the difference between inbound and outbound rules in NSGs.

Inbound rules control traffic coming into your resource, like visitors entering a building. Outbound rules control traffic leaving your resource, like people exiting. Each rule can allow or deny traffic based on conditions such as IP address and port number.

Result

You can distinguish how NSGs manage incoming and outgoing traffic separately.

Knowing the direction of traffic each rule controls helps you design precise security policies.

4

Intermediate

Priority and Rule Evaluation Order

🤔Before reading on: Do you think NSG rules are applied all at once or one by one in order? Commit to your answer.

Concept: Understand how NSG rules are prioritized and evaluated.

Each NSG rule has a priority number from 100 to 4096. Lower numbers have higher priority. When traffic arrives, NSG checks rules starting from the lowest number. The first rule that matches the traffic decides if it is allowed or denied. If no rule matches, default rules apply.

Result

You know that NSG rules are checked in order of priority, and the first match wins.

Understanding rule priority prevents conflicts and unexpected access in your security setup.

5

Intermediate

Default Rules and Their Role

Concept: Learn about built-in NSG rules that always exist.

NSGs come with default rules that allow essential traffic like communication within the virtual network and deny all other traffic by default. These rules have fixed priorities and cannot be removed but can be overridden by custom rules with higher priority.

Result

You understand that NSGs have built-in safety nets to keep basic network functions working.

Knowing default rules helps you avoid accidentally blocking necessary traffic.

6

Advanced

Applying NSGs to Subnets and Network Interfaces

🤔Before reading on: Do you think NSGs apply only to whole networks or can they target smaller parts? Commit to your answer.

Concept: Explore how NSGs can be attached to different parts of the network.

You can associate NSGs with entire subnets or individual network interfaces of virtual machines. When applied to a subnet, the NSG controls traffic for all resources inside it. When applied to a network interface, it controls traffic for that specific resource. Both associations can be used together, and their rules combine.

Result

You know how to target NSGs to control traffic at different network levels.

Understanding NSG scope allows flexible and layered security designs.

7

Expert

NSG Rule Conflicts and Effective Security

🤔Before reading on: If two NSGs have conflicting rules on the same resource, which one wins? Commit to your answer.

Concept: Learn how Azure resolves conflicts when multiple NSGs apply to the same resource.

When NSGs are applied both to a subnet and a network interface, their rules combine. If one NSG allows traffic but the other denies it, the deny rule takes precedence. This ensures the strictest security is enforced. Understanding this helps avoid accidental access through conflicting rules.

Result

You understand how Azure merges NSG rules and enforces the strictest policy.

Knowing conflict resolution prevents security gaps caused by overlapping NSGs.

Under the Hood

NSGs work by inspecting each network packet against a list of ordered rules. Each rule checks packet properties like source IP, destination IP, port, and protocol. The system evaluates rules by priority, and the first matching rule determines if the packet is allowed or denied. This filtering happens at the Azure network fabric level before the packet reaches the resource.

Why designed this way?

NSGs were designed to provide simple, fast, and scalable network filtering without complex firewall setups. Using ordered rules with priorities allows quick decisions on traffic, minimizing delays. The combination of subnet and interface associations offers flexible security layers. Alternatives like full firewalls are more complex and costly, so NSGs balance ease and effectiveness.

┌───────────────┐
│ Incoming Packets │
└───────┬───────┘
        │
        ▼
┌─────────────────────────────┐
│  NSG Rule Evaluation Engine  │
│  (Checks rules by priority)  │
├─────────────┬───────────────┤
│  Matches?   │   No Match     │
│  (Allow/Deny)│               │
└───────┬─────┴───────┬───────┘
        │             │
        ▼             ▼
   Allow Packet    Default Rule
        │             │
        ▼             ▼
  Packet Delivered  Packet Blocked

Myth Busters - 4 Common Misconceptions

Quick: Do NSGs act like full firewalls with deep packet inspection? Commit to yes or no.

Common Belief: NSGs are full firewalls that inspect all packet contents deeply.

Reality: NSGs only filter traffic based on simple header information like IP, port, and protocol, not the full packet content.

Why it matters: Expecting NSGs to block complex threats can leave your network vulnerable if you don't use additional security tools.

Quick: If an NSG denies traffic on a subnet but allows it on a VM's interface, does the traffic get through? Commit to yes or no.

Common Belief: Allow rules on a VM's interface always override subnet deny rules.

Reality: Deny rules always take precedence over allow rules, so the subnet deny will block the traffic despite the VM's allow.

Why it matters: Misunderstanding this can cause confusion when traffic is blocked unexpectedly.

Quick: Are NSGs stateful, remembering previous connections? Commit to yes or no.

Common Belief: NSGs are stateless and treat each packet independently.

Reality: NSGs are stateful; once a connection is allowed inbound, return traffic is automatically allowed outbound without explicit rules.

Why it matters: Knowing this helps simplify rule creation and avoid redundant outbound rules.

Quick: Can NSGs filter traffic based on application-level data like URLs? Commit to yes or no.

Common Belief: NSGs can filter traffic based on application data like URLs or HTTP headers.

Reality: NSGs cannot inspect application-level data; they only filter based on network and transport layer information.

Why it matters: Relying on NSGs for application-level filtering can leave security gaps that require other tools.

Expert Zone

1

NSG rules are processed in a strict priority order, but default rules always exist and can only be overridden by higher priority custom rules.

2

When multiple NSGs apply, deny rules always override allow rules, ensuring the strictest security is enforced.

3

NSGs are stateful, meaning return traffic for allowed inbound connections is automatically permitted, reducing rule complexity.

When NOT to use

NSGs are not suitable for deep packet inspection, application-level filtering, or advanced threat protection. For these needs, use Azure Firewall, Web Application Firewall, or third-party security appliances.

Production Patterns

In production, NSGs are layered by applying broad rules at the subnet level and more specific rules at the network interface level. Teams use naming conventions and automation scripts to manage NSGs at scale. Monitoring NSG flow logs helps detect unusual traffic patterns.

Connections

Firewall

NSGs provide basic network filtering, while firewalls offer deeper inspection and more complex policies.

Understanding NSGs clarifies the role of simple network controls before adding full firewall protections.

Stateful vs Stateless Systems

NSGs are stateful, remembering connection states, unlike stateless packet filters.

Knowing NSGs are stateful helps grasp why some return traffic is automatically allowed, simplifying rule sets.

Security Guards in Physical Security

Both NSGs and security guards control access based on rules and identity checks.

Recognizing this connection helps appreciate layered security approaches in both digital and physical worlds.

Common Pitfalls

#1 Blocking essential internal traffic by misconfiguring NSG rules.

Wrong approach:

Deny inbound from all IPs to subnet without exceptions:
Priority 100, Deny, Source: *, Destination: subnet, Port: *

Correct approach:

Allow inbound from virtual network:
Priority 100, Allow, Source: VirtualNetwork, Destination: subnet, Port: *
Then add deny rules for unwanted traffic with lower priority.

Root cause:

Not understanding default rules and the need to allow internal traffic causes service disruptions.

#2 Assuming NSGs filter application-level data like URLs.

Wrong approach:

Creating NSG rules to block HTTP URLs or headers.

Correct approach:

Use Azure Web Application Firewall or Azure Firewall for application-level filtering.

Root cause:

Misunderstanding NSG capabilities leads to ineffective security policies.

#3 Applying conflicting NSGs without knowing deny overrides allow.

Wrong approach:

Subnet NSG allows port 80, but VM NSG denies port 80, expecting traffic to pass.

Correct approach:

Ensure deny rules are intentional and understand they override allow rules, so traffic will be blocked.

Root cause:

Lack of knowledge about rule conflict resolution causes unexpected traffic blocks.

Key Takeaways

Network Security Groups control cloud network traffic by applying ordered rules that allow or deny data based on IP, port, and protocol.

Inbound rules manage incoming traffic, outbound rules manage outgoing traffic, and rule priority determines which rule applies first.

NSGs are stateful, automatically allowing return traffic for allowed connections, simplifying rule management.

Deny rules always override allow rules when multiple NSGs apply, ensuring the strictest security.

NSGs provide basic network filtering but do not replace advanced firewalls or application-level security tools.

Practice

1. What is the primary purpose of an Azure Network Security Group (NSG)?

easy

A. To monitor application performance

B. To store data securely in Azure Blob Storage

C. To control inbound and outbound traffic to Azure resources

D. To manage user identities and access

Solution

1. Step 1: Understand NSG function

   NSGs are designed to filter network traffic to and from Azure resources.

2. Step 2: Identify correct purpose

   They do not store data, manage identities, or monitor performance.

3. Final Answer:

   To control inbound and outbound traffic to Azure resources -> Option C

4. Quick Check:

   NSG controls traffic [OK]

Hint: NSG controls network traffic, not data or users [OK]

Common Mistakes:

• Confusing NSG with storage or identity services
• Thinking NSG monitors performance
• Assuming NSG stores data

2. Which of the following is the correct way to specify a rule priority in an NSG rule?

easy

A. Priority is a string describing the rule

B. Priority is an IP address range

C. Priority is a boolean value true or false

D. Priority must be a unique integer between 100 and 4096

Solution

1. Step 1: Understand NSG rule priority format

   NSG rule priority is a unique integer between 100 and 4096 that determines rule evaluation order.

2. Step 2: Eliminate incorrect types

   Priority is not a string, boolean, or IP range.

3. Final Answer:

   Priority must be a unique integer between 100 and 4096 -> Option D

4. Quick Check:

   Priority = integer 100-4096 [OK]

Hint: Priority is a number from 100 to 4096 [OK]

Common Mistakes:

• Using strings or booleans for priority
• Confusing priority with IP ranges
• Not using unique priority numbers

3. Given this NSG rule:
Priority: 200, Direction: Inbound, Access: Deny, Source: Any, Destination: 10.0.0.4, Protocol: TCP, Port: 22
What happens when a user tries to SSH (port 22) to 10.0.0.4?

medium

A. The connection is denied

B. The connection is allowed only if from a specific IP

C. The connection is allowed

D. The connection is logged but allowed

Solution

1. Step 1: Analyze rule details

   The rule denies inbound TCP traffic on port 22 to destination 10.0.0.4 from any source.

2. Step 2: Determine effect on SSH connection

   SSH uses TCP port 22, so the connection attempt matches the deny rule and is blocked.

3. Final Answer:

   The connection is denied -> Option A

4. Quick Check:

   Deny inbound TCP port 22 = connection denied [OK]

Hint: Deny inbound on port 22 blocks SSH connections [OK]

Common Mistakes:

• Assuming 'Any' source means allow
• Confusing deny with logging
• Ignoring direction and port in rule

4. You created an NSG rule to allow inbound HTTP traffic on port 80, but the traffic is still blocked. What is the most likely cause?

medium

A. The NSG is not attached to the subnet or network interface

B. A higher priority deny rule blocks port 80 traffic

C. The source IP address is not specified

D. The protocol is set to UDP instead of TCP

Solution

1. Step 1: Check rule priority and conflicts

   NSG rules are evaluated by priority; a deny rule with higher priority can block traffic despite allow rules.

2. Step 2: Confirm rule attachment and protocol

   While attachment and protocol matter, the most common cause is a conflicting higher priority deny rule.

3. Final Answer:

   A higher priority deny rule blocks port 80 traffic -> Option B

4. Quick Check:

   Higher priority deny overrides allow [OK]

Hint: Check for higher priority deny rules first [OK]

Common Mistakes:

• Ignoring rule priority order
• Assuming NSG attachment is always correct
• Confusing protocol types

5. You want to restrict access so only a specific IP address (203.0.113.5) can access a VM on port 3389 (RDP). Which NSG rule configuration achieves this securely?

hard

A. Priority: 300, Direction: Inbound, Access: Allow, Source: 203.0.113.5, Destination: Any, Protocol: TCP, Port: 3389

B. Priority: 100, Direction: Inbound, Access: Deny, Source: Any, Destination: Any, Protocol: TCP, Port: 3389

C. Priority: 200, Direction: Inbound, Access: Allow, Source: Any, Destination: Any, Protocol: TCP, Port: 3389

D. Priority: 400, Direction: Outbound, Access: Allow, Source: 203.0.113.5, Destination: Any, Protocol: TCP, Port: 3389

Solution

1. Step 1: Allow only specific IP inbound on port 3389

   Priority: 300, Direction: Inbound, Access: Allow, Source: 203.0.113.5, Destination: Any, Protocol: TCP, Port: 3389 allows inbound TCP traffic on port 3389 only from IP 203.0.113.5, which matches the requirement.

2. Step 2: Check other options for correctness

   Priority: 100, Direction: Inbound, Access: Deny, Source: Any, Destination: Any, Protocol: TCP, Port: 3389 denies all inbound TCP 3389 traffic, blocking access. Priority: 200, Direction: Inbound, Access: Allow, Source: Any, Destination: Any, Protocol: TCP, Port: 3389 allows all sources, which is insecure. Priority: 400, Direction: Outbound, Access: Allow, Source: 203.0.113.5, Destination: Any, Protocol: TCP, Port: 3389 is outbound, irrelevant for inbound access.

3. Final Answer:

   Priority: 300, Direction: Inbound, Access: Allow, Source: 203.0.113.5, Destination: Any, Protocol: TCP, Port: 3389 -> Option A

4. Quick Check:

   Allow inbound TCP 3389 from specific IP [OK]

Hint: Allow inbound from specific IP, deny others by priority [OK]

Common Mistakes:

• Allowing all sources instead of specific IP
• Using outbound direction instead of inbound
• Denying all traffic without exception