Infrastructure Protection
Infrastructure protection is one of the areas of the Security Pillar of the AWS Well-Architected Framework. It ensures that systems and services within your workload are protected against unintended and unauthorized access, and potential vulnerabilities. This section outlines recommendations for Distributed Denial of Service (DDoS) resilience and security groups.
Distributed Denial of Service (DDoS) Protection
Every ELB is automatically protected by AWS Shield standard, which is a managed distributed denial of service (DDoS) protection service. AWS Shield Standard provides protection against the most common and frequently occurring infrastructure (layer 3 and 4) attacks, such as SYN/UDP floods, reflection attacks, and others to support high availability of your applications on AWS.
Additionally, Application Load Balancer (ALB) also provides additional protection at layer 7 when using HTTP/HTTPS listeners:
- They will not forward mal-formed HTTP Requests (don’t meet HTTP RFC specification).
- They offer protection against certain types of HTTP slow attacks.
Furthermore, ELB also :
- Reduce the risk of overloading your application by distributing traffic across many target instances.
- Automatically scales based on traffic received, and than can include DDoS traffic. Customers should plan for target scaling, see Plan for Scale.
- Can integrate with Shield Advance
- Can integrate with AWS WAF
References and Further Reading
Consider using AWS Shield Advanced
By default, ALB comes with AWS Shield Standard, which provides all AWS customers with protection against common and most frequently occurring infrastructure (layer 3 and 4) attacks like SYN/UDP floods, reflection attacks, and others to endure high availability of your applications on AWS.
Some customers are regularly targeted by DDoS attacks or may have strict compliance requirements to mitigate attacks. For customers requiring enhanced protection against more sophisticated, frequent and larger attacks, it is suggested enabling AWS Shield Advanced.
AWS Shield Advanced offers advanced attack mitigation, 24x7 access to the Shield Response Team (SRT) and cost protection for scaling.
Best Practice
[ALB, NLB] For DDoS protection against sophisticated, frequent and large attacks enable AWS Shield Advanced.
References and Further Reading
Security Group - Flow tracking (ALB only)
Security groups attached to the ALB use connection tracking to monitor traffic to and from the load balancer. Enhance the DDoS resilience of your load balancer by configuring it to not require EC2 connection tracking. If a security group rule allows TCP or UDP flows from all traffic (0.0.0.0/0 or ::/0) to the listening port (80, 443, etc.), and there is a matching rule in the opposite direction that permits all response traffic (0.0.0.0/0 or ::/0) for all ports (0-65535) on both TCP and UDP, then that flow of traffic is not tracked. This helps to prevent potential negative effects of this feature on the load balancer’s packet throughput, enabling it to detect and scale based on the increase in traffic during a DDoS event.
Example of a security group allowing untracked flows for connections to the port 443:
| Ingress Rule | ||
|---|---|---|
| Protocol | Port | Source |
| TCP | 443 | 0.0.0.0/0 |
| Egress Rule | ||
| Protocol | Port | Destination |
| TCP | 0-65535 | 0.0.0.0/0 |
Best Practice
[ALB, NLB] For enhanced DDoS resilience, allow untracked flows in the security group.
References and Further Reading
Best practices for DDoS mitigation - Elastic Load Balancing (BP6)
Know normal behavior (Traffic pattern, user agents, demographics)
In the event of a DDoS attack, distinguishing between normal and abnormal traffic is crucial. To do so, an understanding of what constitutes ‘normal’ is essential.
To profile typical traffic, consider the following aspects:
- Traffic patterns: What are the typical fluctuations in your traffic throughout the day? For instance, a food delivery company may see a surge in traffic around lunch time and significantly less activity in the early hours of the day.
- User agents: What are the usual user agents connecingt to your load balancer? These could be common web browsers or specific applications.
- Demographics: Where are the clients accessing your load balancer typically located?
Significant deviation from these norms could indicate a potential attack, providing valuable information for mitigation strategies. For example, you could use AWS WAF to block access from some specific countries if you identify unusual traffic from those locations.
Best Practice
[ALB, NLB] For DDoS protection and mitigation, know the normal behaviour of your clients.
References and Further Reading
Monitor your Network Load Balancers
Plan for Scale
Scaling to absorb is one of the mitigation techniques that can be used against a DDoS attack. While the ELB will automatically scale to manage the additional traffic, you will need to configure your targets for the same. Using an Auto Scaling group, you can set scaling policies based on resource usage of your EC2 instance targets, and integrate with ELB to automatically register the new instances with the load balancer.
It’s important to ensure you have enough free IP addresses in both ELB and target subnets to accommodate scaling, and that you have sufficient EC2 quota to launch the desired number of EC2 instances.
Best Practice
[ALB, NLB] For DDoS mitigation, scale the targets to absorb the traffic.
References and Further Reading
What is Amazon EC2 Auto Scaling?
Use Elastic Load Balancing to distribute traffic across the instances in your Auto Scaling group
Consider using AWS WAF (ALB only)
ALB can be integrated with AWS WAF (Web Application Firewall) , allowing you to filter and block requests based on specific request signatures. With WAF, you can create Web Access Control Lists (ACLs) with custom rules, and also utilize AWS Managed rules. For instance, the Amazon IP Reputation List rule group includes rules based on Amazon's internal threat intelligence, allowing for further protection of your applications against potential threats.
Best Practice
[ALB] For DDoS protection, use AWS WAF integrated with ALB for Application layer defense.
When using WAF, implement rate-based rules for better protection against Layer 7 HTTP flood attacks. The blog post "The three most important AWS WAF rate-based rules" is a great reference based on the learnings of AWS’ Shield Response Team (SRT).
Best Practice
[ALB] For DDoS protection, use AWS WAF rate-based rules.
References and Further Reading
Amazon IP Reputation List rule
Consider using Amazon CloudFront or AWS Global Accelerator
ELB can integrate with Amazon CloudFront or AWS Global Accelerator, which can serve as entry points for your web application.
Both Amazon CloudFront and AWS Global Accelerator uses AWS Edge locations. These edge locations provide an additional layer of network infrastructure and can increase your ability to optimize latency and throughput to users, but also enhances your application resilience against DDoS attacks.
Best Practice
[ALB, NLB] For DDoS protection, leverage AWS Edge locations by integrating either CloudFront or Global Accelerator to your load balancer.
References and Further Reading
When using CloudFront, restrict the direct access to the load balancer
Prevent users from bypassing Amazon CloudFront and accessing your load balancer directly. You can configure Amazon CloudFront and your Application Load Balancer to prevent users from directly accessing the load balancer by configuring CloudFront to add a custom HTTP header to the requests that it sends to your origin. In the ALB you then configure a rule to validate the existance of the header.
This allows users to access the Application Load Balancer only through CloudFront, ensuring that you get the benefits of using CloudFront.
Best Practice
[ALB] When using CloudFront, restrict users from directly accessing the Application Load Balancer.
Additionally, you should lock down the security group associated with the load balancer used as the origin, ensuring it accepts connections only from CloudFront.
Best Practice
[ALB, NLB] When using CloudFront, lock down the load balancer security group to accept connections only from CloudFront.
References and Further Reading
Restricting access to Application Load Balancers
Limit access to your origins using the AWS-managed prefix list for Amazon CloudFront
Target Security Groups
To ensure your targets receive traffic exclusively from the load balancer, restrict the security group(s) associated with your targets to accept traffic solely from the load balancer. This can be achieved by setting the load balancer's security group as the source in the ingress rule of the target's security group.
Best Practice
[ALB, NLB] Lock down the target security groups to receive traffic only from the load balancer.