Going from client > route 53 address > cloudfront > custom ec2 origin

Hello, I want to go fronm

client > route 53 address > cloudfront > custom ec2 origin

But without the clients being able to access to custom ec2 origin directly. Any pointers?

You can use a prefix list on the security group. https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html

Thank you for responding. So I add the prefix list to the ec2 origin security group, but how will the response get back to the client? As I understand it, this will allow cloudfront to the custom ec2 origin but responses back to the client will still be blocked

Security groups are stateful. Responses to incoming requests are permitted. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html

Thank you for this. I have set it on my sg and I can see requests coming through on nginx on my ec2 instance from cloudfront, but the request ‘times out’ with took too long to respond

It is odd as I know you have mentioned the sg is stateful, and it is seeing the requests on nginx, just it seems the request is timing out

When I open the sg up to the world it works immediately

You know I think I have it, when the response is returned it is a 302, which then redirects me to the origin FQDN on the ec2 instance, but of course as it has the sg to only allow cloudfront, it blocks it…

Thank you for your advice

Prefix list isn’t a security strategy. You can’t prevent access to your EC2 origins, end of story, these are public, CF only access public servers (with the exception of S3)

Are you opposed to putting and ALB in between cloudfront > ALB > ec2 origin

An old post, but this touches on keeping the SG in sync with CF ips: https://aws.amazon.com/blogs/security/how-to-automatically-update-your-security-groups-for-amazon-cloudfront-and-aws-waf-by-using-aws-lambda/

But that’s bad advice because anyone with a CF can hit your origin, so we should stop suggesting to use SGs for this. And ALB is the best infra level security for your EC2, and zero-trust user auth is the best app level security.

It’s not “bad advice”. Yes, it’s not perfect because anyone could point their CF at your endpoint, but then you can find issues with pretty much any solution. It’s always a trade-off and good security always involves layers of protection.

On the spectrum from 1-10, with 10 being perfect, and 1 being passwords in plaintext, this is a 2.

Is that your opinion? OR do you have evidence to back that up

I am also going to georestrict my distribution which is the main point I wanted to do this

If you want to georestrict, you can attach the WAF directly to an ALB and put that in front of your instance. It’s easy to share why I think that is a 2, because, it’s a joke to circumvent, AWS attaches CF headers to the response, once I see that I can spin up my own CDN and pwn your service.

Nothing is 100% secure, its about adding obstacles to make an attacker work a bit rather than having nothing. 2 is better than a 1 you might say

But it literally doesn’t add an obstacle