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 firstname.lastname@example.org
Feel free to comment your view below as well.