There is growing need for ways to Mitigate and Prevent DDOS attacks on AWS, I have put down 10 ways to make sure that the infrastructure is safe from DDOS atttacks

Here is the detailed list of best practices Mitigate and Prevent DDOS attacks on AWS :




Step 1 : Move any web servers/services behind CloudFront

CloudFront owns the layer 7 view of the traffic, meaning you can do layer 7 mitigations, which are likely to be more effective than our rate limiting and prioritization. CloudFront has more locations and might be able to move traffic around to help isolate the attack and use geographic location to isolate an attack to a specific region. http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Introduction.html Most of the time I suggest this, people respond with something like “that will work great for their static sites but what about their dynamic content?” but CF supports dynamic content: http://aws.typepad.com/aws/2012/05/amazon-cloudfront-support-for-dynamic-content.html

Step 2 : Move to ELB

ELBs can scale to absorb certain attacks like SYN floods, though it might be expensive and reserved for certain customers. ELB terminates TCP connections so someday you might be able to do layer 7 mitigations (BF is purely a layer 2/3/4 device). http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/SvcIntro.html

Step 3 : Scale up your fleet and run it “cold”

Running your fleet at 99% utilization might be frugal but it makes your customer’s experience really bad when traffic jumps by even a small amount. Be prepared to scale up on any increase in traffic, legitimate or not. One example is DNS resolver fleets. These are often run at extremely low utilization levels, due to the importance of DNS and the fact that they are often the targets of DDoS attacks.

Step 4 : Move any instances to Enhanced Networking

Shift your instance to Enhanced Networking underlying host(ex: c3.* instances) Even if you aren’t using SRIOV but are using VPC and c3.* instances, the underlying host will do the work of applying Network ACLs and Security Groups. If you are using SRIOV, you will see a much higher rate of PPS before the instance is unreachable.

Step 5 : Auto Scaling

It is going to help at any layer to use Auto Scaling, whether you are running your own load balancer instances, application servers, backend servers, etc. Sometimes attacks are very sudden, however, so auto scaling might not be able to easily see the ramp up in traffic in a natural way. http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/WhatIsAutoScaling.html

Step 6 : Move to a larger instance size

This might help you to absorb more PPS, but more importantly (for EC2), it will decrease the impact of the attack on neighboring instances.

Step 7 : Separate the public traffic from administrative traffic

This configuration helps because we will need to rate limit traffic to the public interface, often dropping 99% or more of the traffic. Management traffic will likely be dropped too. But the instance will (hopefully) be alive. With separate interfaces, you can easily bypass the rate limiting mitigation and determine what is happening (tcpdump on the public interface, for instance). One option is to create two separate network interfaces, one that handles the public (web, DNS, etc) traffic and another that handles management traffic (ssh). The public interface is published in obvious DNS records (www.company.com) but the management interface either is only accessible via a bastion host within the same VPC or via a tunnel or DirectConnect, or simply has a different public IP address.

Step 8 : Network ACL best practices

If you have a web server and want to create a Network ACL where it only allows TCP port 80 in, with a default rule of DROP. Ideally, you would set things up so any outgoing connections the web servers needs to make go through a separate path (see previous item re: separate public traffic and administrative traffic) If you can’t do that, you might need to also allow ephemeral ports (1024-65535) through. If you do this, it will block many attacks, such as UDP port 80 attacks, attacks to other non-ephemeral ports, ICMP, etc You can also add DROP rules before the TCP port 80 rule to drop any subnets that you see sending traffic, which is something our customers already do frequently.

For more info you can contact at mail@bhargavamin.com

Feel free to comment your view below as well.

-Bhargav Amin