Amazon CloudFront VPC Origins was announced on November 20, 2024. Have you had a chance to try it yet? Today, I’d like to explore why this feature is exciting from a security perspective and discuss the challenges it addresses when this feature is not in use.
Why is Amazon CloudFront with VPC Origins exciting?
One of the significant advantages of this feature is the elimination of direct access to ALB or EC2 instances. These resources can now reside in private subnets, making them inaccessible directly from external sources. Access is strictly limited to routes through CloudFront within the same AWS account. Moreover, when WAF is configured on CloudFront, it ensures that origin access cannot bypass the WAF, adding an extra layer of security.
The structure is as shown in the following diagram.
How does it differ from previous setups?
In the architecture shown above, direct access to the ALB was possible if no additional configurations were applied. Similarly, if EC2 instances were deployed in public subnets, they could also be accessed directly. This meant that even with WAF configured on CloudFront, it couldn’t function effectively in this scenario.
To mitigate these risks and block direct access to origins, it was necessary to implement additional measures. These included configuring CloudFront's managed prefix list on the ALB or adding custom headers in CloudFront and validating them at the ALB, as demonstrated below:
*Example: Configuring the managed prefix list.
*Setting and verifying custom headers
While effective, these configurations could be surprisingly tedious. Ideally, CloudFront should have been the sole entry point from the start. The new VPC Origins feature eliminates the need to worry about inadvertent external access caused by misconfigurations.
Limitations of ALB-Based Validation
As mentioned earlier, preventing origin access previously relied on measures like CloudFront's managed prefix list or custom header validation on the ALB. However, these methods could still be bypassed.
Relying solely on CloudFront's managed prefix list is particularly insufficient. If an attacker knows the domain of the ALB, they can reference it from a different AWS account using their own CloudFront distribution. In other words, cross-account access is still possible.
In such cases, requests can still reach the ALB from CloudFront's IP addresses. The problem here is that while the legitimate CloudFront may have WAF configured, the attacker’s CloudFront would not. As a result, even the most robust WAF rules can be bypassed entirely.
For this reason, it’s generally recommended to validate custom headers alongside using the managed prefix list. However, this issue is completely resolved with CloudFront VPC Origins—a game-changing improvement.
How can the ALB domain be exposed?
There are scenarios where the ALB domain becomes discoverable. For instance, when enabling HTTPS access from CloudFront to the ALB, it’s common to assign a subdomain to the ALB. If the domain assigned to CloudFront is example.com, the ALB might use a subdomain like alb.example.com.
In such cases, bypassing the legitimate CloudFront becomes relatively straightforward. Additionally, this information could potentially leak through former employees. Rotating credentials or domains to mitigate such risks can be both time-consuming and cumbersome. This is why VPC Origins, which can guard against such threats, is an incredibly valuable feature.
Conclusion
What do you think? Have you been relying solely on a managed prefix list? As this post highlights, there are potential pitfalls to that approach. Let’s take advantage of CloudFront VPC Origins to build a more secure and robust environment!
Top comments (0)