5 ms·

so i keep having people froth at the mouth about how it is more secure to use VPC endpoints to communicate to AWS services. is there any practical mechanism by

so i keep having people froth at the mouth about how it is more secure to use VPC endpoints to communicate to AWS services. is there any practical mechanism by which not using the VPC endpoints can be insecure, which does not also affect VPC endpoints? i usually get some hand waving about man in the middle attacks, but i figure if you can insert that into an AWS data center you can probably just see all the VPC internal traffic anyways. and one should be using TLS to talk to the services anyways.

spydum 4y ago
If you don't use vpc endpoints, usually you end up having to open network traffic to all of a particular aws service, not just yours. This means as an attacker, I can also go spin up (s3/lambda/etc) and if your app was vulnerable in some way, I could exfil data to those aws services (or leverage them in RFI/CSRF/other attacks) in a way that shouldn't be possible.
- sigstoat 4y ago
  > you end up having to open network traffic to all of a particular aws service, not just yours > I could exfil data to those aws services I don't think any of the VPC endpoints have any restrictions on them; that is, once I've made an S3 endpoint in my VPC, it can be used to access any bucket. So... it seems like it could be used just as easily to exfiltrate data?
  - cldellow 4y ago
    I haven't done it, but the docs seem to imply that some VPC endpoints, including S3, can support the usual policy documents to describe which actions/principals/resources are permitted: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#edit-vpc-endpoint-policy-s3 https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpo...
    - different_sort 4y ago
      That is indeed the case.
  - Galanwe 4y ago
    > once I've made an S3 endpoint in my VPC, it can be used to access any bucket. So... it seems like it could be used just as easily to exfiltrate data? On the contrary, and that is one of the strong points of using VPC endpoints. You can whitelister the buckets that are accessible through the endpoints, which means it is in fact the only way to prevent data exfiltration.
Galanwe 4y ago
> is there any practical mechanism by which not using the VPC endpoints can be insecure, Hum, yes. If you're not using VPC endpoints, basically you're routing all your AWS traffic to the open internet. Not only is it wasteful and slow, but that also means you have to open free lunch internet egress on your instances, or implement some convoluted DNS based firewalling. Using VPC endpoints also allows you to capture AWS service traffic and apply policy on it, such as whitelisting which buckets are accessible, thus avoiding internal data leaks. Honestly there is just no argument for _not_ using VPC endpoints. Even on a purely architectural point of view, having you AWS traffic being routed out to internet just to get back in makes no sense. If you are still unconvinced, the pricing argument of course still stands.
- sigstoat 4y ago
  > If you're not using VPC endpoints, basically you're routing all your AWS traffic to the open internet. yes this is what i normally hear. but by “the open internet” you mean “some other spot in the AWS data center”. what’s the risk here? somebody is going to slip some bad routes into AWS over BGP? and then also fake the SSL certs? this seems like some mission impossible stuff. > Honestly there is just no argument for _not_ using VPC endpoints. unless something has changed in the last three months they’re not available for all services. would you advocate against using those services? > If you are still unconvinced, the pricing argument of course still stands. sure that and the exfiltration argument are reasonable enough. thanks for response
  - Galanwe 4y ago
    > some other spot in the AWS data center Well I can only guess so much of the underlying egress internet routing of AWS. At worst, if no explicit region is specified, it will reach the global aws endpoint through internet which is likely in a complete different part of the world than where you are, redirect to the local endpoint, and back. > what’s the risk here? Minimal, though I'm not sure the question is really relevant. It's a bit as if you design a house with no internal doors, and you have to get out the window and back through the front door whenever you want to change room. I guess that wouldn't make you house less safe, though it's definitely a design that smells weird. There is a real security point to make on the fact that it forces you to open access to egress internet though, and that is not to be taken lightly. There is no reason to allow a server full egress internet, and accessing AWS through internet basically forces you to do so, or leaves you implementing DNS based firewalling which is error prone, less secure, and overall a pain to setup. > unless something has changed in the last three months they’re not available for all services. would you advocate against using those services? No. Though I would (and do) strongly recommend implementing either DNS based firewalling, or a dynamic ruleset based on AWS ip ranges (they publish it as JSON).

spydum 4y ago

If you don't use vpc endpoints, usually you end up having to open network traffic to all of a particular aws service, not just yours. This means as an attacker, I can also go spin up (s3/lambda/etc) and if your app was vulnerable in some way, I could exfil data to those aws services (or leverage them in RFI/CSRF/other attacks) in a way that shouldn't be possible.

sigstoat 4y ago
> you end up having to open network traffic to all of a particular aws service, not just yours > I could exfil data to those aws services I don't think any of the VPC endpoints have any restrictions on them; that is, once I've made an S3 endpoint in my VPC, it can be used to access any bucket. So... it seems like it could be used just as easily to exfiltrate data?
- cldellow 4y ago
  I haven't done it, but the docs seem to imply that some VPC endpoints, including S3, can support the usual policy documents to describe which actions/principals/resources are permitted: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#edit-vpc-endpoint-policy-s3 https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpo...
  - different_sort 4y ago
    That is indeed the case.
- Galanwe 4y ago
  > once I've made an S3 endpoint in my VPC, it can be used to access any bucket. So... it seems like it could be used just as easily to exfiltrate data? On the contrary, and that is one of the strong points of using VPC endpoints. You can whitelister the buckets that are accessible through the endpoints, which means it is in fact the only way to prevent data exfiltration.

Galanwe 4y ago

> is there any practical mechanism by which not using the VPC endpoints can be insecure, Hum, yes. If you're not using VPC endpoints, basically you're routing all your AWS traffic to the open internet. Not only is it wasteful and slow, but that also means you have to open free lunch internet egress on your instances, or implement some convoluted DNS based firewalling. Using VPC endpoints also allows you to capture AWS service traffic and apply policy on it, such as whitelisting which buckets are accessible, thus avoiding internal data leaks. Honestly there is just no argument for _not_ using VPC endpoints. Even on a purely architectural point of view, having you AWS traffic being routed out to internet just to get back in makes no sense. If you are still unconvinced, the pricing argument of course still stands.

sigstoat 4y ago
> If you're not using VPC endpoints, basically you're routing all your AWS traffic to the open internet. yes this is what i normally hear. but by “the open internet” you mean “some other spot in the AWS data center”. what’s the risk here? somebody is going to slip some bad routes into AWS over BGP? and then also fake the SSL certs? this seems like some mission impossible stuff. > Honestly there is just no argument for _not_ using VPC endpoints. unless something has changed in the last three months they’re not available for all services. would you advocate against using those services? > If you are still unconvinced, the pricing argument of course still stands. sure that and the exfiltration argument are reasonable enough. thanks for response
- Galanwe 4y ago
  > some other spot in the AWS data center Well I can only guess so much of the underlying egress internet routing of AWS. At worst, if no explicit region is specified, it will reach the global aws endpoint through internet which is likely in a complete different part of the world than where you are, redirect to the local endpoint, and back. > what’s the risk here? Minimal, though I'm not sure the question is really relevant. It's a bit as if you design a house with no internal doors, and you have to get out the window and back through the front door whenever you want to change room. I guess that wouldn't make you house less safe, though it's definitely a design that smells weird. There is a real security point to make on the fact that it forces you to open access to egress internet though, and that is not to be taken lightly. There is no reason to allow a server full egress internet, and accessing AWS through internet basically forces you to do so, or leaves you implementing DNS based firewalling which is error prone, less secure, and overall a pain to setup. > unless something has changed in the last three months they’re not available for all services. would you advocate against using those services? No. Though I would (and do) strongly recommend implementing either DNS based firewalling, or a dynamic ruleset based on AWS ip ranges (they publish it as JSON).