Optimizing DDoS Protection Costs: Adding IPs to Existing DDoS Protection Plans
Azure DDoS Protection has been a key part of securing internet-facing applications in the cloud. The DDoS Network Protection SKU already provides robust capabilities for protecting resources at scale. However, in certain architectures, additional flexibility is beneficial. This allows organizations to align protection more closely with their security and cost management strategies. We're introducing a new enhancement “Add to existing DDoS Protection Plan” that provides more flexibility. This feature allows you to link individual Public IPs (configured with the IP Protection SKU) to a DDoS Network Protection plan. Once linked, the Public IP is no longer billed at the standalone IP Protection SKU rate of 199 USD/month. Instead, it is covered under the DDoS Network Protection plan billing. The DDoS Network Protection plan itself is priced at 2,944 USD/month and includes coverage for up to 100 Public IPs. If the number of linked IPs exceeds 100, each additional IP incurs an overage fee of 29,5 USD/month. This provides a more scalable and cost-effective way to manage DDoS protection across large environments. How to Link Public IPs to a DDoS Protection Plan Below is how you can configure this feature using the Azure Portal and PowerShell: In the Azure Portal Go to Public IP addresses in the Azure portal. Select the Public IP you want to protect. Under Protect IP Address, click Protect. Set Protection Type to IP. Enable Add to existing DDoS Protection Plan. Choose your existing DDoS Network Protection plan from the dropdown. Click Save. This links the Public IP to your network-level DDoS plan and eliminates the separate charge for the IP Protection SKU, avoiding duplicate billing. Using PowerShell # Get the DDoS protection plan $ddosPlan = Get-AzDdosProtectionPlan -Name "YourPlanName" -ResourceGroupName "YourPlanRG" # Get and update the Public IP $publicIp = Get-AzPublicIpAddress -Name "YourPublicIPName" -ResourceGroupName "YourIPRG" $publicIp.DdosSettings = @{ ProtectionMode = "Enabled" DdosProtectionPlan = @{ Id = $ddosPlan.Id } } Set-AzPublicIpAddress -PublicIpAddress $publicIp Use Case 1: Selective Protection Within a VNET In many environments, a single VNET may host multiple Public IPs across development, staging, and production workloads. Previously, enabling DDoS Network Protection at the VNET level would automatically include all Public IPs, potentially securing more resources than intended and increasing cost. With this new feature, you can: Assign the DDoS IP Protection SKU only to the Public IPs you want to protect Link them individually to a DDoS Network Protection plan Gain granular control and optimize costs without restructuring your network This is ideal for organizations that want to apply protection only where it's needed, such as critical production endpoints, while excluding development and test environments. Use Case 2: Enabling DDoS Protection on Azure Firewall in Virtual WAN Hubs While it has always been possible to enable DDoS IP Protection on Azure Firewalls deployed in Virtual WAN (VWAN) hubs using the IP Protection SKU, customers using the DDoS Network Protection SKU could not previously extend their existing plan to cover these firewall Public IPs. This meant they would incur additional costs for IP Protection even if they were already paying for Network Protection. With the Add to existing DDoS Protection Plan feature, this limitation is removed. Customers can now: Assign the DDoS IP Protection SKU to the Azure Firewall’s Public IP in a VWAN hub Link that Public IP to their existing DDoS Network Protection plan Once linked, the standalone IP Protection SKU charge is waived, allowing customers to consolidate billing under their Network Protection plan. This improves cost efficiency and enables unified protection across both VNET and non-VNET resources. Script to Link Public IPs to DDoS Protection Plan To streamline the process, here is a PowerShell script that enables the DDoS IP Protection SKU on selected Public IPs and links them to an existing DDoS Network Protection plan. Update the variables below with your environment details: # Variables $resourceGroupName = "YourResourceGroupName" $ddosProtectionPlanName = "YourDdosProtectionPlanName" $publicIpNames = @("PublicIP1", "PublicIP2", "PublicIP3") # Add your public IP names here # Get the DDoS protection plan $ddosProtectionPlan = Get-AzDdosProtectionPlan -ResourceGroupName $resourceGroupName -Name $ddosProtectionPlanName # Loop through each public IP and enable DDoS protection foreach ($publicIpName in $publicIpNames) { # Get the public IP address $publicIp = Get-AzPublicIpAddress -Name $publicIpName -ResourceGroupName $resourceGroupName # Check if the public IP is Standard SKU if ($publicIp.Sku.Name -ne "Standard") { Write-Output "Skipping ${publicIpName}: DDoS protection is only supported on Standard SKU public IPs." continue } # Enable DDoS protection and associate with the DDoS protection plan $publicIp.DdosSettings = @{ ProtectionMode = "Enabled" DdosProtectionPlan = @{ Id = $ddosProtectionPlan.Id } } # Update the public IP address Set-AzPublicIpAddress -PublicIpAddress $publicIp Write-Output "DDoS protection enabled for ${publicIpName} and associated with DDoS protection plan ${ddosProtectionPlanName}." This script is also available in our GitHub repository for easy access and more details on how to run it. Note: DDoS protection is supported only on Standard SKU Public IPs. The script checks and skips unsupported ones automatically. Conclusion The Add to existing DDoS Protection Plan feature gives Azure customers more control and flexibility in applying DDoS protection to their resources. Whether you are looking to protect specific workloads within a VNET or extend coverage to non-VNET resources like Azure Firewall in Virtual WAN, this capability helps you: Apply protection exactly where it is needed Avoid unnecessary billing Automate DDoS configuration at scale To learn more Azure DDoS Protection, visit the official Azure documentation Azure DDoS Protection Overview | Microsoft Learn
Protect against Next.js CVE-2025-29927 with Azure Web Application Firewall (WAF)
Next.js versions prior to 12.3.5, 13.5.9, 14.2.25 and 15.2.3 are vulnerable to bypass authorization checks within a Next.js application, according to a recently published CVE-2025-29927. It is strongly recommended to upgrade Next.js to a patched version – 12.3.5, 13.5.9, 14.2.25 or 15.2.3. For Next.js versions 11.x which currently have no patches available, or other applications based on Next.js which cannot be patched immediately - creating a custom rule in Azure WAF can help mitigate this vulnerability. The custom rule will block any request with the header 'x-middleware-subrequest' which is used as part of this attack. Note that this rule is not exploitation-specific rule, but rather a more general approach which would block legitimate sites using auth middleware. Create a custom rule to mitigate CVE-2025-29927 In Azure Portal, navigate to your Web Application Firewall, then select 'Settings' -> 'Custom Rules'. Click on 'Add Custom Rule' button. Give your custom rule a name, like 'CVE202529927', and set its priority from 1-100. In the Conditions, select Match Type = 'String', Match Variable = 'RequestHeaders', and 'Header Name' = 'x-middleware-subrequest'. Under 'Operation' select 'is', set 'Operator' to 'Regex' and the Match Values to '.*' Under 'Then' section, select 'Deny Traffic' to block any request containing this header. Click 'OK' to complete editing, then select 'Save' to apply the new rule. You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here.Comprehensive Guide to Monitoring Azure WAF Metrics and Logs
In today’s digital landscape, web applications are constantly under threat from various types of attacks such as SQL injection, cross-site scripting (XSS), and distributed denial-of-service (DDoS) attacks. Azure Web Application Firewall provides robust mechanisms to protect your applications and services against such threats. In this blog post, we’ll explore how to configure and monitor Azure WAF metrics and logs for both Application Gateway v2 WAF and Azure Front Door WAF and demonstrate how to fully utilize the available metrics/logs to monitor your web applications for potential threats. Understanding Azure WAF Metrics Azure WAF offers a variety of metrics that provide insights into potential threats targeting your resources. These metrics are accessible through Azure Monitor and can be used to set up alerts and automated responses. Key metrics include: Application Gateway v1 WAF Metrics: Web Application Firewall Blocked Requests Count: Count of total requests that have been blocked by the WAF engine. Web Application Firewall Blocked Requests Distribution: Total number of rules hit distribution for the blocked requests by Rule Group and Rule ID. Web Application Firewall Total Rule Distribution: Count of total matched requests distribution by Rule Group and Rule ID. Note: The Application Gateway v1 SKU (Standard and WAF) was deprecated on April 28, 2023 and will be retired on April 28, 2026. Customers on the v1 SKU are advised to migrate to the v2 SKU. For more details, please refer to - Migrate from V1 to V2 - Azure Application Gateway | Microsoft Learn Application Gateway v2 WAF Metrics: WAF Total Requests: Count of successful requests that the WAF engine has served. WAF Managed Rule Matches: Count of total managed rule matches. WAF Custom Rule Matches: Count of custom rule matches. WAF Bot Protection Matches: Count of total bot protection rule matches that have been blocked or logged from malicious IP addresses. WAF JS Challenge Request Count: Count of requests that match JavaScript challenge WAF rules. Azure Front Door WAF Metrics: Web Application Firewall Request Count: Tracks the number of requests that match WAF rules. Web Application Firewall JS Challenge Request Count: Tracks the number of requests that match JavaScript challenge WAF rules. Note: These metrics are not found in the WAF policy resource but in the Application Gateway or Azure Front Door resource themselves. Steps to Monitor WAF Metrics Navigate to Azure Monitor: Sign in to the Azure portal and go to Azure Monitor. Select Metrics: In the Azure Monitor menu, select “Metrics.” Choose Scope: Select the scope by choosing the subscription and the specific WAF resource you want to monitor. Add Metric: Click on “Add metric” and select the desired metric, such as “WAF Total Requests” or “Web Application Firewall Request Count.” Set Aggregation Type: Choose the aggregation type. Configuring Alerts Configuring alerts for Azure WAF metrics is crucial for proactive monitoring and quick response to potential threats. Here are detailed steps to set up alerts: Navigate to Azure Monitor: Sign in to the Azure portal and go to Azure Monitor. Select Metrics: In the Azure Monitor menu, select “Metrics.” Choose Scope: Select the scope by choosing the subscription and the specific WAF resource you want to monitor. Add Metric: Click on “Add metric” and select the desired metric, such as “WAF Total Requests” or “Web Application Firewall Request Count.” Set Aggregation Type: Choose the aggregation type (e.g., Sum, Average, Maximum). Configure Alert Rule: Click on “New alert rule.” Set the signal name (e.g., “WAF Request Count Alert”). Select the aggregation type (e.g., Maximum). Choose the operator (e.g., “Greater than or equal to”). Select the unit (e.g., Count). Set the threshold value based on the average traffic you see in the chart, choosing a value lower than the WAF threshold. Click “Next” and under the Actions tab, choose how you want to be notified (e.g., email, SMS, webhook). Click on “Review + create.” WAF Alert example and use case With the increasing threat of DDoS attacks, it's vital to have alerting systems in place that keep you informed about any unusual activities in your web environment. By setting targeted alerts, you can quickly identify and address potential threats. Here's a practical example to demonstrate this. Suppose you want to be alerted about potential DDoS attacks targeting your web environment. For this scenario, we have a custom rule named "RateLimitRequest." This rule is designed to limit the number of requests to 400 within a 5-minute window, grouping the traffic by client address. This helps in identifying and mitigating potential threats from specific IP addresses. To ensure you are promptly notified of any potential DDoS attacks without enabling alerts for all rules, you can create a targeted alert based on the metric "WAF Custom Rule Match." Here's how you can configure it: Select the Signal: Navigate to the Alert page and choose "WAF Custom Rule Match" as the signal. This metric tracks the matches for your custom WAF rules. Configure Dimensions: In the "Split by dimensions" section, select "Rule name" as the dimension name. This allows you to filter the alerts based on specific rules. Set the Operator and Value: Set the operator to "=" and enter "RateLimitRequest" as the dimension value. This ensures that the alert is triggered only for the specified custom rule. In this example, I’ve configured a notification to be sent only through email. However, you can also set up notifications via SMS, the Azure Mobile app, or voice calls. Besides receiving notifications from alerts, you can configure the system to trigger various actions such as an Automation runbook, Azure Function, or Logic App. This allows you to, for instance, automatically create a ticket for the SOC team immediately through the alert rule action. By configuring the alert in this manner, you will receive notifications whenever the rate limit rule is triggered beyond a certain threshold. This indicates that a few client IPs are being blocked due to rate limiting, which could be a sign of a potential DDoS attack. Being promptly alerted allows you to take necessary actions to protect your web environment from such threats. Configuring logging In addition to monitoring metrics, logging plays a crucial role in maintaining the security and performance of your web applications. While metrics provide a high-level overview of your application's health and potential threats, logs offer detailed insights into specific events and activities. By using both metrics and logs together, you can gain a comprehensive understanding of your application's behavior, quickly identify and respond to security incidents, and ensure optimal performance. Enabling Application Gateway WAF logs To configure logging for workspace analytics for Application Gateway WAF, follow these steps: Navigate to Azure Portal: Sign in to the Azure portal. Select Application Gateway Resource: Go to your Application Gateway resource. Diagnostic Settings: Under the 'Monitoring' section, select 'Diagnostic settings'. Add Diagnostic Setting: Click on 'Add diagnostic setting'. Configure Logs: Select the logs you want to collect, such as 'ApplicationGatewayAccessLog', 'ApplicationGatewayPerformanceLog', and 'ApplicationGatewayFirewallLog' and make sure to select the 'Application Gateway Firewall Log' category to get WAF logs. Destination: Choose the destination for the logs. You can send them to a Log Analytics workspace, an Event Hub, or a Storage Account. Save: Click 'Save' to apply the settings. Note: The Application Gateway supports both Azure diagnostics tables and resource-specific tables. Make sure to use the correct query. For example, if you send logs to an Azure diagnostics table and query “AGWFirewallLogs,” you will not get any results. Enabling Azure Front Door WAF logs To set up logging for workspace analytics for Azure Front Door WAF, follow these steps: Navigate to Azure Portal: Sign in to the Azure portal. Select AFD Resource: Go to your Azure Front Door resource. Diagnostic Settings: Under the 'Monitoring' section, select 'Diagnostic settings'. Add Diagnostic Setting: Click on 'Add diagnostic setting'. Configure Logs: Choose the logs you want to collect by selecting the categories: 'FrontDoor Access Log', 'FrontDoor Health Probe Log', and 'FrontDoor WebApplicationFirewall Log'. Ensure you select the 'FrontDoor WebApplicationFirewall Log' category to capture WAF logs. Destination: Choose the destination for the logs. You can send them to a Log Analytics workspace, an Event Hub, or a Storage Account. Save: Click 'Save' to apply the settings. Running KQL queries Kusto Query Language (KQL) is a powerful tool for querying and analyzing data in Azure Monitor logs. Logs can be accessed directly under the resource, such as Application Gateway or Front Door, by navigating to the Logs section. Alternatively, you can query the logs from your Log Analytics workspace. Below are some useful KQL queries for monitoring Azure WAF metrics, along with scenarios to help you understand their use cases. Identify Top IP Offenders To identify the top IP addresses that are being blocked by your Azure WAF, you can use the following query for Application Gateway WAF logs: AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | summarize count() by clientIp_s | top 10 by count_ Scenario: Suppose you notice an unusual spike in blocked requests on your Azure WAF. You want to identify the top IP addresses that are being blocked to understand if there is a targeted attack from specific IPs. This query will help you list the top offending IP addresses, allowing you to take further action, such as blocking these IPs at the firewall level. Azure Front Door WAF Query To monitor the top IP addresses being blocked by Azure Front Door WAF, use this query: AzureDiagnostics | where Category == "FrontDoorWebApplicationFirewallLog" | summarize count() by clientIP_s | top 10 by count_ Top Five Matched Rules To understand which WAF rules are being triggered the most, you can use the following query for Application Gateway WAF logs: AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | summarize count() by ruleId_s | top 5 by count_ Scenario: You want to identify potential focused attacks or false positives by understanding which WAF rules are being triggered the most. By running this query, you can see the top five rules with the highest number of matches. This information can help you fine-tune your WAF rules to reduce false positives or strengthen your defenses against specific attack vectors. Azure Front Door WAF Query To monitor the top rules being triggered by Azure Front Door WAF, use this query: AzureDiagnostics | where Category == "FrontDoorWebApplicationFirewallLog" | summarize count() by ruleName_s | top 5 by count_ Matched/Blocked Requests by URI To understand which parts of your web application are being targeted the most, use this query to identify the top URIs that are being matched or blocked by the Application Gateway WAF logs: AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | project TimeGenerated, clientIp_s, requestUri_s, ruleId_s, action_s, Message | summarize count() by requestUri_s | top 10 by count_ This query helps you pinpoint vulnerable areas of your application by identifying the top URIs that are being matched or blocked by the WAF. You can then take appropriate measures to secure these areas. Azure Front Door WAF Query To monitor the top URIs being matched or blocked by Azure Front Door WAF, use this query: AzureDiagnostics | where Category == "FrontDoorWebApplicationFirewallLog" | project TimeGenerated, clientIP_s, requestUri_s, ruleName_s, action_s, details_msg_s | summarize count() by requestUri_s | top 10 by count_ Best Practices for Monitoring WAF Metrics and Logs Enable Logging: Ensure that logging is enabled for all WAF resources. This includes enabling diagnostic logs and integrating them with Azure Monitor logs. Use Managed Rules: Utilize managed rules provided by Azure WAF to protect against common threats. Regularly update these rules to ensure they cover the latest vulnerabilities. Set Up Alerts: Configure alerts for critical metrics such as “WAF Managed Rule Matches” and “WAF Custom Rule Matches” to get notified of potential threats in real-time. Regularly Review Logs: Periodically review WAF logs to identify patterns and trends in the traffic. This helps in fine-tuning the WAF rules and improving the overall security posture. Implement Exclusions: Use exclusions to fine-tune rules and exclude any data that you want to be excluded from the logs. This helps in reducing false positives and focusing on actual threats. Monitor Traffic Thresholds: Compare your real traffic to the thresholds set by Azure WAF to determine if you are close to or far from them. Adjust the thresholds as needed to suit your environment and downstream architecture. Integrate with SIEM/SOAR: Utilize Azure Sentinel for creating Workbooks and automating responses to threats. This integration allows for enhanced monitoring and automated threat response, ensuring a more robust security posture. For more details, you can refer to https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Real-World Scenarios for WAF Metrics and Logs High Volume of Requests: If you notice a sudden spike in the “WAF Total Requests” metric, it could indicate a potential DDoS attack. Setting up alerts for this metric can help you respond quickly to mitigate the attack. To configure WAF for high volume of requests: Scaling: Ensure your Application Gateway is set to auto scale. For Application Gateway v2 SKU, set the maximum instance count to the maximum possible value of 125 to handle traffic surges. Rate Limiting: Implement rate limiting to control the number of requests from specific IP addresses or geographies. Frequent Rule Matches: A high number of matches for “WAF Managed Rule Matches” or “WAF Custom Rule Matches” could indicate that your application is being targeted by specific types of attacks. Reviewing the logs and adjusting the rules can help in blocking these attacks more effectively. To configure WAF for frequent rule matches: Custom Rules: Create custom rules to block or allow traffic based on specific criteria. For example, you can block all requests from a specific IP address range. Detection Mode: Set the WAF policy to detection mode to log requests that match custom rules without blocking them, allowing you to analyze the traffic patterns. Bot Protection: If the “WAF Bot Protection Matches” metric shows a high count, it could indicate that your application is being targeted by malicious bots. Implementing bot protection rules and monitoring this metric can help in blocking these bots and protecting your application. To configure WAF for bot protection: Bot Protection Rule Set: Enable the managed bot protection rule set in your WAF policy to block or log requests from known malicious IP addresses. JavaScript Challenge: Enable the JavaScript challenge action for bot rules. This helps in blocking bots and reducing false positives by challenging requests that match specific criteria. JavaScript Challenge: The “WAF JS Challenge Request Count” metric tracks the number of requests that match JavaScript challenge WAF rules. A high count could indicate that your application is being targeted by automated scripts. Monitoring this metric and adjusting the challenge rules can help in mitigating such attacks. Key Takeaways Azure Web Application Firewall offers robust protection mechanisms for web applications. By monitoring Azure WAF metrics, you can gain valuable insights into the security and performance of your web applications. Proactively monitoring and analyzing WAF logs using Kusto Query Language (KQL) helps identify and mitigate potential threats. This approach ensures your web applications remain secure and performant, providing a seamless experience for your users. Understanding and fine-tuning WAF policies and rules reduce false positives and focus on actual threats. Regularly reviewing WAF logs helps identify patterns and trends, improving your security strategies continuously. In conclusion, staying vigilant and proactive in your WAF protection strategy is essential for ensuring uninterrupted service delivery and safeguarding your web applications from potential threats. By fully utilizing the available metrics and logs, you can effectively monitor and protect your resources, providing a secure and reliable experience for your users. References Monitoring metrics for Azure Application Gateway Web Application Firewall metrics | Microsoft Learn Azure Monitor metrics for Application Gateway | Microsoft Learn Azure Web Application Firewall monitoring and logging | Microsoft Learn https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinelBuilding a POC for TLS inspection in Azure Firewall
Encrypted traffic can pose a security risk by hiding malicious traffic and illegal user activity. TLS inspection in Azure Firewall Premium provides the capability to decrypt, process the data, encrypt the data, and send it to its destination. Check out this blogpost and learn how to build a POC for TLS inspection in Azure Firewall Premium to provide visibility and protection against attacks in encrypted traffic.Getting Started with Azure Firewall REST API: A Step-by-Step Guide – Part I
This blog is written in collaboration with andrewmathu. The REST API is essential for managing resources in Azure, providing a structured way to perform create, read, update, and delete (CRUD) operations. By using HTTP methods such as GET, POST, PUT, and DELETE, the REST API makes it straightforward for administrators to interact with Azure resources. It supports various data formats, including JSON and XML, ensuring flexibility in data exchange. This capability is particularly useful for automating workflows, streamlining deployments, and integrating with continuous deployment and integration processes. Azure Firewall is a cloud-native, intelligent network firewall security service that provides top tier threat protection for your cloud workloads running in Azure. It is a fully stateful firewall-as-a-service with built-in high availability and unrestricted cloud scalability. The Azure Firewall REST API allows users to automate firewall configurations, retrieve policy details, and manage rules programmatically. This blog provides step-by-step guidance on interacting with the Azure Firewall REST API and serves as Part I of our series. In this part, we will focus on the prerequisites, initial setup, and specific tasks such as creating an Azure Firewall instance, creating a firewall policy, associating policies, updating threat intelligence settings, and defining network and application rules. Getting Started In this blog, we will use Bruno, a lightweight, offline and user-friendly API testing tool, to send REST API requests to Azure Resource Manager for managing Azure Firewall configurations. While other API testing tools such as Postman, PowerShell, Azure CLI, and Swagger can also be used to interact with Azure REST APIs, the fundamental principles remain the same, with only the interface differing. Before diving into the API requests, we will first cover the prerequisites and initial setup. Then, we will demonstrate how to use Bruno to perform essential Azure Firewall operations such as creating a firewall instance, configuring policies, associating policies, updating threat intelligence settings, and defining firewall rules Prerequisites: Link to download Bruno: Bruno API Client | Downloads. Bruno documentation: What is Bruno? – Bruno Docs Link to blog that covers how to prepare your identities: Azure REST APIs with Postman (2021) | Jon Gallant. Note: While this blog focuses on using Postman to send REST API commands, the steps can be adapted for other API testing tools, such as Bruno, which we are using in this blog. Using the steps outlined in the blog, we can configure a collection for Bruno with the variables defined as below: Bruno supports pre-request scripts for modifying requests, but unlike Postman, it lacks built-in request chaining for authentication. While it's possible to use fetch() to obtain an access token, Bruno does not ensure the request waits for the token before execution. Other tools such as PowerShell or Insomnia can automate token retrieval, but in our case, we manually fetch the token via a POST request and use it in the Authorization header for subsequent API calls. Since tokens expire after about 60 minutes, this process will need to be repeated periodically. The access token that we obtain from our POST request is used in the collection to authenticate API requests to Azure Resource Manager. It is included in the Authorization header of each request to ensure that the API calls have the necessary permissions to interact with Azure Firewall. Azure Firewall Configurations via REST API With our prerequisites complete, we now proceed with some Azure Firewall configurations through REST API: Creating a new Azure Firewall instance. Creating a new Azure Firewall policy. Associating an Azure Firewall policy to an Azure Firewall instance. Updating Azure Firewall Threat Intelligence mode. Creating Rule Collections for Network and Application Rules. Listing our created resources. Azure Firewall REST API offers a wide range of configuration and management capabilities beyond these tasks. The steps covered in this section represent just a subset of the available operations that can be performed programmatically, enabling automation and streamlined management of firewall resources. To get us started, we need to have a resource group, a virtual network and a public IP address for the firewall to be created. The resource group has been created with the help of API, as shown below: To create the Virtual Network and the Firewall public IP address, we have utilized the portal as shown below: Creating a new Azure Firewall instance: The following are the parameters required for Azure Firewall instance via REST API: By using the PUT command and request body, we can create a firewall instance as shown below: Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/azureFirewalls/{azureFirewallName}?api-version=2024-05-01 As we can confirm on the portal, that the firewall has now been created Creating a new Azure Firewall policy: The following are the parameters required for Azure Firewall Policy creation via REST API By using the PUT command and request body, we can create a firewall policy as shown below: HTTP Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/firewallPolicies/{firewallPolicyName}?api-version=2024-05-01 Associating an Azure Firewall policy to an Azure Firewall instance: To associate a Firewall Policy with an Azure Firewall instance, use the following parameters. HTTP Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/azureFirewalls/{{azureFirewallName}}?api-version=2024-05-01 As we can see below, the firewall policy has now been associated with the firewall AZFW-RestAPI Updating Azure Firewall Threat Intelligence Mode: Updating the threat intelligence mode for your Azure Firewall instance can be done similarly by using the parameters below Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/firewallPolicies/RestAPI-FirewallPolicy-Standard?api-version=2024-05-01 Creating Rule Collections for Network and Application Rules: To create rule collection groups for network and application rules, use the following parameters. By using the below Put Command we will be able to create Network and Application rule collection groups as shown below: Method URL PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/firewallPolicies/{firewallPolicyName}/ruleCollectionGroups/{ruleCollectionGroupName}? api-version=2024-05-01 Listing Created Resources: To list the resources you've created, you can use the following GET command. When sending a GET request, we no longer require the request body, only the URI parameters to pull the information for the resource we want. HTTP Method URL GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/firewallPolicies/{firewallPolicyName}/ruleCollectionGroups?api-version=2024-05-01 As we can see from the above screenshot, we are able to list the rule collections that we created using the GET command. Similarly, we can use the GET command to list or get details of any created resources using the respective URL. Conclusion: By utilizing the Azure REST API, you can efficiently create, update, and configure Azure Firewall and Firewall Policies, streamlining deployment and management processes. This guide has shown how to set up and manage firewall instances, create policies, rule collection groups, and view resources, ultimately automating and securing your cloud environment with Azure Firewall. References: Azure Firewalls - Create Or Update - REST API (Azure Firewall) | Microsoft Learn Firewall Policies - REST API (Azure Virtual Networks) | Microsoft Learn Getting Started with Azure WAF REST API for Application Gateway: A Step-by-Step Guide | Microsoft Community Hub Getting Started with Azure WAF REST API for Azure Front Door: A Step-by-Step Guide | Microsoft Community Hub Getting Started with Azure DDoS Protection REST API: A Step-by-Step Guide | Microsoft Community HubProtecting the Public IPs of Secured Virtual Hub Azure Firewalls against DDoS Attacks
As discussed previously in the blog post “Fortify Your Azure Firewall: Custom Public IP Configuration on Secured Virtual Hub Deployments”, in the current cloud-focused environment, the management of network security has become increasingly important. Azure Firewall has long been an effective solution for securing virtual networks and virtual hubs, but recent updates have further enhanced its capabilities. The ability to specify your own Azure public IP to be used by your Azure Firewall within an Azure Virtual WAN Secured Virtual Hub, rather than relying on Azure to automatically assign one is a great feature that provides enhanced control over your network's public-facing IPs, enabling alignment with organizational security policies and compliance standards. In this blog, we'll discuss enhancing your secured virtual hub Azure firewall security by configuring Azure DDoS IP Protection for a comprehensive solution. Recap of the key benefits of using specific Public IPs for your Secured Virtual Hub Azure Firewalls Full Control: Gain complete ownership and management over the lifecycle of your firewall's public IP address. This means you can assign, reassign, and retire IP addresses as needed, ensuring that your network infrastructure remains agile and responsive to changing demands. By having full control, you can also implement custom configurations and policies that align with your specific security and operational requirements. Enhanced Security: Strengthen your network's defenses by enabling Distributed Denial of Service (DDoS) mitigation. This advanced security feature helps protect your infrastructure from malicious attacks that aim to overwhelm your network with excessive traffic. By proactively identifying and neutralizing potential threats, DDoS mitigation ensures that your services remain available and secure, providing peace of mind and uninterrupted access for your users. IP Address Flexibility: Enjoy the flexibility of allocating public IP addresses from a predefined IP prefix pool. This allows you to efficiently manage your IP resources, ensuring that you have the right number of addresses available for your current and future needs. With this flexibility, you can easily scale your network, accommodate new devices, and optimize IP address usage, all while maintaining a streamlined and organized IP address management system. How-to enable Azure DDoS IP Protection In this section we’ll configure Azure DDoS Protection to prevent DDoS attacks against the deployment. This is a key benefit that comes with the ability to configure your own public IPs on the Azure Firewall with Secured Virtual Hub. Select any of the public IPs you have associated with the firewall, this should bring you to the Overview blade of that resource. From the Overview blade, select the Protect button under Get Started. This will be how we enable the protection level for the public IP today, since the SKU that can be used for the protection will be Azure DDoS IP Protection, not Azure DDoS Network Protection. Since the virtual network used for the Virtual Hub is a managed virtual network, we cannot use the DDoS Network Protection SKU. You do have the option to enable this level of protection via Azure PowerShell or Azure CLI. From this view, we can see the various ways to configure DDoS protection for a public IP in Azure. As mentioned before, public IPs associated with an Azure Firewall in Secured Virtual Hub must use IP protection. In case you already have a DDoS Protection Plan, you will have the option to link it to the DDoS IP SKU when enabling the IP protection. When a DDoS IP SKU is linked to a plan, you will only be charged by your DDoS Protection Plan, instead of being charged for both. Once DDoS IP Protection is enabled, you can check the following 3 metrics, under the public IP resource, to validate the threshold levels applied to the public IP. Inbound SYN packet to trigger DDoS mitigation Inbound UDP packets to trigger DDoS mitigation Inbound TCP packet to trigger DDoS mitigation This indicates that the Azure DDoS IP Protection is on and protecting the workload behind the public endpoint. Conclusion Configuring specific public IP addresses for your Azure Firewall within a secured virtual hub represents a major leap forward in network security management. This feature not only offers enhanced control over your firewall's public-facing IPs but also significantly bolsters your security posture by incorporating Azure DDoS IP Protection. By utilizing this capability, you can safeguard your firewall against potential DDoS attacks, ensuring a more resilient and secure environment for your applications and services.
