This source did not publish a separate summary. Review SKILL.md before using the skill.
SKILL.md
Azure VNet Networking Security Audit
Cloud resource audit for Azure Virtual Network (VNet) architecture,
network security posture, and hybrid connectivity. This skill evaluates
provider-specific Azure networking constructs — VNet design, NSG priority-
based rules, Azure Firewall rule collection groups, ExpressRoute circuits,
VNet Peering topology, UDR forced tunneling, and Application Gateway
placement — not generic cloud networking advice.
Scope covers VNet-layer networking: address space planning, subnet
delegation, NSG filtering, Azure Firewall inspection, hybrid connectivity
via ExpressRoute and VPN Gateway, and route management. Out of scope:
Azure Front Door CDN policies, Azure WAF custom rule authoring,
application-layer routing in Application Gateway path rules, and Azure
DNS zone management. Reference references/cli-reference.md for read-only
Azure CLI commands organized by audit step, and references/vnet-architecture.md
for the VNet packet flow model, NSG evaluation order, and ExpressRoute
routing architecture.
When to Use
VNet architecture design review — validating address space allocation, subnet delegation, and service endpoint configuration
Post-migration networking audit — verifying VNet connectivity, NSG rules, and UDR entries after workload migration
Compliance preparation — documenting VNet segmentation, NSG justification, and Azure Firewall logging for auditors
Cost optimization review — identifying unused public IPs, orphaned NICs, and underutilized Application Gateway instances
Prerequisites
Azure CLI authenticated (az account show succeeds)
RBAC permissions — Reader role on target subscription, or granular read permissions: Microsoft.Network/virtualNetworks/read, Microsoft.Network/networkSecurityGroups/read, , , , ,
Microsoft.Network/azureFirewalls/read
Microsoft.Network/expressRouteCircuits/read
Microsoft.Network/virtualNetworkGateways/read
Microsoft.Network/routeTables/read
Microsoft.Network/networkInterfaces/read
Target scope identified — specific subscription, resource group(s), and VNet name(s). Multi-subscription audits require az account set per subscription
Network Watcher enabled — NSG Flow Logs and effective security rules require Network Watcher in the target region. If disabled, document as Critical
Procedure
Follow these six steps sequentially. Each step builds on prior findings,
moving from inventory through security analysis to optimization.
Step 1: VNet Inventory and Design Assessment
Enumerate all VNets in the target subscription and assess architectural design.
az network vnet list --output table
az network vnet show --name <vnet-name> --resource-group <rg>
az network vnet subnet list --vnet-name <vnet-name> --resource-group <rg>
For each VNet, evaluate:
Address space allocation: Primary and additional address spaces. Check RFC 1918 compliance, overlapping address spaces across peered VNets (blocks VNet Peering), and sufficient space for growth.
Subnet layout: Identify subnets by purpose — workload subnets, AzureFirewallSubnet (required name for Azure Firewall), GatewaySubnet (required for VPN Gateway and ExpressRoute Gateway), AzureBastionSubnet. Verify required named subnets exist for deployed services.
Subnet delegation: Check delegations to Azure services (Microsoft.Sql/managedInstances, Microsoft.Web/serverFarms). Delegated subnets restrict which resources can deploy — a subnet delegated to SQL Managed Instance cannot host VMs or other services.
Service endpoints vs Private Endpoints: Service endpoints route PaaS traffic over Azure backbone but don't remove public endpoints on the PaaS resource. Private Endpoints create a private IP within the VNet for the PaaS service, removing public exposure entirely. Audit whether data services (Storage, SQL, Key Vault) use Private Endpoints (preferred for zero-trust) or service endpoints (legacy approach with broader exposure).
DDoS Protection: Verify whether DDoS Protection Standard is enabled on the VNet. Basic DDoS protection is automatic for all Azure resources; Standard adds volumetric attack mitigation, cost protection guarantees, and access to the DDoS Rapid Response team.
Step 2: NSG Rule Audit
Audit Network Security Groups using Azure's priority-based evaluation model.
az network nsg list --output table
az network nsg rule list --nsg-name <nsg-name> --resource-group <rg> --include-default --output table
NSG rules evaluate by priority (lowest number = highest priority, range 100–4096). First match wins.
Priority ordering conflicts: An Allow at priority 200 cannot be overridden by a Deny at 300. Verify Deny rules have lower priority numbers than conflicting Allows — inverse of AWS NACL logic.
Default NSG rules: Azure creates three default inbound rules (AllowVNetInBound 65000, AllowAzureLoadBalancerInBound 65001, DenyAllInBound 65500) and three outbound defaults (AllowVNetOutBound, AllowInternetOutBound, DenyAllOutBound). These cannot be deleted but are overridden by any custom rule with lower priority number.
Internet inbound: NSG rules permitting inbound from * or the Internet service tag. SSH/RDP from Internet is Critical; HTTPS on an Application Gateway subnet may be acceptable. The Internet service tag covers all public IP space excluding VNet, peered VNet, and on-premises address ranges.
Effective security rules: NSGs apply at both subnet and NIC level. Azure evaluates subnet NSG first (inbound), then NIC NSG — traffic must pass both. Use az network nic show-effective-nsg to see the combined effective rules with resolved priorities. A rule allowed by subnet NSG but denied by NIC NSG is effectively denied.
Application Security Groups (ASGs): ASGs group NICs for use as source/destination in NSG rules instead of IP ranges. Audit ASG membership for correctness.
Unused NSGs: NSGs not associated with any subnet or NIC are cleanup candidates.
Step 3: Azure Firewall and Network Security
Evaluate Azure Firewall policies, rule collection groups, and threat intelligence.
az network firewall list --output table
az network firewall policy rule-collection-group list --policy-name <policy> --resource-group <rg>
Rule collection group priority: Azure Firewall processes rule collection groups by priority (lowest first). DNAT rules process first, then Network rules, then Application rules.
DNAT rules: Translate inbound traffic to private IPs. Verify each DNAT rule maps to a valid backend. Stale DNAT rules pointing to decommissioned hosts create exposure.
Network rules: Permit/deny by IP, port, protocol. Audit for overly broad rules (* source/destination, wide port ranges).
Application rules: Filter outbound by FQDN/URL. Verify application rules enforce FQDN restrictions for workload internet access.
Threat intelligence mode: Azure Firewall supports threat intelligence filtering in Alert or Deny mode. Verify production firewalls use Deny mode.
IDPS: Azure Firewall Premium supports signature-based IDPS. Verify mode (Alert vs Alert and Deny) and that bypass rules are justified.
Azure Firewall subnet: AzureFirewallSubnet must be /26 or larger with a public IP and UDRs routing traffic through it.
Step 4: Connectivity Analysis
Evaluate hybrid and inter-VNet connectivity through ExpressRoute, VPN Gateway, and VNet Peering.
ExpressRoute:
az network express-route show --name <circuit> --resource-group <rg>
az network express-route peering list --circuit-name <circuit> --resource-group <rg>
Circuit status: Verify ExpressRoute circuit shows "Provisioned" (provider side) and "Enabled" (Azure side). "NotProvisioned" means the provider has not completed circuit setup — no traffic will flow.
BGP peering state: Check Azure Private Peering and Microsoft Peering BGP session state. State should be "Connected" — "Idle" or "Active" without "Connected" indicates peering negotiation failure (ASN mismatch, VLAN ID mismatch, or provider issue).
Advertised routes: Verify on-premises routes are visible in Azure via az network express-route list-route-tables and Azure VNet routes are advertised back to on-premises. Missing routes cause silent traffic drops.
VPN Gateway:
az network vpn-connection show --name <conn> --resource-group <rg>
Connection status: Should show "Connected". "Connecting" indicates IKE/IPsec parameter mismatch.
Gateway SKU: Basic SKU lacks BGP and zone-redundancy. VpnGw2+ recommended for production.
VNet Peering:
az network vnet peering list --vnet-name <vnet> --resource-group <rg> --output table
Peering state: Both sides must show "Connected". "Initiated" means reciprocal peering missing.
Transit settings:AllowGatewayTransit on hub and UseRemoteGateways on spoke enable shared ExpressRoute/VPN. Verify settings match hub-spoke intent.
Address space overlap: VNet Peering requires non-overlapping address spaces. Compare both VNets.
Forwarded traffic:AllowForwardedTraffic must be enabled on both peering links for transit routing through Azure Firewall in the hub.
Step 5: UDR and Routing Validation
Audit User-Defined Routes for correctness, forced tunneling, and conflicts.
az network route-table list --output table
az network route-table route list --route-table-name <rt> --resource-group <rg>
az network nic show-effective-route-table --name <nic> --resource-group <rg>
Forced tunneling: UDRs with 0.0.0.0/0 next-hop to Azure Firewall or NVA force internet traffic through inspection. Verify forced tunneling is NOT applied to AzureFirewallSubnet, GatewaySubnet, or AzureBastionSubnet.
Asymmetric routing: Inbound via ExpressRoute but return via Azure Firewall UDR causes asymmetry. Verify UDR next-hop addresses match expected traffic paths in both directions.
Effective routes per NIC: Azure resolves UDR > BGP > system routes. Use az network nic show-effective-route-table for final effective routes.
BGP route propagation: UDR tables can disable BGP propagation (disableBgpRoutePropagation). When disabled, ExpressRoute/VPN routes are not injected. Verify this matches routing design.
Next-hop validation: UDR routes to virtual appliance IPs must reference running, healthy NVAs or Azure Firewall. A stopped VM next-hop creates a silent black hole.
Step 6: Report and Optimization
Compile findings and identify resource optimization opportunities.
az network nic list --query "[?virtualMachine==null]" --output table
az network public-ip list --query "[?ipConfiguration==null]" --output table
Orphaned NICs: NICs not attached to a VM — common after deletions. Each may have NSG rules and private IPs consuming address space.
Unassociated public IPs: Standard SKU public IPs incur charges when unassociated. Release or associate.
If Network Watcher NSG Flow Logs are not configured, traffic visibility is
limited to NSG hit counts. NSG Flow Logs require Network Watcher enabled
and a storage account. Version 2 includes throughput data. Document
missing Flow Logs as High.
Effective Security Rules Show Unexpected Allows
Use az network nic show-effective-nsg for combined subnet and NIC NSG
rules. Check for: higher-priority Allow in NIC NSG overriding subnet Deny,
default rules (65000+) permitting VNet-to-VNet traffic, or ASG membership
including unintended NICs.
ExpressRoute BGP Session Not Established
Verify VLAN ID matches between Azure and provider. Check BGP ASN matches
on-premises router. Use az network express-route peering show to compare
settings. Both primary and secondary should show "Connected".
VNet Peering Shows Initiated But Not Connected
Both peering links must be created. "Initiated" means only one side is
configured. Create the reciprocal link. Cross-subscription peering requires
RBAC on both subscriptions.
UDR Causing Asymmetric Routing
When ExpressRoute delivers inbound traffic directly but UDR routes return
traffic through Azure Firewall, asymmetric routing occurs — the firewall
drops return packets with no session state. Ensure UDR routes both
directions through the firewall, or configure Azure Firewall SNAT.
