We’re switching the series up a little bit and going to pay some attention to the network layer for a couple of posts. There are important configuration best practices we should follow.
As part of the Shared Security Responsibility model, AWS is committed to Security in the AWS cloud. This means they secure the foundation upon which applications on AWS are built.
However, you are responsible to secure the layers on top of the foundation, including how applications react to DoS and DDoS attacks.
Amazon Web Services Shared Responsibility Model
DoS and DDoS attacks are defined as attempts at making an application or web site inoperable by means of overwhelming a website. These attacks are either by a direct attacker (DoS) or coordinated via a group of collaborating attackers (DDoS).
The very public nature of AWS makes any resource deployed a prime target for DDoS attacks. These include Elastic Load Balancers (ELB) or EC2 Instances. AWS has an excellent White Paper on how to mitigate DDoS attacks.
The easiest approach to take when trying to prevent a service interruption is to absorb the attack. There are other more complicated and costly approaches such as deploying advanced and/or application firewalls, and in some cases that’s the approach needed.
However, there’s a relatively lower-cost and effective solution to absorb DDoS attacks: AutoScaling.
Most of the time, a publicly-available site’s traffic will be directed by an ELB. The underlying compute instances that make up the ELB are managed by AWS directly, and are built to scale horizontally and vertically without intervention or advance planning.
Meaning, as traffic to your site increases, so scales the ELB. ELBs also only direct TCP traffic. This means that attack types that use protocols other than TCP will not reach your underlying applications.
However, all of that TCP traffic needs to be directed at something that can process the data contained therein. Those are the EC2 compute instances running web or application servers being managed. When the ELB scales, in most cases the instances managed needs to scale in proportion.
As described in the AWS DDoS white paper and AutoScaling service documentation, events can be triggered to automatically launch new EC2 instances running applications in reaction to an increase in network traffic.
Running application instances in an AutoScaling group is good AWS practice anyway, since doing so can automatically give applications resiliency and availability if configured appropriately.
For example, let’s say we set a condition for AutoScaling to launch two new application EC2 instances when the amount of network activity crosses a certain threshold.
This trigger would already allow your site to scale based on normal, legitimate demand. However, if abnormal, attack traffic were to come in to the site, AutoScaling would also trigger a scale up event, launching new EC2 instances to meet demand and process requests.
This means your service remains operational during the attack. Business continues as normal. Because the attention span of most attackers is short, most of them will move on to their next target.
And once the attack is over, AutoScaling will automatically scale down the number of EC2 instances if configured to do so.
The price to pay for the increase in instance hours to cover the attack is well-justified so that business as usual continues. Think of it as one of the cheapest and most effective insurance policies on the AWS cloud!
- Disable Root API Access Key and Secret Key
- Enable MFA Tokens Everywhere
- Reduce Number of IAM Users with Admin Rights
- Use Roles for EC2
- Least Privilege: Limit what IAM Entities Can Do with Strong Policies
- Rotate all the Keys Regularly
- Use IAM Roles with STS AssumeRole Where Possible
- Use AutoScaling to Dampen DDoS Effects
- Do Not Allow 0.0.0.0/0 Unless You Mean It
- Watch World-Readable and Listable S3 Bucket Policies