Introduction

Lately I've been doing some networking configuration reviews for some of the projects I've been put on; to balance out the #crazycatlady blogs I'll be blogging about some network patterns and components that don't often get much attention or get used at all in the pipeline of blogs.

Today I'll be talking about Network Access Control List (NACL) and examples of how it could be used; and most importantly why it should be used.

NACLs are firewalls rules for your Subnets like how Security Group (SG) are firewall rules for your ENIs - SGs controls what traffic are allowed to enter your ENIs and NACLs controls what network traffic is allowed to enter your Subnet. Think of an onion and its layers, the NACLs is the outer layer around your SGs, so if your traffic is blocked by NACL rules (outer layer) then it will not be able to get into your Subnet, therefore it is impossible for the traffic to reach your ENIs (next layer in).

I've only reviewed a small handful of AWS network configurations but one thing I've noticed is that I've only ever seen the same default single NACL rule used that Allows all network traffic sources to all ports going into a Subnet.

Problem

We've reached the maximum allowable limit for rules in a Security Group and attached as many Security Groups to an ENI as we are allowed to.

Short summary of the solution

Reduce the number of rules: incorporating some NACL rules into a network design could reduce the overall number of Security Group rules if used effectively - by pulling firewall rules out into the Subnet layer using NACLs; and at the same time improves security posture as traffic is checked and blocked before it enters a Subnet, as opposed to traffic getting checked and blocked at a resource layer by Security Groups after it enters a Subnet – this effectively is adopting a defence in layers approach.

Example of the problem

We commonly open up All Ports, Protocols and Sources/Destinations into and out of a Subnet using NACLs without leveraging Deny rules.

We commonly apply all Firewall rules at the resource’s ENI layer via Security Groups; after all traffic routed into a Subnet is allowed to enter.

The network traffic allowed into an AWS resource depends on the combination of the rules applied to the Subnet’s NACL, as well as the rules applied at the Security Groups layer: the Intersection of the 2 rule sets is what allows network traffic to be entered into an ENI – think of it like the intersection of a Venn Diagram, or, a well commonly known model called the “Swiss Cheese” as my mate Marty (check out the cool stuff he blogs about: https://blog.caarels.com) would describe it: https://en.wikipedia.org/wiki/Swiss_cheese_model

This is net result of network traffic sources and ports allowed to enter an AWS resource by the 2 layers of rules – as you expect to see this is all the rules applied at the Security Group layer. Below we show the equivalent configuration in the AWS Console as depicted by the diagrams above.

Note, we have 1 Allow rule in the NACL for all Protocols, Ports and Sources; and 9 Security Group rules made up of 3 CIDR blocks with each allowed to enter the same 3 Ports.

Solution

Here we have a solution that achieves the same outcome as the example described in the problem, but we will achieve it with the use of NACLs.

In the NACL, instead of using a single Allow rule for network traffic for all Protocols, Ports and Sources/Destinations, we have the following 3 rules:

To allow all traffic source from 0.0.0.0/0 to enter the Subnet for Port 22
To allow all traffic source from 0.0.0.0/0 to enter the Subnet for Port 80
To allow all traffic source from 0.0.0.0/0 to enter the Subnet for Port 443

In the Security Group, we have the following rules:

To allow all traffic source from 10.0.0.0/8 to hit the ENI on all Ports
To allow all traffic source from 172.16.0.0/12 to hit the ENI on all Ports
To allow all traffic source from 192.168.0.0/16 to hit the ENI on all Ports

At first glance when you look at the Security Group rules you may think that it is overly permissive because all Ports are opened for the 3 CIDR blocks, however, if we apply the logic of Venn Diagram Intersects for the 2 rule sets made up of NACL and Security Groups, then you will realise the net result of traffic Source and Ports allowed into an ENI is identical to the example in the problem without using NACLs.

Here is what the NACL and Security configuration looks like in the AWS Console for the proposed pattern:

The net result of the 2 rule sets is identical and the traffic allowed to enter into an ENI remains the same; but notice in this pattern we have 3 Allow rules for the NACL and 3 rules for the Security Group (total of 6 vs where it was previously 10). In effect, we’ve reduced the number of rules in the Security Group by a factor of 3 but achieved the same outcome by leveraging NACLs, so this pattern is useful if you constantly find yourself hitting the AWS Quota limits for the number of rules in a Security or even hitting the limit for the number of Security Groups attached to an ENI.

Now let’s consider a more problematic example where there are many more Ports used that are spread out with gaps in between, with many specific CIDR values.
Under the current pattern imagine the 60 rules in a Security Group made up of combinations of 6 different Ports and 10 different Sources with the following configuration:

Port	Source
310	10.1.0.1/32
310	10.3.0.1/32
310	10.9.0.1/32
310	172.16.1.0/32
310	172.16.4.0/32
310	172.16.8.0/32
310	192.168.1.1/32
310	192.168.4.1/32
310	192.168.8.1/32
310	192.168.9.1/32
320	10.1.0.1/32
320	10.3.0.1/32
320	10.9.0.1/32
320	172.16.1.0/32
320	172.16.4.0/32
320	172.16.8.0/32
320	192.168.1.1/32
320	192.168.4.1/32
320	192.168.8.1/32
320	192.168.9.1/32
322	10.1.0.1/32
322	10.3.0.1/32
322	10.9.0.1/32
322	172.16.1.0/32
322	172.16.4.0/32
322	172.16.8.0/32
322	192.168.1.1/32
322	192.168.4.1/32
322	192.168.8.1/32
322	192.168.9.1/32
400	10.1.0.1/32
400	10.3.0.1/32
400	10.9.0.1/32
400	172.16.1.0/32
400	172.16.4.0/32
400	172.16.8.0/32
400	192.168.1.1/32
400	192.168.4.1/32
400	192.168.8.1/32
400	192.168.9.1/32
420	10.1.0.1/32
420	10.3.0.1/32
420	10.9.0.1/32
420	172.16.1.0/32
420	172.16.4.0/32
420	172.16.8.0/32
420	192.168.1.1/32
420	192.168.4.1/32
420	192.168.8.1/32
420	192.168.9.1/32
500	10.1.0.1/32
500	10.3.0.1/32
500	10.9.0.1/32
500	172.16.1.0/32
500	172.16.4.0/32
500	172.16.8.0/32
500	192.168.1.1/32
500	192.168.4.1/32
500	192.168.8.1/32
500	192.168.9.1/32

When we convert the 60 rules in the Security Group into using NACL and Security Group we get:

Port	Source
ALL or 310-500 (for narrow rules)	10.1.0.1/32
ALL or 310-500	10.3.0.1/32
ALL or 310-500	10.9.0.1/32
ALL or 310-500	172.16.1.0/32
ALL or 310-500	172.16.4.0/32
ALL or 310-500	172.16.8.0/32
ALL or 310-500	192.168.1.1/32
ALL or 310-500	192.168.4.1/32
ALL or 310-500	192.168.8.1/32
ALL or 310-500	192.168.9.1/32

Port	Source
310	0.0.0.0/0
320	0.0.0.0/0
322	0.0.0.0/0
400	0.0.0.0/0
420	0.0.0.0/0
500	0.0.0.0/0

We have gone from 61 (60 SG rules + the NACL Allow all) rules down to 16 rules between the NACL and Security Group – the net result is identical. I have not stated which of the 2 tables above is for the NACL rules and which is for the Security Group rules, this is because it does not matter which attribute is used to factorise the rules into the NACL - if we remember the Intersect of a Venn Diagram – however, I suggest picking the Port or Source depending based around the network construct are you most likely hitting the rule limits – the area you want to leave wiggle room for. If we use table 2 for the Security Group rules then we’ve effectively reduced the rules by 90%.

To be able to fully take advantage of this pattern, careful consideration needs to happen at the beginning of any VPC and Subnet designs in respect to how resources are grouped within a VPC and especially within Subnet, too many grouping of dissimilar resources in terms of Source Traffic, Protocols and Ports could have consequence of too many rules; a blog in the pipeline. Off course it is best practice to implement security in all layers so if there is room left in your Security Groups you should lock down your rules by Ports and Source as much as you can.

This solution compliments the use of networking solutions in other blogs I have written:

Swiss Cheese Network Security: Factorising Security Group Rules into NACLs and Security Group Rules