Concepts

High Availability and Availability Zones

High availability is built in (99.95% SLA)
Availability zones support - 99.99% uptime SLA is offered when two or more Availability Zones are selected

Notes:

No additional cost for a firewall deployed in an Availability Zone but inbound and outbound data transfers associated with Availability Zones will be charged
Availability Zones can only be configured during deployment. We can’t configure an existing firewall to include Availability Zones

Firewall policy is the collection of rules - Application rules, Network rules and NAT rules
Firewall policy is a global resource that can be used across multiple Azure Firewall instances
Firewall Policy is the recommended method to configure your Azure Firewall
Policies can be associated with one or more virtual hubs (Secured Virtual Hubs) or VNets (Hub Virtual Networks)
Policies work across regions and subscriptions
Hierarchy: a policy can inherit from parent policy

Policy type

SNAT stands for “Source Network Address Translation”
SNAT allows traffic from a private network to go out to the internet using Firewall public IP
Azure Firewall provides automatic SNAT for all outbound traffic to public IP addresses. All outbound virtual network traffic IP addresses are translated to the Azure Firewall public IP
By default, Azure Firewall doesn’t SNAT with Network rules when the destination IP address is in a private IP address range
If you enable forced tunneling, Internet-bound traffic is SNATed to one of the firewall private IP addresses in AzureFirewallSubnet, hiding the source from your on-premises firewall

DNAT stands for “Destination Network Address Translation”
DNAT allows access to a resource protected by Firewall using Firewall IP
Inbound Internet connectivity can be enabled by configuring Azure Firewall DNAT
Destination Network Address Translation is used by an external host to initiate connection with a private network
NAT rules are applied in priority before network rules

Layer-7 (application layer in OSI model) rule to allow or deny URL based traffic (both inbound and outbound)
Determines whether the application should be allowed or blocked
- Which protocol is allowed
- Which port is allowed
Azure firewall uses “transparent proxy” for application rules
Application rules are always SNATed

Layer-4 (transport layer) rules to allow or deny “IP:port”
Determines whether TCP or UDP or other layer-4 based protocols should be allowed or blocked
- Which protocol is allowed
- Which IP or IP range (CIDR) is allowed
- Which port is allowed
Network rules are processed before application rulee
Layer 3 IP protocols can be filtered by selecting Any protocol in the Network rule and select the wild-card * for the port

FQDN stands for “fully qualified domain names”
FQDN is used in Application rules
FQDN is used to limit outbound HTTP/S traffic or Azure SQL traffic to a specified list of fully qualified domain names including wild cards
FQDN feature does not require TLS termination

If “DNS proxy” is enabled, then FQDN can be used in network rule
The specified FQDNs in your rule collections are translated to IP addresses based on your firewall DNS settings

A FQDN tag is a collection of FQDNs for a particular Azure service i.e. FQDN tag for AKS
Azure manages and periodically updates all FQDNs for FQDN tags
FQDN tags make it easy for you to allow well-known Azure service network traffic through firewall using Application rule
Example: force AKS egress traffic through Firewall and use “AzureKubernetesService” FQDN tag to allow AKS management traffic

A service tag represents a group of IP address prefixes (address spaces in CIDR notation)
Service tag minimizes the complexity for security rule creation
We can’t create your own service tag, nor specify which IP addresses are included within a tag
Microsoft manages the address prefixes encompassed by the service tag, and automatically updates the service tag as addresses change

Azure Firewall can be configured to listen for DNS query (UDP, port 53) by enabling “DNS proxy” feature
This functionality is crucial and required to have reliable FQDN filtering in network rules
Details: Azure Firewall DNS proxy for name resolution

Azure Firewall has “threat intelligence-based filtering” feature that (when enabled) allows firewall to alert and deny traffic from/to known malicious IP addresses and domains
IP addresses and domains (used for threat intelligence-based filtering) are sourced from the Microsoft Threat Intelligence feed, which includes multiple sources
- Microsoft Cyber Security team
- Intelligent Security Graph (also used by Microsoft Defender for Cloud)
When enabled threat intelligence-based filtering, the associated rules are processed before any of the NAT rules, network rules, or application rules
Modes:
- Alert
- Alert and deny
- Note: Alert in this context means just log an alert when a rule is triggered (you need to set alert notification by using action group in log analytics)

Forced tunneling lets us redirect or “force” all Internet-bound traffic back to on-premises NVA for inspection and auditing. If we don’t configure forced tunneling, Internet-bound egress will traverse from virtual network to the Internet directly
Azure Firewall allows to route all Internet-bound traffic to a designated next hop (i.e. IP of on-premises edge Firewall) instead of going directly to the Internet
To support forced tunneling, you must create Azure Firewall with Forced Tunnel configuration enabled (this is a mandatory requirement to avoid service disruption)
With forced tunneling enabled, Internet-bound traffic is SNATed to one of the firewall private IP addresses in the AzureFirewallSubnet
- By default, Azure Firewall provides automatic SNAT for all outbound traffic to public IP addresses
- We can configure Azure Firewall to not SNAT regardless of the destination IP address by adding 0.0.0.0/0 as your private IP address range

Extends FQDN filtering capability to consider an entire URL i.e. “https://hovermind.com/azure” instead of “https://hovermind.com”
URL Filtering can be applied both on HTTP and HTTPS traffic
If TLS inspection is enabled, we can use URLs for filtering with HTTPS

Allows us to categorize websites and use it in Firewall rule to allow or deny
Lets use allow or deny user access to web site categories such as gambling websites, social media websites, and others
Available for both Firewall Standard and Firewall Premium, but more fine-tuned in Azure Firewall Premium
- Firewall Standard: only the FQDN part will be examined i.e. “www.searchengine.com” will be categorized as Search Engine
- Firewall Premium: the complete URL will be examined i.e. “www.searchengine.com/news” will be categorized as News

IDPS stands for “Intrusion Detection and Prevention System”
IDPS monitors network for malicious activities, logs activity related data, reports it, and attempts to block it
Details: IDPS feature of Azure Firewall Premium