Azure Firewall Premium: IDPS and TLS Inspection

Azure Firewall Premium is a managed, cloud-native network security service that provides advanced threat protection. Two of its key features are IDPS and TLS inspection. IDPS (Intrusion Detection and Prevention System) inspects network traffic for malicious patterns, known as signatures, and can alert or block traffic based on those signatures. TLS inspection allows the firewall to decrypt outbound TLS traffic (HTTPS), inspect the plaintext content, and then re-encrypt it before forwarding to the destination. This enables the firewall to enforce URL filtering, malware detection, and IDPS rules on encrypted traffic.

Most internet traffic today is encrypted (TLS). Traditional network security tools that cannot inspect encrypted traffic are blind to threats hidden inside HTTPS connections. IDPS without TLS inspection can only analyze metadata (IP addresses, ports, SNI headers) but not the actual payload. TLS inspection solves this by acting as a man-in-the-middle (MITM) proxy. It terminates the client's TLS connection, inspects the decrypted traffic, and then initiates a new TLS connection to the destination. This allows the firewall to apply security policies to the content. IDPS then works on the decrypted payload.

IDPS in Azure Firewall Premium uses a signature-based detection engine. Signatures are patterns that match known vulnerabilities, exploits, malware, and attack techniques. The engine examines each packet's payload (after decryption if TLS inspection is enabled) against its signature database. The database is continuously updated by Microsoft via the Microsoft Defender Threat Intelligence feed.

When a packet arrives, the firewall performs the following steps: 1. Packet capture: The firewall receives the packet and extracts the payload. 2. Decryption (if TLS inspection enabled): If the packet is TLS encrypted and matches a rule that requires inspection, the firewall decrypts it using the configured CA certificate. 3. Protocol decoding: The engine identifies the application protocol (HTTP, SMTP, etc.) and normalizes the data. 4. Pattern matching: The engine compares the normalized payload against the signature database. This is a multi-pattern matching algorithm (like Aho-Corasick) that can match thousands of signatures simultaneously. 5. Action determination: If a match is found, the configured action (alert or deny) is applied. If multiple signatures match, the most severe action is taken. 6. Re-encryption (if TLS inspection enabled): The firewall re-encrypts the packet and forwards it.

TLS inspection requires the firewall to have a trusted root Certificate Authority (CA) certificate. This certificate is used to dynamically generate certificates for each destination domain that the client connects to. The process is:

To enable IDPS and TLS inspection:

You can use Azure Monitor, Firewall logs, and the following Azure CLI commands:

# List all IDPS signatures
az network firewall policy intrusion-detection signature list --policy-name <policy-name> --resource-group <rg>

# Override a signature action
az network firewall policy intrusion-detection signature override add --policy-name <policy-name> --resource-group <rg> --id <signature-id> --state Alert

# Show TLS inspection configuration
az network firewall policy tls-inspection show --policy-name <policy-name> --resource-group <rg>

A bank wants to prevent sensitive data (like credit card numbers) from being exfiltrated via HTTPS. They deploy Azure Firewall Premium with TLS inspection on all outbound traffic. They upload their internal CA certificate and distribute it to all corporate VMs via Group Policy. They create a rule to inspect all HTTPS traffic to external destinations. The IDPS is configured in Prevention mode with custom signatures that match patterns of credit card numbers (using regex). In production, they noticed that some internal applications (like Office 365) broke because the firewall’s certificate was not trusted by those services. They had to create bypass rules for trusted Microsoft domains. Performance was a concern: with full TLS inspection, firewall CPU usage reached 80% during peak hours. They mitigated by using selective inspection—only inspecting traffic to non-whitelisted domains. Misconfiguration example: an engineer set the TLS inspection action to "Bypass" for all traffic, effectively disabling inspection, but IDPS still ran on the encrypted traffic (which is useless). The correct approach is to enable TLS inspection and set IDPS to Prevention.

A hospital network uses Azure Firewall Premium to protect its Azure workloads. They enable IDPS in Prevention mode and TLS inspection for outbound HTTPS. They configure signature overrides to block all signatures with severity High and Critical. During a security incident, the firewall blocked traffic to a known malware command-and-control (C2) domain. The IDPS signature ID 123456 matched the C2 traffic. However, the hospital’s security team found that some legitimate traffic to a third-party healthcare API was also blocked because it matched a generic SQL injection signature. They had to create an exception for that API’s IP range. Common pitfall: the team initially forgot to distribute the CA certificate, so all clients had certificate errors. They resolved by deploying the certificate via Azure Policy Guest Configuration. Scale: they handle 10 Gbps of outbound traffic; the firewall scaled automatically but they monitored CPU and memory.

An online retailer must comply with PCI DSS, which requires monitoring all traffic to cardholder data environments (CDE). They deploy Azure Firewall Premium with IDPS and TLS inspection to inspect all traffic to the CDE. They use a dedicated CA certificate that is trusted only by the CDE servers. They configure IDPS to alert on any attempt to access the CDE from unauthorized IPs. During a penetration test, the IDPS detected and blocked an SQL injection attempt. The firewall logs showed the decrypted HTTP request with the malicious payload. The security team used Azure Sentinel to correlate firewall logs with other sources. One issue: the firewall’s TLS inspection added 3-5 ms latency, which was acceptable. Misconfiguration: they initially set IDPS mode to Detection instead of Prevention, so the attack was logged but not blocked. They corrected this after the test.