The massive DDoS (distributed denial-of-service) attack on GitHub, an online code repository site, a couple weeks ago, has again reminded us that every web site or any type of online presences may eventually deal with this kind of threat. If your infrastructure is currently hosted on Amazon Web Services (AWS), you need to consider employing mitigation and protection techniques similar to what you have used on your local premise, or if you don’t have one, establishing your own mitigation strategies.
Some AWS services, such as Amazon S3 (Storage) and EC2 (Compute), use shared logical or physical infrastructure, which means that multiple AWS accounts can access and store data on the same set of infrastructure components. In this case, a DoS/DDoS attack is likely to affect multiple AWS customers and AWS is responsible to secure this infrastructure based on a shared responsibility model1 introduced to their customers. In this model, AWS maintains what they call a ‘security of the cloud’ to secure the shared infrastructure. While in a service like EC2, customers are in-charge of some of the controls and have the responsibility to choose any security implementations to protect their content, applications, and networks, or what AWS called as ‘security in the cloud’.
To effectively protect your assets against DoS/DDoS attack in the AWS cloud, you need to consider the following actions:
Establish a security and performance baseline for your service.
Before you start implementing any protection techniques or tweaking your applications or systems to mitigate DoS/DDoS attack on your cloud environment, it is important and part of a good practice to establish a security and performance baseline. This baseline shall capture your application and system metrics under normal circumstances, including the peak period or other notable patterns applicable for your type of business. For example, an application which typically expects 1,000 concurrent sessions at a specific time of day might trigger an alarm using Amazon CloudWatch and Amazon SNS if the current number of concurrent sessions exceeds twice that amount (2,000).
Implement stringent firewall controls and install web server security extensions specific to your systems.
Common approaches are to set up a firewall via AWS security groups (EC2 Classic/Amazon VPC) or using the operating system’s firewall to white-list all necessary ports, or to temporarily/permanently deny access from specific IP addresses, use Amazon Elastic Load Balancers, whenever possible, to protect your application from TCP-SYN flood attacks, and enable security extension specific for your operating system or web server. On Apache, you might consider to use mod_evasive to provide evasive action in the event of a DoS/DDoS attack or brute force attack. It is designed to be a detection and network management tool, and can be easily configured with ipchains. Mod_evasive reports attacks via email and syslog. On IIS, you might want to use ‘Dynamic IP Restrictions’ extension to identify attack patterns that could signal an attack. When an attack is detected, the attacker IP addresses will be placed in a temporary deny list for a predetermined amount of time.
If your business and applications risk profile requires a more sophisticated protection technique, you could deploy web application firewalls for a deep packet inspection of web traffics or install any host-based/inline Intrusion Detection Systems (IDS)/Intrusion Prevention System (IPS) to detect and contain all type of network attacks on your cloud networks. If you do not have the adequate capacity to deploy these types of protections, you might consider putting a third-party service in between your customers and your resources (for examples include aiCache Denial of Service Protection or Imperva Cloud DDoS Protection).
Implement an inline layer of protections.
Depends on your business risk profile, you might want to add a threat protection layer on your current network architecture. This layer defense model builds a layer to protect and contain your system’s exposure against DoS/DDoS attacks. In this layer, you could install or set up any software or devices mentioned in the previous section or use third-party firewall devices installed on Amazon EC2 instances (also known as soft blades).
Layered Network Defense in the Cloud2
Define a security policy for your service.
AWS outlines the ‘do’s and don’ts’ behavior in the cloud for their customers to protect their services from security violations and network abuse3. In this context, your organization is encouraged to create your own Acceptable Use policy as a deterrent factor and a guideline to overcome the abusive nature of network attacks on your service. It is also preferable to regularly review the effectiveness of your security policies and, If possible, to perform a vulnerability assessment on your cloud network. AWS supports both inbound and outbound penetration testing in the cloud, although you must request permission to conduct penetration tests.
Absorb the attack to your network.
One of the benefit of deploying your network to the cloud is the elastic nature of cloud infrastructure. With AWS cloud, new resources can be added, replaced or removed on your demand, if and when needed. If an attack occurs on your on-premises infrastructure, the common way to handle this situation is by starting to deny traffics from specific sources or even regions, on the assumption there are no customers residing on those locations, or if any, the numbers are small compare to your overall numbers of customers. However if your goal is to provide a reliable service to your customers, a denial of service, even to only one customer is unacceptable. In the AWS cloud, you have the option to absorb such an attack by employing Amazon Elastic Load Balancing (ELB) and Auto Scaling. With Auto Scaling you can configure your web servers to scale up when under DoS/DDoS attacks and scale down once the attack stops. You could also use Amazon CloudFront to absorb this type of attack. An attack to the content behind CloudFront is likely to send most or all requests to CloudFront edge locations, where the AWS infrastructure would absorb the extra requests with minimal to no impact on the back-end customer web servers. Keep in mind that there will be service cost associated with this service. Cost-benefit analysis is highly recommended before you start using any of these services.
Activate your business continuity and disaster recovery plan on the event of service disruption.
At Hardin, we understand each client has a different risk appetite and cost agility to overcome this kind of attack. Therefore, given your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) and budget, you may need to put your disaster recovery plan into action on the event of a massive DDoS attack on your service. Since AWS services are available on demand and you only pay for what you use, you can use this key advantage to build your own effective disaster recovery strategy by quickly provisioning new services on the event of a disaster.
1AWS Shared Responsibility Model – http://aws.amazon.com/compliance/shared-responsibility-model/
2AWS Security Best Practices – http://aws.amazon.com/whitepapers/aws-security-best-practices/
3Amazon Web Services Acceptable Use Policy – http://aws.amazon.com/aup/