8.3 Azure Firewall

Azure Firewall on the SC-500 Blueprint

Implement and configure Azure Firewall sits in the networking security skill set. Azure Firewall is a managed, cloud-native stateful firewall for Azure Virtual Network traffic—centralized east-west and north-south filtering, threat intelligence, and (on Premium) deep inspection. Prefer it over a zoo of unmanaged NVAs when you want Azure-native HA, autoscaling characteristics, Firewall Manager policy hierarchy, and integration with hub-and-spoke or Virtual WAN hubs.

Azure Firewall SKUs commonly contrasted on exams:

For SC-500, focus on Standard vs Premium decision points: if the scenario mandates TLS inspection, IDPS, or full URL path filtering on encrypted traffic, answer Premium.

---

Premium Features in Depth

TLS inspection

Azure Firewall Premium can decrypt outbound (and east-west) TLS, inspect content, then re-encrypt to the destination (forward proxy model). It establishes TLS with the client and separately with the server. Certificates for interception are managed with Azure Key Vault.

Exam notes:

• TLS inspection is not automatic on Premium—you enable it in policy and application rules.
• Inbound internet TLS reverse-proxy inspection for HTTP apps is often paired with Application Gateway + WAF; do not assume Firewall Premium replaces WAF for Layer-7 web attacks.
• Standard can still filter HTTPS using SNI/FQDN without decrypting payload.

IDPS

Intrusion Detection and Prevention System on Premium is signature-based, with a large ruleset (on the order of tens of thousands of signatures across 50+ categories, with frequent updates). Modes:

• Alert — detect and log
• Alert and deny — block matching malicious traffic

IDPS inspects non-encrypted traffic broadly; for HTTPS payloads, combine with TLS inspection so signatures see cleartext. Start with Alert mode in production cutovers, then move to deny after tuning.

URL filtering and web categories

• URL filtering (Premium) evaluates the full URL path, not only the hostname—requires TLS inspection for HTTPS paths.
• Web categories allow/deny groups of sites (social media, gambling, etc.) for user egress control.

---

Rule Types: DNAT, Network, Application

Azure Firewall uses rule collection groups → rule collections → rules. All matching is terminating when a rule hits; traffic that matches nothing is denied by default.

Processing order (memorize)

With Firewall Policy, processing concepts you must know:

1. Threat intelligence filtering (when enabled) is evaluated with highest priority—can block before your DNAT/network/application rules.
2. Within configured rules, the firewall walks rule collection groups by priority, processing rule types in this order: DNAT → Network → Application.
3. Parent policy settings/rules take precedence over child policy inheritance in hierarchical designs.
4. Rule collection action (Allow/Deny) applies to rules inside that collection; priorities decide order.

Exam trap: An allow application rule never “overrides” a matching network deny that already handled the flow in the network pass—or TI deny that fired first. Design priorities deliberately; do not assume later application allows resurrect denied traffic.

Threat intelligence modes

Use Alert and deny for production internet egress when false-positive process is mature.

---

Azure Firewall Manager and Policies

Azure Firewall Manager centralizes security policy and hub configurations across:

• Hub virtual networks (secured virtual hubs / traditional hub VNets with Firewall)
• Azure Virtual WAN secure hubs
• Hierarchical Firewall Policy objects (parent/child) for platform vs application teams

Firewall Policy (recommended over classic per-firewall classic rules alone) stores:

• Rule collection groups and rules
• Threat intelligence mode
• DNS settings / DNS proxy
• Intrusion detection (Premium)
• TLS inspection settings (Premium)
• IDPS signature overrides

Benefits for SC-500 architecture answers: one policy → many firewalls, inheritance for base deny/allow sets, and consistent governance across regions.

---

Forced Tunneling

Forced tunneling sends Azure subnet internet-bound traffic to on-premises inspection appliances (via ExpressRoute/VPN) instead of breaking out directly from Azure.

Azure Firewall forced tunneling specifics:

Exam trap: Forgetting AzureFirewallManagementSubnet breaks firewall management when forced tunneling is enabled. Do not force 0.0.0.0/0 for management through on-premises.

---

Hub-and-Spoke Integration

Canonical pattern:

1. Deploy Azure Firewall in the hub VNet (AzureFirewallSubnet, /26 recommended historically for scale).
2. Peer spokes to hub (Use remote gateway patterns as designed; no gateway transit conflicts).
3. On spoke subnets, UDR 0.0.0.0/0 (and/or specific prefixes) → Firewall private IP as next hop virtual appliance.
4. On hub, ensure return paths and avoid asymmetric routing through other NVAs without care.
5. Attach Firewall Policy with shared platform rules + app-specific collections.
6. Optionally integrate Firewall Manager, NAT Gateway for SNAT scale, and logging to Log Analytics/Sentinel.

Availability: Use Availability Zones for Firewall in supported regions for higher SLA. Pair with zone-redundant public IPs where applicable.

---

Operational Notes and Exam Scenarios

Scenario A — Healthcare TLS mandate. Inspect HTTPS egress for malware.
Answer: Azure Firewall Premium, enable TLS inspection + IDPS, Key Vault certificates, application rules with TLS inspection flag.

Scenario B — Publish RDP only through firewall.
Answer: DNAT rule on Firewall public IP to jump host private IP; restrict source IPs; prefer Bastion for admin instead when the goal is Azure VM management (know both tools).

Scenario C — Central policy for 12 hubs.
Answer: Firewall Manager + parent Firewall Policy inheritance.

Scenario D — All Azure egress must hit on-premises DLP.
Answer: Forced tunneling with management subnet internet route; accept DNAT limitations.

SC-500 Exam Traps (Azure Firewall)

• Premium-only: TLS inspection, IDPS, full URL filtering.
• TI can deny before your allow rules.
• Rule type order: DNAT → Network → Application (after TI).
• Forced tunneling needs management subnet; DNAT unsupported.
• Firewall ≠ WAF: web app OWASP protection → Application Gateway/Front Door WAF.
• UDRs in spokes are what actually steer traffic into the firewall—deploying Firewall without UDRs does nothing for spoke egress.

Hardening Checklist

1. Choose SKU (Standard vs Premium) from inspection requirements.
2. Deploy in hub with correct subnets and zones.
3. Use Firewall Policy + Manager hierarchy.
4. Enable TI (alert → deny).
5. Prefer FQDN application rules + DNS proxy for outbound.
6. Add Premium TLS/IDPS when regulated.
7. Steer spokes with UDRs; log to Sentinel.
8. Document forced-tunnel exceptions and DNAT constraints.