2

My Setup

I have Elastic Beanstalk application, with a public LoadBalancer and public IPs on EC2. The application is behind CloudFront, which is protected with AWS WAF from different attacks I am experiencing now. Route 53 forwards DNS queries to the CloudFront.

My Problem

WAF is only on the CloudFront. There is still Elastic Beanstalk public dns name, elastic load balancer public dns name, and EC2 instance public IP. Attackers are hitting them, and bypassing the WAF.

My Request

I don't need anything other than the CloudFront to be exposed to the internet. How do I remove all public DNS's and IP's from all, or at least some, of these resources, and still have it working. Ideally CloudFront would forward requests over inner Amazon domain.

What I tried

I tried setting ELB to private in BeanStalk Network Configuration tab, but it failed. When setting Public IP address to false, it just stops working with error 502

kenlukas
  • 2,886
  • 2
  • 14
  • 25
f.khantsis
  • 319
  • 1
  • 5
  • 13

1 Answers1

3

You need to change your security groups so only CloudFront IPs can contact the server. You can also whitelist your own IP address. They key is to only let selected addresses in.

This AWS sample code will update your security group as CloudFront IP addresses change. I suspect that it will do the initial setup for you once you deploy the function and create the security groups it requires. Because of the number of IP ranges CloudFront has it uses four security groups, which is fine, you can associate them all with a load balancer and / or EC2 instance.

You can download the AWS IP addresses here, filter on CLOUDFRONT for those IPs, if you want to do it manually. Beware the IP address ranges change, which would leave some CloudFront nodes unable to contact your server if you do this manually.

Note that you can't use NACLs as they have too low a limit. Interesting thing though, NACLs run on the instance hardware (maybe the Nitro card now) but if you're under DDOS the NACLs get pushed out to CloudFront to reject the traffic at the edge. I believe security groups also run on the instance hardware or in the nitro card, but managed by AWS of course.

Tim
  • 30,383
  • 6
  • 47
  • 77
  • *"but if you're under DDOS the NACLs get pushed out to CloudFront to reject the traffic at the edge."* Wat? – Michael - sqlbot Dec 14 '19 at 02:02
  • I read that in the AWS Shield documentation a while back @Michael-sqlbot . I'll find it some time and send you the link. – Tim Dec 14 '19 at 04:30
  • @Michael-sqlbot this information used to be on the AWS Shield features page, but doesn't seem to be there anymore. I'm 95% sure I didn't just make this up. This is an implementation detail so maybe they decided not to share it any more. It makes sense that NACLs that run on an instance could be pushed to the edge during an attack. – Tim Dec 14 '19 at 06:37
  • You might have been thinking of *"AWS Shield Advanced also ensures that, during a DDoS attack, all your Amazon VPC Network Access Control Lists (ACLs) are automatically enforced at the border of the AWS network giving you access to additional bandwidth and scrubbing capacity..."* but that's the regional border, rather than the edge network. CloudFront isn't integrated with VPC so while it can do mitigations, they wouldn't be NACL-based. – Michael - sqlbot Dec 14 '19 at 12:28
  • Could be that. If I find the source written down in any of my documentation I'll fire it through, and I'll ask one of the AWS guys next time I see them. – Tim Dec 15 '19 at 08:07