Network Access Control Lists (NACLs) and Security Groups (SGs)

Access Control Lists (ACLs) also known as Network Access Control Lists (NACLs) and Security Groups (SGs) are used to allow or deny inbound or outbound traffic. They are rules that we can set in place to control what’s allowed to flow throughout our networks, so they are an important part of securing our resources and networks.

If it helps, you can think of NACLs as being components of a network firewall configuration that we can use to specify what type of traffic is allowed in or out of our networks, and you can think of SGs as host-based firewalls that control what traffic is allowed to reach a resource, such as a cloud instance. As you’ll see, they’re a little bit different than traditional network and host-based firewalls, but it can help to think of it in those terms if you are more familiar with them.

Let’s take a look at how we could configure both of these security controls in the AWS cloud for a practical example.

Network Access Control Lists (NACLs)

Take these two tables for inbound and outbound rules as an example.

As packets come into the subnet, they get evaluated by the inbound ACL rules starting from the top of the rules and working its way down until the request matches the rule. If none of the rules match the request, then the catch-all rule gets used, which in this case would deny the request.

For example, if a user attempts to access the website at https://cybr.com. As the request enters the subnet, it gets evaluated. Because HTTPS uses port 443, the first rule (#100) won’t match the request, so it will check the next rule at #110. Since that rule does match the request, and since it allows all sources, that means the request will be allowed to go through.

If, instead, a request attempt gets made at port 587 for SMTP over TLS, then rules 100 through 140 will get checked, but nothing will match. As a result, the catch-all rule will be used which is a DENY rule, and which means the request won’t be allowed through.

Even if the server that the request is trying to reach is running SMTP over TLS and has port 587 open, the request will never reach that server or port because of the NACL. We would have to add a rule before the catch-all statement that explicitly allows port 587 requests.

Rule #148 is interesting because it targets ephemeral ports. Ephemeral ports get used by services to communicate, and the client that initiates requests gets to choose the ephemeral port that it uses. Because we don’t know ahead of time what the exact port will be, but we do know the range of ports it could be, we can open up entire ranges like this. Of course, we want to narrow this range down as much as possible so it depends on the use case, but these ephemeral ports aren’t as risky to leave open unlike well-known ports ranging from 0 to 1023 which serve specific purposes.

Stateful vs. Stateless

You’ll also notice that we have both inbound and outbound rules. Even if a request is allowed in, if we’re blocking the same request in the outbound rules, then the server won’t be able to respond. This is called stateless — it doesn’t keep track of an already approved connection, and it instead evaluates it going both ways.

Stateful firewall rules would instead keep track. If the connection is allowed in, then it automatically gets allowed out.

We looked at NACLs and these are stateless, but AWS also offers something called a security group and those are stateful. For example, our security groups could look like this:

Inbound

Protocol Type	Protocol	Port range	Source	Comments
All traffic	All	All	sg-1321654sdfkjsdnf	All instances associated with this security group can communicate with each other
SSH	TCP	22	192.0.2.0	Allows inbound SSH access from a remote computer at a specific IP address

Outbound

Protocol Type	Protocol	Port range	Source	Comments
All traffic	All	All	sg-1321654sdfkjsdnf	All instances associated with this security group can communicate with each other

In the inbound security group, we are allowing SSH access from a specific IP address, but we don’t have to specify it again in the outbound security group rules. The reason is because SSH connections will be coming from a remote computer to this server, which means it’s inbound. If the security group approves this inbound connection, then it automatically approves the outbound connection as well — we don’t have to specify it in outbound because security groups are stateful.

NACLs vs. Security Groups – when to use one or the other?

NACLs and Security Groups can be applied in layers together, meaning that we could have NACL rules and security group rules, and they will all have to be evaluated before a request can make it through. This is helpful because even if we happen to misconfigure the security groups, for example, the NACL will still prevent unwanted requests (or vice versa).

NACLs are also applied to subnets, while security groups are applied to hosts. This is great because you have NACLs covering entire subnets, but then you may want each host within those subnets to have slightly different rules, and you can do that with this configuration.

This essentially means that security groups act as host-based firewalls, while NACLs act as network-based firewalls. They’re not truly firewalls in the traditional sense of the word firewall because they don’t give us the full suite of functionality, but it can be helpful to think of them in that way.

Conclusion

As we learned in this post, the terms stateful and stateless are important to understand because they dictate how we need to configure our rules. For the Security+ exam, we also want to make sure that we understand what Access Control Lists are used for, and how they compare to Security Groups. Finally, make sure that you familiarize yourself with what rules look like, as you could potentially see tables like the ones we saw in this article on the exam.