Search Blog for

AWS DDoS Mitigation: Challenges, Best Practices and Tips

With Amazon Web Services accounting for more than one third of the cloud infrastructure market, many websites rely on AWS. While Amazon protects its own platform from attacks, websites that do not use AWS Shield are not protected from DDoS attacks. If your web server gets hit by an application layer DDoS attack, AWS will not mitigate it.

If you come under a massive network attack, you’ll be charged for the additional bandwidth your server consumes as a result. AWS’s native DDoS protection can absorb attack traffic up to a limit, but any traffic to your site beyond that limit, either good or bad, is simply dropped. Note: the limit is dependent on the size and duration of attack.

The first of this two-part series looks at how to secure your AWS instance. We follow up on how you can improve DDoS security with Incapsula in the second part of this series.

DDoS Protection from AWS

The level and type of DDoS protection with AWS can vary dramatically depending on its many deployment choices.

Based on its DDoS-resilient reference architecture, AWS separates its network components into two categories:

  1. AWS Edge Locations and AWS Regions

AWS edge locations and regions

AWS uses BP1 – BP7* which are a combination of the edge locations and AWS regions. BP1, BP2 are Amazon CloudFront with AWS WAF edge locations; while BP5 – BP7 are the AWS regional components to which you need to subscribe.

Mitigating a UDP attack on AWS

Let’s look at the step-by-step example for mitigating a UDP reflection attack. Here you start by manually configuring BP1 and BP 2 which are the WAF ACL.

Configure BP3 which controls Route 53 for AWS edge locations

Configure BP4 which is the API gateway

Next configure BP6 AWS Elastic Load Balancing

To block an application layer attack, configure Amazon CloudFront (BP1) with AWS WAF (BP2), Amazon API Gateway (BP4) and Amazon Route 53 (BP3)

How AWS Mitigates an IP Attack

Let’s take a look at AWS’s mitigation approach during a directed IP attack.

In this scenario you will need to log into your AWS account, access your instance(s) and then switch your DNS to AWS’s Route53. This rearranges certain services and immediately stops the flow of traffic to those IP addresses.

Let’s say the attack recurs and includes HTTP floods or WordPress pingback floods. However, this time it targets your website’s DNS name, so your IP address blocking settings from the first attack are ineffective. You’ll need to make the following changes to mitigate these two events:

  1. Identify where the attacks are coming from geographically and then block it by manually modifying firewall rules.
  2. Apply the AWS WAF add-on, which sits behind the AWS Route 53 configuration.

NoteAWS WAF has a set of standard rules and doesn’t allow modifications or additions to them.

  1. If you know the malicious IP address(es), which can number in the hundreds, you want to block then you need to create a rule with a “Block” action and associate it with the web ACL.
  2. You then create an IP address match condition in the web ACL to block the source IP addresses that are participating in the attack.
  3. Create further rules with conditions to block by URI, query string, HTTP method, or header key. For example, a WordPress ping attack will almost always contain “WordPress” in the user-agent field.

Note: This method of mitigating attacks can be challenging as you’ll need to identify malicious signatures or accurately distinguish malicious IP addresses.

  1. Increase the scaling parameters for EC2 instances to absorb the attack. Auto-scaling can help but may not be efficient if the attack is large.
  2. Scale up HA proxy servers and increase S3 storage capacity to increase data logging.
  3. Increase the auto-scaling “scale-down triggers” to set them much higher than the “scale-up triggers.” This removes the scale-down threshold.

For each phase of the mitigation process you’ll need to separately reconfigure settings for each AWS component based on the specifics of your account.

AWS DDoS protection doesn’t offer technology that is built on reputation lists, traffic behavioral analysis, attack awareness, alerting, and dynamic mitigation changes based on attack evasion. As a result you’ll need to make the changes manually and get familiar with how AWS works. For advanced mitigation methods that include the technology listed above look to services specializing in internet security and DDoS mitigation.

Best Practices for Preventing DDoS Attacks on Your AWS Instance

AWS customers can adapt their infrastructure and add security to defend against any attack. Here are some DDoS security best practices you can use for your AWS instance immediately.

  • Prepare adequate resources to handle huge surges of traffic, whether it’s from a successful marketing campaign or from a DDoS attack. Check in with business stakeholders to find out what sales programs they have in place that you need to prepare for.
  • Reduce the attack surface to safeguard exposed resources by delinking your infrastructure. For instance, customers running public websites need to separate web applications from backend databases, dynamic media and from static content.
  • Benchmark what is normal. It’s important to correctly identify traffic. For example, if your website gets media attention and suddenly receives a lot of traffic, you would not want to block that. Monitor and log your sites’ traffic trends and user behavior analysis patterns. This helps you determine if you’re seeing a false positive or an actual attack so you can quickly alert AWS.
  • Create a plan in the event of an assault. If you suspect a DDoS event is underway, immediately request assistance from AWS. At a minimum, AWS strongly advises using their Business Support service to ensure 24/7 access to a support engineer.

Tips on How to Prepare for a DDoS Event

There are several things you can do to prevent or quickly recover if you are under attack.

  • Design, configure and test your infrastructure to withstand DDoS attacks.
  • Alias your public facing domain name to an internal courtesy domain.
  • Learn how to efficiently manage DNS changes in the middle of potentially challenging scenarios.
  • Conduct a traffic test to your server.

Note: Before you start, get permission from AWS prior to mounting any significant test or you may risk having your services suspended or cancelled.

  • Scale up your capacity quickly, but reduce slowly in case a second wave of attacks occurs.
  • If you are using AWS Elastic Load Balancing (ELB), enable cross-zone load balancing to reduce the load on your DNS infrastructure.

As you tune your AWS instance, remember that—as part of their best practices deployment—AWS loads predefined lists and allows limited custom rules or changes to their solution. This limits any customization for each company’s specific needs.

Look for our next installment of this two-part series on how you can achieve high availability on your AWS instance using Incapsula.

* BP- Best Practice

AWS Edge Location AWS Regions
BP1 = Amazon CloudFront BP5 = Amazon VPC
BP2 = AWS WAF BP6 = Elastic Load Balancing
BP3 = AWS Route 53 BP7 = Amazon EC2 with Auto Scaling
BP4 = Amazon API Gateway