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 LearnAzure Networking Portfolio Consolidation
Overview Over the past decade, Azure Networking has expanded rapidly, bringing incredible tools and capabilities to help customers build, connect, and secure their cloud infrastructure. But we've also heard strong feedback: with over 40 different products, it hasn't always been easy to navigate and find the right solution. The complexity often led to confusion, slower onboarding, and missed capabilities. That's why we're excited to introduce a more focused, streamlined, and intuitive experience across Azure.com, the Azure portal, and our documentation pivoting around four core networking scenarios: Network foundations: Network foundations provide the core connectivity for your resources, using Virtual Network, Private Link, and DNS to build the foundation for your Azure network. Try it with this link: Network foundations Hybrid connectivity: Hybrid connectivity securely connects on-premises, private, and public cloud environments, enabling seamless integration, global availability, and end-to-end visibility, presenting major opportunities as organizations advance their cloud transformation. Try it with this link: Hybrid connectivity Load balancing and content delivery: Load balancing and content delivery helps you choose the right option to ensure your applications are fast, reliable, and tailored to your business needs. Try it with this link: Load balancing and content delivery Network security: Securing your environment is just as essential as building and connecting it. The Network Security hub brings together Azure Firewall, DDoS Protection, and Web Application Firewall (WAF) to provide a centralized, unified approach to cloud protection. With unified controls, it helps you manage security more efficiently and strengthen your security posture. Try it with this link: Network security This new structure makes it easier to discover the right networking services and get started with just a few clicks so you can focus more on building, and less on searching. What you’ll notice: Clearer starting points: Azure Networking is now organized around four core scenarios and twelve essential services, reflecting the most common customer needs. Additional services are presented within the context of these scenarios, helping you stay focused and find the right solution without feeling overwhelmed. Simplified choices: We’ve merged overlapping or closely related services to reduce redundancy. That means fewer, more meaningful options that are easier to evaluate and act on. Sunsetting outdated services: To reduce clutter and improve clarity, we’re sunsetting underused offerings such as white-label CDN services and China CDN. These capabilities have been rolled into newer, more robust services, so you can focus on what’s current and supported. What this means for you Faster decision-making: With clearer guidance and fewer overlapping products, it's easier to discover what you need and move forward confidently. More productive sales conversations: With this simplified approach, you’ll get more focused recommendations and less confusion among sellers. Better product experience: This update makes the Azure Networking portfolio more cohesive and consistent, helping you get started quickly, stay aligned with best practices, and unlock more value from day one. The portfolio consolidation initiative is a strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. By focusing on top-line services, combining related products, and retiring outdated offerings, Azure Networking aims to provide a more cohesive and efficient product experience. Azure.com Before: Our original Solution page on Azure.com was disorganized and static, displaying a small portion of services in no discernable order. After: The revised solution page is now dynamic, allowing customers to click deeper into each networking and network security category, displaying the top line services, simplifying the customer experience. Azure Portal Before: With over 40 networking services available, we know it can feel overwhelming to figure out what’s right for you and where to get started. After: To make it easier, we've introduced four streamlined networking hubs each built around a specific scenario to help you quickly identify the services that match your needs. Each offers an overview to set the stage, key services to help you get started, guidance to support decision-making, and a streamlined left-hand navigation for easy access to all services and features. Documentation For documentation, we looked at our current assets as well as created new assets that aligned with the changes in the portal experience. Like Azure.com, we found the old experiences were disorganized and not well aligned. We updated our assets to focus on our top-line networking services, and to call out the pillars. Our belief is these changes will allow our customers to more easily find the relevant and important information they need for their Azure infrastructure. Azure Network Hub Before the updates, we had a hub page organized around different categories and not well laid out. In the updated hub page, we provided relevant links for top-line services within all of the Azure networking scenarios, as well as a section linking to each scenario's hub page. Scenario Hub pages We added scenario hub pages for each of the scenarios. This provides our customers with a central hub for information about the top-line services for each scenario and how to get started. Also, we included common scenarios and use cases for each scenario, along with references for deeper learning across the Azure Architecture Center, Well Architected Framework, and Cloud Adoption Framework libraries. Scenario Overview articles We created new overview articles for each scenario. These articles were designed to provide customers with an introduction to the services included in each scenario, guidance on choosing the right solutions, and an introduction to the new portal experience. Here's the Load balancing and content delivery overview: 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 Lea Improving user experience is a journey and in coming months we plan to do more on this. Watch out for more blogs over the next few months for further improvements.AZ-500: Microsoft Azure Security Technologies Study Guide
The AZ-500 certification provides professionals with the skills and knowledge needed to secure Azure infrastructure, services, and data. The exam covers identity and access management, data protection, platform security, and governance in Azure. Learners can prepare for the exam with Microsoft's self-paced curriculum, instructor-led course, and documentation. The certification measures the learner’s knowledge of managing, monitoring, and implementing security for resources in Azure, multi-cloud, and hybrid environments. Azure Firewall, Key Vault, and Azure Active Directory are some of the topics covered in the exam.
Automating 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.Accelerate designing, troubleshooting & securing your network with Gen-AI powered tools, now GA.
We are thrilled to announce the general availability of Azure Networking skills in Copilot, an extension of Copilot in Azure and Security Copilot designed to enhance cloud networking experience. Azure Networking Copilot is set to transform how organizations design, operate, and optimize their Azure Network by providing contextualized responses tailored to networking-specific scenarios and using your network topology.
Unmasking DDoS Attacks (Part 1/3)
In today’s always-online world, we take uninterrupted access to websites, apps, and digital services for granted. But lurking in the background is a cyber threat that can grind everything to a halt in an instant: DDoS attacks. These attacks don’t sneak in to steal data or plant malware—they’re all about chaos and disruption, flooding servers with so much traffic that they crash, slow down, or completely shut off. Over the years, DDoS attacks have evolved from annoying nuisances to full-blown cyber weapons, capable of hitting massive scales—some even reaching terabit-level traffic. Companies have lost millions of dollars due to downtime, and even governments and critical infrastructure have been targeted. Whether you’re a CTO, a business owner, a security pro, or just someone who loves tech, understanding these attacks is key to stopping them before they cause real damage. That’s where this blog series comes in. We’ll be breaking down everything you need to know about DDoS attacks—how they work, real-world examples, the latest prevention strategies, and even how you can leverage Azure services to detect and defend against them. This will be a three-part series, covering: 🔹Unmasking DDoS Attacks (Part 1): Understanding the Fundamentals and the Attacker’s Playbook What exactly is a DDoS attack, and how does an attacker plan and execute one? In this post, we’ll cover the fundamentals of DDoS attacks, explore the attacker’s perspective, and break down how an attack is crafted and launched. We’ll also discuss the different categories of DDoS attacks and how attackers choose which strategy to use. 🔹 Unmasking DDoS Attacks (Part 2): Analyzing Known Attack Patterns & Lessons from History DDoS attacks come in many forms, but what are the most common and dangerous attack patterns? In this deep dive, we’ll explore real-world DDoS attack patterns, categorize them based on their impact, and analyze some of the largest and most disruptive DDoS attacks in history. By learning from past attacks, we can better understand how DDoS threats evolve and what security teams can do to prepare. 🔹 Unmasking DDoS Attacks (Part 3): Detection, Mitigation, and the Future of DDoS Defense How do you detect a DDoS attack before it causes damage, and what are the best strategies to mitigate one? In this final post, we’ll explore detection techniques, proactive defense strategies, and real-time mitigation approaches. We’ll also discuss future trends in DDoS attacks and evolving defense mechanisms, ensuring that businesses stay ahead of the ever-changing threat landscape. So, without further ado, let’s jump right into Part 1 and start unraveling the world of DDoS attacks. What is a DDoS Attack? A Denial-of-Service (DoS) attack is like an internet traffic jam, but on purpose. It’s when attackers flood a website or online service with so much junk traffic that it slows down, crashes, or becomes completely unreachable for real users. Back in the early days of the internet, pulling off a DoS attack was relatively simple. Servers were smaller, and a single computer (or maybe a handful) could send enough malicious requests to take down a website. But as technology advanced and cloud computing took over, that approach stopped being effective. Today’s online services run on massive, distributed cloud networks, making them way more resilient. So, what did attackers do? They leveled up. Instead of relying on just one machine, they started using hundreds, thousands, or even millions—all spread out across the internet. These attacks became "distributed", with waves of traffic coming from multiple sources at once. And that’s how DDoS (Distributed Denial-of-Service) attacks were born. Instead of a single attacker, imagine a botnet—an army of compromised devices (anything from hacked computers to unsecured IoT gadgets)—all working together to flood a target with traffic. The result? Even the most powerful servers can struggle to stay online. In short, a DDoS attack is just a bigger, badder version of a DoS attack, built for the modern internet. And with cloud computing making things harder to take down, attackers have only gotten more creative in their methods. An Evolving Threat Landscape As recently reported by Microsoft: “DDoS attacks are happening more frequently and on a larger scale than ever before. In fact, the world has seen almost a 300 percent increase in these types of attacks year over year, and it’s only expected to get worse [link]". Orchestrating large-scale DDoS botnets attacks are inexpensive for attackers and are often powered by leveraging compromised devices (i.e., security cameras, home routers, cable modems, IoT devices, etc.). Within the last 6 months alone, our competitors have reported the following: June 2023: Waves of L7 attacks on various Microsoft properties March 2023: Akamai – 900 Gbps DDoS Attack Feb 2023: Cloudflare mitigates record-breaking 71 million request-per-second DDoS attack August 2022: How Google Cloud blocked the largest Layer 7 DDoS attack at 46 million rps Graphs below are F5 labs report. Figure 1 Recent trends indicate that Technology sector is one of the most targeted segments along with Finance and Government Figure 2 Attacks are evolving & a large % of attacks are upgrading to Application DDoS or a multi-vector attack As the DDoS attacks gets bigger and more sophisticated, we need to take a defense-in-depth approach, to protect our customers in every step of the way. Azure services like Azure Front Door, Azure WAF and Azure DDoS are all working on various strategies to counter these emerging DDoS attack patterns. We will cover more on how to effectively use these services to protect your services hosted on Azure in part-3. Understanding DDoS Attacks: The Attacker's Perspective There can be many motivations behind a DDoS attack, ranging from simple mischief to financial gain, political activism, or even cyber warfare. But launching a successful DDoS attack isn’t just about flooding a website with traffic—it requires careful planning, multiple test runs, and a deep understanding of how the target’s infrastructure operates. So, what does it actually mean to bring down a service? It means pushing one or more critical resources past their breaking point—until the system grinds to a halt, becomes unresponsive, or outright collapses under the pressure. Whether it’s choking the network, exhausting compute power, or overloading application processes, the goal is simple: make the service so overwhelmed that legitimate users can’t access it at all. Resources Targeted During an Attack Network Capacity (Bandwidth and Infrastructure): The most common resource targeted in a DDoS attack, the goal is to consume all available network capacity, thereby preventing legitimate requests from getting through. This includes overwhelming routers, switches, and firewalls with excessive traffic, causing them to fail. Processing Power: By inundating a server with more requests than it can process, an attacker can cause it to slow down or even crash, denying service to legitimate users. Memory: Attackers might attempt to exhaust the server's memory capacity, causing degradation in service or outright failure. Disk Space and I/O Operations: An attacker could aim to consume the server's storage capacity or overwhelm its disk I/O operations, resulting in slowed system performance or denial of service. Connection-based Resources: In this type of attack, the resources that manage connections, such as sockets, ports, file descriptors, and connection tables in networking devices, are targeted. Overwhelming these resources can cause a disruption of service for legitimate users. Application Functionality: Specific functions of a web application can be targeted to cause a denial of service. For instance, if a web application has a particularly resource-intensive operation, an attacker may repeatedly request this operation to exhaust the server's resources. DNS Servers: A DNS server can be targeted to disrupt the resolution of domain names to IP addresses, effectively making the web services inaccessible to users. Zero-Day Vulnerabilities: Attackers often exploit unknown or zero-day vulnerabilities in applications or the network infrastructure as part of their attack strategy. Since these vulnerabilities are not yet known to the vendor, no patch is available, making them an attractive target for attackers. CDN Cache Bypass – HTTP flood attack bypasses the web application caching system that helps manage server load. Crafting The Attack Plan Most modern services no longer run on a single machine in someone’s basement—they are hosted on cloud providers with auto-scaling capabilities and vast network capacity. While this makes them more resilient, it does not make them invulnerable. Auto-scaling has its limits, and cloud networks are shared among millions of customers, meaning attackers can still find ways to overwhelm them. When planning a DDoS attack, attackers first analyze the target’s infrastructure to identify potential weaknesses. They then select an attack strategy designed to exploit those weak points as efficiently as possible. Different DDoS attack types target different resources and have unique characteristics. Broadly, these attack strategies can be categorized into three main types: Volumetric Attacks For volumetric attacks, the attacker’s goal is to saturate the target’s system resources by generating a high volume of traffic. To weaponize this attack, attackers usually employ botnets or compromised systems or even use other cloud providers (paid or fraudulently) to generate a large volume of traffic. The traffic is directed towards the target's network, making it difficult for legitimate traffic to reach the services. Examples: SYN Flood, UDP Flood, ICMP Flood, DNS Flood, HTTP Flood. Amplification Attacks Amplification attacks are a cunning tactic where attackers seek to maximize the impact of their actions without expending significant resources. Through crafty exploitation of vulnerabilities or features in systems, such as using reflection-based methods or taking advantage of application-level weaknesses, they make small queries or requests that produce disproportionately large responses or resource consumption on the target's side. Examples: DNS Amplification, NTP Amplification, Memcached Reflection Low and Slow Attacks Non-volumetric exhaustion attacks focus on depleting specific resources within a system or network rather than inundating it with sheer volume of traffic. By exploiting inherent limitations or design aspects, these attacks selectively target elements such as connection tables, CPU, or memory, leading to resource exhaustion without the need for high volume of traffic, making this a very attractive strategy for attackers. Attacks, such as Slowloris and RUDY, subtly deplete server resources like connections or CPU by mimicking legitimate traffic, making them difficult to detect. Examples: Slowloris, R-U-Dead-Yet? (RUDY). Vulnerability-Based Attacks Instead of relying on sheer traffic volume, these attacks exploit known vulnerabilities in software or services. The goal isn’t just to overwhelm resources but to crash, freeze, or destabilize a system by taking advantage of flaws in how it processes certain inputs. This type of attack is arguably the hardest to craft because it requires deep knowledge of the technology stack a service is running on. Attackers must painstakingly research software versions, configurations, and known vulnerabilities, then carefully craft malicious “poison pill” requests designed to trigger a failure. It’s a game of trial and error, often requiring multiple test runs before finding a request that successfully brings down the system. It’s also one of the most difficult attacks to defend against. Unlike volumetric attacks, which flood a service with traffic that security tools can detect, a vulnerability-based attack can cause a software crash so severe that it prevents the system from even generating logs or attack traffic metrics. Without visibility into what happened, detection and mitigation become incredibly challenging. Examples: Apache Killer, Log4Shell Executing The Attack Now that an attacker has finalized their attack strategy and identified which resource(s) to exhaust, they still need a way to execute the attack. They need the right tools and infrastructure to generate the overwhelming force required to bring a target down. Attackers have multiple options depending on their technical skills, resources, and objectives: Booters & Stressers – Renting attack power from popular botnets. Amplification attacks – Leveraging publicly available services (like DNS or NTP servers) to amplify attack traffic. Cloud abuse – Hijacking cloud VMs or misusing free-tier compute resources to generate attacks. But when it comes to executing large-scale, persistent, and devastating DDoS attacks, one method stands above the rest: botnets. Botnets: The Powerhouse Behind Modern DDoS Attacks A botnet is a network of compromised devices—computers, IoT gadgets, cloud servers, and even smartphones—all controlled by an attacker. These infected devices (known as bots or zombies) remain unnoticed by their owners while quietly waiting for attack commands. Botnets revolutionized DDoS attacks, making them: Massive in scale – Some botnets include millions of infected devices, generating terabits of attack traffic. Hard to block – Since the traffic comes from real, infected machines, it’s difficult to filter out malicious requests. Resilient – Even if some bots are shut down, the remaining network continues the attack. But how do attackers build, control, and launch a botnet-driven DDoS attack? The secret lies in Command and Control (C2) systems. How a Botnet Works: Inside the Attacker’s Playbook Infecting Devices: Building the Army Attackers spread malware through phishing emails, malicious downloads, unsecured APIs, or IoT vulnerabilities. Once infected, a device becomes a bot, silently connecting to the botnet's network. IoT devices (smart cameras, routers, smart TVs) are especially vulnerable due to poor security. Command & Control (C2) – The Brain of the Botnet A botnet needs a Command & Control (C2) server, which acts as its central command center. The attacker sends instructions through the C2 server, telling bots when, where, and how to attack. Types of C2 models: Centralized C2 – A single server controls all bots (easier to attack but simpler to manage). Peer-to-Peer (P2P) C2 – Bots communicate among themselves, making takedowns much harder. Fast Flux C2 – C2 infrastructure constantly changes IP addresses to avoid detection. Launching the Attack: Overwhelming the Target When the attacker gives the signal, the botnet unleashes the attack. Bots flood the target with traffic, connection requests, or amplification exploits. Since the traffic comes from thousands of real, infected devices, distinguishing attackers from normal users is extremely difficult. Botnets use encryption, proxy networks, and C2 obfuscation to stay online. Some botnets use hijacked cloud servers to further hide their origins. Famous Botnets & Their Impact Mirai (2016) – One of the most infamous botnets, Mirai infected IoT devices to launch a 1.2 Tbps DDoS attack, taking down Dyn DNS and causing major outages across Twitter, Netflix, and Reddit. Mozi (2020-Present) – A peer-to-peer botnet with millions of IoT bots worldwide. Meris (2021) – Hit 2.5 million RPS (requests per second), setting records for application-layer attacks. Botnets have transformed DDoS attacks, making them larger, harder to stop, and widely available on the dark web. With billions of internet-connected devices, botnets are only growing in size and sophistication. We will cover strategies on botnet detection and mitigations employed by Azure Front Door and Azure WAF services against such large DDoS attacks. Wrapping Up Part-1 With that, we’ve come to the end of Part 1 of our Unmasking DDoS Attacks series. To summarize, we’ve covered: ✅ The fundamentals of DDoS attacks—what they are and why they’re dangerous. ✅ The different categories of DDoS attacks—understanding how they overwhelm resources. ✅ The attacker’s perspective—how DDoS attacks are planned, strategized, and executed. ✅ The role of botnets—why they are the most powerful tool for large-scale attacks. This foundational knowledge is critical to understanding the bigger picture of DDoS threats—but there’s still more to uncover. Stay tuned for Part 2, where we’ll dive deeper into well-known DDoS attack patterns, examine some of the biggest DDoS incidents in history, and explore what lessons we can learn from past attacks to better prepare for the future. See you in Part 2!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.
