DDoS Protection Standard protects resources in a virtual network, including public IP addresses associated with virtual machines, load balancers, and application gateways. When coupled with the Application Gateway web application firewall or a third-party web application firewall deployed in a virtual network with a public IP, DDoS Protection Standard can provide full layer 3 to layer 7 mitigation capability.
DDoS Protection Standard can mitigate the following types of attacks
Volumetric attacks
These attacks flood the network layer with a substantial amount of seemingly legitimate traffic. They include UDP floods, amplification floods, and other spoofed-packet floods. DDoS Protection Standard mitigates these potential multi-gigabyte attacks by absorbing and scrubbing them with Azure's global network scale automatically.
Protocol attacks
These attacks render a target inaccessible by exploiting a weakness in the layer 3 and layer 4 protocol stack. They include SYN flood attacks, reflection attacks, and other protocol attacks. DDoS Protection Standard mitigates these attacks, differentiating between malicious and legitimate traffic by interacting with the client and blocking malicious traffic.
Resource (application) layer attacks
These attacks target web application packets to disrupt the transmission of data between hosts. They include HTTP protocol violations, SQL injection, cross-site scripting, and other layer 7 attacks. Use a Web Application Firewall, such as the Azure Application Gateway web application firewall, as well as DDoS Protection Standard to provide defense against these attacks. There are also third-party web application firewall offerings available in the Azure Marketplace.
The following sections outline the key features of the Azure DDoS Protection Standard service.
Always-on traffic monitoring
DDoS Protection Standard monitors actual traffic utilization and constantly compares it against the thresholds defined in the DDoS Policy. When the traffic threshold is exceeded, DDoS mitigation is initiated automatically. When traffic returns below the thresholds, the mitigation is stopped.
During mitigation, traffic sent to the protected resource is redirected by the DDoS protection service and several checks are performed, such as:
Ensure packets conform to internet specifications and are not malformed.
Interact with the client to determine if the traffic is potentially a spoofed packet (e.g: SYN Auth or SYN Cookie or by dropping a packet for the source to retransmit it).
Rate-limit packets if no other enforcement method can be performed.
DDoS protection drops attack traffic and forwards the remaining traffic to its intended destination. Within a few minutes of attack detection, you are notified using Azure Monitor metrics. By configuring logging on DDoS Protection Standard telemetry, you can write the logs using available options for future analysis. Metric data in Azure Monitor for DDoS Protection Standard is retained for 30 days.
Adaptive real-time tuning
The complexity of attacks (for example, multi-vector DDoS attacks) and the application-specific behaviours of tenants call for per-customer, tailored protection policies. The service accomplishes this by using two insights:
Automatic learning of per-customer (per-public IP) traffic patterns for Layers 3 and 4.
Minimizing false positives, considering that the scale of Azure allows it to absorb a significant amount of traffic.
DDoS Protection telemetry, monitoring, and alerting
DDoS Protection Standard exposes rich telemetry via Azure Monitor. You can configure alerts for any of the Azure Monitor metrics that DDoS Protection uses. You can integrate logging with Splunk (Azure Event Hubs), Azure Monitor logs, and Azure Storage for advanced analysis via the Azure Monitor Diagnostics interface.
DDoS mitigation policies.
In the Azure portal, select Monitor > Metrics. In the Metrics pane, select the resource group, select a resource type of Public IP Address, and select your Azure public IP address. DDoS metrics are visible in the Available metrics pane.
DDoS Protection Standard applies three autotuned mitigation policies (TCP SYN, TCP, and UDP) for each public IP of the protected resource in the virtual network that has DDoS enabled. You can view the policy thresholds by selecting the metric Inbound packets to trigger DDoS mitigation.
The policy thresholds are autoconfigured via machine learning-based network traffic profiling. DDoS mitigation occurs for an IP address under attack only when the policy threshold is exceeded.
The metric for an IP address under a DDoS attack
If the public IP address is under attack, the value for the metric Under DDoS attack or not changes to 1 as DDoS Protection performs mitigation on the attack traffic.
We recommend configuring an alert on this metric. You'll then be notified when there’s an active DDoS mitigation performed on your public IP address.
For more information, see Manage Azure DDoS Protection Standard using the Azure portal.
Web application firewall for resource attacks
Specific to resource attacks at the application layer, you should configure a web application firewall (WAF) to help secure web applications. A WAF inspects inbound web traffic to block SQL injections, cross-site scripting, DDoS, and other Layer 7 attacks. Azure provides WAF as a feature of Application Gateway for centralized protection of your web applications from common exploits and vulnerabilities. There are other WAF offerings available from Azure partners that might be more suitable for your needs via the Azure Marketplace.
Even web application firewalls are susceptible to volumetric and state exhaustion attacks. We strongly recommend enabling the DDoS Protection Standard on the WAF virtual network to help protect from volumetric and protocol attacks. For more information, see the DDoS Protection reference architectures section.
Protection Planning
Planning and preparation are crucial to understand how a system will perform during a DDoS attack. Designing an incident management response plan is part of this effort.
If you have a DDoS Protection Standard, make sure that it's enabled on the virtual network of internet-facing endpoints. Configuring DDoS alerts helps you constantly watch for any potential attacks on your infrastructure.
Monitor your applications independently. Understand the normal behaviour of an application. Prepare to act if the application is not behaving as expected during a DDoS attack.
Fundamental Best Practices
The following sections give prescriptive guidance to build DDoS-resilient services on Azure.
Design for security
Ensure that security is a priority throughout the entire lifecycle of an application, from design and implementation to deployment and operations. Applications can have bugs that allow a relatively low volume of requests to use an inordinate amount of resources, resulting in a service outage.
To help protect a service running on Microsoft Azure, you should have a good understanding of your application architecture and focus on the five pillars of software quality. You should know typical traffic volumes, the connectivity model between the application and other applications, and the service endpoints that are exposed to the public internet.
Ensuring that an application is resilient enough to handle a denial of service that's targeted at the application itself is most important. Security and privacy are built into the Azure platform, beginning with the Security Development Lifecycle (SDL). The SDL addresses security at every development phase and ensures that Azure is continually updated to make it even more secure.
Design for scalability
Scalability is how well a system can handle increased load. Design your applications to scale horizontally to meet the demand of an amplified load, specifically in the event of a DDoS attack. If your application depends on a single instance of a service, it creates a single point of failure. Provisioning multiple instances makes your system more resilient and more scalable.
For Azure App Service, select an App Service plan that offers multiple instances. For Azure Cloud Services, configure each of your roles to use multiple instances. For Azure Virtual Machines, ensure that your virtual machine (VM) architecture includes more than one VM and that each VM is included in an availability set. We recommend using virtual machine scale sets for autoscaling capabilities.
Defense in depth
The idea behind defense in depth is to manage risk by using diverse defensive strategies. Layering security defenses in an application reduces the chance of a successful attack. We recommend that you implement secure designs for your applications by using the built-in capabilities of the Azure platform.
You should deploy Azure services in a virtual network whenever possible. This practice allows service resources to communicate through private IP addresses. Azure service traffic from a virtual network uses public IP addresses as source IP addresses by default. Using service endpoints will switch service traffic to use virtual network private addresses as the source IP addresses when they're accessing the Azure service from a virtual network.
Azure security baseline for Azure DDoS Protection Standard
This security baseline applies guidance from the Azure Security Benchmark version 2.0 to the Azure DDoS Protection standard. The Azure Security Benchmark provides recommendations on how you can secure your cloud solutions on Azure. The content is grouped by the security controls defined by the Azure Security Benchmark and the related guidance applicable to the Azure DDoS Protection standard.
Asset Management
For more information, see the Azure Security Benchmark: Asset Management.
AM-1: Ensure the security team has visibility into asset risks
Guidance: Make sure to grant security teams Security Reader permissions in your Azure tenant and subscriptions so they can monitor for security risks by using Microsoft Defender for Cloud.
Monitoring for security risks could be the responsibility of a central security team or a local team, depending on how you structure responsibilities. Always aggregate security insights and risks centrally within an organization.
Always aggregate security insights and risks centrally within an organization.
You can apply Security Reader permissions broadly to an entire tenant's Root Management Group, or scope permissions to specific management groups or subscriptions.
Note: Visibility into workloads and services might require more permissions.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
AM-2: Make sure the security team has access to asset inventory and metadata
Guidance: DDoS Protection Standard doesn't use tags. Customers can't apply or use tags as metadata to logically organize resources in a taxonomy.
Use Azure Virtual Machine Inventory to automate collecting information about software on virtual machines (VMs). Software Name, Version, Publisher, and Refresh Time are available from the Azure portal. To access install dates and other information, enable guest-level diagnostics and import the Windows Event Logs into a Log Analytics workspace.
Azure Resource Graph doesn't allow running an application or installing software on its resources.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
AM-3: Use only approved Azure services
Guidance: Use Azure Policy to audit and restrict which services users can provision in your environment. Use Azure Resource Graph to query for and discover resources within subscriptions. You can also use Azure Monitor to create rules that trigger alerts when they detect an unapproved service.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
Logging and Threat Detection
For more information, see the Azure Security Benchmark: Logging and Threat Detection.
LT-1: Enable threat detection for Azure resources
Guidance: Use the Microsoft Defender for Cloud built-in threat detection capability. Enable Microsoft Defender for your DDoS Protection Standard resources. Microsoft Defender provides an extra layer of security intelligence. Microsoft Defender detects unusual and potentially harmful attempts to access or exploit your DDoS Protection resources.
Forward DDoS Protection logs from Azure to your security information and event management (SIEM) system. You can use your SIEM to set up custom threat detections.
Make sure to monitor different types of Azure assets for potential threats and anomalies. Focus on getting high-quality alerts to reduce false positives for analysts to sort through. You can source alerts from log data, agents, or other data.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
LT-3: Enable logging for Azure network activities
Guidance: Not applicable. DDoS Protection Standard doesn't support integrating with networks and doesn't expose its network-related activities.
DDoS Protection can't deploy directly into virtual networks. You can't use network security group flow logging, route traffic through a firewall, or do packet captures.
Even when you can deploy DDoS Protection resources into a virtual network, you can't enforce network traffic or pass traffic through a network security group. You have to disable network policies on the subnet for DDoS Protection to function correctly. For this reason, you can't configure network security group flow logging for DDoS Protection.
DDoS Protection Standard doesn't produce or process DNS query logs.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: The Azure Security Benchmark is the default policy initiative for Microsoft Defender for Cloud and is the foundation for Microsoft Defender for Cloud's recommendations. The Azure Policy definitions related to this control are enabled automatically by Microsoft Defender for Cloud. Alerts related to this control may require a Microsoft Defender plan for the related services.
Azure Policy built-in definitions - Microsoft Network
Name (Azure portal) | Description | Effect(s) | Version (GitHub) |
Network Watcher is a regional service that enables you to monitor and diagnose conditions at a network scenario level in, to, and from Azure. Scenario-level monitoring enables you to diagnose problems at an end-to-end network-level view. It is required to have a network watcher resource group created in every region where a virtual network is present. An alert is enabled if a network watcher resource group is not available in a particular region. |
LT-4: Enable logging for Azure resources
Guidance: DDoS Protection Standard activity logs are available automatically. The logs contain all PUT, POST, and DELETE, but not GET, operations for DDoS Protection resources. You can use activity logs to find errors when troubleshooting or to monitor how users modify resources.
DDoS Protection Standard also produces security audit logs for the local administrator accounts. Enable these local admin audit logs. DDoS Protection Standard currently doesn't produce Azure resource logs.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
LT-6: Configure log storage retention
Guidance: For storage accounts or Log Analytics workspaces that store DDoS Protection Standard logs, set a log retention period that meets your organization's compliance regulations.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
Posture and Vulnerability Management
For more information, see the Azure Security Benchmark: Posture and Vulnerability Management.
PV-1: Establish secure configurations for Azure services
Guidance: Use Azure Blueprints to automate deployment and configuration of services and application environments. A single blueprint definition can include Azure Resource Manager templates, RBAC controls, and policies.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PV-2: Sustain secure configurations for Azure services
Guidance: Use Microsoft Defender for Cloud to monitor your configuration baseline. Use Azure Policy [deny] and [deploy if not exist] to enforce secure configuration across Azure compute resources including VMs and containers.
Responsibility: Customer
Microsoft Defender for Cloud monitoring: None
PV-6: Do software vulnerability assessments
Guidance: Microsoft does vulnerability management on the underlying systems that support the DDoS Protection Standard.
Responsibility: Microsoft
Microsoft Defender for Cloud monitoring: None
Components of a DDoS response strategy
A DDoS attack that targets Azure resources usually requires minimal intervention from a user standpoint. Still, incorporating DDoS mitigation as part of an incident response strategy helps minimize the impact on business continuity.
Microsoft threat intelligence
Microsoft has an extensive threat intelligence network. This network uses the collective knowledge of an extended security community that supports Microsoft's online services, Microsoft partners, and relationships within the Internet security community.
As a critical infrastructure provider, Microsoft receives early warnings about threats. Microsoft gathers threat intelligence from its online services and from its global customer base. Microsoft incorporates all of this threat intelligence back into the Azure DDoS Protection products.
Also, the Microsoft Digital Crimes Unit (DCU) performs offensive strategies against botnets. Botnets are a common source of command and control for DDoS attacks.
Risk evaluation of your Azure resources
It’s imperative to understand the scope of your risk from a DDoS attack on an ongoing basis. Periodically ask yourself:
What new publicly available Azure resources need protection?
Is there a single point of failure in the service?
How can services be isolated to limit the impact of an attack while still making services available to valid customers?
Are there virtual networks where the DDoS Protection Standard should be enabled but isn't?
Are my services active/active with failover across multiple regions?
It is essential that you understand the normal behaviour of an application and prepare to act if the application is not behaving as expected during a DDoS attack. Have monitors configured for the business-critical applications that mimic client behaviour and notify you when relevant anomalies are detected?
Azure Application Insights is an extensible application performance management (APM) service for web developers on multiple platforms. Use Application Insights to monitor your live web application. It automatically detects performance anomalies. It includes analytics tools to help you diagnose issues and to understand what users do with your app. It's designed to help you continuously improve performance and usability.
Customer DDoS response team
Creating a DDoS response team is a key step in responding to an attack quickly and effectively. Identify contacts in your organization who will oversee both planning and execution. This DDoS response team should thoroughly understand the Azure DDoS Protection Standard service. Make sure that the team can identify and mitigate an attack by coordinating with internal and external customers, including the Microsoft support team.
We recommend that you use simulation exercises as a normal part of your service availability and continuity planning, and these exercises should include scale testing.
Alerts during an attack
Azure DDoS Protection Standard identifies and mitigates DDoS attacks without any user intervention.
When to contact Microsoft support
Azure DDoS Protection Standard customers have access to the DDoS Rapid Response (DRR) team, which can help with attack investigation during an attack as well as post-attack analysis.
Post-attack steps
It’s always a good strategy to do a postmortem after an attack and adjust the DDoS response strategy as needed. Things to consider:
Was there any disruption to the service or user experience due to a lack of scalable architecture?
Which applications or services suffered the most?
How effective was the DDoS response strategy, and how can it be improved?
If you suspect you're under a DDoS attack, escalate through your normal Azure Support channels.
Comments