DDoS protection

Distributed Denial of Service (DDoS) attacks are malicious attempts to disrupt the normal traffic of a targeted server, service, or network by overwhelming it with a flood of internet traffic. If not mitigated effectively, DDoS attacks can lead to impaired availability or degraded response times for web applications. In such situations, if the application scales to absorb the attack, it incurs undesired scaling costs. Fortunately, applications built on AWS benefit from native DDoS protections and can be designed to be highly resilient against these attacks using AWS services and security controls.

Security is a shared responsibility between AWS and the customer. AWS is responsible for protecting the infrastructure that underpins its cloud services. To safeguard its infrastructure, AWS employs native protections against infrastructure DDoS attacks (at layer 3 and 4) at no additional charge. These protections are provided through Shield Standard and are based on the following components:

• Monitoring systems analyze various sources, such as NetFlow from networking devices and service logs, to detect DDoS attacks.
• Scrubbing systems clean traffic from DDoS attacks using Deep Packet Inspection, firewalling, and traffic shaping. For services like CloudFront and Route 53, scrubbing systems are deployed within their Points of Presence (PoPs), enabling sub-second detection and mitigation. In contrast, for regional services like ALB or EC2, scrubbing systems mitigate attacks after detection, usually within minutes.
• The Shield Response Team drives rapid resolution of DDoS attacks that are not automatically detected and mitigated by the monitoring and scrubbing systems.

In the shared responsibility model, your responsibility for DDoS protection depends on the AWS Cloud services you use, which determines the amount of configuration work you must perform. For instance, exposing files from S3 instead of an EC2 instance reduces the security controls you need to employ against DDoS attacks. Regardless of the services used, AWS provides capabilities to protect, monitor, and respond to DDoS attacks within your responsibility scope.

You are responsible for designing DDoS-resilient architectures using AWS services. Best practices include:

• Using CloudFront for web applications, and Global Accelerator for other use cases to benefit from hundreds of Tbps of mitigation capacity across the AWS distributed edge network. Both CloudFront and Global Accelerator employ advanced DDoS mitigation techniques such as SYN Proxy, which provides protection against SYN floods by sending SYN cookies to challenge new connections before they are allowed to continue upstream. CloudFront provides the fastest (sub-millisecond) and the most complete protection against all known Layer 3 and 4 DDoS attacks, as well against DDoS attacks targeting HTTP protocol such as Slowloris and HTTP/2 rapid reset attacks.
• Reducing the attack surface of your origins using Origin Cloaking techniques.
• Preparing your application to scale, for example, using autoscaling with EC2-based origins.
• Blocking HTTP Floods using AWS WAF
• Monitoring your application behavior to alarm on abnormal activities, analyzing threats, and responding using pre-established runbooks with the possibility to engage AWS for support.

To effectively block HTTP floods (DDoS attacks at Layer 7), AWS WAF provides a combination of multiple rules.

• Rules to reduce the surface attack of the application, by denying any unexpected request patterns. For example, you can write rules to deny requests with URLs not adhering to your API URL schemes, requests with HTTP verbs not supported by your API, or simply Host header values not part of your domain names. Such rules block undesired traffic immediately.
• Rules based on IP reputation which block traffic from IPs with bad reputation. You can use Amazon Managed rules based on threat intelligence gathered by AWS, Managed rules for AWS WAF by vendors from the AWS Marketplace, such as Imperva, or you can build your own IP reputation list and automatically update AWS WAF. IP reputation based rules tend to immediately block a significant portion of HTTP floods.
• Rate limiting rules that aggregate requests according to a configured dimension (e.g. IP), then block traffic if the aggregated request volume exceed configured thresholds (e.g. 100 request) within a certain duration (e.g. 1 min). Rate limits block offending traffic within tens of seconds until their volume goes down below configured thresholds. If you want to extend the blocking duration of rate limits, implement the custom solution described in this blog. Examples of rate limiting rules include: a blanket IP based rule with high threshold (e.g. 2 000), URI specific (e.g. /login) IP based rule with lower threshold (e.g. 100), country based rule for countries where you do not operate meaningful business, cookie based to block offending authenticated sessions, etc..
• Rules with JavaScript Challenge action, to immediately block undesired traffic generated by tools that fail in executing JavaScript and solving challenges like legitimate browsers do.
• Bot Control rules to protect against HTTP floods orchestrated by evasive bots. Bot management techniques using AWS WAF Bot Control include behavioral detections, ML based detection of coordinated activity, browser automation detection and CAPTCHA challenges. Detection and mitigation happen within tens of seconds.
• Rules based on attack signature automatically created by Shield Advanced's automatic application layer DDos mitigation (L7AM). When this capability of Shield Advanced is activated, an empty managed rule group is created in your AWS WAF WebACL, and your application traffic is monitored for at least 72 hours to build a baseline of normal traffic. When there is a significant deviation of the traffic profile from the established baseline, Shield Advanced signals a DDoS detection and starts analyzing the traffic for an attack signature. If a signature is found, it is first tested on past traffic to reduce the risk of false positive, then if it's safe to use it, a corresponding WAF rule is placed in the previously created rule group. After a certain time, when the attack is stopped, the rule is automatically removed from the rule group. When successful, this process takes several minutes.

Additionally, you can implement dynamic WAF rules that adapt to the perceived threat level, enabling more aggressive responses (e.g., CAPTCHA or Challenge actions) during high-severity DDoS attacks. Learn more about how you can implement this pattern using this solution.

Shield Advanced is an additional AWS service that enhances your security posture against DDoS attacks. It provides automatic mitigation at Layer 7 using AWS WAF for web applications and better protections for non-web applications, such as enforcing Network Access Control List (NACL) rules at the border network with higher bandwidth capacity. With Shield Advanced, attacks that are not mitigated automatically can be escalated to the Shield Response Team for manual mitigation.

To benefit from the full capabilities of Shield Advanced, it is recommended to:

1. After subscribing to Shield Advanced, add Shield Advanced protections to your internet-facing AWS resources. Protections must be in place 72 hours prior to an attack to ensure that application traffic is baselined and mitigations are applied.
2. For CloudFront and ALB resources, associate an AWS WAF WebACL with best practices described in the previous section (e.g Rate limiting, IP reputation, etc). Enable Layer 7 protection for these resources. Optionally, configure AWS WAF logging.
3. Configure proactive engagement to receive direct contact from the AWS Shield Response Team (SRT). Proactive engagement can be enabled prior to creating Amazon Route53 health checks. Health checks associated with your application improves the detection sensitivity of Shield Advanced. For example, when the health checks detect increased 5xx errors returned by your application, Shield Advanced lowers down the detection thresholds. Watch this short video to learn how to configure health checks.
   
4. Configure CloudWatch alarms for Shield and WAF to receive notifications when you are under attack.

To audit your configuration of Shield Advanced, run the DDoSResiliencyAssessment runbook in AWS Systems Manager. It collects, analyzes, and assesses the following resources: Amazon Route 53, Amazon Load Balancers, Amazon CloudFront distributions, AWS Global Accelerator and AWS Elastic IPs for their configuration settings in accordance with the recommended best practices for AWS Shield Advanced Protection.

DDoS simulation testing is permitted on AWS, and it is subject to the terms and conditions detailed on this page. AWS offers two options for running DDoS simulation tests: Either a simulated DDoS attack in production traffic with an authorized pre-approved AWS Partner such as NCC Group plc, RedWolf and Red Button; or a synthetic simulated DDoS attack with the Shield Response Team, also referred to as a firedrill.

• Find AWS WAF delivery partners
• Whitepaper - AWS Best Practices for DDoS Resiliency
• Blog - Understanding DDoS simulation testing in AWS
• Blog - The three most important AWS WAF rate-based rules
• Blog - Discover the benefits of AWS WAF advanced rate-based rules