Network security

Which control for which job

Network security groups

Rules

• An NSG holds inbound and outbound security rules. Each rule has: priority (100–4096, lower number first), name, source and destination (IP, CIDR, service tag, or ASG), service/port (protocol, port ranges), and action (Allow or Deny).
• Stateful: if an inbound flow is allowed, the return traffic is allowed automatically (no matching outbound rule needed), and the reverse.
• First match wins. Evaluation stops at the first matching rule by priority.
• Default rules (can’t be deleted, priority 65000+, but can be overridden by your lower-numbered rules):

• Service tags (for example Internet, VirtualNetwork, AzureLoadBalancer, Storage, Sql, AzureCloud, GatewayManager, AzureFrontDoor.Backend) are Microsoft-maintained prefix lists. Augmented rules allow several IPs, ranges and ports in one rule. Limit: about 1,000 rules per NSG.
• Default allow VNet-to-VNet means subnets in the same VNet (and peered VNets, since peered ranges are in the VirtualNetwork tag) can talk by default. Add a Deny rule with a lower number to segment.

Association and evaluation

• Associate an NSG to a subnet, a NIC, or both. One NSG per subnet or NIC. An NSG can be shared by many.
• If both exist, inbound traffic is evaluated by the subnet NSG first, then the NIC NSG. Outbound goes NIC NSG first, then subnet NSG. Traffic must be allowed by both.
• Best practice is to associate at the subnet and keep NIC-level NSGs for exceptions.
• NSGs don’t apply to the platform address 168.63.129.16 for DHCP and DNS (always allowed), and don’t filter traffic of some PaaS in managed networks. Don’t attach one to GatewaySubnet (unsupported, can break the gateway).
• To allow Azure Load Balancer health probes, keep AzureLoadBalancer inbound allowed (the default rule does it, unless you override with a Deny).

Application security groups

An ASG groups NICs (usually by role: web, app, db). Use ASGs as the source or destination in NSG rules, for example “allow asg-web → asg-db on 1433”. Benefits: no IP maintenance, rules follow the VMs. Rules:

• A NIC can belong to several ASGs, and all must be in the same VNet as the NIC.
• If a rule uses ASGs as both source and destination, both ASGs must be in the same VNet.
• Associate by editing the NIC (or the VM’s networking) and adding the ASG. You can’t associate an ASG with a subnet.

Remote administration and Azure Bastion

Avoid exposing RDP/SSH. Choices: Azure Bastion, just-in-time VM access (Defender for Servers, which adds temporary NSG allow rules), or a VPN.

Azure Bastion gives RDP/SSH over TLS 443 from the portal (or native client) to VMs with private IPs, no public IP on the VM and no agent.

Required NSG rules on AzureBastionSubnet (if you attach an NSG):

On the target VM subnets, the NSG must allow inbound 22/3389 from the AzureBastionSubnet range and not from the internet. Bastion in a hub reaches peered spokes (Standard/Premium, with peering).

Virtual network flow logs

• VNet flow logs capture IP flow information for the whole VNet, subnet or NIC (all supported workloads, not just NSG-governed), stored as JSON in a storage account, with optional Traffic Analytics (Log Analytics workspace) for visualisation, top talkers and threat detection. They replace NSG flow logs (new NSG flow logs couldn’t be created after 30 June 2025, and NSG flow logs retire on 30 September 2027).
• Each record shows the 5-tuple, direction, flow state (begin, continuing, end, denied) and bytes/packets. VNet flow logs include flows allowed or denied by NSGs and by Virtual Network Manager security admin rules, and encryption state (for virtual network encryption).
• Retention is set per log on the storage account (0 = forever).
• Interpreting: read the flow tuples to see who talked to whom and whether it was allowed or denied. Use Traffic Analytics KQL tables (NTANetAnalytics) to find denied flows, blocked inbound from the internet, or unexpected east-west traffic. Network Watcher must be enabled in the region.

IP flow verify

IP flow verify (Network Watcher) tests whether a packet to or from a VM is allowed, given protocol, direction, local and remote IP and port. It tells you Allow or Deny and the name of the NSG rule. It tests NSGs (and AVNM security admin rules), not routing, firewalls, or the guest OS firewall. Use Effective security rules for the merged list, NSG diagnostics for a flow across the path, and Connection troubleshoot for end-to-end.

Azure Virtual Network Manager (security)

Security admin configuration applies security admin rules to network groups across VNets. They are evaluated before NSGs:

Use it for rules like “block RDP/SSH from the internet everywhere” or “allow monitoring ports always”, where owners of workload NSGs mustn’t be able to override. Apply to network groups (static or dynamic) and deploy the configuration. They apply to VMs in the VNets but not by default to some managed services. AVNM security admin rules aren’t a replacement for a firewall.

Azure Firewall

Azure Firewall is a managed, stateful, cloud-native firewall as a service with built-in HA and autoscaling and unlimited scale. Typically in a hub VNet or a Virtual WAN hub (secured hub).

SKUs

Pick Premium for TLS inspection, IDPS, URL filtering or full web categories. Pick Standard for FQDN and network filtering with threat intelligence. Pick Basic for small, cost-sensitive. You can upgrade (Basic → Standard → Premium) and downgrade by recreating or with policy and SKU change.

Design and deployment

• Deploy in AzureFirewallSubnet (/26) with one or more Standard static public IPs, and for Basic or forced tunneling, AzureFirewallManagementSubnet (/26) and a management public IP.
• Availability zones: deploy across zones for 99.99% availability (vs 99.95% without zones).
• Scaling: automatic. Add public IPs for more SNAT ports (each gives ~2,496 ports per backend IP), or place a NAT Gateway on the AzureFirewallSubnet for up to 16 IPs and 64,512 ports each. Premium and Standard can use many public IPs.
• Hub-and-spoke: firewall in the hub, spokes have UDRs 0.0.0.0/0 → firewall private IP, peering with allow forwarded traffic. Return traffic must come back through the same firewall (watch asymmetric routing).
• Forced tunneling: the management NIC keeps internet access for the platform while workload traffic goes to on-premises.
• Private IP ranges for SNAT: by default the firewall does not SNAT to private (RFC 1918) destinations and does SNAT to public destinations. Change this to SNAT private ranges (for on-premises traffic) or always.
• Firewall as DNS proxy lets FQDN rules work for clients and gives name resolution with a consistent answer between client and firewall. Set VNet DNS to the firewall IP.
• Structured/resource-specific logs to Log Analytics (application rule, network rule, DNS proxy, threat intel logs), with workbooks.

Rules

Processing: DNAT → Network → Application, then deny by default. Rules are grouped in rule collections (action Allow or Deny, priority 100–65000) inside rule collection groups (priority). Inside a type, collections run by priority, and the first match ends processing. Network rules take precedence over application rules, so a matching allow network rule bypasses application rules.

Other features: FQDN tags (Windows Update, Azure Backup…), service tags, IP Groups, threat intelligence (alert or alert-and-deny against Microsoft’s feed), infrastructure FQDN rules, custom DNS, and in Premium TLS inspection (needs a CA certificate in Key Vault and trusted by clients), IDPS (signature-based, over 58,000 signatures, modes off/alert/alert and deny) and URL filtering.

Azure Firewall Manager

Firewall Manager centrally manages many firewalls across regions and subscriptions.

• Azure Firewall Policy is a top-level resource of rules, threat intelligence, DNS settings, IDPS and TLS inspection settings. Policies are hierarchical: a parent (base) policy from the central security team, with child policies inheriting it and adding local rules. Child rule collections can’t override parent rules.
• Policy association: associate a policy to a firewall in a hub VNet or a secured virtual hub.
• Two architectures:
  • Hub virtual network: a standard VNet you manage with a firewall, plus Firewall Manager policy.
  • Secured virtual hub: a Virtual WAN hub with Azure Firewall (a secure hub) and routing intent or Firewall Manager routing to send internet and/or private traffic through it. No UDRs to maintain.
• Security partner providers (Zscaler, Check Point, iboss) for branch-to-internet in a secured hub.
• Also manages DDoS plans and WAF policies.

Create a secure hub

1. Create a Virtual WAN (Standard) and a virtual hub.
2. In Firewall Manager → Virtual hubs → Convert to secured virtual hub, or deploy Azure Firewall into the hub with a policy.
3. Set routing intent / routing policies (Internet traffic and private traffic) to send branch and VNet traffic through the firewall.
4. Verify with firewall logs and effective routes.

Web Application Firewall

WAF protects web apps from common exploits (SQL injection, cross-site scripting, protocol violations, bots) at layer 7. It’s a feature of Application Gateway (WAF_v2), Front Door (Premium or Standard) and Azure CDN, and uses a WAF policy resource.

Modes

• Detection: logs matching requests, doesn’t block. Use for tuning when first deploying.
• Prevention: blocks matching requests (default 403) and logs. Start in Detection, tune exclusions, then switch to Prevention.

Rule evaluation

• Anomaly scoring (CRS 3.x, DRS 2.x): each matched rule adds a severity score (Critical 5, Error 4, Warning 3, Notice 2). When the total reaches the threshold of 5, the request is blocked (in Prevention). Without scoring (older CRS 2.x), each match is independent.
• Order: custom rules first (by priority), then managed rules. A custom rule with Allow ends evaluation and skips the managed rules. Block ends with a block. Log continues.
• Exclusions stop specific request elements (header, cookie, query arg, body field) from being inspected by a rule or rule group, which fixes false positives without disabling a rule. Disable rules or whole rule groups when needed. Adjust request body inspection, size limits, and file upload limits in policy settings.

Policy implementation and association

• Create a WAF policy (Application Gateway WAF or Front Door WAF), choose mode, managed rule set version, custom rules, exclusions and policy settings (custom block response code and body, redirect URL).
• Application Gateway: associate to the gateway (applies to all listeners), a listener (per-site), or a path rule (per-URI). The most specific association wins: URI over site over global.
• Front Door: create a security policy that links the WAF policy to endpoints/custom domains (and paths).
• Logs: ApplicationGatewayFirewallLog and FrontdoorWebApplicationFirewallLog in Log Analytics or storage. Set alerts on blocked requests.
• Prefer a WAF policy over the legacy inline WAF configuration on Application Gateway. The policy supports the new features and per-site policies.

Where to put the WAF