Introduction
Virtual Private Clouds or VPCs in AWS provide a way to isolate a network in a specific AWS account. At the end of the day however, there's a good chance that external network traffic will be occurring in the VPC. This means extra setup may be required to further secure a VPC environment. Let's take a look at a few ways to do that.
Fundamentals
But first, time to explain a few networking basics and give insight as to how things work behind the scenes. A decent amount of network communication will be occurring with the TCP/IP protocol. This works off of client-server communication. On a basic level you need a client IP, client port, server IP, and server port. Now assuming a web server being connected to on port 80, what happens with the client?
It turns out that operating systems have something called ephemeral ports. It's essentially a range of ports used by the operating system for cases where it's not the server. Here's an example on windows:
In this case the Dropbox client is reaching out to an SSL port on their servers and the local port is 49694.
NACL
Now at the subnet level there are Network Access Control Lists or NACLs which can operate on this low level. In order for most things to work you'll need ephemeral ports allowed for both inbound and outbound traffic. You also have to know what the ephemeral port range is as it can be adjusted or vary depending on the operating system. Unless you're an extremely high compliance setting or have network requirements for it. Due to requiring separate incoming and outgoing traffic settings NACLs are often refereed to as stateless firewalls.
Security Groups
Now security groups on the other hand are stateful firewalls. In other words it tracks a connection over its lifetime and you only have to care if the origin is incoming or outgoing. After that it keeps tabs on the traffic and handles things like allowing the related ephemeral port for a traffic session for you automatically. This is nice security wise at it avoids keeping an entire port range open.
In terms of threat models communication starting from an instance is generally assumed to be secure so most security groups allow all outbound traffic. Trying to lock down outgoing ports tends to be tedious as you have to account for DNS, HTTP/HTTPS (system packages, API connections), and sometimes even FTP.
Security groups can further guard your traffic by restricting source and destinations. This can be an IP range/single IP or even another security group. Note that because tracking connections has a network performance cost on it you generally don't see AWS allowing your quota to go beyond the hard limit.
Application Firewalls
This is a contextual firewall that understands more higher level protocols that run on lower level ones. Such examples include HTTP and HTTPS. Such firewalls guard against things like SQL injection, XSS injection, region based blocking, etc. This is something you'll generally see used in web services or REST APIs. AWS has the Web Application Firewall (WAF) as a managed service for this.
Routing
This is more of a minor protection system but still one nonetheless. Not having a route to an internet gateway and no NAT gateway essentially means traffic can only occur within the VPC and resources inside won't be able to connect with the outside world. Also interesting to note that the underlying routing that powers this is one of the .1 restricted IPs in a subnet.
Any subnet without a route to an internet gateway is a private subnet (yes, even if you name it public subnet). If there is an internet gateway route it's a public subnet. A common use case for this kind of separation is to have something like a load balancer in a public subnet reaching out to resources in a private subnet.
NAT Gateway
This is another "where the traffic is going" type of protection. The main usage for this is mapping private IP addresses in a way that can reach the outside internet. If the outside internet tries to reach the internal VPC it will get dropped as the NAT gateway has no context about the connection. Only when a resource inside the VPC calls out to the internet does a context exist that can potentially allow traffic in.
VPC Endpoints
These are special routing restrictions which are somewhat of contextual form of a NAT gateway. This is used to reach out to specific AWS services via private subnets. This can be used in some cases to completely remove the need for a NAT gateway. Especially Amazon Linux instances as packages are available in S3 meaning the S3 endpoint can be used.
Do note that there are resource permissions for endpoints and a certain way of doing API calls to support them so it's something to take into consideration in making sure people who need access are able to easily. Consider starting with a NAT gateway and gradually transition to VPC endpoints as seen fit. This way if something goes wrong the NAT gateway is there for a fallback.
Conclusion
I hope this guide was useful in clearing up some of the concepts on how network traffic security works with VPCs. Here's a list of additional resources:
- Control traffic to subnets using Network ACLs
- Security Groups
- AWS WAF
- Configure Route Tables
- NAT Gateways
- VPC Endpoints
If you like what you see here I'm open for opportunities
Top comments (0)