Protecting Origin for Exclusive CloudFront access: Best Practices

Question

A customer wants to protect his origin server (**ALB** + **EC2**) of a **CloudFront** distribution, allowing it to receive only the traffic coming from the CloudFront distribution, and preventing it to be accessible by other sources that basically would bypass CloudFront. The customer might consider to use **WAF**.

The **approaches** we discussed are basically **3**:

1. Given that the ALB has his Security Group (SG), use a Lambda function to update a SG rule that only allows requests coming from CloudFront Edge Locations service IP range. This IP range could be modified every time a new Edge Location is added/removed to the global Amazon PoPs. Therefore an SNS topic can be used in order to trigger the automatic editing of the rule in the SG (with the updated IP range), through the Lambda function. This is well described in this [blog post][2];

2. Use the same setup of solution 1, with WAF between the CloudFront distribution and the ALB (users -> CF -> WAF -> ALB -> compute_service). The difference with solution 1 would be that instead of updating the ALB Security Group rule, the Lambda function would update WAF rules based on [IP Set][3].

3. Just use WAF between the CloudFront Distribution (users -> CF -> WAF -> ALB -> compute_service), and configure CF such that it [adds a custom secret header to origin requests][4] in order to identify all the requests coming from CloudFront and set up WAF such that only allows requests with that specific custom header, denying all the other requests to the origin (ALB). There is an **external** [blog post][5] that actually uses this approach, but not actually well documented in AWS doc/blog as a possible use case.

My **questions**/**doubts** are:

1. Which of the following approaches do you think is the best option in terms of configuration effort/operational efficiency? My idea is that the 1st is the more old-fashion, even if it has the advantages of being cost-efficient (since no WAF is used and SGs are free) and well proofed. I would move towards the 3rd approach, if possible.

2. Regarding the **3rd approach**, is it a best practice to use WAF just for this task (to only allow requests coming from CloudFront)? I know that WAF fits both with CloudFront and with ALB, but in the most part of architectural patterns I've seen so far, WAF is always in front of a CloudFront (users -> WAF -> CF -> ALB -> compute_service).

3. Regarding the **3rd approach**, is it secure to use a custom header that is basically a constant string over time? Or should I disregard this, as at the end of the day we encrypt it through HTTPS?

Thanks for sharing your perspective on that.

[2]: https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/
  [3]: https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-ipset-match.html
  [4]: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html
  [5]: https://www.metaltoad.com/blog/how-to-protect-origin-with-aws-waf-shield

Accepted Answer

I think the problem (though it may have changed recently) with Security Groups is that it couldn't handle all the CloudFront IP addresses. Therefore, using WAF was the preferred solution.

Whichever you use to limit access based on IP addresses, the IP addresses are used by all CloudFront distributions, so this protection on its own is not enough - I could create my own distribution and point it to your ALB. Therefore you do need to use a shared secret in a custom header to origin. As WAF support the ability to protect based on the contents of a header, you might as well use it to restrict access by IP addresses as well. If you're using a custom header, do you need IP protection? Perhaps not, but it's best to have defence in depth. I wrote a [blog post][1] a while back that, while it relates to using MediaStore as the origin, describes using a shared secret to restrict access to a CloudFront distribution.

It would also be good practice to rotate the shared secret in the custom header, though I don't know of a specific blog post or documentation to do that. This could be achieved by using a Lambda function running on a schedule to update the CloudFront configuration and WAF (making sure that you have a suitable window where both the old and new secret is accepted).

[1]: https://aws.amazon.com/blogs/media/using-amazon-cloudfront-and-aws-media-services/

Protecting Origin for Exclusive CloudFront access: Best Practices

Relevant content