AWS for beginners - Network ACLs

I wrote about security groups a few weeks ago, which act as firewalls before the traffic hits the EC2 instances. AWS also provide network ACLs, which play a similar role in filtering traffic to/from the EC2 instances in the VPC and add another layer of protection.

1. What is a Network ACL?

Network ACLs (or Network Access Control Lists) provide an additional level of defence to our applications at a subnet level. Similarly to security groups, they are virtual firewalls with defined sets of rules in both inbound and outbound directions.

Each subnet must have a network ACL associated with it. A particular subnet can only have one set of ACL rules, but one Network ACL can belong to multiple subnets.

2. They also have deny rules

Network ACLs have both allow and deny rules.

This means that we can explicitly prevent IP addresses, IP address ranges, protocols and ports from accessing the subnet.

2.1. Rules with numbers

As the picture above shows, ACLs have numbered rules. The reason for this is that AWS evaluate the parameters of the traffic in relation to the rules from top to bottom. If a matching rule is found, the traffic is judged accordingly, and all rules coming after will be ignored. It’s a good idea to have some gap between the rule numbers, so that new rules can be inserted later if needed.

This means that rules can be added or deleted any time. New rules are effective immediately, so no waiting period applies.

2.2. Explicit deny

Each ACL ends with an explicit deny rule marked with * as the rule number. This rule denies all traffic from all protocols and ports from all sources (inbound rules) and to all destinations (outbound rules).

The reason for this explicit deny rule is to block all traffic that is not allowed. We have to manually allow the traffic we want to reach our servers, everything else will be blocked.

The explicit deny rule cannot be deleted.

3. Network ACLs are stateless

As opposed to security groups (SGs), network ACLs are stateless, i.e. they don’t remember where the traffic originates from.

This means that we have to configure the return (response/reply) traffic as well.

The image below shows a possible set of outbound rules.

In this case, incoming traffic is allowed on port 80 (HTTP protocol, rule 120 inbound in the first image), and it goes on to the VPC (outbound rule 120, where the CIDR block of the VPC is 172.31.0.0/16).

The response to the incoming traffic comes from the VPC (inbound rule 140), and goes to the internet (outbound rule 100). In both cases, the response traffic will go on ephemeral ports; this is what the 1-65535 range represents.

So with network ACLs, the response traffic must also be configured, because they are stateless.

4. Network ACLs vs SGs

Both network ACLs and security groups protect the EC2 instances from unwanted traffic. Having both at the same time may seem redundant but this is just the first impression.

The main differences between network ACLs and SGs are the following.

Network ACLs

1. are stateless i.e. response traffic must also be configured.
2. have both allow and deny rules, therefore they can be used for blocking traffic from/to an IP address or a range of IP addresses.
3. protect the EC2 instances at a subnet level, which means that their rules apply to all instances in that subnet.

On the other hand, security groups

1. are stateful, which means that they remember where the traffic comes from, and the response traffic doesn't need to be configured.
2. only have allow rules, and they can implicitly deny traffic if it's not configured.
3. protect the EC2s at an instance level, so each EC2 must have a SG assigned. One SG can belong to multiple EC2s, though.

5. Default and custom Network ACLs

When a new VPC is created, AWS automatically adds a network ACL to that VPC. This is marked as default.

Network ACLs can also be created separately, they will be custom ACLs.

5.1. Default ACLs

They allow all traffic in both inbound and outbound directions.

The outbound side is identical to this one.

Of course, these rules need to be changed, because it raises security concerns: We shouldn’t allow all traffic to reach our instances.

The second rule marked with * is the explicit deny, which blocks all traffic. In this case, this rule won’t be assessed against the incoming traffic, because the first rule (100) will be a match for all traffic, and everything else coming after rule 100 will be ignored.

5.2. Custom ACLs

On the other hand, custom ACLs deny all traffic in both directions.

There’s only one rule in both inbound and outbound sections, and this is the explicit deny with the *. This means that no traffic is allowed to go in the subnet, and no traffic can leave the subnet.

Of course, this setup is not ideal. Because the subnet and its content become unreachable, additional rules need to be added to allow traffic from certain ports and addresses.

The explicit deny rule cannot be deleted.

6. Conclusion

Network ACLs act as virtual firewalls at a subnet level and provide additional layer of defence for the EC2 (server) instances. Their rules apply to all EC2s in that subnet.

They can both allow and deny traffic from an address or range of IP addresses, and protocols and ports can also be specified.

When a network ACL is created either as part of a new VPC (default ACL) or by itself (custom ACL), the rules provided by AWS should be changed to for maximum security.

Thanks for reading and see you next time.