diff --git a/_posts/2023-11-26-preventing-accidental-internet-exposure-of-aws-resources-part-1-vpc.md b/_posts/2023-11-26-preventing-accidental-internet-exposure-of-aws-resources-part-1-vpc.md index 6eaa938..25d0c87 100644 --- a/_posts/2023-11-26-preventing-accidental-internet-exposure-of-aws-resources-part-1-vpc.md +++ b/_posts/2023-11-26-preventing-accidental-internet-exposure-of-aws-resources-part-1-vpc.md @@ -98,7 +98,9 @@ See [the FAQ](#can-you-walk-through-the-cost-details-around-option-1) for a verb PrivateLink ([and VPC Peering](#why-is-vpc-peering-not-a-straightforward-option)) are mostly non-options. -The reason for this is as follows. When you make an interface VPC endpoint with AWS PrivateLink, a "[requester-managed network interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requester-managed-eni.html)" is created. The "requester" is AWS, as you can see by the mysterious `"727180483921"` account ID. If you try to disable "[Source/destination checking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics)" (which ensures that the ENI is either the source or the destination of any traffic it receives), you will not be able to since AWS manages it. Thus, traffic destined for the Internet but sent to that network interface is dropped before it travels cross-account. +The reason for this is as follows. When you make an interface VPC endpoint with AWS PrivateLink, a "[requester-managed network interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requester-managed-eni.html)" is created with "[source/destination checking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics)" enabled.[^84415] Due to this check, traffic destined for the Internet but sent to that network interface is dropped before it travels cross-account. + +[^84415]: The "requester" is AWS, as you can see by [the mysterious `"727180483921"` account ID](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requester-managed-eni.html). Since you do not manage it, you cannot disable the [source/destination checking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#eni-basics) However, suppose you are willing to do a lot of heavy lifting that is orthogonal to AWS primitives. diff --git a/_site/2023/11/26/preventing-accidental-internet-exposure-of-aws-resources-part-1-vpc.html b/_site/2023/11/26/preventing-accidental-internet-exposure-of-aws-resources-part-1-vpc.html index b9284cd..5e43170 100644 --- a/_site/2023/11/26/preventing-accidental-internet-exposure-of-aws-resources-part-1-vpc.html +++ b/_site/2023/11/26/preventing-accidental-internet-exposure-of-aws-resources-part-1-vpc.html @@ -226,7 +226,7 @@
PrivateLink (and VPC Peering) are mostly non-options.
-The reason for this is as follows. When you make an interface VPC endpoint with AWS PrivateLink, a “requester-managed network interface” is created. The “requester” is AWS, as you can see by the mysterious "727180483921"
account ID. If you try to disable “Source/destination checking” (which ensures that the ENI is either the source or the destination of any traffic it receives), you will not be able to since AWS manages it. Thus, traffic destined for the Internet but sent to that network interface is dropped before it travels cross-account.
The reason for this is as follows. When you make an interface VPC endpoint with AWS PrivateLink, a “requester-managed network interface” is created with “source/destination checking” enabled.3 Due to this check, traffic destined for the Internet but sent to that network interface is dropped before it travels cross-account.
However, suppose you are willing to do a lot of heavy lifting that is orthogonal to AWS primitives.
@@ -237,14 +237,14 @@iptables
and a proxy are too heavyweight.)With that said, AWS does not have a primitive to perform Egress filtering,5 so you will eventually have to implement Egress filtering via a proxy or a firewall. Therefore, in non-sandbox accounts, you could go with this option.
+With that said, AWS does not have a primitive to perform Egress filtering,6 so you will eventually have to implement Egress filtering via a proxy or a firewall. Therefore, in non-sandbox accounts, you could go with this option.
GWLB is a service intended to enable the deployment of virtual appliances in the form of firewalls, intrusion detection/prevention systems, and deep packet inspection systems. The appliances get sent the original traffic encapsulated via the Geneve protocol.6
+GWLB is a service intended to enable the deployment of virtual appliances in the form of firewalls, intrusion detection/prevention systems, and deep packet inspection systems. The appliances get sent the original traffic encapsulated via the Geneve protocol.7
In the previous section, I wrote that PrivateLink was mostly a non-option because interface endpoint ENIs have “Source/destination checking” enabled.
@@ -255,11 +255,11 @@Regarding specific vendors, DiscrimiNAT seems much easier to configure compared to e.g. Palo Alto Firewall,7 as all you do is add FQDNs to security group descriptions. However, DiscrimiNAT would need to add subaccount support for the diagram above to function to read the security groups in the ‘spoke’ account.
+Regarding specific vendors, DiscrimiNAT seems much easier to configure compared to e.g. Palo Alto Firewall,8 as all you do is add FQDNs to security group descriptions. However, DiscrimiNAT would need to add subaccount support for the diagram above to function to read the security groups in the ‘spoke’ account.
VPC Sharing is a tempting, simple, and little-known option.8
+VPC Sharing is a tempting, simple, and little-known option.9
You can simply make a VPC in your networking account and share private subnets to subaccounts.
@@ -267,10 +267,10 @@The main problem is that there will still be an Internet Gateway in the VPC.
-Unless you also used one of the other options, like a TGW:9 +
Unless you also used one of the other options, like a TGW:10
-Assuming you don’t want to pay for TGW, you can ban actions that would explicitly give an instance in a private subnet a public IP.10
+Assuming you don’t want to pay for TGW, you can ban actions that would explicitly give an instance in a private subnet a public IP.11
These actions are ec2:RunInstances
with the "ec2:AssociatePublicIpAddress
condition key set to "true"
and EIP-related IAM actions such as ec2:AssociateAddress
.
If you are like most AWS customers:
* = YMMV
-** = URL path is only available to filter on if MITM is performed.12
+** = URL path is only available to filter on if MITM is performed.13
As for why it cannot respond to traffic, that is more interesting!
-For a private subnet, the route table – which is only consulted for outgoing traffic – will have a path to a NAT Gateway, not the IGW. So response packets will reach the NAT Gateway, which does connection/flow tracking,13 and get dropped because there is no existing connection.14
+For a private subnet, the route table – which is only consulted for outgoing traffic – will have a path to a NAT Gateway, not the IGW. So response packets will reach the NAT Gateway, which does connection/flow tracking,14 and get dropped because there is no existing connection.15
If the EC2 has UDP ports open, an attacker can receive responses, and you have a security problem. (A NACL will not help, as an Ingress deny rule blocking the Internet from hitting the EC2 will also block responses from the Internet to Egress Traffic.)
Let me know how it goes limiting your Internet-exposed attack surface in an easy to understand, secure-by-default way.15
+Let me know how it goes limiting your Internet-exposed attack surface in an easy to understand, secure-by-default way.16
You might still get breached, but hopefully in a more interesting way.
@@ -584,6 +584,9 @@Some companies with agents meant to be deployed on EC2s do not offer a VPC endpoint or charge an exorbitant fee to use one; perhaps a wall of shame can be made. Chime mentioned: "Although our vendor offers PrivateLink, they have also chosen to monetize it, charging so much for access to the feature that it was not a viable option."
↩
The “requester” is AWS, as you can see by the mysterious "727180483921"
account ID. Since you do not manage it, you cannot disable the source/destination checking ↩
Flow log limitations do not state “Internet-bound traffic sent to a peering connection” or “Internet-bound traffic sent to a VPC interface endpoint.” under The following types of traffic are not logged:
. After testing, I believe these are likely omitted due to not being a proper use-case. ↩