Understanding Network Access Control Lists and Security Groups in AWS

In an article I published exactly a year ago, I wrote about VPCs and subnets in the AWS cloud and all one needs to know about these foundational AWS networking concepts. However, I did not go into the details of Network Access Control Lists (NACLs) and Security Groups (SGs). This doesn't mean the significance of these core aspects of AWS networking is lost on me. The purpose of this write up is to provide you with an in depth examination of Security Groups and NACLs. I recommend reading the article I wrote on VPCs and subnets before coming back to this one. If you went to read that, welcome back and without further ado let's get to business!

Network Access Control Lists

As we all know, security is a very important component of your AWS infrastructure and it is something that should always be top of mind when you are implementing solutions in the cloud.

NACLs are security filters that control the flow of traffic in and out of a subnet. When you create a subnet in the AWS cloud, a default NACL is associated with it if you didn't explicitly configure one while creating the subnet. These defaults NACLs allow all inbound and outbound to and from the subnet respectively. Because of this, they pose a security threat. To eliminate this security threat you can configure your NACL by adding rules to it. These rules could either be inbound or outbound.

Each inbound rule added to you NACL is made up of the following fields:

• A Rule number (Rule #) which determines the order in which the rules are evaluated.

• A Type field which determines the type of inbound traffic you want to allow or deny into the subnets the NACL is associated with.

• A Protocol field which determines the protocols used by the inbound traffic.

• Port range field which determines the range of ports to be used by the inbound traffic.

• Source which determines the source IP address range of the inbound traffic and

• An Allow / Deny field which determines whether the rule is allowing or denying the inbound traffic.

The image below shows a visual example of NACL inbound rules:

For outbound rules, all the fields are the same except for the Source field which is replaced with a Destination field determining the destination of outbound traffic from the subnets associated with the NACL.

NACLs are stateless. This means any response traffic generated from a request needs to be explicitly allowed else they are a denied implicitly. To put it simply, when traffic is allowed from particular source with a particular port range, type and protocol, the return traffic to that source is not allowed by default and you have explicitly allow it.

Noteworthy: A subnet can only have one NACL associated with it at any point in time but a NACL can be associated with multiple subnets at a time.

Now let's move on to security groups.

Security Groups

Security Groups are much like NACLs with a few difference such as: SGs control the flow of traffic in and out of an EC2 instance, they are stateful unlike NACLs which are stateless. Let's unpack each of these aspects in more detail.

Security Groups also act as traffic filters but rather than working at the subnet level like NACLs do, they work at the instance level. They have similar fields to NACL rules except for the fact that there is no Rule # and Allow / Deny fields. Since SG rules do not have rule numbers to determine the order which they are evaluated, all the rules in a security group have to be evaluated before a decision is made on the flow of traffic.

SGs have only allow rules implying that any traffic that is not allowed by a security group rule is denied. Because security groups are stateful, any traffic allowed into an instance, the return traffic is allowed by default. The image below shows some examples of security group rules.

As a final recap, NACLs filter traffic at the subnet level and they are stateless while SGs filter traffic at the instance level and they are stateful.

Conclusion

We have seen how security groups and NACLs work together to control the flow of traffic into and out of your AWS environment. Configuring NACLs and SGs is your responsibility as stipulated by the AWS Shared Responsibility Model so learning how to use them properly will greatly improve the security posture of your AWS infrastructure. This is where this article ends but it shouldn't be where you end your journey of learning about Security Groups and NACLs. Good luck in all your endeavors.