Azure Network Security Groups and Firewalls

A Network Security Group (NSG) is a stateful, distributed firewall that filters network traffic to and from Azure resources in a virtual network (VNet). It contains a set of security rules that allow or deny inbound or outbound traffic based on source/destination IP address, port, and protocol. NSGs can be associated with a subnet or a virtual network interface card (NIC). When associated with a subnet, the rules apply to all resources in that subnet. When associated with a NIC, the rules apply only to that specific VM.

Each NSG has a collection of rules. Rules are evaluated in priority order, from lowest number (highest priority) to highest number. Once a rule matches, evaluation stops. If no rule matches, traffic is denied by default. Azure creates default rules that cannot be deleted but can be overridden by custom rules with higher priority (lower number).

Default inbound rules:

Default outbound rules:

Note: The default rules allow outbound internet access. This is often a security concern and should be restricted with custom rules.

Each rule has the following properties:

Service tags are predefined IP ranges managed by Azure. They simplify rule creation by allowing you to specify a group of Azure services instead of individual IPs. Examples: VirtualNetwork, Internet, AzureLoadBalancer, Sql, Storage. The IP ranges for service tags are updated automatically as Azure adds new regions or services.

ASGs allow you to group VMs logically without relying on IP addresses. For example, you can create an ASG named "WebServers" and assign a VM's NIC to it. Then, in an NSG rule, you can specify the source or destination as the ASG. This makes rule management easier, especially in dynamic environments where IPs change.

NSGs are stateful. When you allow inbound traffic, the return traffic is automatically allowed, even if no rule explicitly allows it. For example, if you allow inbound TCP 443 from the internet, the outbound response traffic (TCP 443 from VM to internet) is allowed automatically. However, statefulness applies only to the same flow. If the VM initiates a new outbound connection, it must be allowed by an outbound rule.

Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a stateful firewall as a service with built-in high availability and scalability. Unlike NSGs, Azure Firewall provides centralized control, application and network-level filtering, threat intelligence integration, and logging.

Azure Firewall comes in three SKUs:

Azure Firewall uses three types of rules:

Rules are collected into rule collections, which have a priority (100-65000). Within a rule collection, rules are evaluated in order. If a packet matches a rule, the action (Allow/Deny) is applied; otherwise, it continues to the next rule. If no match, the packet is denied by default.

A common enterprise deployment is the hub-and-spoke topology. The hub VNet contains Azure Firewall and shared services. Spoke VNets connect to the hub via VNet peering. All traffic between spokes or to the internet is routed through the hub firewall. User-defined routes (UDRs) force-tunnel traffic to the firewall. NSGs are still used within each spoke for east-west traffic between VMs on the same subnet.

When both NSGs and Azure Firewall are applied to the same traffic, the order of evaluation is: 1. NSG rules associated with the subnet or NIC. 2. Azure Firewall rules (if traffic is routed through the firewall).

If an NSG denies traffic, the firewall never sees it. If an NSG allows traffic but the firewall denies it, the traffic is blocked. This layered approach provides defense-in-depth.

Using Azure CLI:

# Create an NSG
az network nsg create --resource-group MyRG --name MyNSG --location eastus

# Create a rule to allow SSH from a specific IP
az network nsg rule create --resource-group MyRG --nsg-name MyNSG --name AllowSSH --priority 100 \
    --source-address-prefixes 203.0.113.0/24 --destination-port-ranges 22 --protocol TCP --access Allow

# Associate with subnet
az network vnet subnet update --resource-group MyRG --vnet-name MyVNet --name MySubnet --network-security-group MyNSG

Using Azure CLI:

# Create a firewall subnet (must be named AzureFirewallSubnet)
az network vnet subnet create --resource-group MyRG --vnet-name MyVNet --name AzureFirewallSubnet --address-prefix 10.0.1.0/26

# Create a public IP for the firewall
az network public-ip create --resource-group MyRG --name MyFwPip --sku Standard --location eastus

# Create the firewall
az network firewall create --resource-group MyRG --name MyFirewall --location eastus --sku AZFW_VNet

# Configure firewall IP configuration
az network firewall ip-config create --resource-group MyRG --firewall-name MyFirewall --name FWConfig --vnet-name MyVNet --public-ip-address MyFwPip

# Add a network rule
az network firewall network-rule create --resource-group MyRG --firewall-name MyFirewall --collection-name MyCollection --priority 100 --action Allow --name AllowDNS --protocol UDP --source-addresses '*' --destination-addresses '8.8.8.8' --destination-ports 53

NSG flow logs can be enabled to capture IP traffic flowing through an NSG. These logs are sent to Azure Storage or Log Analytics. Azure Firewall logs all traffic (by default, only logs denied traffic; you can enable logging for allowed traffic). Logs include source/destination IP, port, protocol, action, and rule matched.

NSG rules are applied at the host level by the Azure hypervisor, so they do not impact network throughput. Azure Firewall scales automatically based on load, but for very high throughput (over 100 Gbps), you may need multiple firewall instances in a firewall policy.

NSGs and Azure Firewall are complementary. NSGs provide distributed, basic filtering at the subnet/NIC level for free. Azure Firewall provides centralized, advanced filtering with features like FQDN filtering, threat intelligence, and logging. For the SC-900 exam, focus on understanding their differences, default rules, stateful behavior, and when to use each.

A company hosts an e-commerce web application in Azure. The architecture includes a web tier, application tier, and database tier, each in separate subnets. They use NSGs for subnet-level segmentation: the web subnet allows inbound TCP 80/443 from the Internet, the app subnet only allows TCP 443 from the web subnet, and the database subnet only allows TCP 1433 from the app subnet. Additionally, they deploy Azure Firewall in a hub VNet connected via VNet peering. All outbound traffic from the app subnet is forced through the firewall using UDRs. The firewall inspects outbound connections for malicious domains using threat intelligence feeds. This layered approach provides security: NSGs block unauthorized east-west traffic, while the firewall monitors north-south traffic. In production, they handle millions of requests per day; NSG performance is negligible, but the firewall must be sized appropriately (they use Premium SKU for TLS inspection). A common misconfiguration is forgetting to update UDRs when adding new subnets, causing asymmetric routing. They also enable NSG flow logs to audit traffic patterns.

A large enterprise with multiple business units (BUs) uses a hub-and-spoke topology. The hub VNet contains shared services (Active Directory, monitoring) and an Azure Firewall. Each BU has its own spoke VNet with multiple subnets. The central security team manages the firewall and creates global rules (e.g., block all traffic to known botnet C2 IPs). Each BU manages its own NSGs for internal segmentation. For example, the finance BU has an NSG that only allows traffic from the finance jumpbox to the finance database subnet. The firewall enforces that no spoke can communicate with another spoke directly; all inter-spoke traffic must go through the firewall, which logs everything for compliance. Performance considerations: with 50 spokes, the firewall must handle high throughput; they use multiple public IPs for SNAT to avoid port exhaustion. A common issue is that some BUs accidentally create NSG rules that conflict with firewall rules, causing connectivity problems. They use Azure Policy to enforce that certain NSG rules cannot be overridden.

A company connects on-premises to Azure via S2S VPN. They want to restrict which on-premises subnets can access Azure VMs. They create an NSG on the Azure subnet that allows inbound traffic only from specific on-premises IP ranges. They also deploy Azure Firewall to inspect traffic between on-prem and Azure for advanced threats. The firewall is placed in the hub VNet, and the VPN gateway connects to the hub. UDRs force all on-prem traffic to the firewall. A common pitfall is that the VPN gateway's public IP is included in the AzureLoadBalancer service tag, which is allowed by default. They must create a custom NSG rule to deny traffic from the internet (including the VPN gateway's public IP) if needed. In production, they monitor the firewall logs to detect unusual traffic patterns, such as a sudden spike in failed authentication attempts from on-prem IPs.