Distributed denial of service (DDoS) attacks are sometimes used by malicious actors in an attempt to flood a network, system, or application with more traffic, connections, or requests than it can handle. Not surprisingly, customers often ask us how we can help them protect their applications against these types of attacks. To help you optimize for availability, AWS provides best practices that allow you to use the scale of AWS to build a DDoS-resilient architecture. These best practices are discussed in depth in the whitepaper,AWS Best Practices for DDoS Resiliency, which also includes reference architecture to help you better prepare for DDoS attacks and protect the availability of your application.
It is important to minimize the opportunities an attacker has to target your applications. In the whitepaper, we refer to this as reducing your attack surface. For DDoS attacks, this means restricting the type of traffic that can reach your applications. For example, if you’re building a simple web application, you might only need to expose TCP ports 80 and 443 to the Internet. This presents an opportunity to block traffic from many common DDoS attack vectors that do not communicate on the same port or protocol as your application.
In this blog post, we will show you how to use Amazon Virtual Private Cloud (VPC) to control access to your applications and minimize public entry points by configuring security groups and network access control lists (ACLs). This is just one of several best practices you should consider when building a DDoS-resilient architecture.
Common DDoS attacks
Before diving into a discussion about configuring Amazon VPC, it is important to understand DDoS attack vectors and how minimizing your attack surface can often prevent malicious traffic from reaching your applications. The most common class of DDoS attack is a reflection attack, which is also the most likely to produce a volume of traffic capable of congesting network interfaces and inhibiting legitimate traffic. To launch a reflection attack, the attacker will first scan the Internet for servers hosting User Datagram Protocol (UDP) services such as Simple Service Discovery Protocol (SSDP), Domain Name System (DNS), Network Time Protocol (NTP), and Simple Network Management Protocol (SNMP). Depending on their configuration, these services will often send a response that is many times larger than the initial request. This allows an attacker to send a large volume of small requests with a spoofed source address, resulting in responses that are sometimes tens or even hundreds of times larger. These responses are sent to the spoofed source, which is the target of the DDoS attack.
The following diagram details how an attacker can use spoofed requests to elicit an amplified response, resulting in a DDoS attack against the victim.
Figure 1. Distributed reflection denial of service attack
Configuring security groups
Reflection attacks allow an attacker to source large volumes of traffic from anywhere in the world using common UDP services. Thankfully, these attacks are also some of the easiest to detect and in many cases can be mitigated by configuring security groups in Amazon VPC. This allows you to control inbound and outbound traffic to your instances by specifically allowing communication only on the ports and protocols required for your applications. Access to any other port or protocol is automatically denied.
The following diagram provides reference architecture for the configuration of Amazon VPC using the example web application mentioned previously in this post. For more information, see Security Groups for Your VPC.
Figure 2. Reference architecture with Amazon VPC configuration
In this reference architecture, we use Amazon VPC configured with a DMZ public subnet and two private subnets. This allows us to create security groups that will permit communication with users and administrators via the Internet, and to create separate security groups for internal resources that are only accessible from the DMZ. For more information about creating and routing subnets in your VPC, see Your VPC and Subnets.
SSH bastion security group
The SSH bastion is a single Amazon EC2 instance used to provide secure administrator access and hosting only a Secure Shell (SSH) service. This allows the administrator to connect to TCP port 22 from the Internet or a specified range of Internet addresses. After connecting to the SSH bastion, the administrator can then connect to the web application server and MySQL database server instances. In case of a DDoS attack against this port, only the SSH service would be impacted. This prevents an attacker from using this port to impact the availability of your web application. To minimize the possibility of unauthorized access, only your network’s public IP range should be allowed to communicate with the SSH bastion security group. The following table provides an example of rules you can use to configure the SSH bastion security group.
ELB security group
Elastic Load Balancing (ELB) allows you to achieve greater fault tolerance by automatically routing inbound traffic across multiple Amazon EC2 instances. It also allows you to reduce your attack surface by receiving requests on behalf of your web application and automatically scaling to handle capacity demands. Additionally, ELB is designed to pass only well-formed connections to your web application on ports and protocols that you specify. This provides an additional layer of DDoS resiliency. To allow users to access your web application through an ELB, we will set up a security group that accepts only TCP port 80 and 443 from the Internet and is able to distribute these requests to EC2 instances in the web application server security group. The following table provides an example of rules you can use to configure the ELB security group.
NAT security group
Because the web application server and MySQL database server in this example are hosted on instances with private subnets, they do not have a route either directly in from or out to the Internet. Though this is not required to serve content to users via ELB, it may be desirable to allow instances to connect to the Internet for software updates. To allow the EC2 instances hosting the web and database services to access the Internet, we will create a network address translation (NAT) instance inside its own security group. With a NAT instance, you can securely route traffic from private subnets out to the Internet, while denying any inbound connectivity from the Internet. For more information, see NAT Instances.
Web application server security group
This security group contains all EC2 instances that serve content on behalf of the web application. These EC2 instances will accept web application requests only from the ELB. In an effort to minimize the attack surface, these instances are assigned only private IP addresses from the VPC subnet address range, which prevents them from being accessed directly via the Internet. Instead, we will configure the web application server security group to permit only TCP port 80 and 443 traffic from the ELB security group and TCP port 22 from the SSH bastion security group (for administrator access). The following table provides an example of rules you can use to configure the web application server security group.
MySQL database server security group
Similarly, we want to ensure that the MySQL database server is only accessible from the EC2 instances hosting the web application. To achieve this, we assign MySQL database server instances private IP addresses from the back-end private subnet IP address range and configure the MySQL database server security group to allow TCP port 3306 connections only from EC2 instances in the web application server security group. The following table provides an example of rules you can use to configure the MySQL database server security group.
Configuring network ACLs
Network ACLs provide an additional layer of defense for your VPC by allowing you to create statelessallow and deny rules that are processed in numeric order, much like a traditional firewall. This is useful for allowing or denying traffic at a subnet level, as opposed to security groups that allow traffic at an EC2 instance level. For example, if you have identified Internet IP addresses or ranges that are unwanted or potentially abusive, you can block them from reaching your application with a deny rule. You can decide whether to create rules that target an entire IP subnet or an individual IP address. The following table is an example of a custom network ACL that complements the security groups discussed earlier in this post. This can be applied to the public subnet. For more information, see Network ACLs. (For more information about how to select the appropriate ephemeral port range [from 1024-65535] in the network ACL, see Ephemeral Ports.)
Other best practices to consider
Configuring security groups and network ACLs in Amazon VPC is an effective tool to help reduce the attack surface of your applications. The approaches may seem similar, but each has an important role in surface area reduction. This is especially important in a DDoS context because security groups allow you to define the traffic that will be allowed access to resources within your applications, and network ACLs allow you to define the port, protocol, and source of traffic that should be explicitly denied at the subnet level. Now that you’ve configured two key security features of VPC, you should consider other components of your DDoS-resilient architecture, such as monitoring with Amazon CloudWatch and scaling with Amazon CloudFront,Amazon Route 53, Elastic Load Balancing, and Auto Scaling.
I hope that this blog post will help you build more secure applications on AWS. If you have any questions about how to reduce your attack surface with Amazon VPC, please post a comment below.
- Jeffrey Lyon, AWS Edge Services
I believe I am a victim of this ddos hacked thing , but I'm not a tech genius just a facebook and twitter activist and believe that my daughter of 8 year old has been getting contacted as well , but as I said I'm not privy to this sort of technology although I know its possible.
Posted by kevinmoody on August 26, 2015 2:05:30 PM PDT
Thank you Jeffery for the great Article. My team just did the similar architecture. I think using security groups for source and destination in rules is very good idea. If we want to connect to our own data center from web app server layer, what would you recommend?
Posted by s.sandhu on August 27, 2015 7:47:28 PM PDT
Hello, Thank you for your feedback. One of the best practices that we recommend is using Amazon CloudFront to distribute content to end users. Amazon CloudFront only accepts well-formed connections and many types of invalid traffic, like UDP floods and SYN floods, do not reach your application. With Amazon CloudFront, you can specify an origin on AWS or a custom web server. You can learn more about security in AWS, to include our AWS Best Practices for DDoS Resiliency, at the AWS Security Center (http://aws.amazon.com/security). Thanks, Jeff