So, you’ve got this shiny new VPC and a fancy new application configured on your EC2 servers ready to go. This application is only accessible from your computer, which is great for security, but that’s not going to cut it for the board; you need your users to be able to access it! So, what’s the easiest way to do this?
Stateless vs. Stateful
A VPC has two primary security components: Security Groups and Network Access Control Lists, or NACLs. Before we dive into the rules required for a secure environment, we need to first go over two very important concepts, stateless and stateful.
A stateful firewall is one that maintains a connection’s “state”. This means that if you have all traffic allowed in one direction, but no traffic is allowed in the other, the firewall will still allow return entry of an established connection.
A stateless firewall is one that maintains no connection state. If traffic is allowed in one direction but not the other, return traffic will be blocked. This can be quite aggravating for someone trying to secure their environment!
Let’s go over these concepts with a mail service metaphor:
If you send a message via a postal service, you place the stamp on the message and you send it to the postal service to handle. This postal service then sends the message to the intended recipient. If that recipient wishes to send a message back to you, the recipient is required to purchase another stamp for their message. This is similar to a stateless firewall. The traffic most be authorized in both directions for it to be allowed.
A stateful firewall is like sending a letter with prepaid postage. If you send a letter with prepaid return postage to a recipient, that recipient can just place the return message in the envelope and that envelope is forwarded back to you without any type of authentication. Since you have authorized the communication between the two of you, the letter can pass in both directions.
Ok, so now we’ve explained that, let’s move on to how this is accomplished and what needs to be allowed to do this effectively!
Security Group vs. NACL
Security Groups are stateful, which means only one rule is needed for incoming and outgoing traffic. As long as one direction of traffic is allowed, the other will be automatically allowed as well. Security Groups are “default deny”. This means that if there are no rules, NOTHING is allowed. Remember this; it is very important! If you do not add a rule to allow the traffic, you will not be able to access your instance. Security Groups are also applied directly to the instances themselves, not to the VPC. So the Security Group is great for fine tuning your permissions based on instance requirements.
NACLs and Ephemeral Ports:
NACLs are stateless. This means that you are required to have a rule for inbound AND outbound traffic. So, if you want to allow your EC2 instance to serve HTTP traffic, you will need to allow port 80 inbound and ports 1024 – 65535 outbound. Wait, what?! You might be asking where 1024 – 65535 came from. The ports 1024 – 65535 are called the “ephemeral ports”. These ports are randomly selected to allow return traffic for a request. So, if a request comes to the server on port 80, the request also specifies a random port between 1024 – 65535 for the return traffic. This causes a lot of grief for many new admins and can cause them to just open all ports to their environment. Please, don’t open all ports to your environment!
Typically, a public webserver that requires access to the internet for updates and to make web requests will require the ephemeral port range to be allowed inbound and outbound. If you are updating your webservers using another method than direct downloading, you only need to allow the ephemeral port range to be allowed outbound. Here is an example of a NACL with the ephemeral ports allowed outbound:
For the Security Group that controls access to a webserver, you only need to allow port 80. The stateful nature of the security group handles the ephemeral port requirement automatically. When the request comes in, it accesses the server on port 80, but also specifies a port for the return traffic. This port is one of the ports in the ephemeral range. The stateful Security Group automatically allows the return traffic on this port.
The concept of ephemeral ports can get fairly complicated, but I am going to keep this guide at a high level to help you get up and running quickly!
Things to Consider
Based on the information above, you should be able to start coming up with a security plan for your VPC. Here are some points to consider when developing your plan:
1. Never just allow “all” inbound or outbound because it’s easy; always use the ephemeral ports for return traffic!
2. Use Security Groups for instance-based security. If it’s a webserver, configure a rule to allow ports 80/443 inbound to your webserver.
3. Use NACLs for whole subnet security. This is the best place for a universal block list to block malicious traffic.
4. Remember, if you just rely on Security Groups, the stateful nature of a Security Group can become a security hole. If a malicious admin of your network can initiate outbound connectivity with a malicious server, that server will be allowed to send return traffic to your server. Make sure you use NACLs as well as another line of defense.
5. Remember, for your server to communicate with the internet, you don’t just need ports 80/443. You may also need DNS port 53 as well. SSH requires port 22. And all of these will require the ephemeral ports 1024 – 65535 for return traffic.
6. You can limit the ephemeral ports on your server to accept a lower range, but AWS services such as NAT and Elastic Loadbalancers require ports 1024 – 65535.
7. Test your security plans! After you secure your environment, make sure you attempt to access your resources from locations that should be blocked to ensure you have configured your environment properly. Make sure you test inbound and outbound connectivity. If you have created a “white list”, for example, remove your address from the list and ensure you are unable to access. If you are still able to access, you may have the subnet associated with the wrong NACL or the resource with the wrong security group. This can be a very costly oversight!
Hopefully, these tips will help you set up a more secure and more reliable security plan. The knowledge of NACLs and Security Groups will prove critical to the deployment of successful applications. So, what are you waiting for? Get out there and secure your VPC!