Azure Network Security Blog articles

Assess Azure DDoS Protection Status Across Your Environment

SaleemBseeu — Thu, 26 Mar 2026 15:36:26 GMT

Introduction

Distributed Denial of Service (DDoS) attacks continue to be one of the most prevalent threats facing organizations with internet-facing workloads. Azure DDoS Protection provides cloud-scale protection against L3/4 volumetric attacks, helping ensure your applications remain available during an attack.

However, as Azure environments grow, maintaining visibility into which resources are protected and whether diagnostic logging is properly configured becomes increasingly challenging. Security teams often struggle to answer basic questions:

Which Public IP addresses are protected by Azure DDoS Protection?
Are we using IP Protection or Network Protection (DDoS Protection Plan)?
Is diagnostic logging enabled for protected resources?

To address these questions at scale, we’ve developed a PowerShell script that assesses your Azure DDoS Protection posture across all subscriptions.

Understanding Azure DDoS Protection SKUs

Azure offers three DDoS Protection tiers:

Protection Type	Description	Scope
Network Protection	Enterprise-grade protection via a DDoS Protection Plan attached to VNETs	All Public IPs in protected VNETs
IP Protection	Per-IP protection for individual Public IP addresses	Individual Public IP

For more details, see Azure DDoS Protection overview.

The Assessment Script

The Check-DDoSProtection.ps1 script provides a full view of DDoS Protection status across your Azure environment. This section covers the script’s key capabilities and the resource types it supports.

Key Features

Multi-subscription support: Scan a single subscription or all subscriptions you have access to
DDoS Protection status: Identifies which Public IPs are protected and which SKU is being used
VNET correlation: Automatically determines the VNET associated with each Public IP to assess Network Protection inheritance
Diagnostic logging check: Verifies if DDoS diagnostic logs are configured for protected resources
CSV export: Export results for further analysis or reporting

Prerequisites

Before running the script, ensure you have:

Azure PowerShell modules installed:

Run the following commands in PowerShell (version 5.1+) or PowerShell Core to install the required Azure modules. No special permissions are needed, these will install in your user profile.

Install-Module -Name Az.Accounts -Scope CurrentUser -Force Install-Module -Name Az.Network -Scope CurrentUser -Force Install-Module -Name Az.Monitor -Scope CurrentUser -Force

Appropriate Azure permissions:

o Reader role on subscriptions you want to scan

o Microsoft.Network/publicIPAddresses/read

o Microsoft.Network/virtualNetworks/read

o Microsoft.Insights/diagnosticSettings/read

Azure login:

Authenticate to Azure before running the script. This opens a browser window for interactive sign-in.

Connect-AzAccount

How to Use the Script

Run the script from a PowerShell session where you’ve already authenticated with Connect-AzAccount. The account must have Reader role on the subscriptions you want to scan.

Download the Script

You can download the script from: - GitHub: Check-DDoSProtection.ps1

Basic Usage: Scan Current Subscription

Scans only the subscription currently selected in your Azure context.

.\Check-DDoSProtection.ps1

Scan a Specific Subscription

Scans a single subscription by its ID.

.\Check-DDoSProtection.ps1 -SubscriptionId "12345678-1234-1234-1234-123456789012"

Scan All Subscriptions

Scans every subscription your account has Reader access to.

.\Check-DDoSProtection.ps1 -AllSubscriptions

Export Results to CSV

Exports the assessment results to a CSV file for reporting or further analysis.

.\Check-DDoSProtection.ps1 -AllSubscriptions -ExportPath "C:\Reports\DDoS-Report.csv"

Large Environment Options

For organizations with many subscriptions or thousands of Public IPs, use the following parameters to handle errors gracefully and avoid API throttling.

.\Check-DDoSProtection.ps1 -AllSubscriptions ` -ContinueOnError ` -SavePerSubscription ` -ExportPath "C:\Reports\DDoS-Report.csv" ` -ThrottleDelayMs 200

Parameters for large environments:

Parameter	Description
-ContinueOnError	Continue scanning even if a subscription fails (e.g., access denied)
-SavePerSubscription	Save a separate CSV file for each subscription
-ThrottleDelayMs	Delay between API calls to avoid throttling (default: 100ms)

Understanding the Output

The script provides both console output and optional CSV export. This section covers what each output type contains.

Console Output

The script displays a summary table for each subscription:

Summary Statistics

At the end of each subscription scan:

CSV Export Columns

Column	Description
Subscription	Name of the Azure subscription
Public IP Name	Name of the Public IP resource
Resource Group	Resource group containing the Public IP
Location	Azure region
IP Address	Actual IP address (or “Dynamic” if not allocated)
IP SKU	Basic or Standard
DDoS Protected	Yes/No
Risk Level	High (unprotected) / Low (protected)
DDoS SKU	Network Protection, IP Protection, or None
DDoS Plan Name	Name of the DDoS Protection Plan (if applicable)
VNET Name	Associated Virtual Network name
Associated Resource	Resource the Public IP is attached to
Resource Type	Type of associated resource (VM, AppGw, LB, etc.)
Diagnostic Logging	Configured/Not Configured/N/A
Log Destination	Log Analytics, Storage, Event Hub, or None
Recommendation	Suggested action for unprotected resources

Sample Scenarios

Scenario 1: Protected Application Gateway

Public IP Name: appgw-frontend-pip
DDoS Protected: Yes
DDoS SKU: Network Protection
DDoS Plan Name: contoso-ddos-plan
VNET Name: production-vnet
Diagnostic Logging: Configured (Log Analytics)
Risk Level: Low

Explanation: The Application Gateway’s Public IP inherits protection from the VNET which has a DDoS Protection Plan attached. Diagnostic logging is properly configured.

Scenario 2: Unprotected External Load Balancer

Public IP Name: external-lb-pip
DDoS Protected: No
DDoS SKU: VNET not protected
VNET Name: (External LB)
Diagnostic Logging: N/A
Risk Level: High
Recommendation: Enable DDoS Protection on associated VNET or enable IP Protection

Explanation: This external Load Balancer’s Public IP is not in a protected VNET. The script flags this as high risk.

Scenario 3: IP Protection Without Logging

Public IP Name: standalone-api-pip
DDoS Protected: Yes
DDoS SKU: IP Protection
VNET Name: -
Diagnostic Logging: Not Configured
Risk Level: Low
Recommendation: Configure diagnostic logging for DDoS-protected resources

Explanation: The IP has IP Protection enabled, but diagnostic logging is not configured. While protected, you won’t have visibility into attack telemetry.

Troubleshooting

Script Doesn’t Find All Subscriptions

Use the following command to list your Azure role assignments and verify you have Reader access to the target subscriptions. Run this from Azure Cloud Shell or a local PowerShell session after authenticating with Connect-AzAccount.

# Check your role assignments

Get-AzRoleAssignment -SignInName (Get-AzContext).Account.Id | Select-Object Scope, RoleDefinitionName

API Throttling

The script includes built-in retry logic for API throttling. If you still experience rate limit errors, increase the delay between API calls. Run this from the directory containing the script.

.\Check-DDoSProtection.ps1 -AllSubscriptions -ThrottleDelayMs 500

Access Denied for Specific Resources

The script displays “(Access Denied)” for VNETs or resources you don’t have permission to read. This doesn’t affect the overall assessment but may result in incomplete VNET information.

Summary

This guide covered how to use the Check-DDoSProtection.ps1 script to identify unprotected Public IP addresses, determine which DDoS SKU (Network Protection vs. IP Protection) is in use, verify diagnostic logging configuration, and assess risk levels across all subscriptions. Running this script periodically helps security teams track protection coverage as their Azure environment evolves.

Related Resources

Azure Bastion: Enterprise-grade secure access made simple

ShabazShaik — Thu, 19 Mar 2026 14:32:39 GMT

Managing secure remote access to virtual machines traditionally means juggling public IP addresses, configuring jump boxes, deploying VPN infrastructure, and managing complex firewall rules. Each layer adds cost, complexity, and potential security vulnerabilities.

Azure Bastion changes everything. It's a fully managed PaaS service that provides secure RDP/SSH connectivity to Azure VMs directly through the Azure portal, without exposing VMs to the public internet. No public IPs, no jump boxes, no VPN clients.

Azure Bastion isn't one-size-fits-all. Whether you're running a development sandbox, managing production workloads at scale, or operating in regulated industries with strict compliance requirements, there's a Bastion SKU designed for your specific needs.

Basic SKU for small production workloads with browser-based access. Ideal for small businesses, startups, or single-application environments with limited concurrent users (up to 2 instances).
Standard SKU for scalable production environments requiring VNet peering, native client and shareable links for non-portal access. Supports up to 50 scale units, perfect for growing organizations and multi-VNET architectures.
Premium SKU for regulated industries requiring session recording for compliance (HIPAA, SOX, PCI-DSS, FDA), private-only deployment for zero internet exposure. Essential for healthcare, finance, pharmaceuticals, government, and air-gapped environments.

Let's dive into real-world scenarios that showcase how Azure Bastion simplifies enterprise-grade secure access.

Real-World Scenarios:

Azure Bastion features are best understood through real-world application. In the scenarios below, we'll tackle three common enterprise challenges with remote secure access. Let's see Azure Bastion in action.

Scenario 1: Instant Vendor Access Without the Hassle

The Challenge:

It's 3 PM on Friday when your production database experiences critical performance issues. An external DBA consultant needs immediate access to investigate, but your organization faces a familiar dilemma. The traditional provisioning process requires creating a temporary Azure AD account, configuring VPN access and credentials, coordinating with the security team for approvals, and ensuring timely revocation after the engagement concludes. Even with expedited processes, this takes 2-3 hours—and there's always the risk of lingering permissions if revocation is overlooked. By the time access is provisioned, it's often too late to resolve the issue before the weekend, leaving your production environment vulnerable and your team working overtime.

The Solution:

Shareable Links: Generate a secure URL for instant VM access: no Azure credentials, no VPN, no account creation is required.

Implementation:

Step 1: Enable Shareable Links

Navigate to Bastion → Configuration → Toggle Shareable Link to Enabled → Click Apply

Step 2: Generate Link

Go to Bastion → Select Shareable Links → Add → Choose VM→ Apply →Copy generated URL

Step 3: Share & Monitor

Share URL securely with vendor → Vendor connects via browser using VM credentials
Monitor active sessions in Bastion → Shareable Links

Real World Impact: A global financial services firm now grants emergency vendor access in under 5 minutes instead of 2-3 hours, with zero IT overhead for account provisioning or VPN setup. Links can be revoked after the set duration, eliminating lingering access risks. Every vendor session is logged, providing complete audit trails that satisfy SOX and PCI-DSS compliance requirements without additional administrative effort.

Scenario 2: Comprehensive Compliance with Session Recording

The Challenge:

Your healthcare organization operates under HIPAA regulations, which mandate comprehensive audit trails of all administrative access to systems containing Protected Health Information (PHI). Traditional text logs capture what was accessed, but not what actions were performed—and they're difficult to analyze during audits. You need indisputable video evidence of administrative activities with secure 7-year retention.

The Solution:

Graphical Session Recording: Azure Bastion Premium's Session Recording feature automatically captures every RDP and SSH session as a video recording, stored securely in Azure Storage with immutable retention policies.

Implementation:

Step 1: Prepare Storage Account

Create a dedicated storage account with blob versioning, lifecycle management (7 years for HIPAA), soft delete (90 days), and RBAC restricted to security/compliance team.
Also make sure there is a dedicated container created for Bastion Sessions and CORS policy configured on the storage account to allow your bastion.

Step 2: Enable Session Recording

Navigate to Bastion → Configuration → Toggle Session Recording to Enabled → Apply
Add/Update the SAS URL of the storage account in the Session Recordings blade of Bastion for the recordings to be stored in the specified storage account.

Step 3: Connect as Usual

Administrators connect through Azure portal normally: VM → Connect → Bastion → Enter credentials → Connect
Every session is automatically recorded—no extra steps for users.

Step 4: Review Recordings

Security teams access recordings from the Session Recordings blade on Azure Bastion which will retrieve data from the configured Storage Account.

Real World Impact: A healthcare provider with 50+ hospitals now maintains 100% HIPAA-compliant audit trails of all administrative access to PHI systems through automated video recordings. The organization reduced audit preparation time by 75%, as compliance teams can quickly review specific sessions instead of analyzing thousands of text log entries. Session recordings have enabled post-incident investigations to identify unauthorized configuration changes and provide indisputable video evidence for security reviews and regulatory audits.

Scenario 3: Zero Internet Exposure with Private-Only Deployment

The Challenge:

A global pharmaceutical company developing cancer treatments operates under FDA regulations requiring zero internet exposure for drug development systems. Their security mandate: no public IP addresses on production infrastructure, complete air-gapped connectivity to protect intellectual property, and administrative access from corporate network only. Traditional Azure Bastion requires a public IP address—violating their zero-trust security policy.

The Solution:

Private-Only Bastion: Azure Bastion Premium's private-only deployment eliminates the public IP address entirely. All connectivity flows through your org’s configured Express Route, S2S or P2S connectivity for complete air-gapped operations.

Implementation:

Select Azure Bastion Premium SKU and Deploy Private-Only Bastion
Configure Private Connectivity from On Prem using your orgs preferred way of connectivity
Connect from Corporate Network using Private IP address of the Bastion Deployment

Real-World Impact

A pharmaceutical company with 20+ research facilities deploys private-only Bastion for FDA-regulated drug development systems. The company now achieves complete air-gapped operations with zero internet endpoints while maintaining centralized access management for 200+ researchers across global facilities. Research teams connect securely via ExpressRoute with all administrative sessions network-isolated, FDA compliance audits confirm 100% of connections originate from corporate private networks, and the organization eliminated $2M in annual costs by decommissioning internet-isolated jump boxes.

Conclusion:

Azure Bastion transforms the traditional trade-off between security and operational efficiency into a unified solution. Whether you're granting emergency access or preparing for your next HIPAA audit, Azure Bastion delivers what enterprises need: secure temporary access as and when needed, complete audit trails with zero administrator overhead, and comprehensive compliance without compromising productivity, bringing a fundamental shift in how organizations approach secure remote access in the cloud.

Resources:

https://learn.microsoft.com/azure/bastion/
https://learn.microsoft.com/azure/bastion/shareable-link
https://learn.microsoft.com/azure/bastion/session-recording
https://azure.microsoft.com/pricing/details/azure-bastion/

Orchestrating Intrusion Detection and Prevention Signature overrides in Azure Firewall Premium

saikishor — Wed, 01 Apr 2026 23:08:21 GMT

Introduction:

Azure Firewall Premium provides strong protection with a built-in Intrusion Detection and Prevention System (IDPS). It inspects inbound, outbound, and east-west traffic against Microsoft’s continuously updated signature set and can block threats before they reach your workloads.

IDPS works out of the box without manual intervention. However, in many environments administrators need the flexibility to override specific signatures to better align with operational or security requirements.

Common reasons include:

Compliance enforcement – enforcing policies that require certain threats (such as High severity signatures) to always be blocked, directional tuning or protocol/category-based tuning.
Incident response – reacting quickly to emerging vulnerabilities by enabling blocking for newly relevant signatures.
Noise reduction – keeping informational signatures in alert mode to avoid false positives while still maintaining visibility.

In many environments, signature overrides are typically managed in one of two ways:

Using the global IDPS mode
Using the Azure portal to apply per-signature overrides individually

While these approaches work, managing overrides manually becomes difficult when thousands of signatures are involved. The Azure portal also limits the number of changes that can be applied at once, which makes large tuning operations time-consuming.

To simplify this process, this blog introduces an automation approach that allows you to export, filter, and apply IDPS signature overrides in bulk using PowerShell scripts.

A Common Operational Scenario:

Consider the following scenario frequently encountered by security teams:

Scenario

A security team wants to move their firewall from Alert → Alert + Deny globally to strengthen threat prevention. However, they do not want Low severity signatures to Deny traffic, because these signatures are primarily informational and may create unnecessary noise or false positives.

Example:

Signature ID: 2014906
Severity: Low
Description: INFO – .exe File requested over FTP

This signature is classified as informational because requesting an .exe file over FTP indicates contextual risk, not necessarily confirmed malicious activity.

If the global mode is switched to Alert + Deny, this signature may start blocking traffic unnecessarily.

The goal therefore becomes:

Enable Alert + Deny globally
Keep Low severity signatures in Alert mode

The workflow described in this blog demonstrates how to achieve this outcome using the IDPS Override script.

Automation Workflow:

The automation process uses two scripts to export and update signatures.

Workflow overview

Azure Firewall Policy
        │
        ▼
Export Signatures (ipssigs.ps1)
        │
        ▼
CSV Review / Edit
        │
        ▼
Bulk Update (ipssigupdate.ps1)
        │
        ▼
Updated Firewall Policy

Before implementing the workflow, it’s helpful to review the available IDPS modes and severity as seen below, very briefly.

IDPS Modes: Severity:

Prerequisites:

Now that we understand Azure Firewall IDPS concepts and have the context for this script, let's get started with the workings of the script itself. First of all, let us ensure that you are connected to your Azure account and have selected the correct subscription. You can do so by running the following command:

Connect-AzAccount -Subscription "<your-subscription-id>"

Ensure the following modules are installed which are required for this operation:

Az.Accounts
Az.Network

💡 Tip: You can check if the above modules are installed by running the following command:

Get-Module -ListAvailable Az* or check specific modules using this following commands:

Get-module Az.Network | select Name, Version, Path

Get-module Az.Accounts | select Name, Version, Path

If you need to install/import them, run the following command which downloads all generally available Azure service modules from the PowerShell Gallery, overwriting existing versions without prompting:

Import-Module Az.Network

Import-Module Az.Accounts

Restart PowerShell after installation.

Configure ipsconfig.json

Now, let's configure the ipsconfig.json file and ensure the configuration file contains your target environment details i.e., target subscription, target firewall policy resource group name, firewall name, firewall policy name, location and rule collection group name.

Example:

{
    "subs": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "rg": "TEST-RG",
    "fw": "fw",
    "fwp": "fw-policy",
    "location": "CentralUS",
    "rcg": "DefaultNetworkRuleCollectionGroup"
}

Note: Your account must have permissions to read and update firewall policy and IDPS settings.

Running the Script:

1. Export Signatures

Now that we have all the prerequisites ready, it's time to run the script. Run the following command in PS in the directory where the script exists:

.\ipssigs.ps1

Now, the script should prompt for filtering criteria as shown below and you can input the values as per your requirements:

For the example scenario that we considered, we will give the following inputs as shown above in the snapshot:

Mode: Alert
Severity: Low

💡 Tip: When specifying multiple values, ensure there is space between the 2 values but no comma, otherwise the script may return no results.

The script now exports the results to ipssignatures_results.csv file by default (or a custom filename if specified). The exported CSV includes metadata such as severity, direction, group, and protocol, which can help inform tuning decisions.

2. Prepare the CSV

Now, we do not need all of these columns when inputting the CSV file to update the Firewall Policy. We only need the following columns.

Signature Id
Mode

Therefore, we will need to remove all other columns while keeping the SignatureId and mode columns along with their headers as seen below:

3. Update the Firewall Policy

Now, it's time to update the Firewall Policy with the signature/mode overrides that we need using the above CSV file. However, please note that the script supports two operations:

Changing the global IDPS mode
Applying bulk signature overrides using the CSV file

You can use either option independently or both together. Let's understand this further by looking at these 2 examples.

Example 1: Change Global Mode and Override Low Severity Signatures

Goal:

Set global mode to Alert + Deny
Keep Low severity signatures in Alert

Command:

.\ipssigupdate.ps1 -GlobalMode Deny -InputFile Lowseveritysignatures.csv

Result:

High and Medium signatures → Alert + Deny
Low signatures → Alert

Example 2: Override Signatures Only

If the global mode should remain unchanged, then run the following command only.

.\ipssigupdate.ps1

The script will then prompt for the input CSV file in the next step as seen below:

As seen the changed were made to the Azure Firewall in just a few seconds. After the script completes, updated signature actions should appear in the firewall policy.

4. Monitoring Script Execution

Please use the following commands to track and monitor the background processes, to verify the status, check for any error and remove completed jobs as seen below:

You can check background job status using:

Get-Job -Id <#>

View results:

Receive-Job -Id <#> -Keep

Remove completed jobs:

Remove-Job -Id <#>

Note: Up to 10,000 IDPS rules can be customized at a time

5. Validate the Changes:

Now that we finished running the script, it's time to verify the update by confirming:

Global IDPS mode in the firewall policy
Signature override state
Alert or block events in your logging destination (Log Analytics or Microsoft Sentinel)

Note: Please note that, while most signatures support Off, Alert, or Deny actions, there are some context-setting signatures, that have fixed actions and cannot be overridden.

Conclusion:

Azure Firewall Premium makes it straightforward to apply broad IDPS configuration changes through the Azure portal. However, as environments scale, administrators often require more precise and repeatable ways to manage signature tuning.

The automation approach described in this blog allows administrators to query, review, and update thousands of signatures in minutes. This enables repeatable tuning workflows, improves operational efficiency, and simplifies large-scale security configuration changes.

References:

Detect, correlate, contain: New Azure Firewall IDPS detections in Microsoft Sentinel and XDR

Mohit_Kumar — Fri, 20 Mar 2026 21:03:45 GMT

As threat actors continue to blend reconnaissance, exploitation, and post-compromise activity, network-level signals remain critical for early detection and correlated response. To strengthen this layer, we're introducing five new Azure Firewall IDPS detections, now available out of the box in the Azure Firewall solution for Microsoft Sentinel and Microsoft Defender XDR.

See It in Action

This short demo walks through Azure Firewall's IDPS capabilities, the new Sentinel detections, and the automated response playbook — from malicious traffic hitting the firewall to the threat being contained without manual intervention.

Watch the demo → Azure Firewall integration with Microsoft Sentinel and Defender XDR

Read on for the full details on each detection, customization options, and a step-by-step walkthrough of the automated response workflow.

What’s new

The Azure Firewall solution now includes five new analytic detections built on Azure Firewall.

Detection name	What it detects (network signal)	MITRE ATT&CK tactic(s)	Example ATT&CK techniques (representative)	SOC impact
High severity malicious activity	Repeated high confidence IDPS hits such as exploit kits, malware C2, credential theft, trojans, shellcode delivery	Initial access (TA0001) execution (TA0002) Command and Control (TA0011)	Exploit public facing application (T1190) command and control over web protocols (T1071.001) Ingress Tool Transfer (T1105)	Highlights active exploitation or post compromise behavior at the network layer; strong pivot point into XDR investigations
Elevation of privilege attempt	Repeated attempts or success gaining user or administrator privileges	Privilege escalation (TA0004)	Exploitation for privilege escalation (T1068)	Flags critical inflection points where attackers move from foothold to higher impact control
Web application attack	Probing or exploitation attempts against web applications	Initial access (TA0001)	Exploit public facing application (T1190)	Surfaces external attack pressure against internet facing apps protected by Azure Firewall
Medium severity malicious activity	Potentially unwanted programs, crypto mining, social engineering indicators, suspicious filenames/system calls	Initial access (TA0001) execution (TA0002) impact (TA0040)	User Execution (T1204) Resource Hijacking (T1496)	Early stage or lower confidence signals that help teams hunt, monitor, and tune response before escalation
Denial of Service (DoS) attack	Attempted or sustained denial of service traffic patterns	Impact (TA0040)	Network Denial of Service (T1498)	Enables faster DoS identification and escalation, reducing time to mitigation

Where these detections apply

These detections are available through the Azure Firewall solution in:

Microsoft Sentinel, enabling SOC centric investigation, hunting, and automation
Microsoft Defender XDR, allowing network level signals to participate in end-to-end attack correlation across identity, endpoint, cloud, and email

They are powered by the AZFWIdpsSignature log table and require Azure Firewall with IDPS enabled (preferably with TLS inspection).

Customizing the detections to fit your environment

The Azure Firewall IDPS detections included in the Microsoft Sentinel solution are designed to be fully adaptable to customer environments, allowing SOC teams to tune sensitivity, scope, and signal fidelity based on their risk tolerance and operational maturity. Each detection is built on the AZFWIdpsSignature log table and exposes several clearly defined parameters that customers can modify without rewriting the analytic logic.

1. Tune alert sensitivity and time horizon

Customers can adjust the lookback period (TimeWindow) and minimum hit count (HitThreshold) to control how aggressively the detection triggers. Shorter windows and lower thresholds surface faster alerts for high-risk environments, while longer windows and higher thresholds help reduce noise in high volume networks.

2. Align severity with internal risk models

Each analytic rule includes a configurable minimum severity (MinSeverity) aligned to Azure Firewall IDPS severity scoring. Organizations can raise or lower this value to match internal incident classification standards and escalation policies.

3. Focus on relevant threat categories and behaviors

Optional filters allow detections to be scoped to specific threat categories, descriptions, or enforcement actions. Customers can enable or disable:

- Category filtering to focus on specific attack classes (for example, command and control, exploit kits, denial of service, or privilege escalation).
- Description filtering to target specific behavioral patterns.
- Action filtering to alert only on denied or alerted traffic versus purely observed activity.

This flexibility makes it easy to tailor detections for different deployment scenarios such as internet facing workloads, internal east-west traffic monitoring, or regulated environments with stricter alerting requirements.

4. Preserve structure while customizing output

Even with customization, the detections retain consistent enrichment fields including source IP, threat category, hit count, severity, actions taken, and signature IDs ensuring alerts remain actionable and easy to correlate across Microsoft Sentinel and Microsoft Defender XDR workflows.

By allowing customers to tune thresholds, scope, and focus areas while preserving analytic intent, these Azure Firewall IDPS detections provide a strong out of the box baseline that can evolve alongside an organization’s threat landscape and SOC maturity.

Automated detection and response for Azure Firewall using Microsoft Sentinel

In this walkthrough, we’ll follow a real-world attack simulation and see how Azure Firewall, Microsoft Sentinel, and an automated playbook work together to detect, respond to, and contain malicious activity, without manual intervention.

Step 1: Malicious traffic originates from a compromised source

A source IP address 10.0.100.20, hosted within a virtual network, attempts to reach a web application protected by Azure Firewall. To validate the scenario, we intentionally generate malicious outbound traffic from this source, such as payloads that match known attack patterns.

This is an outbound flow, meaning the traffic is leaving the internal network and attempting to reach an external destination through Azure Firewall.

At this stage:

- - Azure Firewall is acting as the central enforcement point
  - Traffic is still allowed, but deep packet inspection is in effect

Step 2: Azure Firewall IDPS detects malicious behavior

Azure Firewall's intrusion detection and prevention system (IDPS) is enabled and inspects traffic as it passes through the firewall. When IDPS detects patterns that match known malicious signatures, the action taken depends on the signature's configured mode:

- Alert mode: IDPS generates a detailed security log for the matched signature but allows the traffic to continue. This is useful for monitoring and tuning before enforcing blocks.
- Alert and Deny mode: IDPS blocks the matching traffic and generates a detailed security log. The threat is stopped at the network layer while full telemetry is preserved for investigation.

In both cases, IDPS records rich metadata including source IP, destination, protocol, signature name, severity, and threat category. These logs are what power the downstream detections in Microsoft Sentinel.

In this walkthrough, the signature is configured in Alert and Deny mode, meaning the malicious traffic from 10.0.100.20 is blocked immediately at the firewall while the corresponding log is forwarded for analysis.

Step 3: Firewall logs are sent to Log Analytics

All Azure Firewall logs, including IDPS logs, are sent to a Log Analytics workspace named law-cxeinstance.

At this point:

- - Firewall logs are centralized
  - Logs are normalized and can be queried
  - No alerting has happened yet, only data collection

This workspace becomes the single source of truth for downstream analytics and detections.

Step 4: Microsoft Sentinel ingests and analyzes the Firewall logs

The Log Analytics workspace is connected to Microsoft Sentinel, which continuously analyzes incoming data.

Using the Azure Firewall solution from the Sentinel Content Hub, we previously deployed a set of built-in analytic rule templates designed specifically for Firewall telemetry.

One of these rules is: “High severity malicious activity detected”. This rule evaluates IDPS logs and looks for: High-confidence signatures, known exploit techniques and malicious categories identified by Firewall IDPS.

Step 5: Sentinel creates an incident

When the analytic rules are met, Microsoft Sentinel automatically:

- - Raises an alert
  - Groups related alerts into an incident
  - Extracts entities such as IP addresses, severity, and evidence

In this case, the source IP 10.0.100.20 is clearly identified as the malicious actor and attached as an IP entity to the incident.

This marks the transition from detection to response.

Step 6: An automation rule triggers the playbook

To avoid manual response, we configured a Sentinel automation rule that triggers whenever:

- - An incident is created
  - The analytic rule name matches any of the analytic rules we configured

The automation rule immediately triggers a Logic App playbook named AzureFirewallBlockIPaddToIPGroup. This playbook is available as part of the Azure Firewall solution and can be deployed directly from the solution package. In addition, a simplified version of the playbook is published in our GitHub repository, allowing you to deploy it directly to your resource group using the provided ARM template.

This is where automated containment begins.

Step 7: The playbook aggregates and updates the IP Group

The playbook performs several critical actions in sequence:

1. 1. Extracts IP entities from the Sentinel incident
  2. Retrieves the existing Azure Firewall IP Group named MaliciousIPs
  3. Checks for duplicates to avoid unnecessary updates
  4. Aggregates new IPs into a single array/list

Updates the IP Group in a single operation. It is important to note that the playbook managed identity should have contributor access on the IP Group or its resource group to perform this action. In our scenario, the IP 10.0.100.20 is added to the MaliciousIPs IP Group.

Step 8: Firewall policy enforces the block immediately

Azure Firewall already has a network rule named BlockMaliciousTraffic configured with:

- - Source: MaliciousIPs IP Group
  - Destination: Any
  - Protocol: Any
  - Action: Deny

Because the rule references the IP Group dynamically, the moment the playbook updates MaliciousIPs, the firewall enforcement takes effect instantly — without modifying the rule itself.

Traffic originating from 10.0.100.20 is now fully blocked, preventing any further probing or communication with the destination. The threat has been effectively contained.

When a SOC analyst opens the Sentinel incident, they see that containment has already occurred: the malicious IP was identified, the IP Group was updated, and the firewall block is in effect — all with a full audit trail of every automated action taken, from detection through response. No manual intervention was required.

Conclusion

With these five new IDPS detections, Azure Firewall closes the gap between network-level signal and SOC-level action. Raw signature telemetry is automatically transformed into severity-aware, MITRE ATT&CK-mapped alerts inside Microsoft Sentinel and Microsoft Defender XDR — giving security teams correlated, investigation-ready incidents instead of isolated log entries.

Combined with automation playbooks, the result is a fully integrated detect-and-respond workflow: Azure Firewall identifies malicious behavior, Sentinel raises and enriches the incident, and a Logic App playbook contains the threat by updating firewall policy in real time — all without manual intervention.

These detections are included at no additional cost. Simply install the Azure Firewall solution from the Microsoft Sentinel Content Hub, and the analytic rules automatically appear in your Sentinel workspace — ready to enable, customize, and operationalize.

Get started today:

Recent real‑world breaches underscore why these detections matter. Over the past year, attackers have repeatedly gained initial access by exploiting public‑facing applications, followed by command‑and‑control activity, web shell deployment, cryptomining, and denial‑of‑service attacks. Incidents such as the GoAnywhere MFT exploitation, widespread web‑application intrusions observed by Cisco Talos, and large‑scale cryptomining campaigns against exposed cloud services demonstrate the value of correlating repeated network‑level malicious signals. The new Azure Firewall IDPS detections are designed to surface these patterns early, reduce alert noise, and feed high‑confidence network signals directly into Microsoft Sentinel and Microsoft Defender XDR for faster investigation and response.

Your network telemetry is a first-class security signal - let it work for you!

Visit us at RSA 2026 to see the full detection-to-containment workflow live.

Navigating the 2025 holiday season: Insights into Azure’s DDoS defense

Jdasari — Wed, 18 Feb 2026 20:30:34 GMT

The holiday season continues to be one of the most demanding periods for online businesses. Traffic surges, higher transaction volumes, and user expectations for seamless digital experiences all converge, making reliability a non-negotiable requirement. For attackers, this same period presents an opportunity: even brief instability can translate into lost revenue, operational disruption, and reputational impact.

This year, the most notable shift wasn’t simply the size of attacks, but how they were executed. We observed a rise in burst‑style DDoS events, fast-ramping, high-intensity surges distributed across multiple resources, designed to overwhelm packet processing and connection-handling layers before traditional bandwidth metrics show signs of strain.

From November 15, 2025 through January 5, 2026, Azure DDoS Protection helped customers maintain continuity through sustained Layer 3 and Layer 4 attack traffic, underscoring two persistent realities:

Most attacks remain short, automated, and frequently create constant background attack traffic.
The upper limit of attacker capability continues to grow, with botnets across the industry regularly demonstrating multi‑Tbps scale.

The holiday season once again reinforced that DDoS resilience must be treated as a continuous operational discipline.

Rising volume and intensity

Between November 15 and January 5, Azure mitigated approximately 174,054 inbound DDoS attacks. While many were small and frequent, the distribution revealed the real shift:

16% exceeded 1M packets per second (pps).
~3% surpassed 10M pps, up significantly from 0.2% last year.

Even when individual events are modest, the cumulative impact of sustained attack traffic can be operationally draining—consuming on-call cycles, increasing autoscale and egress costs, and creating intermittent instability that can provide cover for more targeted activity.

Operational takeaway:
Treat DDoS mitigation as an always-on requirement. Ensure protection is enabled across all internet-facing entry points, align alerting to packet rate trends, and maintain clear triage workflows.

What the TCP/UDP mix is telling us this season

TCP did what it usually does during peak season: it carried the fight. TCP floods made up ~72% of activity, and ACK floods dominated (58.7%) a reliable way to grind down packet processing and connection handling. UDP was ~24%, showing up as sharp, high-intensity bursts; amplification (like NTP) appeared, but it wasn’t the main play.

Put together, it’s a familiar one-two punch: sustain TCP/ACK pressure to exhaust the edge, then spike UDP to jolt stability and steal attention. The goal isn’t just to saturate bandwidth, it’s to push services into intermittent instability, where things technically stay online but feel broken to users.

TCP-heavy pressure: Make sure your edge and backends can absorb a surge in connections without falling over—check load balancer limits, connection/state capacity, and confirm health checks won’t start flapping during traffic spikes.
UDP burst patterns: Rely on automated detection and mitigation—these bursts are often over before a human can respond.
Reduce exposure: Inventory any internet-facing UDP services and shut down, restrict, or isolate anything you don’t truly need.

Attack duration:

Attackers continued to favor short-lived bursts designed to outrun manual response, but we also saw a notable shift in “who” felt the impact most. High-sensitivity workloads, especially gaming, experienced some of the highest packet-per-second and bandwidth-driven spikes, often concentrated into bursts lasting from a few minutes to several minutes. Even when these events were brief, the combination of high PPS + high bandwidth can be enough to trigger jitter, session drops, match instability, or rapid scaling churn. Overall, 34% of attacks lasted 5 minutes or less, and 83% ended within 40 minutes, reinforcing the same lesson: modern DDoS patterns are optimized for speed and disruption, not longevity.

For latency- and session-sensitive services, “only a few minutes” can still be a full outage experience. Attack duration is an attacker advantage when defenses rely on humans to notice, diagnose, and react. Design for minute-long spikes: assume attacks will be short, sharp, and high PPS such that your protections should engage automatically. Watch the right signals: alert on PPS spikes and service health (disconnect rates, latency/jitter), not bandwidth alone.

Botnet-driven surges:

Azure observed rapid rotation of botnet traffic associated with Aisuru and KimWolf targeting public-facing endpoints. The traffic was highly distributed across regions and networks. In several instances, when activity was mitigated in one region, similar traffic shifted to alternate regions or segments shortly afterward. “Relocation” behavior is the operational signature of automated botnet playbooks: probe → hit → shift → retry. If defenses vary by region or endpoint, attackers will find the weakest link quickly. Customers should standardize protection posture, ensure consistent DDoS policies and thresholds across regions. Monitor by setting the right alerts and notifications.

The snapshot below captures the Source-side distribution at that moment, showing which industry verticals were used to generate the botnet traffic during the observation window

The geography indicators below reflect where the traffic was observed egressing onto the internet, and do not imply attribution or intent by any provider or country.

Preparing for 2026

As organizations transition into 2026, the lessons from the 2025 holiday season marked by persistent and evolving DDoS threats, including the rise of DDoS-for-hire services, massive botnets underscore the critical need for proactive, resilient cybersecurity. Azure's proven ability to automatically detect, mitigate, and withstand advanced attacks (such as record-breaking volumetric incidents) highlights the value of always-on protections to maintain business continuity and safeguard digital services during peak demand periods.

Adopting a Zero Trust approach is essential in this landscape, as it operates on the principle of "never trust, always verify," assuming breaches are inevitable and requiring continuous validation of access and traffic principles that complement DDoS defenses by limiting lateral movement and exposure even under attack. To achieve comprehensive protection, implement layered security: deploy Azure DDoS Protection for network-layer (Layers 3 and 4) volumetric mitigation with always-on monitoring, adaptive tuning, telemetry, and alerting; combine it with Azure Web Application Firewall (WAF) to defend the application layer (Layer 7) against sophisticated techniques like HTTP floods; and integrate Azure Firewall for additional network perimeter controls. Key preparatory steps include identifying public-facing exposure points, establishing normal traffic baselines, conducting regular DDoS simulations, configuring alerts for active mitigations, forming a dedicated response team, and enabling expert support like the DDoS Rapid Response (DRR) team when needed. By prioritizing these multi-layered defenses and a well-practiced response plan, organizations can significantly enhance resilience against the evolving DDoS landscape in 2026.

A Practical Guide to Azure DDoS Protection Cost Optimization

SaleemBseeu — Wed, 18 Feb 2026 13:55:49 GMT

Introduction

Azure provides infrastructure-level DDoS protection by default to protect Azure’s own platform and services. However, this protection does not extend to customer workloads or non-Microsoft managed resources like Application Gateway, Azure Firewall, or virtual machines with public IPs. To protect these resources, Azure offers enhanced DDoS protection capabilities (Network Protection and IP Protection) that customers can apply based on workload exposure and business requirements. As environments scale, it’s important to ensure these capabilities are applied deliberately and aligned with actual risk.

For more details on how Azure DDoS protection works, see Understanding Azure DDoS Protection: A Closer Look.

Why Cost Optimization Matters

Cost inefficiencies related to Azure DDoS Protection typically emerge as environments scale:

New public IPs are introduced
Virtual networks evolve
Workloads change ownership
Protection scope grows without clear alignment to workload exposure

The goal here is deliberate, consistent application of enhanced protection matched to real risk rather than historical defaults.

Scoping Enhanced Protection

Customer workloads with public IPs require enhanced DDoS protection to be protected against targeted attacks. Enhanced DDoS protection provides:

Advanced mitigation capabilities
Detailed telemetry and attack insights
Mitigation tuned to specific traffic patterns
Dedicated support for customer workloads

When to apply enhanced protection:

Workload Type	Enhanced Protection Recommended?
Internet-facing production apps with direct customer impact	Yes
Business-critical systems with compliance requirements	Yes
Internal-only workloads behind private endpoints	Typically not needed
Development/test environments	Evaluate based on exposure

Best Practice: Regularly review public IP exposure and workload criticality to ensure enhanced protection aligns with current needs.

Understanding Azure DDoS Protection SKUs

Azure offers two ways to apply enhanced DDoS protection: DDoS Network Protection and DDoS IP Protection. Both provide DDoS protection for customer workloads.

Comparison Table

Feature	DDoS Network Protection	DDoS IP Protection
Scope	Virtual network level	Individual public IP
Pricing model	Fixed base + overage per IP	Per protected IP
Included IPs	100 public IPs	N/A
DDoS Rapid Response (DRR)	Included	Not available
Cost protection guarantee	Included	Not available
WAF discount	Included	Not available
Best for	Production environments with many public IPs	Selective protection for specific endpoints
Management	Centralized	Granular
Cost efficiency	Lower per-IP cost at scale (100+ IPs)	Lower total cost for few IPs (< 15)

DDoS Network Protection

DDoS Network Protection can be applied in two ways:

VNet-level protection: Associate a DDoS Protection Plan with virtual networks, and all public IPs within those VNets receive enhanced protection
Selective IP linking: Link specific public IPs directly to a DDoS Protection Plan without enabling protection for the entire VNet

This flexibility allows you to protect entire production VNets while also selectively adding individual IPs from other environments to the same plan.

For more details on selective IP linking, see Optimizing DDoS Protection Costs: Adding IPs to Existing DDoS Protection Plans.

Ideal for: - Production environments with multiple internet-facing workloads - Mixed environments where some VNets need full coverage and others need selective protection - Scenarios requiring centralized visibility, management, and access to DRR, cost protection, and WAF discounts

DDoS IP Protection

DDoS IP Protection allows enhanced protection to be applied directly to individual public IPs, with per-IP billing. This is a standalone option that does not require a DDoS Protection Plan.

Ideal for:

Environments with fewer than 15 IPs requiring protection
Cases where DRR, cost protection, and WAF discounts are not needed
Quick enablement without creating a protection plan

Decision Tree: Choosing the Right SKU

Now that you know the main scenarios, the decision tree below can help you determine which SKU best fits your environment based on feature requirements and scale:

Network Protection exclusive features:

DDoS Rapid Response (DRR): Access to Microsoft DDoS experts during active attacks
Cost protection: Resource credits for scale-out costs incurred during attacks
WAF discount: Reduced pricing on Azure Web Application Firewall

Consolidating Protection Plans at Tenant Level

A single DDoS Protection Plan can protect multiple virtual networks and subscriptions within a tenant. Each plan includes:

Fixed monthly base cost
100 public IPs included
Overage charges for additional IPs beyond the included threshold

Cost Comparison Example

Consider a customer with 130 public IPs requiring enhanced protection:

Configuration	Plans	Base Cost	Overage	Total Monthly Cost
Two separate plans	2	$2,944 × 2 = $5,888	$0	~$5,888
Single consolidated plan	1	$2,944	30 IPs × $30 = $900	~$3,844

Savings: ~$2,044/month ($24,528/year) by consolidating to a single plan.

In both cases, the same public IPs receive the same enhanced protection. The cost difference is driven entirely by plan architecture.

How to Consolidate Plans

Use the PowerShell script below to list existing DDoS Protection Plans and associate virtual networks with a consolidated plan. Run this script from Azure Cloud Shell or a local PowerShell session with the [Az module](https://learn.microsoft.com/powershell/azure/install-azure-powershell) installed. The account running the script must have Network Contributor role (or equivalent) on the virtual networks being modified and Reader access to the DDoS Protection Plan.

# List all DDoS Protection Plans in your tenant Get-AzDdosProtectionPlan | Select-Object Name, ResourceGroupName, Id # Associate a virtual network with an existing DDoS Protection Plan $ddosPlan = Get-AzDdosProtectionPlan -Name "ConsolidatedDDoSPlan" -ResourceGroupName "rg-security" $vnet = Get-AzVirtualNetwork -Name "vnet-production" -ResourceGroupName "rg-workloads" $vnet.DdosProtectionPlan = New-Object Microsoft.Azure.Commands.Network.Models.PSResourceId $vnet.DdosProtectionPlan.Id = $ddosPlan.Id $vnet.EnableDdosProtection = $true Set-AzVirtualNetwork -VirtualNetwork $vnet

Preventing Protection Drift

Protection drift occurs when the resources covered by DDoS protection no longer align with the resources that actually need it. This mismatch can result in wasted spend (protecting resources that are no longer critical) or security gaps (missing protection on newly deployed resources). Common causes include:

Applications are retired but protection remains
Test environments persist longer than expected
Ownership changes without updating protection configuration

Quarterly Review Checklist

List all public IPs with enhanced protection enabled
Verify each protected IP maps to an active, production workload
Confirm workload criticality justifies enhanced protection
Review ownership tags and update as needed
Remove protection from decommissioned or non-critical resources
Validate DDoS Protection Plan consolidation opportunities

Sample Query: List Protected Public IPs

Use the following PowerShell script to identify all public IPs currently receiving DDoS protection in your environment. This helps you audit which resources are protected and spot candidates for removal. Run this from Azure Cloud Shell or a local PowerShell session with the Az module installed. The account must have Reader access to the subscriptions being queried.

# List all public IPs with DDoS protection enabled Get-AzPublicIpAddress | Where-Object { $_.DdosSettings.ProtectionMode -eq "Enabled" -or ($_.IpConfiguration -and (Get-AzVirtualNetwork | Where-Object { $_.EnableDdosProtection -eq $true }).Subnets.IpConfigurations.Id -contains $_.IpConfiguration.Id) } | Select-Object Name, ResourceGroupName, IpAddress, @{N='Tags';E={$_.Tag | ConvertTo-Json -Compress}}

For a comprehensive assessment of all public IPs and their DDoS protection status across your environment, use the DDoS Protection Assessment Tool.

Making Enhanced Protection Costs Observable

Ongoing visibility into DDoS Protection costs enables proactive optimization rather than reactive bill shock. When costs are surfaced early, you can spot scope creep before it impacts your budget, attribute spending to specific workloads, and measure whether your optimization efforts are paying off. The following sections cover three key capabilities: budget alerts to notify you when spending exceeds thresholds, Azure Resource Graph queries to analyze protection coverage, and tagging strategies to attribute costs by workload.

Setting Up Cost Alerts

Navigate to Azure Cost Management + Billing
Select Cost alerts > Add
Configure:

o Scope: Subscription or resource group

o Budget amount: Based on expected DDoS Protection spend

o Alert threshold: 80%, 100%, 120%

o Action group: Email security and finance teams

Tagging Strategy for Cost Attribution

Apply consistent tags to track DDoS protection costs by workload:

# Tag public IPs for cost attribution $pip = Get-AzPublicIpAddress -Name "pip-webapp" -ResourceGroupName "rg-production" $tags = @{ "CostCenter" = "IT-Security" "Workload" = "CustomerPortal" "Environment" = "Production" "DDoSProtectionTier" = "NetworkProtection" } Set-AzPublicIpAddress -PublicIpAddress $pip -Tag $tags

Summary

This guide covered how to consolidate DDoS Protection Plans to avoid paying multiple base costs, select the appropriate SKU based on IP count and feature needs, apply protection selectively with IP linking, and prevent configuration drift through regular reviews. These practices help ensure you're paying only for the protection your workloads actually need.

References

Zero Trust with Azure Firewall, Azure DDoS Protection and Azure WAF: A practical use case

saikishor — Thu, 05 Feb 2026 05:15:27 GMT

Introduction

Zero Trust has emerged as the defining security ethos of the modern enterprise. It is guided by a simple but powerful principle: “Never trust, always verify.” This principle is more relevant now than ever as cyberattacks continue to trend upward in both frequency and impact, affecting organizations of every size and industry. No entity large or small can assume immunity. As a result, adopting Zero Trust is no longer optional, it is a foundational requirement for designing secure, resilient architectures.

A key tenet of Zero Trust is the assumption of breach, thus designing systems with the expectation that threats may already exist both outside and inside the network perimeter. To implement this principle, you need multiple, independent security controls that inspect traffic at different layers and enforce least privilege access continuously. Relying on a single security control, even a highly capable one, leaves gaps that modern attackers are adept at exploiting.

It is within this context that combining the use of Azure Firewall, Azure DDoS Protection and Azure Web Application Firewall (WAF) services to secure Web Applications while protecting the network perimeter becomes important. Together, these services deliver comprehensive protection across the network and application layers.

Defense-in-depth: Why Azure WAF, Azure DDoS Protection and Azure Firewall are essential for Zero Trust

In these sections ahead, we examine the common network and application-layer attack vectors that target modern web applications and illustrate how Azure WAF, Azure DDoS protection, and Azure Firewall, when layered strategically, work in tandem to mitigate these threats.

The architecture

The test environment was designed to reflect a common Azure deployment pattern:

Azure DDoS Protection at the edge, to defend against a comprehensive set of network layer (layer 3/4) attacks
Azure Application Gateway with WAF, inspecting inbound HTTP traffic for application-layer threats
Azure Firewall Premium behind the gateway, providing network-layer protection, deep packet inspection, and outbound traffic governance.
A backend subnet hosting an intentionally vulnerable application (OWASP Juice Shop) to simulate real-world attack scenarios.

Traffic flows through the DDoS first, then WAF, and then the firewall, before reaching the backend. Outbound traffic from the backend is routed through the firewall for inspection. This ensures that all inbound and outbound traffic is scrutinized.

Two access paths that will be tested:

Via the Application Gateway public IP, where traffic passes through DDoS, WAF and Firewall.
Via the Firewall public IP using a DNAT rule, where traffic bypasses WAF and is inspected only by the Firewall.

The following scenarios illustrate how this complementary protection strengthens overall resilience:

Scenario 1: SQL injection (application-layer attack)

Let’s say an attacker on the internet attempts to access the application’s login endpoint via the Application Gateway IP address and injects a SQL payload into the input field. For example, the attacker submits a request containing the following payload in the User ID field:

?id=' OR 1=1 --

Azure WAF will receive the request, analyze, and if Azure WAF is deployed in Prevention mode, it will immediately detect the SQL injection attempt using its built-in Managed Ruleset. Upon detection, Azure WAF will return a WAF block page, preventing the request from ever reaching the application.

By contrast, when the same application is accessed through a firewall-only path (for example, via a DNAT rule on Azure Firewall that exposes the application on port 443), Azure Firewall allows the traffic as it does not perform deep Application layer inspection and SQL injection payloads when embedded within the HTTP request body, appear legitimate at the network layer. Here is a snapshot of the attacker gaining access to the admin role when they insert this SQL injection attack without Azure WAF and only Azure Firewall in the path.

Scenario 2: Volumetric and application-layer DDoS attacks

Next, the attacker launches a volumetric network layer DDoS (SYN/UDP floods) to saturate bandwidth, but Azure DDoS Network Protection absorbs and scrubs the attack at the edge, so no traffic reaches Application Gateway, WAF, or Firewall.

When the network layer attack fails, they shift to HTTP flood attack at the application layer, overwhelming the web application with a high volume of requests. Some requests include exploit attempts, while others are designed purely to exhaust application resources. Azure WAF here, can identify malicious patterns such as:

Automated bots lacking proper headers
Abnormal request rates
Known exploit payloads embedded within requests
Malicious IP addresses

Note: Azure DDoS Protection is a comprehensive service that provides protection across network layers (Layer 3 and 4), while HTTP DDoS Protection specifically targets application-layer attacks (Layer 7) and is integrated with Azure WAF. They are complementary services designed to defend against different types of threats within the Azure environment.

Additionally, if the botnet’s IPs are known threat actors or malicious traffic, Azure Firewall’s threat intelligence and IDPS will be able to flag this traffic too.

Together, these services form a complementary, defense-in-depth strategy for protecting Azure workloads against distributed denial-of-service attacks.

Scenario 3: Path Traversal Attempt/Information leak: (Application-Layer Attack)

Next, the attacker sends HTTP requests to access sensitive system files such as /etc/passwd by sending crafted HTTP requests to the application via the Application Gateway public IP address.

The request successfully passes through Azure Application Gateway WAF, as it does not trigger a managed rule violation in this case. However, when the request reaches Azure Firewall, the Firewall’s IDPS detects the malicious pattern in the HTTP header and blocks the connection before it can reach the backend workload.

Because the backend connection is denied by Azure Firewall, Application Gateway is unable to establish a successful response and returns a 504 Gateway Timeout to the client, rather than a 403 Forbidden response that would typically be generated by WAF when it blocks traffic. Below is the log from Azure Firewall showing that its able to detect this traffic as – Attempted Information Leak. As seen below, the traffic passed Application Gateway+WAF but was caught by Azure Firewall:

This scenario highlights an important architectural outcome: The combination of WAF and Azure Firewall provides layered enforcement, even if an attack manages to slip past Azure WAF, Azure Firewall adds an additional enforcement layer to ensure the application remains protected.

Now, let’s look at some more Network Layer attacks:

Scenario 4: Network reconnaissance and breach

In this scenario, port 3389 is exposed on Application Gateway using the L4 TCP Proxy option. Now, the attacker attempts to scan the Application Gateway on all the ports/protocols and found that port 3389 was open along with other ports such as ports 80, 8080, 3000.

Azure WAF will alert us for Layer 7/Application exploit but cannot verify/validate the attack on port 3389 since it was purely Layer 3/4 and contained no HTTP payload for WAF inspection. The L4 proxy listener on App Gateway simply forwards the raw TCP connections to the Azure Firewall behind it. Azure Firewall, however, performs full network‑layer inspection across all ports and protocols, allowing it to detect and alert on this type of L3/L4 reconnaissance even when App Gateway had the port open via the TCP proxy feature. As seen below the traffic passed Application Gateway+WAF but was caught by Azure Firewall since it is non-HTTP:

The attacker then tries a different approach: Now the attacker somehow compromises a workstation inside our network and attempts to move laterally to the web server via RDP on port 3389 and/or attempts to exfiltrate and try to access something outside of the network. Azure Firewall located inside the VNet blocks the RDP attempt (if there is no rule allowing it) and if there is, its IDPS flags/blocks the traffic as suspicious. In this case, Azure WAF will not be involved but Azure Firewall inspects this internal and/or outbound traffic and blocks it. This illustrates how a combination of the two stops the attacker at multiple points: firewall foiled the reconnaissance and lateral movement/exfiltration, WAF foiled the application exploit.

We can see below the outbound malicious attempt caught by Azure Firewall IDPS:

In summary, Azure WAF is like the “bodyguard at the application’s front door” – inspecting every HTTP request in detail and ejecting those carrying hidden weapons or exhibiting bad behavior. It focuses on the web layer, which Azure Firewall or DDoS alone cannot fully protect. If we only had the WAF and no network firewall or DDoS, we’d be safe from many web attacks but would remain exposed to network-level threats (e.g., someone trying to RDP into a VM, or flooding a non-HTTP service). Conversely, if we had only the firewall, a crafty attacker could still exploit a vulnerability in our web app with a well-crafted HTTP request that looks “allowed” to the firewall – that’s where the WAF comes in to catch it.

Azure Firewall on the other hand, acts as the “moat and drawbridge” to your cloud network: it keeps out the obvious bad guys at the gate, tightly limits what’s allowed in or out (no implicit trust for internal IPs), and uses threat intel + signatures to sniff out known threats in any traffic it passes, even outbound traffic.

The table below shows the traffic flow that will be filtered by Azure WAF vs Azure Firewall. As you can see, layered security is fundamental to Zero Trust

Conclusion

In a Zero Trust architecture, security cannot rely on implicit trust or a single layer of defense. The combination of Azure Firewall Premium, Azure DDoS protection and Azure Application Gateway WAF exemplifies defense-in-depth by protecting both network and application layers. Organizations hosting internet-facing applications should adopt this layered strategy to reduce exposure to modern threats, prevent lateral movement, and maintain strict control over outbound traffic. By implementing these services together, you align with Microsoft’s recommended best practices for Zero Trust and significantly strengthen your cloud security posture.

References:

Application layer DDoS protection using the HTTP DDoS Ruleset in Azure WAF

saikishor — Thu, 18 Dec 2025 07:18:22 GMT

Today, Distributed Denial of Service (DDoS) attacks can strike as soon as public connectivity is enabled, highlighting their widespread prevalence. Factors such as easily accessible botnets, the explosion of IoT devices, and the growth of API-driven workloads, e-commerce platforms, and global web applications have made these attacks easier to launch and more impactful.

Importantly, attackers are no longer focusing solely on the network layer, they increasingly target the application layer. Application-layer DDoS attacks often mimic normal user activity, making detection and mitigation far more challenging than traditional network-layer attacks. The most common types of Application layer/HTTP based DDOS attacks are outlined below.

Common HTTP-based DDoS attacks:

HTTP floods: Large volumes of valid looking GET or POST requests are sent to webpages or APIs, overwhelming application gateways and backend services without saturating network bandwidth.
API abuse attacks: Attackers repeatedly call specific API endpoints, such as authentication, search, or checkout that trigger expensive backend operations, quickly exhausting compute and database resources.
Slow HTTP attacks: Connections are deliberately kept open by sending data very slowly, consuming server threads and connection limits while generating relatively little traffic.
TLS-intensive attacks: A high number of encrypted connections are initiated to increase CPU usage during TLS handshakes, impacting application gateways and load balancers.

In order to defend against these sophisticated threats, organizations need application-aware protection that can identify abnormal behavior patterns rather than relying only on traffic volume. This is precisely the capability provided by the HTTP DDoS Ruleset for Azure Application Gateway WAF.

What Is the HTTP DDoS Ruleset?

The HTTP DDoS Ruleset is a built-in capability of Azure Application Gateway WAF designed to protect your applications from large-scale HTTP floods at the application layer. Unlike static rate-limiting or manual IP blocking, this ruleset uses adaptive learning to understand what “normal” traffic looks like for your gateway and then automatically mitigates anomalies.

Key features

Baseline learning: The ruleset observes traffic for about 24 hours to establish a normal request pattern per gateway.
Dynamic detection: When incoming requests exceed the learned baseline, the ruleset identifies potential abuse (Client-specific or IP specific limits are applied only when the overall request volume to the gateway exceeds its learned baseline).
Automated mitigation: Offending clients are blocked and are placed in a “penalty box” for the defined time (15 minutes).
Sensitivity levels: Choose low, medium, or high to control aggressiveness. Medium is recommended for most workloads.
Leverages Microsoft’s vast global network’s threat intelligence to establish a stricter baseline for suspected botnet traffic and when exceeded, blocks them and places those suspected bots into the penalty box.

Threat intelligence plays a critical role here. By continuously aggregating data from global telemetry, threat intelligence systems can identify sources that are likely participating in coordinated attacks. When applied to HTTP DDoS protection, this intelligence allows suspected bot traffic to be treated differently from normal user traffic. Instead of relying only on static blocklists, botnet-aware defenses use reputation, behavior, and historical signals to apply throttling or penalties dynamically. This approach reduces the attack surface, limits the impact of distributed bot-driven floods, and avoids unnecessary disruption to legitimate users.

Threat intelligence shifts DDoS defense from a purely reactive posture to a more informed, proactive one, making it far more effective against today’s botnet-driven application-layer attacks.

Enabling and validating the HTTP DDoS Ruleset:

Getting started with the HTTP DDoS Ruleset on Application Gateway WAF is simple.

Enable the Ruleset:

In the Azure portal, open your WAF policy.

Note: Currently the ruleset is available only in the preview portal: https://preview.portal.azure.com/

Under Managed Rules, Click on Assign and then assign the HTTP DDoS Ruleset_1.0 (Preview) and save.

Each rule can be configured to either Log traffic for observation or Deny traffic for active mitigation. Sensitivity can be adjusted to High, Medium, or Low, allowing you to balance detection speed and accuracy. Higher sensitivity enforces lower thresholds and detects anomalies sooner, while lower sensitivity raises thresholds to reduce false positives. Medium sensitivity is the default and recommended setting for most workloads.

Once enabled, the ruleset is evaluated early in the WAF pipeline, before custom rules are processed. This ensures that HTTP-based DDoS protection cannot be bypassed by DDoS protection. The ruleset works alongside the Default Rule Set (DRS) and any custom rules for comprehensive security.

After the policy is applied to an Application Gateway, the ruleset enters a learning phase that lasts at least 24 hours. During this time, it observes traffic patterns to establish normal baselines for the gateway. No detection or blocking occurs during this period, allowing the ruleset to understand typical application behavior before enforcement begins.

Metrics:

Once the learning phase completes, traffic surges that exceed the learned baseline are reflected in the Application Gateway metrics. These metrics provide immediate visibility into when the HTTP DDoS ruleset is actively detecting and mitigating abnormal behavior.

Metric – WAF Penalty Box Size

This metric shows how many IP addresses are currently inside the penalty box, meaning that the WAF has detected them exceeding the learned HTTP DDoS baseline and is temporarily blocking them. A spike here indicates that multiple clients crossed their thresholds at the same time, often during an attack or load-test scenario.

Metric – WAF Penalty Box Hits

This metric represents how many IPs entered the penalty box. Every time a client breaches its threshold, the ruleset logs a hit and places that IP into the penalty box for approximately 15 minutes. Multiple hits often correlate with repeated spikes or sustained abusive traffic patterns.

Logs:

For deeper analysis, enabling diagnostic settings allows you to inspect HTTP DDoS Ruleset events directly in the logs. These logs provide granular details about which IPs were flagged, why they were flagged, and how far they exceeded expected thresholds.

Example of DetailedData from a log: RemoteAddress: 4.x.x.x (Public IP) crossed threshold. Expected: 4400.000000 request per 900 seconds, Actual: 8407.000000 requests per 900 seconds.

KQL queries to retrieve these logs:

Resource specific logs:

AGWFirewallLogs

| where RuleSetType == "Microsoft_HTTPDDoSRuleSet"

Diagnostic logs:

AzureDiagnostics

| where Category == "ApplicationGatewayFirewallLog"

| where ruleSetType_s == "Microsoft_HTTPDDoSRuleSet"

Note: Identify IPs repeatedly flagged and confirm they’re malicious, not legitimate clients.

Conclusion:

The threat landscape continues to evolve, and defenses must evolve with it. Leveraging the HTTP DDoS Ruleset in Azure Application Gateway WAF helps ensure protections keep pace with modern application-layer attacks. With built-in visibility through metrics and logs, teams can better understand traffic behavior and operate their WAF with greater confidence.

Next Steps:

Access the HTTP DDoS ruleset for Application Gateway via the preview portal: https://preview.portal.azure.com/
HTTP DDoS Ruleset (Preview) - Application Gateway WAF | Microsoft Learn
Azure Web Application Firewall (WAF) policy overview | Microsoft Learn

Protect against React RSC CVE-2025-55182 with Azure Web Application Firewall (WAF)

yuvalpery — Mon, 19 Jan 2026 13:52:07 GMT

Please subscribe to this blog as we will be updating the suggested rules as new attack permutations are found.

On December 3, 2025, the React team disclosed a critical remote code execution (RCE) vulnerability in React Server Components (RSC), tracked as CVE-2025-55182. The vulnerability allows an unauthenticated attacker to send a specially crafted request to an RSC “Server Function” endpoint and potentially execute arbitrary code on the server.

This vulnerability affects applications using React RSC in the following versions:

19.0.0

19.1.0

19.1.1

19.2.0

Patched versions are available, and all customers are strongly encouraged to update immediately.

About CVE-2025-55182

According to the React security advisory, the issue stems from unsafe deserialization within React Server Components, where server function payloads were not adequately validated. When exploited, an attacker can execute arbitrary code on the server without authentication.

The NVD entry classifies this vulnerability as Critical, with a CVSS score of 10.0, due to its ease of exploitation and the potential impact on server-side execution.

All organizations using React Server Components — or frameworks that embed RSC capabilities such as Next.js, React Router (RSC mode), Waku, @parcel/rsc, @vitejs/plugin-rsc, or rwsdk — should consider themselves potentially exposed until the relevant patches are applied.

Azure WAF Mitigation to CVE-2025-55182

The primary and most effective mitigation for this vulnerability is to upgrade any unpatched React versions to the latest security-patched releases.

Mitigation on WAF on Application Gateway or Application Gateway for Containers

If you are using the latest and recommended Default Rule Set (DRS) 2.1, or the previous Core Rule Set (CRS) 3.2, a new CVE-specific managed rule is available in Azure Web Application Firewall (WAF) for Application Gateway and Application Gateway for Containers.

Please ensure this rule is enabled and retains its default Anomaly Score–based action:

Rule ID: 99001018 (DRS 2.1) or 800115 (CRS 3.2)
Rule description: Attempted React2Shell remote code execution exploitation (CVE-2025-55182)

This CVE-specific rule has also been added to CRS 3.1. However, for enhanced and more comprehensive protection specifically against CVE-2025-55182, we strongly recommend upgrading to DRS 2.1, which includes additional detection coverage and tuning for this vulnerability.

If you are using CRS 3.0, there is no built-in CVE-specific protection for CVE-2025-55182, and upgrading to DRS 2.1 is strongly advised.

If upgrading is not currently possible, you may implement custom WAF rules to detect this exploit pattern using a Block action. Any custom rules should be validated in a test or staging environment before being enforced in production.

Custom rules definition for WAF on Application Gateway and Application Gateway for Containers:

"customRules": [ { "name": "cve202555182", "priority": 1, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "next-action" } ], "operator": "Any", "negationConditon": false, "matchValues": [], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" }, { "name": "cve202555182ver2", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "rsc-action-id" } ], "operator": "Any", "negationConditon": false, "matchValues": [], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" } ],

Adding these custom rules may fail if your WAF runs on the old WAF engine. In this case, we strongly recommend upgrading your WAF policy to the next-generation WAF engine by moving to a newer ruleset: either to the latest DRS 2.1 which includes the built-in managed rule (preferred) or to the previous CRS 3.2, then apply the custom rules described above.

If upgrading your ruleset version is not an option, and your WAF remains on the old WAF engine, you can instead use the following alternative rules:

"CustomRules": [ { "Name": "cve202555182", "Priority": 1, "RuleType": "MatchRule", "MatchConditions": [ { "MatchVariables": [ { "VariableName": "PostArgs" } ], "Operator": "Contains", "MatchValues": [ "constructor", "__proto__", "prototype", "_response" ], "Transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "MatchVariables": [ { "VariableName": "RequestHeaders", "Selector": "next-action" } ], "Operator": "Regex", "MatchValues": [ "." ], "Transforms": [] } ], "Action": "Block" }, { "Name": "cve202555182ver2", "Priority": 2, "RuleType": "MatchRule", "MatchConditions": [ { "MatchVariables": [ { "VariableName": "PostArgs" } ], "Operator": "Contains", "MatchValues": [ "constructor", "__proto__", "prototype", "_response" ], "ATransforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "MatchVariables": [ { "VariableName": "RequestHeaders", "Selector": "rsc-action-id" } ], "Operator": "Regex", "MatchValues": [ "." ], "Transforms": [] } ], "Action": "Block" } ]

Mitigation for WAF on Azure Front Door:

If you are using WAF on Azure Front Door, you can create custom WAF rules to detect this exploit pattern. These custom rules are configured with a Block action. We recommend validating them in a test or staging environment before enforcing them in production.

"customRules": [ { "name": "cve202555182", "enabledState": "Enabled", "priority": 1, "ruleType": "MatchRule", "rateLimitDurationInMinutes": 1, "rateLimitThreshold": 100, "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "next-action", "operator": "Any", "negateCondition": false, "matchValue": [], "transforms": [] }, { "matchVariable": "RequestHeader", "selector": "content-type", "operator": "Contains", "negateCondition": false, "matchValue": [ "multipart/form-data", "application/x-www-form-urlencoded" ], "transforms": [ "Lowercase" ] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] } ], "action": "Block", "groupBy": [] }, { "name": "cve202555182ver2", "enabledState": "Enabled", "priority": 2, "ruleType": "MatchRule", "rateLimitDurationInMinutes": 1, "rateLimitThreshold": 100, "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "rsc-action-id", "operator": "Any", "negateCondition": false, "matchValue": [], "transforms": [] }, { "matchVariable": "RequestHeader", "selector": "content-type", "operator": "Contains", "negateCondition": false, "matchValue": [ "multipart/form-data", "application/x-www-form-urlencoded" ], "transforms": [ "Lowercase" ] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] } ], "action": "Block", "groupBy": [] } ]

You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here.

Changelog

1/19/2026 5:00 PST - Updated built-in managed rule for CRS 3.2 and CRS 3.1 on WAF for Application Gateway
12/20/2025 11:00 PST - Updated built-in managed rule on WAF for Application Gateway and Application Gateway for Containers
12/7/2025 23:30 PST - Updated custom rules to detect additional attack permutation
12/5/2025 17:45 PST - Updated custom rules to include additional transform "RemoveNulls".

Public Preview: Entra ID support for RDP connections in portal

aarontsang — Mon, 24 Nov 2025 20:15:00 GMT

Overview

Azure Bastion provides secure RDP and SSH access to Azure virtual machines directly via the Azure portal or via the native SSH/RDP client already installed on your local computer. Previously, Bastion supported Entra ID authentication (formerly AAD) for RDP and SSH connections via native client and for SSH connections via the portal. Today, we are introducing public preview for Entra ID support for RDP connections in the portal, delivering a more seamless and secure experience for users.

Why Entra ID authentication?

When Bastion users connect to Windows VMs through the portal, they authenticate using either a VM password or a password stored in Azure Key Vault. By leveraging Microsoft Entra ID, authentication becomes identity-based, eliminating the need for local credentials and reducing complexity. This approach provides a seamless, one-click sign-in experience, making it easier for users to access their Windows VMs without managing separate passwords. Beyond convenience, Entra ID strengthens organizational security by centralizing identity management and enforcing robust access controls. The result is a simplified, secure, and user-friendly way to connect to virtual machines while improving the overall security posture.

Getting Started in Azure Portal

Prerequisites:

Ensure that the user connecting either has Virtual Machine User Login OR Virtual Machine Administrator Login role on the virtual machine
Ensure that AADLoginForWindows extension is enabled on the VM. Microsoft Entra ID Login can be enabled during VM creation by checking the box for Login with Microsoft Entra ID or by adding the AADLogin extension to a pre-existing VM.

Steps:

Navigate to your Virtual Machine resource in the Azure portal.
Select Bastion under Connect.
Check that Microsoft Entra ID is the Authentication Type.
Click Connect.

Next Steps

Try Entra ID authentication support today, now in public preview - and share your feedback with the team.

Learn more about Bastion support for Entra ID authentication here and keep up to date with all things Azure Bastion in our What's New page.

DNS flow trace logs in Azure Firewall are now generally available

surenjamiyanaa — Wed, 12 Nov 2025 17:56:17 GMT

Background

Azure Firewall helps secure your network by filtering traffic and enforcing policies for your workloads and applications. DNS Proxy, a key capability in Azure Firewall, enables the firewall to act as a DNS forwarder for DNS traffic.

Today, we’re introducing the general availability of DNS flow trace logs — a new logging capability that provides end-to-end visibility into DNS traffic and name resolution across your environment, such as viewing critical metadata including query types, response codes, queried domains, upstream DNS servers, and the source and destination IPs of each request.

Why DNS flow trace logs?

Existing Azure Firewall DNS Proxy logs provide visibility for DNS queries as they initially pass through Azure Firewall. While helpful, customers have asked for deeper insights to troubleshoot, audit, and analyze DNS behavior more comprehensively.

DNS flow trace logs address this by offering richer, end-to-end logging, including DNS query paths, cache usage, forwarding decisions, and resolution outcomes. With these logs, you can:

Troubleshoot faster with detailed query and response information throughout the full resolution flow
Validate caching behavior by determining whether Azure Firewall’s DNS cache was used
Gain deeper insights into query types, response codes, forwarding logic, and errors

Figure 1: End-to-end DNS query path from client virtual machine, through the Azure Firewall, to the Custom DNS server.

Example scenarios

Custom DNS configurations – Verify traffic forwarding paths and ensure custom DNS servers are functioning and responding as expected
Connectivity issues – Debug DNS resolution issues that prevent apps from connecting to critical services.

Getting started in Azure Portal

Navigate to your Azure Firewall resource in the Azure Portal.
Select Diagnostic settings under Monitoring.
Choose an existing diagnostic setting or create a new one.
Under Log, select DNS flow trace logs.
Stream logs to Log Analytics, Storage, or Event Hub as needed.
Save the settings.

Figure 2: Example DNS flow trace logs in Azure Firewall logging

✨ Next steps

DNS flow trace logs give you greater visibility and control over DNS traffic in Azure Firewall, helping you secure, troubleshoot, and optimize your network with confidence.

🚀 Try DNS flow trace logs today, now generally available – and share your feedback with the team

Learn more about how to configure and monitor these logs in the Azure Firewall monitoring data reference documentation.

General Availability of JavaScript Challenge in Azure Front Door WAF

andrewmathu — Thu, 13 Nov 2025 14:33:07 GMT

We are pleased to announce the General Availability (GA) of the JavaScript Challenge feature for Azure Web Application Firewall (WAF) on Azure Front Door. This capability equips organizations with a seamless, invisible anti-bot verification layer that distinguishes legitimate users from malicious scripts helping protect web applications from automated threats while preserving a smooth user experience.

Azure WAF JavaScript Challenge

Modern bot attacks are increasingly evasive, often bypassing traditional defenses like IP based blocking or simple rate limits. The JavaScript Challenge introduces a lightweight, browser-based verification step that helps distinguish legitimate users from automated scripts without requiring user interaction. Benefits of the JavaScript Challenge include:

Low friction for legitimate users: Genuine users experience minimal latency or interruption since no manual interaction is required.
Stronger bot protection: Automated tools and scripts fail to pass the computational challenge, enabling more effective blocking of bad bots.
Flexible enforcement: You can target specific endpoints (e.g., login, registration, checkout flows), apply to bot manager or custom rules, and adjust cookie lifetimes to align with your user experience goals.

How JavaScript Challenge Works

The JavaScript Challenge is configured as an action in either custom rules or in the Bot Manager ruleset. When a client’s HTTP/S request matches a rule with this action, Azure WAF directs the browser to a lightweight challenge page. The page runs a short computational task automatically usually invisible to the user.

If the browser successfully completes the computation, the request is validated and allowed to proceed, confirming that it originated from a legitimate user. If the challenge fails, the request will be blocked, preventing automated bots from accessing the application.

Getting Started

If you have been using JavaScript Challenge during the public preview, your existing configurations will continue to work. For new users, simply enable the JavaScript Challenge action in your WAF policy and define the triggering conditions.

For more details on configuration and best practices, check out our earlier blogs:

Documentation

Web Application Firewall JavaScript Challenge | Microsoft Learn

Using Packet Capture for troubleshooting Azure Firewall flows

ShabazShaik — Wed, 12 Nov 2025 15:14:04 GMT

This blog is written in collaboration with @GustavoModena

Introduction

Azure Firewall is a cloud-native and intelligent network firewall security service that provides best of breed threat protection for your cloud workloads running in Azure. It’s a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. Azure Firewall provides both east-west and north-south traffic inspection, and it is offered in three SKUs: Basic, Standard and Premium.

Azure Firewall also brings powerful logs and metrics to monitor your traffic and operations within the firewall. These logs and metrics include Traffic Analysis, Performance and Health Metrics, and Audit Trail. However, there are situations where you may need a comprehensive network packet capture to troubleshoot and investigate an incident reported by users. We are happy to announce that Microsoft just released the new Packet capture feature and it is Generally Available for Azure Firewall.

The Packet capture feature in Azure Firewall is intended for troubleshooting purposes and will allow customers and engineers to debug connectivity issues by tracing packets passing through their Azure Firewall. Azure Firewall Packet Capture shows two packets per flow, one for incoming direction and one for outgoing direction, so you can accurately correlate requests and responses during troubleshooting.

What is a network packet capture?

Network packet capture is a process that involves capturing network packets as they traverse a network interface. It's a valuable tool for network troubleshooting, analysis, and security monitoring.

A network packet capture involves intercepting Internet Protocol (IP) packets for analysis and then saving the packets captured to output files, typically saved in the “.pcap” file extension. Network engineers often utilize packet capturing for troubleshooting and monitoring network traffic to identify security threats. In the event of a data breach or other incident, packet captures offer essential forensic evidence that supports investigations. From a malicious actor’s viewpoint, packet captures can be used to steal passwords and other sensitive data. Unlike active reconnaissance techniques like port scanning, packet capturing can be conducted covertly, leaving no trace for investigators.

How Does a Packet Capture Work?

Packet captures can be performed using networking equipment like routers, firewalls or switches, or even an engineer’s laptop or desktop. Regardless of the method, packet capture involves creating copies of some or all packets passing through a particular point in the network.

Capturing packets from a specific device on the network is the simplest way to start troubleshooting, but there are a few caveats. By default, network interfaces only monitor traffic destined for them. For a more comprehensive view of network traffic, you’ll need to set the interface to promiscuous mode or monitor mode. Many routers, firewalls and other network devices have embedded packet capture functions that can be used to quickly troubleshoot directly from the device's admin console. This capability is now available in Azure Firewall.

Scenario (VNET to VNET)

In this blog we have VM-1 (10.10.0.4) unsuccessfully trying to establish HTTP (TCP 80)/HTTPS (TCP 443) connection to VM-2 (10.10.0.132) via Azure Firewall.

Using Azure Firewall Packet Capture to investigate the connection issue

In this section, we will use Azure Firewall Packet Capture to understand why an HTTP/HTTPS connection between VM-1 and VM-2 is not working properly. For this demonstration, we are not going to review the rules and Azure Firewall logs, as the purpose of the blog is to demonstrate the new Packet Capture feature, and we are assuming that the Azure Firewall is configured correctly.

Let’s start by making sure that we have all the required resources to take the packet captures from Azure Firewall:

Azure Firewall with Management NIC enabled
Storage account with a container in which you can store the packet captures

Once you have all the required resources available, follow the next steps to start running a Packet Capture via Azure Firewall:

Create a SAS URL to the container in the storage account: In the Azure Portal go to Storage Account > Containers and select the 3 ellipses at the very right side of the name of the container that you want to use to store the packet captures and select “Generate SAS”.

When defining the parameters of the SAS select “Write” under Permissions, so Azure Firewall will be able to successfully save the packet captures. Then click on “Generate SAS token and URL”.

Now, we must go to the Azure Firewall > Packet Capture (under Help) to start running the packet capture.
On the Packet Capture page, provide the following information:

- Packet capture name - the name of one or more capture files.
- Output SAS URL - the SAS URL of the storage container you created previously.

Next, complete the Basic settings for the packet capture:

- Maximum number of packets - You should limit the packet capture to a set number of packets.
- Time limit (seconds) - Since the packet capture is intended for troubleshooting purposes, you should limit the capture time.
- Protocols - the protocols you want the capture to save (values: Any, TCP, UDP, ICMP).
- TCP Flags - if TCP or Any is selected, you can select which types of packets to save (values: FIN, SYN, RST, PSH, ACK, URG)

If both the Maximum number of packets and Time limit are set, the capture ends when the earliest condition is met. So, either when the maximum number of packets is received or when the time limit is reached.

In the Filtering section, you can add the source, destination, and destination ports to include in the capture. You must add at least one filter.

- The packet capture saves bidirectional traffic that matches each row in the filter section.
- For the source and destination fields you can list multiple commas separated values in a single filter including IP addresses and IP blocks.

Select Run Packet Capture after you're done with your configuration.

Once the packet capture is complete, you will navigate to the container used in the storage account and download the pcap files. Note that you will see multiple pcap files, this is because each virtual machine in the backend of the firewall has its own file.

Analyzing the Packet Captures

When using Azure Firewall Packet Capture, you will always see two packets for every single packet in the flow. This is because the firewall captures both the incoming and outgoing directions of the traffic. Understanding this behavior is critical for accurate troubleshooting, as it ensures you can correlate the original request with its corresponding response. The additional scenarios below will explain how to match these incoming and outgoing flows effectively.

To analyze the pcap files you need a network protocol analyzer tool. In this blog we are using Wireshark.

Note: The intent of this blog is not to show how to use it nor to do advanced troubleshooting using Wireshark.

With the pcap files downloaded to your computer, open the files to start your investigation. Since we have multiple files due to the number of active Azure Firewall instances at the time of the packet capture, it may be easier to merge the files. To merge the pcap files, first open one of them using Wireshark and then go to File > Merge and select the second file. There are different ways to merge them, but here we are using “Merge packets chronologically”.

Once the pcap files are merged, you will start your investigation by using filters. In this scenario, we want to investigate why an HTTP request from VM-1 to VM-2 on port TCP 80 is not working, and we are using the following filter:

Wireshark filter: tcp.port==80 && tcp.port==50245 && ip.addr==10.10.0.132 (VM-2’s IP address)

Ok, so here we can see that VM-1 (10.10.0.4) sends a SYN packet from port 53945 to VM-2 (10.10.0.132) on port 80, then VM-2 sends a reset back to VM-1. This behavior shows us that the traffic is successfully passing through Azure Firewall (allowed), and the issue may possibly be something on VM-2. After involving the application team, they have found an issue related to the IIS configuration and it is now fixed as we can see the TCP request being established on ports 80 and 443 in the screenshot below.

Other Scenarios

DNAT (Inbound traffic)

In this scenario we are connecting from a client via Internet to the Azure Firewall’s public IP, using DNAT rules on port 8443. You can see in the screenshot below the incoming request (TCP 3-way handshake) and all the hops until it gets to the Web Server. L3 (and source IP) differs from the incoming packet since its SNATed at L3 while L4 remains the same. For taking the packet capture in this scenario, we are using the following filters:

Source: 71.28.90.56,52.176.62.243,10.10.0.64/26,10.10.0.128/26
Destination: 71.28.90.56,52.176.62.243,10.10.0.64/26,10.10.0.128/26
Destination ports: 8443,443

Check below to understand what each one of the IP/IP ranges and ports are used as filters:

Client Public IP: 71.28.90.56
Azure Firewall Public IP: 52.176.62.243
Azure Firewall Instance Private IP: 10.10.0.69 (this IP is included in the IP range 10.10.0.64/26)
Web Server Private IP: 10.10.0.132 (this IP is included in the IP range 10.10.0.128/26
Azure Firewall Listening Port: 8443
Web Server Listening (translated) Port: 443

In DNAT scenarios, you will notice two SYN packets for the same flow. SYN 1 represents the incoming packet with its original 5-tuple (source IP, destination IP, source port, destination port, protocol), while SYN 2 corresponds to the same flow but with a different 5-tuple after translation by Azure Firewall. This behavior contrasts with VNET-to-VNET flows, where the 5-tuple remains unchanged.

When you are SNATing, connecting to/from the Internet, or processing application rules, to see both incoming and outgoing packets you need to make sure that both Public IP address and subnet address space are included.

Internet Access (Outbound traffic)

In this scenario, we are connecting from an Azure VM to the public IP via Azure Firewall using Network rules. The screenshot illustrates the TCP three-way handshake followed by the HTTP GET request. Notice two SYN packets: one originating from the client to the destination and another from the Azure Firewall instance IP to the destination. In the first two lines, packets flow from the Azure VM IP to the external public IP, followed by the SNATed packet from the Azure Firewall instance IP to the same external address. For this packet capture, the following filters were applied:

Source: 10.10.0.132, 10.10.0.0/26
Destination: 151.101.195.5
Destination ports: 80,443

Check below to understand what each one of the IP/IP ranges and ports are used as filters:

Azure VM: 10.10.0.132
Azure Firewall Subnet: 10.10.0.0/26 (10.10.0.5 is the instance IP)
External Public IP: 151.101.195.5
External Public IP Port: 80

Application Rule Traffic:

In this scenario, we are connecting from an Azure VM to the public IP via Azure Firewall using Application rules. While the original request originates from the VM with source IP 10.0.2.4, the Layer 4 details differ from the incoming packet because, during application rule evaluation, the firewall establishes a new outbound connection acting as a proxy. As shown in the image, the SNAT IP of the Azure Firewall instance (10.0.0.5) initiates the connection to the public IP 140.82.112.4. HTTP or TLS keys can be used to match incoming and outgoing packets. L7 remains the same. For packet capture in this scenario, the following filters are applied:

Source: 10.0.2.4, 10.0.0.0/24
Destination: 140.82.112.4
Destination ports: 80,443

Check below to understand what each one of the IP/IP ranges and ports are used as filters:

Azure VM: 10.0.2.4
Azure Firewall Subnet: 10.0.0.0/24 (10.10.0.5 is the instance SNAT IP)
External Public IP: 140.82.112.4
External Public IP Port: 80,443

VNET to VNET with SNAT:

In this scenario, the client VM 10.1.0.4 initiates the connection to the server VM 10.0.2.4 but we have enabled SNAT to happen by default. So, the Firewall’s Private IP 172.16.0.5 (SNAT) will initiate a connection with the destination web server as we can see in the below image. For packet capture in this scenario, the following filters are applied:

Source: 10.1.0.4, 172.16.0.0/24
Destination: 10.2.0.4
Destination ports: 80,443

Check below to understand what each one of the IP/IP ranges and ports are used as filters:

Azure VM: 10.1.0.4
Azure Firewall Subnet: 172.16.0.0/24 (172.16.0.5 is the instance SNAT IP)
Web Server Private IP: 10.2.0.4
Web Server Port: 80

Conclusion

The availability of Azure Firewall Packet Capture is crucial for effective network and security troubleshooting. It allows network administrators and security professionals to monitor, analyze, and diagnose network traffic in real-time, providing invaluable insights into potential issues and vulnerabilities. By capturing and examining data packets, they can identify anomalies, detect malicious activities, and ensure the integrity and performance of the network. This proactive approach not only enhances the overall security posture but also minimizes downtime and improves the reliability of network services, making packet capture an indispensable tool in the modern IT landscape.

Public Preview: Custom WAF Block Status & Body for Azure Application Gateway

SaleemBseeu — Wed, 05 Nov 2025 15:28:03 GMT

Introduction

Azure Application Gateway Web Application Firewall (WAF) now supports custom HTTP status codes and custom response bodies for blocked requests. This Public Preview feature gives you more control over user experience and client-side handling, aligning with capabilities already available on Azure Front Door WAF.

Why this matters

Previously, WAF returned a fixed 403 response with a generic message. Now you can:

Set a custom status code (e.g., 403, 429) to match your app logic.
Provide a custom response body (e.g., a friendly error page or troubleshooting steps).
Ensure consistency across all blocked requests under WAF policy.

This feature improves user experience (UX), helps with compliance, and simplifies troubleshooting.

Key capabilities

Custom Status Codes: Allowed values: 200, 403, 405, 406, 429, 990–999.
Custom Response Body: Up to 32 KB, base64-encoded for ARM/REST.
Policy-level setting: Applies to all blocked requests under that WAF policy.
Limit: Up to 20 WAF policies with custom block response per Application Gateway.

Configure in the Azure Portal

Follow these steps:

Sign in to the https://portal.azure.com.
Navigate to your WAF Policy linked to the Application Gateway.
Under Settings, select Policy settings.
In the Custom block response section:
Block response status code: Choose from allowed values (e.g., 403 or 429).
Block response body: Enter your custom message (plain text or HTML).
Save the policy.
Apply the policy to your Application Gateway if not already associated.

Configure via CLI

az network application-gateway waf-policy update \ --name MyWafPolicy \ --resource-group MyRG \ --custom-block-response-status-code 429 \ --custom-block-response-body "$(base64 custompage.html)"

Configure via PowerShell

Set-AzApplicationGatewayFirewallPolicy ` -Name MyWafPolicy ` -ResourceGroupName MyRG ` -CustomBlockResponseStatusCode 429 ` -CustomBlockResponseBody (Get-Content custompage.html -Encoding Byte | [System.Convert]::ToBase64String)

Tip: For ARM/REST, the body must be base64-encoded.

Best practices

Use meaningful status codes (e.g., 429 for rate limiting).
Keep the response body lightweight and informative.
Test thoroughly to ensure downstream systems handle custom codes correctly.

Resources

General Availability of CAPTCHA in Azure Front Door WAF

andrewmathu — Wed, 29 Oct 2025 18:00:25 GMT

We are excited to announce the General Availability (GA) of the Azure Web Application Firewall (WAF) CAPTCHA challenge for Azure Front Door, empowering customers to better defend their web applications against automated bot attacks while ensuring legitimate users can still access their apps seamlessly.

This milestone marks the culmination of a successful public preview that saw hundreds of customers defend against more than 700 million bot requests, reinforcing the value of interactive security mechanisms in modern web application protection.

Why CAPTCHA Matters

Web applications today face an ever-growing array of automated threats - bots, scrapers, credential stuffing, and brute-force attacks - that often bypass traditional defenses like IP blocking and rate limiting. CAPTCHA introduces a human verification layer that helps distinguish legitimate users from malicious automation.

With this GA release, Azure Front Door WAF now offers a fully supported CAPTCHA action that can be configured in custom rules or Bot Manager rules. When suspicious traffic matches a CAPTCHA-enabled rule, users are prompted with a visual or audio challenge to verify their identity before proceeding.

How CAPTCHA Works

When a client request matches a WAF rule that has the CAPTCHA action enabled, Azure WAF displays an interactive CAPTCHA challenge in the browser to verify that the requester is human.

If the user successfully solves the CAPTCHA, Azure WAF marks the request as validated and allows it to proceed through the rest of the rule evaluation.
Requests that don’t complete the challenge (or fail it) are blocked, stopping automated bots from advancing.

What’s New in GA

With the GA release, customers can expect:

Updated Interstitial Page: The CAPTCHA page now includes refreshed Microsoft branding, delivering a more consistent and trusted experience for users.
Enhanced Stability and Performance: Improvements based on feedback from preview deployments to ensure faster response times and smoother user verification experiences.
Full Production Support: The feature is now backed by Microsoft’s service-level agreement (SLA) and is recommended for all production workloads.

How to Get Started

If you have already been using CAPTCHA during the public preview, no action is needed, your configurations will continue to work as expected. For new users, simply enable the CAPTCHA action within your custom rules or managed rule sets and define the triggering conditions.

For a deeper dive into how CAPTCHA works and how to configure it, check out our earlier blogs:

Documentation

Azure Front Door Web Application Firewall CAPTCHA | Microsoft Learn

Prescaling in Azure Firewall is now generally available

surenjamiyanaa — Thu, 16 Oct 2025 18:00:59 GMT

Azure Firewall protects your applications and workloads with cloud-native network security that automatically scales based on your traffic needs. Today, we’re excited to announce the general availability of prescaling in Azure Firewall – a new capability that gives you more control and predictability over how your firewall scales.

Why pre-scaling?

Today, Azure Firewall automatically scales in response to real-time traffic demand. For organizations with predictable traffic patterns – such as seasonal events, business campaigns, holidays, or planned migrations – the ability to plan capacity in advance can provide greater confidence and control.

That’s where prescaling comes in.

With prescaling, you can:

Plan ahead– Set a baseline number of firewall capacity units to ensure capacity is already in place before demand rises.
Stay flexible – Define both minimum and maximum capacity unit values, so your firewall always has room to grow while staying within your chosen bounds.
See clearly – Monitor capacity trends with a new observed capacity metric and configure alerts to know when scaling events occur.

You can think of it as adding extra checkout counters before a holiday rush – when the customers arrive, you’re already prepared to serve them without delays or bottlenecks.

Example scenarios

E-commerce sales events – Scale up before a holiday shopping promotion to handle the surge in online buyers.
Workload migrations – Ensure sufficient capacity is ready during a large data or VM migration window.
Seasonal usage – For industries like education, gaming, or media streaming, pre-scale ahead of known peak seasons.

Getting started in Azure Portal

Navigate to your Azure Firewall resource in the Azure Portal.
Select Scaling options in settings.
By default, every Azure Firewall starts in autoscaling mode. To enable prescaling, simply switch to pre-scaling mode in the Azure Portal and configure your desired capacity range:
Minimum capacity: 2 or higher.
Maximum capacity: up to 50, depending on your needs.
Monitor the scaling behavior with the observed capacity metric.

Billing and availability

Pre-scaling uses a new Capacity Unit Hour meter. Charges apply based on the number of firewall instances you configure.

Standard: $0.07 per capacity unit hour
Premium: $0.11 per capacity unit hour

✨ Next steps

Prescaling gives you predictable performance and proactive control over your firewall, helping you confidently handle the traffic patterns that matter most to your business.

🚀 Try prescaling today and share your feedback with the team.

Learn more about how to configure and monitor this feature in the Azure Firewall prescaling documentation.

How Azure network security can help you meet NIS2 compliance

SaleemBseeu — Fri, 26 Sep 2025 15:18:07 GMT

With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance.

If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations.

Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts.

What is NIS2?

NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to:

Expand the scope of covered entities essential and important entities
Harmonize cybersecurity standards across member states
Introduce stricter supervisory and enforcement measures
Strengthen supply chain security and reporting obligations

Key provisions include:

Article 20 management responsibility and governance
Article 21 cybersecurity risk management measures
Article 23 incident notification obligations

These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability.

Where Azure network security fits

The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes.

NIS2 focus area	Azure services and capabilities	How this supports compliance
Incident handling and detection	Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs	Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable.
Business continuity and resilience	Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover	Improve service availability and provide data for resilience reviews and disaster recovery scenarios.
Access control and segmentation	Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link	Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress.
Vulnerability and misconfiguration defense	Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures	Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs.
Encryption and secure communications	TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection	Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats.
Incident reporting and evidence	Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks	Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines.

NIS2 articles in practice

Article 21 cybersecurity risk management measures

Azure network controls contribute to several required measures:

Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance.
Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation.
Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions.
Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones.

Article 23 incident notification

Build an evidence friendly workflow with Sentinel:

Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory.
Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF.
Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative.

Article 20 governance and accountability

Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification.
Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations.
Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes.

Network security baseline

Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance.

Topology and control plane
1. Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones.
2. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs.
3. Use Network Security Hub for at-scale management.
4. Require Infrastructure as Code for all network security resources.
Web application protection
1. Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios.
2. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate.
DDoS strategy
1. Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios.
2. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement.
Firewall policy
1. Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported.
2. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments.
3. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments.
Logging, retention, and access
1. Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention.
2. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits.
3. Restrict access with Azure RBAC and Customer Managed Keys where applicable.
Automation and playbooks
1. Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises.
2. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access.

Conclusion

Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture.

Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence.

References

NIS2 primary source

Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng

Azure Firewall

Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features
Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy
IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories
Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference

Web Application Firewall

WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall
WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview
Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics
Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit

Azure DDoS Protection

Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview
Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal
View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs

Azure Bastion

Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview
Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal
Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline
Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs

Microsoft Sentinel

Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/
Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview
Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel

Architecture & routing

Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke
Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hub

Azure DDoS Protection now supports QUIC protocol — Securing the future of HTTP/3 traffic

ShabazShaik — Wed, 24 Sep 2025 09:13:29 GMT

The internet’s transport layer is undergoing one of its most significant evolutions in decades. QUIC (Quick UDP Internet Connections) — the protocol underpinning HTTP/3 — is rapidly becoming the default for high performance, secure communication on the web. From YouTube streaming to WhatsApp messaging, QUIC is already powering billions of connections daily.

Recognizing both its potential and its unique security challenges, Microsoft has now integrated full QUIC mitigation capabilities into Azure DDoS Protection. This protection is enabled by default — no configuration required — ensuring that customers adopting HTTP/3 can do so with confidence.

What is QUIC and why it matters

QUIC was originally developed by Google and standardized by the IETF in 2021 (RFC 9000). Unlike traditional HTTP/2 over TCP, QUIC runs over UDP port 443, combining transport and security layers into a single handshake. This allows a secure, encrypted connection to be established in just one round trip — or even zero round trips for repeat connections.

Technical advantages of QUIC include:

Integrated TLS 1.3 — Encryption is built into the protocol, eliminating the need for separate TLS negotiation.

Multiplexed streams without head of line blocking — Independent streams mean packet loss in one stream doesn’t stall others.

Connection migration — QUIC connections survive IP address changes, ideal for mobile devices switching between Wi-Fi and cellular.

Faster recovery from loss — QUIC uses packet numbers instead of TCP sequence numbers, improving loss detection and retransmission.

These features make QUIC ideal for latency sensitive workloads such as video streaming, online gaming, and real-time collaboration tools.

The DDoS challenge for QUIC:

While QUIC’s design improves performance and security, its reliance on UDP introduces a distinct threat profile that goes beyond traditional UDP floods. QUIC’s handshake, encryption model, and connection identifiers create attack surfaces unique to the protocol.

Key QUIC‑specific DDoS vectors include:

Initial Packet Floods with Fake Handshakes
- Attackers send large volumes of QUIC Initial packets containing incomplete or malformed TLS Client Hello messages.
- This forces the server to allocate cryptographic resources for each bogus attempt, consuming CPU and memory.
Connection ID Exhaustion
- QUIC uses Connection IDs to maintain state across IP changes. Attackers can rapidly cycle through random Connection IDs to bypass per‑IP rate limits.
- This can overwhelm connection tracking tables.
Version Negotiation Abuse
- Attackers send unsupported or random QUIC version numbers to trigger repeated version negotiation responses from the server.
- This consumes bandwidth and processing without establishing a valid session.
Malformed Frame Injection
- QUIC frames (STREAM, ACK, CRYPTO, etc.) can be deliberately malformed to trigger parsing errors or excessive error handling.
- Unlike generic UDP payloads, these require QUIC‑aware inspection to detect.
Amplification via Retry Packets
- QUIC Retry packets can be abused in reflection attacks if the server responds with larger payloads than the request.
- Attackers spoof victim IPs to direct amplified traffic toward them.

Why this is different from generic UDP floods: Generic UDP attacks typically rely on raw packet volume or reflection from open services. QUIC attacks exploit protocol‑level behaviors — handshake processing, version negotiation, and Connection ID handling — that require stateful, QUIC‑aware mitigation. Traditional UDP filtering cannot distinguish between a legitimate QUIC Initial packet and a crafted one designed to exhaust resources.

Azure DDoS Protection — QUIC mitigation [built-in]:

Azure DDoS Protection now supports QUIC mitigation by default. This enhancement applies to all customers automatically — no opt-in or no manual tuning is required.

Technical capabilities include:

Protocol Compliance Validation — Ensures QUIC packets conform to RFC specifications, including fixed bit checks, version enforcement, and valid Connection ID lengths.

Initial Packet Verification — Validates that QUIC initial packets contain a proper TLS Client Hello with Server Name Indication (SNI), blocking spoofed or incomplete handshakes.

Source & Destination Rate Limiting — Controls excessive connection attempts per 4tuple (source IP, destination IP, source port, destination port).

Global Limit IDs (GLID) — Applies connection and packet rate limits globally across the mitigation platform.

Retry Authentication — Issues a cryptographic cookie challenge to verify client authenticity before allowing session establishment.

Packet Rate Limiting by Connection ID — Limits both long header (initial) and short header (post handshake) packet rates to prevent floods.

Malformed Packet Filtering — Drops packets with unsupported frames, invalid versions, or missing headers.

Version Pinning — Prevents downgrade attacks by enforcing negotiated QUIC versions.

All existing Layer 4 protections for UDP traffic — such as flood detection, anomaly scoring, and adaptive thresholds — are fully applied to QUIC.

Real-world impact:

Without effective mitigation, QUIC based services are highly susceptible to a range of disruptive threats. UDP floods can quickly overwhelm servers, consume resources and render applications unresponsive. Amplification attacks, which exploit the stateless nature of UDP, can multiply inbound traffic by factors of ten to a hundred, creating massive spikes that cripple performance. Such attacks often lead to high packet loss, degraded user experiences, and service interruptions. They can also drive-up infrastructure costs significantly, as organizations are forced to handle large volumes of malicious traffic that consume bandwidth and processing power.

With Azure DDoS Protection in place, these risks are proactively addressed. Intelligent rate limiting and packet filtering mechanisms stop floods before they impact service availability. Spoofed packet blocking prevents reflection attacks from ever reaching the application layer. The result is a consistently reliable, low latency connection for QUIC enabled applications, even under hostile network conditions. By scrubbing malicious traffic before it reaches customer workloads, Azure also helps reduce operational costs, ensuring that resources are spent serving legitimate users rather than absorbing attack traffic.

Who benefits from QUIC DDoS mitigation:

The benefits of QUIC aware DDoS protection extend across industries and use cases. Web applications and APIs built on HTTP/3 gain the performance advantages of QUIC without inheriting its security risks. Streaming platforms such as YouTube or Twitch can deliver high quality, uninterrupted video experiences to millions of viewers, even during attempted network disruptions. Messaging and VoIP services like WhatsApp, Discord, and Zoom maintain crystal clear communication and low latency, which are critical for user satisfaction. Online gaming platforms, where milliseconds matter, can preserve smooth gameplay and prevent lag spikes caused by malicious traffic. Financial services and real-time transaction systems also stand to benefit, as they can maintain secure, uninterrupted operations in environments where downtime or delays could have significant business and compliance implications.

Looking ahead:

Microsoft is committed to continuously strengthening QUIC protection within Azure DDoS Protection. Efforts are already underway to expand mitigation capabilities ensuring broader coverage across the global network and to detect and neutralize threats faster and with greater precision, adapting to the evolving tactics of attackers. Just as importantly, Microsoft is actively gathering feedback from customers and internal teams to refine mitigation strategies, ensuring that QUIC protection remains both robust and aligned with real world usage patterns. These ongoing enhancements will help customers confidently adopt and scale QUIC based services, knowing that their performance and security are safeguarded by default.

Conclusion:

QUIC is the future of fast, secure internet communication — and Azure DDoS Protection is ready for it. With always-on, default-enabled QUIC mitigation, Azure customers can confidently adopt HTTP/3 without worrying about the unique DDoS risks that come with UDP based protocols.

Your applications stay fast. Your users stay connected. Your infrastructure stays protected.

Monitoring web application traffic for configuring rate limit on Azure Front Door WAF

andrewmathu — Tue, 23 Sep 2025 15:01:54 GMT

Introduction

Azure Web Application Firewall (WAF) is a cloud-native service that actively protects web applications from common vulnerabilities and exploits. It also supports custom rules that allow fine-grained control over traffic. Among these custom rules is the rate-limiting feature available in both Azure Application Gateway and Azure Front Door. Rate limiting helps mitigate denial-of-service (DoS) attacks, prevents abuse from misconfigured clients sending excessive requests, and controls traffic from specific geographies. By limiting requests per client in a set time window, WAF keeps your app available and responsive even under heavy load.

While rate limiting is a powerful tool for safeguarding web applications, some users struggle with configuring appropriate thresholds and durations. These two values often require tuning based on actual traffic patterns. Without proper planning or visibility into real traffic patterns, rate limit settings often end up being:

Too strict – Blocking legitimate users and degrading user experience.
Too lenient – Failing to stop abusive or malicious traffic.

This blog is the first in a two-part series designed to help users configure rate limiting in Azure Web Application Firewall (WAF). In this first part, we focus on Azure Front Door WAF and demonstrate how to use diagnostic logs to make informed, data-driven decisions about rate limit thresholds and durations. By analyzing real traffic patterns, you can configure rate limits that strike the right balance between security and usability, protecting your application without disrupting legitimate users.

Understanding rate limiting in Azure Front Door WAF

At its core, rate limiting is a mechanism that restricts the number of requests a client can make to a web application within a specified period. This helps prevent issues like brute-force login attacks, automated bots scraping data, or sudden traffic spikes. Azure Front Door WAF applies rate limiting through custom rules that monitor incoming requests according to specific match conditions.

Key characteristics of rate limiting in Azure Front Door WAF include:

Duration: Can be set to 1 or 5 minutes.
Threshold: Number of requests allowed in the time window.
Customizability match conditions: You can match based on country (geolocation), IP address (remote address or socket address) request URI, HTTP method, and more.
Action: What to do when the threshold is exceeded e.g., deny, log, redirect, JS Challenge (preview), CAPTCHA (preview).

Below is an example of a rate limit rule configured in Azure Front Door WAF:

Using diagnostic logs to configure WAF rate limiting

To configure effective rate limiting policies in Azure Front Door WAF, it is important to understand how users are accessing your application. Diagnostic logs from Azure Front Door provide this visibility. In this section, we’ll walk through:

Enabling diagnostic logs
Querying traffic patterns with KQL
Using insights to define smart thresholds and durations

Enable diagnostic logs

In Azure Front Door:

Go to your Front Door profile.
Under Monitoring, select Diagnostic settings.
Click + Add diagnostic setting.
Add a new setting to capture:
- FrontDoor Access Log – request level data.
- FrontDoor WebApplicationFirewall Log – WAF rule matches.
Send logs to:
- Log Analytics workspace (recommended for querying),
- Storage account, or
- Event Hub.
Save the settings.

When configuring rate limit rules in Azure Front Door WAF, you can choose either a 1-minute or 5-minute time window. While both options are supported, using a 5-minute window with a higher threshold can improve detection accuracy by reducing false positives. Rate limiting is applied per socket IP - the source IP as seen by Azure Front Door. If there's another CDN or proxy in front of Front Door, this IP may not represent the original client, which can affect how rate limits are enforced. Please refer to Web application firewall rate limiting for Azure Front Door | Microsoft Learn.

Analyze traffic behavior with KQL

With diagnostic logs flowing into your log analytics workspace, you can begin to understand actual request volumes, IP behavior, and trends across time. These insights form the basis for defining effective rate limits.

Query 1: Average requests per IP (5-minute intervals)

This first query provides the average number of requests each client IP sends over 5-minute windows. It helps establish a baseline of expected activity per user. Understanding the average request rate helps you distinguish between normal and abnormal behavior. It’s your starting point for setting a rate limit that won’t block legitimate users.

AzureDiagnostics

| where Category == "FrontDoorAccessLog"

| summarize RequestsPerIP = count() by clientIp_s, bin(TimeGenerated, 5m)

| summarize AvgRequestsPerIP = avg(RequestsPerIP) by bin(TimeGenerated, 5m)

| order by TimeGenerated asc

Usage: Set your initial rate limit slightly above the observed average to allow for minor bursts while still preventing abuse.

The screenshot below shows the average number of requests per IP in 5-minute intervals from our Azure Front Door demo environment within a 7-day period. Most intervals fall between 1 to 5 requests per IP, indicating normal user behavior. However, there are occasional spikes, such as 15.5 requests at 4:10 PM and a significant burst of 459 requests at 4:15 AM. This highlights the importance of using real data to set thresholds. While a baseline of 20–30 requests per 5 minutes would cover typical traffic, it would still catch outlier spikes like these that may indicate abuse or automation.

Query 2: Max requests seen from a client IP (5-minute window)

This query surfaces the maximum number of requests observed from any individual IP address in a single 5-minute time window. This helps you understand peak load behavior, which could be from a legitimate spike or a potential abuse/bot.

AzureDiagnostics

| where Category == "FrontDoorAccessLog"

| summarize RequestsPerIP = count() by clientIp_s, bin(TimeGenerated, 5m)

| summarize MaxRequestsPerIP = max(RequestsPerIP) by clientIp_s

| order by MaxRequestsPerIP desc

Usage: Use this to define an upper threshold for rate limiting. To avoid overfitting outliers, consider setting your limit near the 95th percentile of these max values.

The screenshot below shows the results of the KQL query executed in my demo environment using Azure Front Door diagnostic logs within a 7-day period. As observed, the most active IP (35.X.X.X) recorded a peak of 459 requests within a 5-minute window, which is significantly higher than the rest. The second highest IP peaked at 106 requests, and most of the client IPs fell well below 30 requests per 5 minutes. This distribution highlights an important insight: while most users exhibit moderate request behavior, a few outliers can generate large bursts. These outliers could be misconfigured clients, aggressive bots, or potential abuse cases.

When configuring rate limits, it’s advisable to base your threshold not on the absolute maximum (459), but rather on a statistical percentile such as the 90th or 95th percentile. In this case, a reasonable threshold might be around 120–150 requests per 5 minutes, allowing headroom for legitimate high-traffic users while still blocking abnormal spikes.

Query 3: Most active IP per country (Geo-aware limit tuning)

This query identifies the top-requesting IP address per country for each 5-minute window. Seeing regional traffic patterns allows you to detect suspicious activity from specific geographies or apply geo-based rate limits.

Azure Front Door:

AzureDiagnostics

| where Category == "FrontDoorAccessLog"

| summarize RequestCount = count() by bin(TimeGenerated, 5m), clientCountry_s, clientIp_s

| summarize arg_max(RequestCount, clientIp_s) by TimeGenerated, clientCountry_s

| project TimeGenerated, clientCountry_s, clientIp_s, RequestCount

| order by TimeGenerated asc, clientCountry_s asc

Usage: Use this to justify stricter thresholds for high-traffic countries or create region-specific custom WAF rules.

The screenshot below shows the output of the geo-based query, which identifies the most active IP address per country in 5-minute intervals. As observed, some IPs consistently generate higher request volumes than others, indicating regional traffic concentration or potential anomalies. This pattern can help inform geo-specific rate limiting strategies, where regions with higher activity may warrant stricter thresholds or additional monitoring to mitigate localized abuse without impacting global user experience.

Query 4: Request trends per URI segment

This query breaks down requests by the first segment of the URI path (e.g., /api, /assets). It helps identify which parts of your app are most accessed.

Azure Front Door:

AzureDiagnostics

| where Category == "FrontDoorAccessLog"

| extend Path = tostring(parse_url(requestUri_s).Path)

| extend FirstSegment = extract("^/([^/]+)", 0, Path)

| summarize RequestCount = count() by FirstSegment, bin(TimeGenerated, 5m)

| order by TimeGenerated asc, RequestCount desc

Usage: Endpoints such as /login or /register are often targets for abuse. Segment-level analysis helps you target rate limits to specific parts of your app.

The screenshot below shows the request distribution across the first URI segment (or resource) in 5-minute intervals. From the data, it’s clear that certain endpoints such as those serving static files (e.g., /styles.css) or known paths like /favicon.ico have consistent but low traffic. However, there are sudden spikes, such as 27 requests to /styles.css and 56 requests to /checkout.html, which could indicate automation, scraping, or testing behavior. Tracking usage by URI segment helps you identify which parts of your app are under heavy or suspicious load. You can use this insight to apply URI-specific rate limiting rules, especially for sensitive or high-traffic paths (e.g., /checkout, /login, /debug). This minimizes the risk of abuse without throttling static content or safe endpoints.

Query 5: Average requests per full URI

This query calculates the average number of requests per full URI across all 5-minute intervals. It helps identify high-traffic endpoints. Endpoints with consistently high traffic may need dedicated rate limits.

Azure Front Door:

AzureDiagnostics

| where Category == "FrontDoorAccessLog"

| summarize RequestsPerUri = count() by requestUri_s, bin(TimeGenerated, 5m)

| summarize AvgRequestsPerUri = avg(RequestsPerUri) by requestUri_s

| order by AvgRequestsPerUri desc

Usage: Use this to create path-specific rules; for example, /login may need a stricter threshold than /homepage.

The screenshot below shows the results of the query, highlighting which full URIs receive the highest average number of requests over 5-minute intervals. The results show frequent access to specific assets (e.g., /favicon.ico, /styles.css), REST API endpoints, and one suspicious XSS injection attempt with unusually high traffic. This insight helps identify abuse patterns, automated scans, or popular resources, guiding you to apply rate limits more precisely either globally or per path to protect critical or vulnerable endpoints.

Guidance and Considerations

The KQL queries and thresholds shared in this blog are intended as guidance based on common patterns and demo environments. Traffic behavior varies across applications, and you should validate results against your own environment and adjust thresholds accordingly. Always test custom rules in Detection mode before enforcing them in Prevention mode to avoid disrupting legitimate traffic.

It’s also important to consider the scalability of the application or backend service behind Azure Front Door. Rate limiting controls traffic, but if your app runs on a single instance or doesn’t scale well, it may still fail under load. As a best practice, ensure your services can auto scale or handle spikes gracefully in tandem with WAF rate limiting rules.

Conclusion

Configuring effective rate limiting in Azure Front Door WAF is not just about setting arbitrary thresholds. It requires understanding how your application is accessed and where traffic patterns indicate potential abuse or anomalies. By leveraging diagnostic logs and analyzing real-world traffic with KQL, you can create rate limit rules that are both protective and practical. This data-driven approach helps you to reduce noise, prevent misuse, and maintain a smooth experience for legitimate users.

References

What is Azure Web Application Firewall on Azure Front Door? | Microsoft Learn

Web application firewall custom rule for Azure Front Door | Microsoft Learn

Web application firewall rate limiting for Azure Front Door | Microsoft Learn

Azure Web Application Firewall monitoring and logging | Microsoft Learn

Introducing the new Network Security Hub in Azure

surenjamiyanaa — Wed, 17 Sep 2025 18:31:16 GMT

Background:

Since its launch in 2020, Azure Firewall Manager has supported customers in securing their networks. But the role of network security has since evolved, from a foundational requirement to a strategic priority for organizations. Today, organizations must protect every endpoint, server, and workload, as attackers continually search for the weakest link.

Over the years, we’ve heard consistent feedback about the importance of centralized management, easier service discovery, and streamlined monitoring across their network security tools. These capabilities can make the difference between a minor incident and a major breach.

That’s why we’re excited to introduce a new, unified Network Security hub experience. This updated hub brings together Azure Firewall, Web Application Firewall, and DDoS Protection—enabling you to manage, configure, and monitor all your network security services in one place. While Azure Firewall Manager offered some of this functionality, the name didn’t reflect the broader scope of protection and control that customers need.

With this new experience, Firewall Manager has expanded into the Network Security Hub, making it easier to discover, configure, and monitor the right security services with just a few clicks. The result: less time navigating, more time securing your environment.

What you’ll notice:

Streamlined navigation: Whether you search for Azure Firewall, Web Application Firewall, DDoS Protection, or Firewall Manager, you’ll now be directed to the new Network Security hub. This unified entry point presents all relevant services in context—helping you stay focused and quickly find what you need, without feeling overwhelmed.
Overview of services: The hub’s landing page provides a high-level view of each recommended solution, including key use cases, documentation links, and pricing details—so you can make informed decisions faster.
Common scenarios: Explore typical deployment architectures and step-by-step guidance for getting started, right from the overview page.
Related services: We’ve consolidated overlapping or closely related services to reduce noise and make your options clearer. The result? Fewer, more meaningful choices that are easier to evaluate and implement.
New insights: We've enhanced the security coverage interface to show how many of your key resources are protected by Azure Firewall, DDoS Protection, and Web Application Firewall. Additionally, our integration with Azure Advisor now provides tailored recommendations to help you strengthen your security posture, reduce costs, and optimize Azure Firewall performance.

What this means for you:

No changes to Firewall Manager pricing or support: This is a user experience update only for Firewall Manager. You can continue to deploy Firewall policies and create Hub Virtual Network or Secured Virtual Hub deployments —now within the streamlined Network Security hub experience.
Aligned marketing and documentation: We’ve updated our marketing pages and documentation to reflect this new experience, making it easier to find the right guidance and stay aligned with the latest best practices.
Faster decision-making: With a clearer, more intuitive layout, it’s easier to discover the right service and act with confidence.
Better product experience: This update brings greater cohesion to the Azure Networking portfolio, helping you get started quickly and unlock more value from day one

Before: The original landing page was primarily focused on setting up Firewall Policies and Secured Virtual Hub, offering a limited view of Azure’s broader network security capabilities.

After: The updated landing page delivers a more comprehensive and intuitive experience, with clear guidance on how to get started with each product—alongside common deployment scenarios to help you configure and operationalize your network security stack with ease.

Before: The previous monitoring and security coverage experience was cluttered and difficult to navigate, making it harder to get a quick sense of your environment’s protection status.

After: The updated Security Coverage view is cleaner and more intuitive. We've streamlined the layout and added Azure Advisor integration, so you can now quickly assess protection status across key services and receive actionable recommendations in one place.

The expansion of Firewall Manager into the Network Security hub is part of a greater strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. You can learn more about this initiative in this blog. This shift is designed to better align with customer needs and industry best practices—by emphasizing core services, consolidating related offerings, and phasing out legacy experiences. The result is a more cohesive, intuitive, and efficient product experience across Azure Networking.

📣 If you have any thoughts or suggestions about the user interface, feel free to drop them in the feedback form available in the Network Security hub on the Azure Portal.

Documentation links:

Azure Networking hub page:
- Azure networking documentation | Microsoft Learn
Scenario Hub pages:
Scenario Overview pages