AWS Best Practices for DDoS Resiliency (Summary)

Introduction: Denial of Service Attacks

A Denial of Service (DoS) attack is a deliberate attempt to make your website or application unavailable to users, attackers use a variety of techniques that consume large amounts of network or tie system resources using single source or using multiple in Disrupted (DoS) to orchestrate an attack.
DDoS attacks are most common at layers 3, 4, 6 and 7 of the OSI model

Infrastructure Layer Attacks (layer 3,4):

Attacker aims to generate large volumes of traffic that can inundate the capacity of a network or tie up system resources like firewall, IPS, loadbalancer. these attacks easy to identify and mitigated using scale up capacity more rapidly than the inbound traffic flood to filter out or absorb attack traffic, most common attacks are:

• UDP Reflection Attacks:

An attacker craft a valid UDP request packet listing the attack target’s IP as the UDP source IP, then sends the UDP packet containing the spoofed source IP to an intermediate serve which effectively amplifying the amount of attack traffic sent to the target IP address. The amplification factor, which is the ratio of response size to request size, varies depending on which protocol the attacker uses.

• SYN Flood Attacks:

To complete three-way handshake (SYN, SYN-ACK, ACK) packets are used, in a SYN flood attack, a malicious client sends a large number of SYN packets without (ACK) while server is waiting for this packet connection remains open resulting in no resources for legitimate connections.

Application Layer Attacks (layer 6,7):

•HTTP flood attack:

an attacker sends HTTP requests just like a real user or emulate human interaction with the application, this can increase the difficulty of using common mitigation techniques like request rate limiting.

• Cache-busting attack:

uses variations in the query string to circumvent content delivery network (CDN) caching, the CDN must contact the origin server for every page request.

• WordPress XML-RPC flood attack:

pingback feature allows a website hosted on WordPress (site A) to notify a different WordPress (site B) through a link that created between those sites, the attacker misuses this capability to cause Site B to attack Site A.

An attacker can also choose to attack (DNS) services by randomizes the subdomain string to bypass the local DNS cache and must repeatedly contact the authoritative DNS server, which amplifies the attack.
An attacker can also choose to attack the TLS negotiation process by sending unintelligible data, or renegotiates the encryption method, or opening and closing many TLS sessions.

Mitigation Techniques:

All AWS customers benefit from the automatic protections of AWS Shield Standard at no additional cost, and it defends against most common Infrastructure Layer Attacks in every region.
Additionally, you can leverage AWS services that operate from edge locations, like Amazon Route 53 and CloudFront and benefit the following:
Reducing time-to-mitigate, Stateless SYN Flood mitigation techniques, Automatic traffic engineering systems, Application layer defense when combined with AWS WAF.

Another way that you can improve your readiness to respond to and mitigate DDoS
attacks is by subscribing to AWS Shield Advanced, gaining the following benefits:
Access to the AWS DDoS Response Team and Global Threat Environment dashboard, Access to WAF with automatic baselining of web traffic attributes and firewall manger (free for both), DDoS attack visibility using (console, API, cloud watch), Enhanced service level agreement, Sensitive detection thresholds, Cost protection.

Infrastructure Layer Defense (BP1, BP3, BP6, BP7,BP8):

Key considerations to help mitigate volumetric DDoS attacks include ensuring that
enough transit capacity and diversity is available, and protecting your AWS resources,like Amazon EC2 instances, some instance supports 25 Gigabit network interfaces (this prevent interface congestion) and enhanced networking (providing higher I/O performance and lower CPU utilization). This improves the ability to handle traffic with larger packet volumes.

• Amazon EC2 with Auto Scaling (BP7):

You can set Amazon CloudWatch alarms to initiate Auto Scaling to automatically scale the size of your Amazon EC2 fleet. This approach protects application availability when there’s an unexpected increase in request volume. If you use Amazon CloudFront, Elastic Load Balancer TLS negotiation is handled by the public endpoint preventing TLS based attacks.

• Choice of Region (BP8):

It is also important to consider DDoS resiliency when you choose the regions for your application. Many regions are close to internet exchanges, so they have more
connectivity to major networks. Being close to exchanges where international carriers and large peers have a strong presence can help give you the internet capacity to mitigate larger attacks.

• Elastic Load Balancing (BP6):

ELB reduce the risk of overloading your application by distributing traffic across many backend instances by scaling automatically.
For web applications:SYN floods, UDP reflection will be blocked by Application load balancer (ALB). when an attacked is detected ALB automatically scale to absorb the additional traffic “free of charge for customer”.
For TCP-based applications: Network Load balancer (NLB) with elastic IP (EIP) can protect of DDoS attacks if customer using Shield advance.

Leverage AWS Edge Locations for Scale (BP1, BP3):

•Web Application Delivery at the Edge (BP1):

CloudFront reduce the number of TCP connections made to origin server and accepting only well-formed connection, preventing many DDoS attacks to reach backend server. Or using origin access identity (OIA) to protect static website hosted in S3.

•Domain Name Resolution at the Edge (BP3):

Amazon Route 53 uses techniques like shuffle-sharding (name server in your delegation set corresponds to a unique set of edge locations and internet paths) and anycast striping (each DNS request is served by optimal location). Amazon Route 53 can detect anomalies in the source and volume of DNS queries and prioritize requests from users that are known to be reliable.

Leverage AWS Edge Locations for Scale (BP1, BP3):

Detect and Filter Malicious Web Requests (BP1, BP2):

Amazon CloudFront reduce server load by preventing non-web traffic from reaching your origin, also automatically closing connections from slow reading or slow writing attackers (for example, Slowloris).
AWS WAF you can configure web access control lists (Web ACLs) on your CloudFront distributions or Application Load Balancers to filter and block requests based on request signatures. This is useful for mitigating HTTP flood attacks that are disguised as regular web traffic by blocking IP address initiating this traffic using web ACL rule.
Both AWS WAF and Amazon CloudFront also allow you to set Geo-restrictions to block or whitelist requests from selected countries.
If customer subscribed to AWS shield advance AWS DDoS Response Team (DRT) to help you create rules to mitigate an attack that is hurting your availability.

AWS Firewall manger can centrally mange and configure AWS rules across organization, master account can designate an admin account to create firewall policies.

Attack Surface Reduction:

is a concept where you expose only necessary part of the application to the internet this limits the options attacker has.

Obfuscating AWS Resources (BP1, BP4, BP5):

Security groups and Network Access Control Lists (NACLs) controls inbound and outbound traffic within VPC, the only difference they operate at instance level and subnet level respectively.

• Security Groups and Network Access Control Lists (NACLs) (BP5):

All traffic to security group is denied unless allow rule is configured. we can use security group referencing to protect backend instance to only receive traffic from ELB not from internet directly.
On the other hand, using NACLs we can specify allow and deny rules which give more control in allowing specific type of traffic (TCP/UDP) and IP addresses while denying other.
If customer subscribed to AWS shield advance can register resources using Elastic IP (EIP) as protected resource, this will allow attacks to detected quicklier and faster mitigation. DDoS mitigation systems read the NACL that corresponds to the targeted EIP and enforce it at the AWS network border.

Protecting Your Origin (BP1, BP5):

If the application uses CloudFront we can use Lambda to automatically update security group to allow traffic only from CloudFront and not bypass WAF. another enforcement can be done by allowing request headers from CloudFront only using X-Shared-Secret header.

Protecting API Endpoints (BP4):

Amazon API Gateway as an entryway to applications running on Amazon EC2, Lambda without exposing frontend API this will prevent DDoS attacks for all internal components. there are two types of API:

• Edge optimized API (Accessed through CloudFront).
• Regional API endpoint (accessed from the same AWS region in which your REST API is deployed).

When you use Amazon CloudFront and AWS WAF with Amazon API Gateway, configure the following options:

• Configure the cache behavior for your distributions to forward all headers to the API Gateway regional endpoint. By doing this, CloudFront will treat the content as dynamic and skip caching the content.
• Protect your API Gateway against direct access by configuring the distribution to include the origin custom header x-api-key, by setting the API key value in API Gateway.
• Protect your backend from excess traffic by configuring standard or burst rate limits for each method in your REST APIs.

Operational Techniques:

Visibility:

By using Amazon CloudWatch, you can monitor applications that you run on AWS number of CloudWatch metrics that can indicate that your application is being targeted.



AWS Shield console (or API) and threat Environment Dashboard can provide additional metrics and alarms in case of an attack.
with VPC flow logs you gain visibility to traffic targeting the application using this information can help to identify anomalies in network traffic and to identify a specific attack vector.

Support:

following all the steps mentioned above are meant to proactively protect the running workload in AWS but DDoS attack might still occur, it is important to create a response plan for DDoS attacks before an actual event.
Depending on the workload type and support type you can benefit from the following:

Workload	Subscription recommendation	Value
Production	Business support	24x7 access to cloud support engineer
Critical	Enterprise support	Open critical cases and receive the fastest response from a Senior Cloud Support Engineer

If you’re subscribed to AWS Shield Advanced and are also subscribed to either Business Support or Enterprise Support, you have the following options:

• escalate to the AWS DDoS Response Team (DRT).
• connect with a live AWS Support representative (if application responsiveness is degraded by DDoS attack).
• AWS Shield Engagement Lambda function

DRT does not typically have access to your AWS account resources, you need to authorize it.