Application layer DDoS protection using the HTTP DDoS Ruleset in Azure WAF
Today, Distributed Denial of Service (DDoS) attacks can strike as soon as public connectivity is enabled, highlighting their widespread prevalence. Factors such as easily accessible botnets, the explosion of IoT devices, and the growth of API-driven workloads, e-commerce platforms, and global web applications have made these attacks easier to launch and more impactful. Importantly, attackers are no longer focusing solely on the network layer, they increasingly target the application layer. Application-layer DDoS attacks often mimic normal user activity, making detection and mitigation far more challenging than traditional network-layer attacks. The most common types of Application layer/HTTP based DDOS attacks are outlined below. Common HTTP-based DDoS attacks: HTTP floods: Large volumes of valid looking GET or POST requests are sent to webpages or APIs, overwhelming application gateways and backend services without saturating network bandwidth. API abuse attacks: Attackers repeatedly call specific API endpoints, such as authentication, search, or checkout that trigger expensive backend operations, quickly exhausting compute and database resources. Slow HTTP attacks: Connections are deliberately kept open by sending data very slowly, consuming server threads and connection limits while generating relatively little traffic. TLS-intensive attacks: A high number of encrypted connections are initiated to increase CPU usage during TLS handshakes, impacting application gateways and load balancers. In order to defend against these sophisticated threats, organizations need application-aware protection that can identify abnormal behavior patterns rather than relying only on traffic volume. This is precisely the capability provided by the HTTP DDoS Ruleset for Azure Application Gateway WAF. What Is the HTTP DDoS Ruleset? The HTTP DDoS Ruleset is a built-in capability of Azure Application Gateway WAF designed to protect your applications from large-scale HTTP floods at the application layer. Unlike static rate-limiting or manual IP blocking, this ruleset uses adaptive learning to understand what “normal” traffic looks like for your gateway and then automatically mitigates anomalies. Key features Baseline learning: The ruleset observes traffic for about 24 hours to establish a normal request pattern per gateway. Dynamic detection: When incoming requests exceed the learned baseline, the ruleset identifies potential abuse (Client-specific or IP specific limits are applied only when the overall request volume to the gateway exceeds its learned baseline). Automated mitigation: Offending clients are blocked and are placed in a “penalty box” for the defined time (15 minutes). Sensitivity levels: Choose low, medium, or high to control aggressiveness. Medium is recommended for most workloads. Leverages Microsoft’s vast global network’s threat intelligence to establish a stricter baseline for suspected botnet traffic and when exceeded, blocks them and places those suspected bots into the penalty box. Threat intelligence plays a critical role here. By continuously aggregating data from global telemetry, threat intelligence systems can identify sources that are likely participating in coordinated attacks. When applied to HTTP DDoS protection, this intelligence allows suspected bot traffic to be treated differently from normal user traffic. Instead of relying only on static blocklists, botnet-aware defenses use reputation, behavior, and historical signals to apply throttling or penalties dynamically. This approach reduces the attack surface, limits the impact of distributed bot-driven floods, and avoids unnecessary disruption to legitimate users. Threat intelligence shifts DDoS defense from a purely reactive posture to a more informed, proactive one, making it far more effective against today’s botnet-driven application-layer attacks. Enabling and validating the HTTP DDoS Ruleset: Getting started with the HTTP DDoS Ruleset on Application Gateway WAF is simple. Enable the Ruleset: In the Azure portal, open your WAF policy. Note: Currently the ruleset is available only in the preview portal: https://preview.portal.azure.com/ Under Managed Rules, Click on Assign and then assign the HTTP DDoS Ruleset_1.0 (Preview) and save. Each rule can be configured to either Log traffic for observation or Deny traffic for active mitigation. Sensitivity can be adjusted to High, Medium, or Low, allowing you to balance detection speed and accuracy. Higher sensitivity enforces lower thresholds and detects anomalies sooner, while lower sensitivity raises thresholds to reduce false positives. Medium sensitivity is the default and recommended setting for most workloads. Once enabled, the ruleset is evaluated early in the WAF pipeline, before custom rules are processed. This ensures that HTTP-based DDoS protection cannot be bypassed by DDoS protection. The ruleset works alongside the Default Rule Set (DRS) and any custom rules for comprehensive security. After the policy is applied to an Application Gateway, the ruleset enters a learning phase that lasts at least 24 hours. During this time, it observes traffic patterns to establish normal baselines for the gateway. No detection or blocking occurs during this period, allowing the ruleset to understand typical application behavior before enforcement begins. Metrics: Once the learning phase completes, traffic surges that exceed the learned baseline are reflected in the Application Gateway metrics. These metrics provide immediate visibility into when the HTTP DDoS ruleset is actively detecting and mitigating abnormal behavior. Metric – WAF Penalty Box Size This metric shows how many IP addresses are currently inside the penalty box, meaning that the WAF has detected them exceeding the learned HTTP DDoS baseline and is temporarily blocking them. A spike here indicates that multiple clients crossed their thresholds at the same time, often during an attack or load-test scenario. Metric – WAF Penalty Box Hits This metric represents how many IPs entered the penalty box. Every time a client breaches its threshold, the ruleset logs a hit and places that IP into the penalty box for approximately 15 minutes. Multiple hits often correlate with repeated spikes or sustained abusive traffic patterns. Logs: For deeper analysis, enabling diagnostic settings allows you to inspect HTTP DDoS Ruleset events directly in the logs. These logs provide granular details about which IPs were flagged, why they were flagged, and how far they exceeded expected thresholds. Example of DetailedData from a log: RemoteAddress: 4.x.x.x (Public IP) crossed threshold. Expected: 4400.000000 request per 900 seconds, Actual: 8407.000000 requests per 900 seconds. KQL queries to retrieve these logs: Resource specific logs: AGWFirewallLogs | where RuleSetType == "Microsoft_HTTPDDoSRuleSet" Diagnostic logs: AzureDiagnostics | where Category == "ApplicationGatewayFirewallLog" | where ruleSetType_s == "Microsoft_HTTPDDoSRuleSet" Note: Identify IPs repeatedly flagged and confirm they’re malicious, not legitimate clients. Conclusion: The threat landscape continues to evolve, and defenses must evolve with it. Leveraging the HTTP DDoS Ruleset in Azure Application Gateway WAF helps ensure protections keep pace with modern application-layer attacks. With built-in visibility through metrics and logs, teams can better understand traffic behavior and operate their WAF with greater confidence. Next Steps: Access the HTTP DDoS ruleset for Application Gateway via the preview portal: https://preview.portal.azure.com/ HTTP DDoS Ruleset (Preview) - Application Gateway WAF | Microsoft Learn Azure Web Application Firewall (WAF) policy overview | Microsoft LearnHow Azure network security can help you meet NIS2 compliance
With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance. If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations. Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts. What is NIS2? NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to: Expand the scope of covered entities essential and important entities Harmonize cybersecurity standards across member states Introduce stricter supervisory and enforcement measures Strengthen supply chain security and reporting obligations Key provisions include: Article 20 management responsibility and governance Article 21 cybersecurity risk management measures Article 23 incident notification obligations These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability. Where Azure network security fits The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes. NIS2 focus area Azure services and capabilities How this supports compliance Incident handling and detection Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable. Business continuity and resilience Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover Improve service availability and provide data for resilience reviews and disaster recovery scenarios. Access control and segmentation Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress. Vulnerability and misconfiguration defense Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs. Encryption and secure communications TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats. Incident reporting and evidence Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines. NIS2 articles in practice Article 21 cybersecurity risk management measures Azure network controls contribute to several required measures: Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance. Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation. Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions. Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones. Article 23 incident notification Build an evidence friendly workflow with Sentinel: Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory. Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF. Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative. Article 20 governance and accountability Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification. Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations. Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes. Network security baseline Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance. Topology and control plane Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs. Use Network Security Hub for at-scale management. Require Infrastructure as Code for all network security resources. Web application protection Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate. DDoS strategy Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement. Firewall policy Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments. Logging, retention, and access Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits. Restrict access with Azure RBAC and Customer Managed Keys where applicable. Automation and playbooks Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access. Conclusion Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture. Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence. References NIS2 primary source Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng Azure Firewall Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference Web Application Firewall WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit Azure DDoS Protection Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs Azure Bastion Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs Microsoft Sentinel Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/ Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Architecture & routing Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hubAzure DDoS Protection now supports QUIC protocol — Securing the future of HTTP/3 traffic
The internet’s transport layer is undergoing one of its most significant evolutions in decades. QUIC (Quick UDP Internet Connections) — the protocol underpinning HTTP/3 — is rapidly becoming the default for high performance, secure communication on the web. From YouTube streaming to WhatsApp messaging, QUIC is already powering billions of connections daily. Recognizing both its potential and its unique security challenges, Microsoft has now integrated full QUIC mitigation capabilities into Azure DDoS Protection. This protection is enabled by default — no configuration required — ensuring that customers adopting HTTP/3 can do so with confidence. What is QUIC and why it matters QUIC was originally developed by Google and standardized by the IETF in 2021 (RFC 9000). Unlike traditional HTTP/2 over TCP, QUIC runs over UDP port 443, combining transport and security layers into a single handshake. This allows a secure, encrypted connection to be established in just one round trip — or even zero round trips for repeat connections. Technical advantages of QUIC include: Integrated TLS 1.3 — Encryption is built into the protocol, eliminating the need for separate TLS negotiation. Multiplexed streams without head of line blocking — Independent streams mean packet loss in one stream doesn’t stall others. Connection migration — QUIC connections survive IP address changes, ideal for mobile devices switching between Wi-Fi and cellular. Faster recovery from loss — QUIC uses packet numbers instead of TCP sequence numbers, improving loss detection and retransmission. These features make QUIC ideal for latency sensitive workloads such as video streaming, online gaming, and real-time collaboration tools. The DDoS challenge for QUIC: While QUIC’s design improves performance and security, its reliance on UDP introduces a distinct threat profile that goes beyond traditional UDP floods. QUIC’s handshake, encryption model, and connection identifiers create attack surfaces unique to the protocol. Key QUIC‑specific DDoS vectors include: Initial Packet Floods with Fake Handshakes Attackers send large volumes of QUIC Initial packets containing incomplete or malformed TLS Client Hello messages. This forces the server to allocate cryptographic resources for each bogus attempt, consuming CPU and memory. Connection ID Exhaustion QUIC uses Connection IDs to maintain state across IP changes. Attackers can rapidly cycle through random Connection IDs to bypass per‑IP rate limits. This can overwhelm connection tracking tables. Version Negotiation Abuse Attackers send unsupported or random QUIC version numbers to trigger repeated version negotiation responses from the server. This consumes bandwidth and processing without establishing a valid session. Malformed Frame Injection QUIC frames (STREAM, ACK, CRYPTO, etc.) can be deliberately malformed to trigger parsing errors or excessive error handling. Unlike generic UDP payloads, these require QUIC‑aware inspection to detect. Amplification via Retry Packets QUIC Retry packets can be abused in reflection attacks if the server responds with larger payloads than the request. Attackers spoof victim IPs to direct amplified traffic toward them. Why this is different from generic UDP floods: Generic UDP attacks typically rely on raw packet volume or reflection from open services. QUIC attacks exploit protocol‑level behaviors — handshake processing, version negotiation, and Connection ID handling — that require stateful, QUIC‑aware mitigation. Traditional UDP filtering cannot distinguish between a legitimate QUIC Initial packet and a crafted one designed to exhaust resources. Azure DDoS Protection — QUIC mitigation [built-in]: Azure DDoS Protection now supports QUIC mitigation by default. This enhancement applies to all customers automatically — no opt-in or no manual tuning is required. Technical capabilities include: Protocol Compliance Validation — Ensures QUIC packets conform to RFC specifications, including fixed bit checks, version enforcement, and valid Connection ID lengths. Initial Packet Verification — Validates that QUIC initial packets contain a proper TLS Client Hello with Server Name Indication (SNI), blocking spoofed or incomplete handshakes. Source & Destination Rate Limiting — Controls excessive connection attempts per 4tuple (source IP, destination IP, source port, destination port). Global Limit IDs (GLID) — Applies connection and packet rate limits globally across the mitigation platform. Retry Authentication — Issues a cryptographic cookie challenge to verify client authenticity before allowing session establishment. Packet Rate Limiting by Connection ID — Limits both long header (initial) and short header (post handshake) packet rates to prevent floods. Malformed Packet Filtering — Drops packets with unsupported frames, invalid versions, or missing headers. Version Pinning — Prevents downgrade attacks by enforcing negotiated QUIC versions. All existing Layer 4 protections for UDP traffic — such as flood detection, anomaly scoring, and adaptive thresholds — are fully applied to QUIC. Real-world impact: Without effective mitigation, QUIC based services are highly susceptible to a range of disruptive threats. UDP floods can quickly overwhelm servers, consume resources and render applications unresponsive. Amplification attacks, which exploit the stateless nature of UDP, can multiply inbound traffic by factors of ten to a hundred, creating massive spikes that cripple performance. Such attacks often lead to high packet loss, degraded user experiences, and service interruptions. They can also drive-up infrastructure costs significantly, as organizations are forced to handle large volumes of malicious traffic that consume bandwidth and processing power. With Azure DDoS Protection in place, these risks are proactively addressed. Intelligent rate limiting and packet filtering mechanisms stop floods before they impact service availability. Spoofed packet blocking prevents reflection attacks from ever reaching the application layer. The result is a consistently reliable, low latency connection for QUIC enabled applications, even under hostile network conditions. By scrubbing malicious traffic before it reaches customer workloads, Azure also helps reduce operational costs, ensuring that resources are spent serving legitimate users rather than absorbing attack traffic. Who benefits from QUIC DDoS mitigation: The benefits of QUIC aware DDoS protection extend across industries and use cases. Web applications and APIs built on HTTP/3 gain the performance advantages of QUIC without inheriting its security risks. Streaming platforms such as YouTube or Twitch can deliver high quality, uninterrupted video experiences to millions of viewers, even during attempted network disruptions. Messaging and VoIP services like WhatsApp, Discord, and Zoom maintain crystal clear communication and low latency, which are critical for user satisfaction. Online gaming platforms, where milliseconds matter, can preserve smooth gameplay and prevent lag spikes caused by malicious traffic. Financial services and real-time transaction systems also stand to benefit, as they can maintain secure, uninterrupted operations in environments where downtime or delays could have significant business and compliance implications. Looking ahead: Microsoft is committed to continuously strengthening QUIC protection within Azure DDoS Protection. Efforts are already underway to expand mitigation capabilities ensuring broader coverage across the global network and to detect and neutralize threats faster and with greater precision, adapting to the evolving tactics of attackers. Just as importantly, Microsoft is actively gathering feedback from customers and internal teams to refine mitigation strategies, ensuring that QUIC protection remains both robust and aligned with real world usage patterns. These ongoing enhancements will help customers confidently adopt and scale QUIC based services, knowing that their performance and security are safeguarded by default. Conclusion: QUIC is the future of fast, secure internet communication — and Azure DDoS Protection is ready for it. With always-on, default-enabled QUIC mitigation, Azure customers can confidently adopt HTTP/3 without worrying about the unique DDoS risks that come with UDP based protocols. Your applications stay fast. Your users stay connected. Your infrastructure stays protected.Introducing the new Network Security Hub in Azure
Background: Since its launch in 2020, Azure Firewall Manager has supported customers in securing their networks. But the role of network security has since evolved, from a foundational requirement to a strategic priority for organizations. Today, organizations must protect every endpoint, server, and workload, as attackers continually search for the weakest link. Over the years, we’ve heard consistent feedback about the importance of centralized management, easier service discovery, and streamlined monitoring across their network security tools. These capabilities can make the difference between a minor incident and a major breach. That’s why we’re excited to introduce a new, unified Network Security hub experience. This updated hub brings together Azure Firewall, Web Application Firewall, and DDoS Protection—enabling you to manage, configure, and monitor all your network security services in one place. While Azure Firewall Manager offered some of this functionality, the name didn’t reflect the broader scope of protection and control that customers need. With this new experience, Firewall Manager has expanded into the Network Security Hub, making it easier to discover, configure, and monitor the right security services with just a few clicks. The result: less time navigating, more time securing your environment. What you’ll notice: Streamlined navigation: Whether you search for Azure Firewall, Web Application Firewall, DDoS Protection, or Firewall Manager, you’ll now be directed to the new Network Security hub. This unified entry point presents all relevant services in context—helping you stay focused and quickly find what you need, without feeling overwhelmed. Overview of services: The hub’s landing page provides a high-level view of each recommended solution, including key use cases, documentation links, and pricing details—so you can make informed decisions faster. Common scenarios: Explore typical deployment architectures and step-by-step guidance for getting started, right from the overview page. Related services: We’ve consolidated overlapping or closely related services to reduce noise and make your options clearer. The result? Fewer, more meaningful choices that are easier to evaluate and implement. New insights: We've enhanced the security coverage interface to show how many of your key resources are protected by Azure Firewall, DDoS Protection, and Web Application Firewall. Additionally, our integration with Azure Advisor now provides tailored recommendations to help you strengthen your security posture, reduce costs, and optimize Azure Firewall performance. What this means for you: No changes to Firewall Manager pricing or support: This is a user experience update only for Firewall Manager. You can continue to deploy Firewall policies and create Hub Virtual Network or Secured Virtual Hub deployments —now within the streamlined Network Security hub experience. Aligned marketing and documentation: We’ve updated our marketing pages and documentation to reflect this new experience, making it easier to find the right guidance and stay aligned with the latest best practices. Faster decision-making: With a clearer, more intuitive layout, it’s easier to discover the right service and act with confidence. Better product experience: This update brings greater cohesion to the Azure Networking portfolio, helping you get started quickly and unlock more value from day one Before: The original landing page was primarily focused on setting up Firewall Policies and Secured Virtual Hub, offering a limited view of Azure’s broader network security capabilities. After: The updated landing page delivers a more comprehensive and intuitive experience, with clear guidance on how to get started with each product—alongside common deployment scenarios to help you configure and operationalize your network security stack with ease. Before: The previous monitoring and security coverage experience was cluttered and difficult to navigate, making it harder to get a quick sense of your environment’s protection status. After: The updated Security Coverage view is cleaner and more intuitive. We've streamlined the layout and added Azure Advisor integration, so you can now quickly assess protection status across key services and receive actionable recommendations in one place. The expansion of Firewall Manager into the Network Security hub is part of a greater strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. You can learn more about this initiative in this blog. This shift is designed to better align with customer needs and industry best practices—by emphasizing core services, consolidating related offerings, and phasing out legacy experiences. The result is a more cohesive, intuitive, and efficient product experience across Azure Networking. 📣 If you have any thoughts or suggestions about the user interface, feel free to drop them in the feedback form available in the Network Security hub on the Azure Portal. Documentation links: Azure Networking hub page: Azure networking documentation | Microsoft Learn Scenario Hub pages: Azure load balancing and content delivery | Microsoft Learn Azure network foundation documentation | Microsoft Learn Azure hybrid connectivity documentation | Microsoft Learn Azure network security documentation | Microsoft Learn Scenario Overview pages What is load balancing and content delivery? | Microsoft Learn Azure Network Foundation Services Overview | Microsoft Learn What is hybrid connectivity? | Microsoft Learn What is Azure network security? | Microsoft LearnAutomating Enriched DDoS Alerts Using Logic Apps
In today’s digital world, Distributed Denial of Service (DDoS) attacks have become one of the most common and disruptive threats facing online applications and services. These attacks aim to overwhelm a target, typically a website, API, or server, by flooding it with massive volumes of traffic, rendering it slow or completely inaccessible. Azure DDoS Protection is Microsoft's cloud-native defense that helps safeguard public-facing endpoints hosted in Azure. It works by continuously monitoring traffic patterns at the network layer (L3 and L4) and applying mitigation techniques in real time when suspicious or anomalous activity is detected. Azure DDoS Protection is tightly integrated with the Azure platform and provides always-on traffic scrubbing without requiring any manual intervention. While Azure mitigates these attacks in the background, understanding who is attacking, which resources are targeted, and how often these events occur is helpful. This is where Azure Logic Apps shines. Azure Logic Apps is a powerful platform to simplify the integration and automation of multiple services that help you run your business workflows. You can run your custom code or use no code at all to get your workflows running. When combined with Log Analytics & KQL queries, Logic Apps can help you extract critical insights from DDoS logs, including: Attack starts and end times Affected public IPs Top attacking IPs, countries, and ASNs Volume of traffic and packets dropped Attack patterns and frequency Application availability The result of the process is an email alert with details about the resource associated with the Public IP as detailed above. The owner of the resource is added as a recipient of the email, along with the security team who get alerted when the Attack occurs. Whether you're a security engineer, a product owner, or part of a cloud operations team, this solution can help you improve visibility and enhance coordination during DDoS incidents. Let’s dive into how this automation works. Here is the link to this template. Note: This template is an updated version of the same template discussed in this Blog- Enriching DDoS Protection Alerts with Logic Apps What this template contains: Log Search Alert rule Action Group Logic App Office 365 API Connector Azure Monitor Logs API Connector Parameters to Input when deploying: Security team's Email Address Company Domain (In the form of abc@domain.com) Workspace name (Name of the Log Analytics workspace being used) Prerequisites: A Public IP Address with DDoS Protection enabled either via IP Protection or Network Protection A Log Analytics Workspace to which the above Public IP Address should be sending Diagnostic logs, specifically all of the below categories: DDoS protection notifications Flow logs of DDoS mitigation decisions Reports of DDoS mitigations Note: The Log Analytics Workspace must reside in the same Resource Group as the one where this template is being deployed. 🔐Authentication Prerequisites: Azure Resource Graph The Logic App uses a Managed Identity to authenticate with Azure Resource Graph and query metadata about Azure resources Required Role: Logic App's Managed Identity will need Reader or higher access on the subscription (or resource group) that contains the Public IP address under DDoS protection Log Analytics Workspace To run Kusto queries and retrieve DDoS mitigation logs, the Logic App connects to Azure Log Analytics Workspace using the same Managed Identity Required Role: Logic App's Managed Identity will need Log Analytics Reader on the target workspace Office 365 (Email Notifications) API Connection For sending enriched alert emails, the Logic App uses an API connection to Office 365. This connection must be authorized to send emails on behalf of the configured account, specifically Mail.Send & User.Read permissions You must sign in and authorize this connection once during setup using the outlook credentials that you need it to use to send the emails If your tenant has admin consent policies, a Global Admin might need to approve use of the connectors (especially Office 365) for the Logic App Azure Monitor Logs API Connection This script queries Flow logs of DDoS mitigation decisions & Reports of DDoS mitigations To do this it needs AzureMonitorLogs API Connection and therefore, authorizing this is necessary for it to work as expected You must sign in and authorize this connection once during setup Firewall & Network Rules Ensure that: No IP restrictions block access from Logic App to the target services or public test URL in the HTTP step. You can find the outgoing IP Addresses here: Go to your Logic App Select Properties Look for the "Runtime outgoing IP addresses" section—these are your runtime IPs Now, let’s look at what each of the items in the Template does and their workings below in detail: Log Search Alert rule Monitors log data: It continuously scans the Azure Diagnostics logs, specifically targeting entries where the Category is DDoSProtectionNotifications and the type_s field indicates a Mitigation started event Runs on a schedule: The rule runs every 5 minutes and looks back at the last 30 minutes of logs. This ensures near-real-time detection of mitigation activity. (This can be modified as needed to increase the look back time if needed) Triggers on first sign of mitigation: If even one matching log entry is found (i.e., one mitigation event has started), the alert fires. This makes it extremely responsive Alerts through an Action Group: Once triggered, the rule calls a pre-defined Action Group, which will Invoke a webhook to notify a Logic App Why It’s Useful: While Azure DDoS Protection automatically mitigates volumetric and protocol attacks at the network edge, getting alerted when an event occurs requires user configuration. This is done by: Notifying your team the moment mitigation begins Adding observability, so you can correlate mitigation with service behavior or performance dips Action Group: Enrich-DDoSAlert — Connecting detection to automation When a DDoS attack is detected through an Azure Monitor alert, the response needs to be fast and efficient. That’s where Action Groups come in. In this case, the Enrich-DDoSAlert action group acts as the automation trigger for our DDoS response pipeline This action group is configured to call a webhook tied to an Azure Logic App using a secure HTTP POST request instantly when the alert fires. Then the Logic App carries out a series of enrichment and response steps based on the DDoS alert Why This Matters: The action group acts as a real-time bridge between detection and automation, triggering the Logic App instantly when an alert fires. The Action Group ensures that: The alert is captured Automation is triggered The investigation process starts without delay Logic App: Enrich-DDoSAlert Step-by-Step Breakdown Triggered via HTTP request Accepts a payload containing alert metadata such as: o Target resource ID o DDoS alert details o Search links and interval data Extracts impacted public IP and performs enrichment Using Azure Resource Graph, it queries the target IP to determine: o Associated Azure resource (VM, App Gateway, etc.) o DNS name, tags, region, resource group, and owner (from tags) Connectivity Check (Optional Validation) It performs an HTTP GET request to the DNS/IP of the attacked resource — checking if it’s still up or responding Generates an HTML-formatted email Using all this context, it builds a clean, readable email body that includes: o Top source IPs o IP under attack o Resource name/type o DNS name o Region o Tag info (owner, environment, etc.) o Link to Log Analytics search results o Status of connectivity test (code, headers, body) Queries Azure Monitor logs again (This time allows it to build a thorough DDoS Post Mitigation Report) After a 50-minute delay, it runs a query on the DDoS mitigation logs to extract: o Top source IPs o Top countries, ASNs, and continents o Time of mitigation o Traffic overview Note: This Delay is required but can be changed subtly. During this time, the post mitigation reports will be accumulated so it can be sent as an email in the next steps. Without this delay the reports will not populate correctly. Send a second email, titled "Post Mitigation DDoS Report", containing the above data. Post Mitigation Report plays a vital role in strengthening your defense strategy. By reviewing patterns in traffic origin, volume, and behavior, teams can: o Identify recurring attack sources or suspicious geographies o Correlate DDoS activity with other system anomalies o Fine-tune firewall and WAF rules based on attacker fingerprints In short, this enriched reporting not only enhances visibility but also enables teams to proactively adapt their security posture and reduce the impact of future attacks. Who gets notified? Office 365 API connector Both emails are sent using an authenticated Office 365 connector, delivered to the security team and tagged owner (which will be inputted during deployment). The high-priority email ensures visibility, while the second report gives retrospective clarity. Why this is useful: Reduces manual effort: No more pivoting across multiple tools to gather context Speeds up response: Teams get instant details Bridges Alert to Action: Combines signal (alert) with enrichment (resource graph + logs) and delivery (email) Customizable: You can adjust queries, recipients, or even trigger conditions Azure Monitor Logs API Connector The Azure Monitor Logs API Connector allows Logic Apps to query data from Log Analytics using Kusto Query Language (KQL). In this solution, it's essential for extracting DDoS-specific insights—such as top attacking IPs, countries, ASNs, and traffic volume—from diagnostic logs. What It Does in This Template: Executes KQL queries against your Log Analytics Workspace Retrieves: Flow logs from DDoSMitigationFlowLogs Mitigation reports from DDoSMitigationReports Delivers summarized data such as: Top attacker IPs Source ASNs and countries Mitigation start/end time Traffic patterns Here are some examples of the Automated & Enriched DDoS E-Mails: Potential Attack, First Email, as soon as an attack event is identified: Post Mitigation Summary Email: Conclusion: This Logic App doesn’t just automate alerting—it empowers your team with actionable context. By stitching together signals from Azure Monitor and Resource Graph, and packaging them into enriched, structured emails, it transforms raw alerts into informed decisions. Whether you're triaging incidents or conducting post-attack analysis, this setup ensures you're not starting from scratch each time. As attacks grow more complex, automation like this isn’t just nice to have—it’s essential. Start simple, adapt to your needs, and let your defenses work smarter.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 LearnProtecting 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.Fortify 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.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 Azure
