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.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-sentinelFortify Your Azure Firewall: Custom Public IP Configuration on Secured Virtual Hub Deployments
Written in collaboration with davidfrazee and gusmodena. In today's cloud-centric world, managing network security is more critical than ever. Azure Firewall has always been a robust solution for protecting your virtual networks, but recent updates have made it even more powerful. One of the latest enhancements allows you to configure which public IP addresses are used on your Azure Firewall in an Azure Virtual WAN Secured Virtual Hub, rather than having Azure automatically assign one for you. This new feature provides greater control over your network's public-facing IPs, enabling you to align them with your organization's security policies and compliance requirements. Moreover, this capability opens the door to leveraging Azure DDoS IP Protection. By selecting specific public IPs for your firewall, you can ensure that these addresses are shielded from distributed denial-of-service (DDoS) attacks, enhancing the overall security posture of your Azure environment. This integration not only fortifies your defenses but also simplifies the management of your network security infrastructure. In this blog, we will discuss our newly announced feature for Azure Firewall, detailing how to configure public IP addresses from your own subscription and highlighting the benefits of this enhancement. Key Benefits Full control – Own and manage the lifecycle of your firewall’s public IP. Enhanced security – Enable DDoS mitigation for better protection. IP address flexibility – Allocate public IPs from an IP prefix pool. How-To To get started with configuring public IP addresses on your Azure Firewall, you'll need to follow a few straightforward steps. This guide will walk you through the process, ensuring that you can take full advantage of this new feature. By the end of this section, you'll have a clear understanding of how to assign specific public IPs to your firewall, enhancing your control over network security and enabling the integration of Azure DDoS IP Protection. You’ve created an Azure Virtual WAN and now need to deploy secured virtual hubs. A great place to start with building out the environment in the Azure Portal will be in the Azure Firewall Manager. Here you’ll be able to have a centralized management portal to view your Azure Firewalls, firewall policies, Azure DDoS Protection plans, and more. Once you’re in Azure Firewall Manager, select Virtual Hubs to build a new secured virtual hub. Once you’ve configured the basic configurations for the secured virtual hub, you’ll have the option to start creating the Azure Firewall. You’ll notice a new option called Select source of public IP. Here we will select Customer provided (Preview) to define which public IPs will be used for the new secured virtual hub. You’ll have the option to choose a pre-created public IP or to create new from the firewall manager blade. With the secured virtual hub created, we can navigate back to Azure Firewall Manager and manage the new deployment from there. Under Virtual Hubs, select on the Firewall name to manage the public IP addresses. To add more public IPs to your Azure Firewall, you can either create new public IP resources or select from pre-created ones. This feature ensures that Azure won't just assign an IP for you; instead, you have the flexibility to choose or create the specific public IPs that align with your network requirements. This approach provides greater control and customization for your firewall's public-facing IP addresses. Now that we’ve added public IPs to the Azure Firewall, we can 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. Stay tuned for our next blog post where we’ll go through the steps needed to protect the Public IP associated to your secured virtual hub Azure Firewall. Conclusion The ability to configure specific public IP addresses for your Azure Firewall in a secured virtual hub marks a significant advancement in network security management. This feature not only grants you greater control over your firewall's public-facing IPs but also enhances your security posture by enabling the integration of Azure DDoS IP Protection. As we continue to navigate the complexities of cloud security, features like these empower organizations to tailor their security strategies to meet their unique needs and compliance requirements. Stay tuned for more updates and best practices on optimizing your Azure Firewall and protecting your network infrastructure.Enhancing Azure Firewall Management with Change Tracking
Azure Firewall's Change Tracking (Preview) feature is a powerful enhancement that provides administrators with insights into changes made to firewall configurations, particularly Rule Collection Groups. This feature leverages Azure Resource Graph (ARG) to enable efficient monitoring and analysis of changes, improving visibility, accountability, and troubleshooting capabilities. Key Benefits of Change Tracking Enhanced Visibility Monitor modifications to Rule Collection Groups, enabling administrators to track configuration changes in real time. Improved Accountability Identify when changes were made and what changed, addressing compliance and audit requirements. Efficient Troubleshooting Detect unintended changes quickly to resolve issues affecting security or performance. How Azure Resource Graph (ARG) Powers Change Tracking Azure Resource Graph is the backbone of the Change Tracking feature, providing an efficient query and analysis engine designed for large-scale Azure environments. ARG collects metadata and property changes from Azure resources, including Azure Firewall, and enables administrators to query and analyze this data. Key ARG Features for Change Tracking: Scalable Querying: ARG supports querying changes across multiple subscriptions, management groups, or even tenants, ensuring insights are accessible for large environments. Detailed Change Insights: Administrators can query historical data, revealing what property changed and when. Kusto Query Language (KQL): ARG queries use KQL, allowing for flexible filtering, grouping, and analysis. ARG’s recent support for Rule Collection Groups ensures precise tracking of firewall rule changes, such as: Addition or removal of rule collections. Updates to specific rules (e.g., IP ranges, protocols, actions). Reordering of rule collections affecting priority and execution. How to Use Change Tracking with ARG Administrators can use the Azure Resource Graph Explorer in the Azure Portal to execute custom queries. Here’s an example query to retrieve changes in Rule Collection Groups: networkresourcechanges | where properties contains "microsoft.network/firewallpolicies/rulecollectiongroups" | where properties contains "properties.rulecollections" For more readable logs, you can use the following enhanced query: networkresourcechanges | where properties contains "microsoft.network/firewallpolicies/rulecollectiongroups" | extend parsedProperties = parse_json(properties) | extend TargetResource = tostring(parsedProperties.targetResourceId), Timestamp = todatetime(parsedProperties.changeAttributes.timestamp), Changes = todynamic(parsedProperties.changes), ChangeType = tostring(parsedProperties.changeType), PreviousSnapshotId = tostring(parsedProperties.changeAttributes.previousResourceSnapshotId), NewSnapshotId = tostring(parsedProperties.changeAttributes.newResourceSnapshotId), CorrelationId = tostring(parsedProperties.changeAttributes.correlationId), ChangesCount = toint(parsedProperties.changeAttributes.changesCount), TenantId = tostring(tenantId), Location = tostring(location), SubscriptionId = tostring(subscriptionId), ResourceGroup = tostring(resourceGroup), FirewallPolicyName = extract('/firewallPolicies/([^/]+)/', 1, tostring(id)) | mv-expand ChangeKey = bag_keys(Changes) | extend ChangeDetails = todynamic(Changes[tostring(ChangeKey)]) | extend RuleCollectionName = extract('properties\\.ruleCollections\\["([^"]+)"\\]', 1, tostring(ChangeKey)) | where isnotempty(RuleCollectionName) | summarize Changes = make_list(pack("ChangeKey", ChangeKey, "PreviousValue", tostring(ChangeDetails.previousValue), "NewValue", tostring(ChangeDetails.newValue))) by Timestamp = format_datetime(Timestamp, 'yyyy-MM-dd HH:mm:ss'), TenantId, SubscriptionId, ResourceGroup, Location, TargetResource, FirewallPolicyName, RuleCollectionName, ChangeType, PreviousSnapshotId, NewSnapshotId, CorrelationId, ChangesCount | project Timestamp, TenantId, SubscriptionId, ResourceGroup, Location, TargetResource, FirewallPolicyName, RuleCollectionName, ChangeType, PreviousSnapshotId, NewSnapshotId, CorrelationId, ChangesCount, Changes This enhanced query filters changes related to Azure Firewall's Rule Collection Groups, parses and extracts key details like timestamps, change types, and rule collection names, and formats the output for readability. This provides a clear and detailed log of configuration changes, making it easier for administrators to monitor and analyze changes over time. Here is a screenshot showing an example of the output from this query: Real-World Use Cases Change Management Maintain a historical record of configuration changes for audits and compliance. Security Monitoring Detect unauthorized changes to firewall rules, ensuring configurations remain aligned with organizational security policies. Operational Efficiency Quickly identify and resolve issues caused by recent changes to Rule Collection Groups. Conclusion With Change Tracking (Preview), powered by Azure Resource Graph, Azure Firewall becomes a more robust tool for managing and securing your network environment. Administrators gain enhanced control and insight into firewall configurations, improving their ability to maintain compliance, troubleshoot issues, and enforce security policies effectively. Start exploring Change Tracking today using the Azure Resource Graph Explorer and enhance your network security posture.Building a DDoS Response Plan
In today's digital age, enterprises face significant threats from Distributed Denial of Service (DDoS) attacks, which target networks and applications to disrupt their availability and performance. Public IP addresses that are accessible via the internet are particularly susceptible to these attacks, which are classified into three main categories: Volumetric Attacks (saturating network links), Protocol Attacks (targeting server resources), and Resource Attacks (overwhelming application layers). Implementing effective mitigation strategies is crucial for maintaining network integrity. Azure DDoS Protection provides advanced, adaptive features designed for automatic protection against both Volumetric and Protocol Attacks. These features include traffic monitoring, real-time tuning, and detailed analytics. For Resource Attacks, pairing Azure DDoS Protection with Azure Web Application Firewall (WAF) ensures comprehensive Layer 7 (L7) protection. To thoroughly safeguard against DDoS attacks, it is essential to establish a comprehensive DDoS response plan. This blog will explore the development of a robust DDoS response plan by leveraging the capabilities offered by Azure DDoS Protection. Building a Robust DDoS Response Plan: Creating a thorough DDoS response plan is critical for protecting your online services and ensuring they remain accessible. The following steps are fundamental to developing a robust DDoS response strategy. Incident Detection: Utilize advanced monitoring tools and establish baseline traffic patterns to quickly identify abnormal activity indicative of a DDoS attack. Communication Protocols: Inform all relevant stakeholders through predefined channels and clarify roles and responsibilities to avoid confusion during the crisis. Mitigation and Recovery: Implement countermeasures such as traffic filtering, rate limiting, and leveraging cloud-based DDoS protection services to ensure service availability for legitimate users. Post-Incident Steps: Assess the attack's impact, identify vulnerabilities, and enhance the response plan through a thorough post-mortem analysis to fortify defences against future attacks. By following these four steps, you can build a solid DDoS response plan that minimizes disruption and enhances your organization's resilience. Let’s explore these four steps using Azure DDoS Protection in detail. Incident Detection Identifying the signs of a DDoS attack is essential. This includes monitoring network traffic, reviewing logs, and analysing alerts. Key indicators to monitor for potential attacks are unusual traffic patterns, spikes in network traffic, service degradation, latency metrics, CPU, memory, and bandwidth usage. Azure DDoS protection metrics can be utilized for this purpose. DDoS Protection Metrics: Azure DDoS Protection Metrics can be accessed through the Azure Portal: Go to Azure Portal > Monitor > Metrics. In the Metrics scope pane: Select the resource group. Select a resource type of Public IP Address. Select your Azure public IP address. Choose from various DDoS metrics in the “Available metrics” pane. Alerts: Alerts can be configured for any of the available DDoS Protection metrics. When conditions are met, the specified email address receives an alert. Works for any of the available DDoS Protection metrics. Alerts when there’s an active mitigation during an attack (using Azure Monitor alert configuration). When the conditions are met, the specified email address receives an alert email. Impact to the Applications: We can also evaluate the health of our application using the metrics furnished by the Application Gateway. These metrics offer detailed insights during the attack time, including but not limited to the metrics listed below: Failed Requests – Count of Failed Requests that the App Gateway has served. Throughput – Number of Bytes per second the App Gateway has served. Backend First Byte Response Time – Approximating Processing time of backend server. Logging: Along with metrics, Azure DDoS Protection offers solid logging capabilities. For example, AzureDiagnostics | where Category == “DDoSProtectionNotifications”: This log category furnishes details about the initiation and cessation of DDoS mitigation. These logs serve as a basis for configuring alerts to notify the Security Operations Center (SOC) Analyst as necessary. The integration of Azure DDoS Protection with Microsoft Defender for Cloud (MDC) provides recommendations for unprotected public IP addresses and consolidates alerts into a unified dashboard, while also offering regulatory compliance guidance based on established standards. Additionally, the integration of Azure DDoS Protection with Microsoft Sentinel facilitates the ingestion of DDoS logs into Sentinel, where prebuilt queries can generate incidents and alerts. Automated remediation options are available as specified here. For comprehensive guidance on researching a DDoS attack, please refer to this blog: Azure DDoS Protection – SecOps Deep Dive Communication Effective communication is crucial during a DDoS attack. It is essential to establish a robust communication strategy to prevent panic-induced miscommunication or the failure to relay information through appropriate channels. The following image illustrates the critical components of a solid communication plan Azure DDoS Rapid Response: Azure DDoS Protection's Rapid Response Support team aids with attack investigations during incidents and post-attack analysis. Engage the DRR team if your protected resource's performance is significantly degraded or unavailable during an attack, if you suspect a DDoS attack but the DDoS Protection service isn't effectively mitigating it, if you're planning an event that will drastically increase network traffic, or if the attack has a critical business impact. You can contact the DRR team during an active attack via Help + Support in the Azure Portal using the below steps. Create a new support request and choose “Issue Type” as Technical. Choose the “Service” as DDOS Protection. Select a DDoS Plan that is being protected by DDoS Network Protection in the “Resource” dropdown. Select "Under attack" in the “Problem Type” dropdown. On the “Details” page, select the severity as A-Critical Impact. Complete additional technical details and submit the support request. Azure DDoS Rapid Response: https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-rapid-response Mitigation and Recovery Mitigation and recovery efforts encompass the implementation of countermeasures to absorb or redirect malicious traffic, thereby ensuring uninterrupted access for legitimate users to services. Mitigation: Below are key mitigation techniques provided by Azure DDoS Protection Azure DDoS Protection Adaptive Tuning No user configuration required. Continuously profiles normal Public IP traffic. Utilizes machine learning algorithms to set mitigation thresholds. Azure DDoS Protection Thresholds: Azure DDoS Protection applies three auto-tuned mitigation policies (TCP SYN, TCP, and UDP) for each public IP of the protected resource. Thresholds are auto-configured via machine learning-based network traffic profiling. DDoS mitigation occurs for an IP address under attack only when the policy threshold is exceeded. Recovery: To ensure an effective recovery from a Distributed Denial-of-Service (DDoS) attack, the following critical steps must be meticulously executed: Isolate Affected Resources: It is imperative to identify and isolate the compromised resources promptly. This isolation helps in containing the attack and prevents further damage to the network and associated systems. Business Continuity Plans: Disaster Recovery: Develop comprehensive disaster recovery protocols to restore normal operations swiftly. This includes predefined strategies to address the attack's impact and ensure a seamless transition back to standard operations. Backups: Regularly maintain secure and up-to-date backups of critical data and systems. These backups should be readily accessible to facilitate rapid restoration in case of data loss or corruption caused by the attack. Failover Mechanisms: Establish efficient failover mechanisms to shift critical services and applications to alternative servers or locations. This redundancy ensures minimal downtime and continuous service availability during recovery efforts. Patching Vulnerabilities: Conduct a thorough assessment to identify and remediate any vulnerabilities that the attack may have exploited. Implementing patches and updates promptly is essential to fortify the system against future incidents and enhance overall security posture. Post Incident Steps: After an attack, conducting a post-attack investigation and analysis, implementing best practices, and performing simulation testing is important. DDoS Protection Workbook: Utilizing the Azure DDoS Protection Workbook is highly recommended to triage and understand the DDoS Threat landscape. Best Practices: Here are some of the best practices to follow Design for Security Prioritize security throughout the application lifecycle. Understand your architecture and focus on software quality. Prepare for direct application-level attacks. Design for Scalability Use horizontal scalability to handle increased load. Avoid single points of failure. Provision multiple instances for resilience. Defense in Depth Implement multi-layered security. Reduce attack surface using approval lists and NSGs. DDoS Attack Simulation: Test your assumptions about how your services will respond to an attack by generating traffic against your applications to simulate DDoS attack. Don’t wait for an actual attack to happen! Approved Simulation Partners include Breaking Point Cloud, Red Button, Red Wolf and MazeBolt Conclusion: DDoS attacks are a serious threat, and having an effective response plan is critical. Utilize effective communication, safeguards, and best practices, and ensure regular testing and updates to stay protected. References: Azure DDoS Protection Overview | Microsoft Learn Microsoft DDoS protection response guide | Blog Azure | Microsoft AzureUnderstanding the Evolving Threat of DDoS Attacks in 2024
You can access the full report here Microsoft Digital Defense Report 2024 The Rise of Network and Application Layer Attacks Beginning in mid-March 2024, there was a noticeable rise in network DDoS attacks, peaking at approximately 4,500 attacks per day by June. These attacks primarily targeted medium-sized applications, with a significant shift towards application layer attacks. Unlike traditional network-level attacks, application layer attacks are more stealthy, sophisticated, and difficult to mitigate. These attacks, which range from 100,000 to 1 million packets-per-second, are aimed directly at specific web applications, revealing the relentless nature of attackers trying to evade volumetric DDoS protection tactics. Without adequate protection, these applications would experience significant availability issues. The increased focus of DDoS attacks on the application layer rather than the more traditional network layers has created a greater risk of impact on business availability. This shift has affected critical services such as online banking and airline check-ins, highlighting the need for robust application layer protection The Emergence of Application Loop Attacks A new type of cyberattack, known as the "loop attack," is targeting the protocols that are essential for internet communication. This vulnerability affects application-layer protocols that rely on the User Datagram Protocol (UDP), such as TFTP, DNS, and NTP, as well as legacy protocols like Echo, Chargen, and QOTD. The loop attack triggers an endless loop of error messages between servers, leading to severe degradation of service and network quality. Unlike traditional UDP-based floods, loop attacks do not amplify traffic volume with each spoofed packet but can still cause significant disruption by trapping multiple servers in a never-ending communication loop. This attack highlights the vulnerabilities within our network protocols and underscores the need for continuous vigilance and robust security measures to protect against such sophisticated threats. Mitigation Efforts and Actionable Insights To combat the increasing threat of DDoS attacks, it is crucial to minimize the exposure of your applications over the public internet. This reduces the attack surface area and helps protect against potential threats. For applications that must be exposed, adopting a defense-in-depth strategy is essential. Ensure that network layer DDoS protection is in place to protect these applications. Specifically for web applications, deploying a web application firewall is vital to provide comprehensive application layer protection. Integrating DDoS simulations into the software development lifecycle and making them a regular part of security operations is also recommended. This ensures that applications and workloads have the appropriate level of protection and can scale effectively to handle potential attacks. The Impact of DDoS Attacks in India In 2024, India continued to be heavily impacted by DDoS attacks, particularly in the gaming sector. The number of DDoS attacks per customer in India has more than doubled since 2020, with mid-size throughput attacks reaching around 1,000 attacks per day on the gaming sector alone. This accounted for approximately 20% of all attacks in the APAC region during that period. The finance, technology, and government sectors were also major targets. The attack volume per customer increased from 1.4 Gbps to 2.4 Gbps. Layer 4 (L4) attacks were the most prevalent type of DDoS attack in the APAC region and globally. DNS query floods were the most common type of application-level DDoS attacks in India. Hacktivists, who use cyberattacks to express their political, social, or ideological views, were a major source of these attacks. There was a notable spike in DDoS activity in June 2024, coinciding with India's national elections. To mitigate these threats, it is essential to implement robust DDoS protection solutions, secure the network and application infrastructure, harden the DNS infrastructure, and prepare an incident response plan. Here are some actionable insights: Implement a DDoS Protection Solution: Secure the network and application infrastructure, harden the DNS infrastructure, and prepare an incident response plan. Security Measures: Implement security measures such as firewalls, load balancers, and routers to secure the network and application infrastructure. DNS Hardening: Implement security measures such as DNSSEC and DNS filtering to harden the DNS infrastructure. By following these actionable insights, organizations can better protect themselves against the increasing threat of DDoS attacks and ensure the availability and security of their critical services. Leveraging Azure DDoS Protection To effectively combat DDoS attacks, customers can leverage Azure DDoS Protection. This service provides comprehensive protection against DDoS attacks by continuously monitoring traffic and automatically mitigating threats. Azure DDoS Protection integrates seamlessly with Azure services, offering enhanced security for your applications and ensuring business continuity even during an attack. Azure DDoS Protection provides several key features: Always-on Monitoring: Monitors traffic 24/7 and automatically mitigates attacks once detected. Adaptive Tuning: Learns your application's traffic patterns and adjusts profiles in real-time. Attack Analytics: Provides detailed reports during and after attacks, with logs for real-time monitoring. Attack Alerts: Configurable alerts for attack start, stop, and duration, integrating with operational software. Rapid Response: Access to the DDoS Rapid Response team for attack investigation and post-attack analysis. Platform Integration: Integrated into Azure with easy configuration through the Azure portal. Turnkey Protection: Simplified setup that protects all resources on a virtual network immediately. Multi-Layered Defense: Works with Azure WAF to protect both network (Layer 3 and 4) and application layers (Layer 7). It is important to note that Azure DDoS Protection primarily provides protection against layer 3 and 4 DDoS attacks. To achieve comprehensive application layer protection, customers can supplement Azure DDoS Protection with Azure Web Application Firewall (WAF). Azure WAF offers robust security features to protect web applications from common threats and vulnerabilities at the application layer. By utilizing Azure DDoS Protection and Azure WAF, organizations can protect their digital assets and maintain high availability of their services. For more detailed insights and to learn how to implement Azure DDoS Protection, visit Azure DDoS Protection Overview | Microsoft Learn Conclusion The Microsoft 2024 Security Report underscores the evolving nature of DDoS attacks and the need for continuous vigilance and robust security measures. As attackers become more sophisticated, it is essential for organizations to stay ahead of the curve by implementing comprehensive DDoS protection strategies and regularly testing their defenses through simulations and security operations. For more detailed insights, you can access the full Microsoft 2024 Security Report Microsoft Digital Defense Report 2024Azure WAF’s Bot Manager 1.1 and JavaScript Challenge: Navigating the Bot Threat Terrain
Discover how Azure WAF’s Bot Manager 1.1 and the JavaScript Challenge elevate your bot protection strategy. In this blog, we explore how these advanced features in Azure Front Door and Application Gateway provide a robust defense against malicious bots while ensuring legitimate traffic flows smoothly. Learn how to fine-tune your web application’s security to safeguard against evolving bot threats without compromising on performance.
