AWS — Security Groups, NACLs and Network Firewall Part 1 — NACLs

Since just before Christmas I have been studying and working towards taking the AWS Security Specialty Exam and I have just recently passed, I am not a huge fan of security topics in general they can be a bit of a dry subject matter, but I have actually enjoyed the AWS Security Specialty syllabus.

So what prompted this blog… well as I do when I am getting close to exam, I like to start look around forums for related subjects and I kept coming across posts and comments about Security Groups and NACLs where people couldn't seem to see the difference or when to use both, so I challenged myself to write a blog about them that could explain them in a simple form. To most of you this probably seems like a waste of time, however I am of the opinion that if it helps even just one person then it was worth they effort to write it.

This blog will form a 4 part series looking at NACLs, Security Groups, AWS Network Firewall and a final piece that will look at combined use cases.

So lets dive in a start to look at these options.

NACLs

Out of the three NACLs or Network Access Control Lists are probably the least complicated.

NACLs simply put are a list of statements that say if you are from this source IP address or Subnet, on this protocol or port number you are either allowed or denied. You have separate list statements for Inbound flows and Outbound flows

So lets see my example below

I have a NACL, and on the Inbound Rules I have two configured rules, Rule 10 which allows HTTPS from 10.10.10.0/24 subnet and Rule 20 which allows HTTPS from 10.10.20.0/24 subnet.

Wait a second what about the * rule? Good question, the * rule is the implicit Deny rule at the end of the Rules, this means that if your flow is not permitted by the rules above then it will be Denied by the catch all deny.

Ok what about the rule numbers are they important? Another good question… the Answer is it depends… let me elaborate. NACL entries are evaluated in number order starting with the lowest number and up to the highest. So in a scenario where you are only permitting the flows with ACL entries then placement of rules and numbering are not a primary concern you start at 1 and add as you go when needed, although AWS guidance says increasing the number by 100 for each rule is best practice.

But in a more complicated scenario where for instance I wanted to block a single subnet out of a wider Supernet, wait whats a super net? what's a Supernet? it is just a term that is used to reference a group of subnets, so for example if I had subnets 10.0.0.0/24, 10.0.1.0/24, 10.0.2.0/24 and 10.0.3.0/24 then I could reference these subnets as a Supernet 10.0.0.0/22, I will cover off in a bit why using Supernets can be important, but back to my example. So lets say I configure my rules as follows

My first rule is a Deny rule that blocks HTTPS from 10.0.3.0/24 and my second rule permits HTTPS from 10.0.0.0/22, this is where order preference becomes important, as this rule stands HTTPS traffic from 10.0.3.0/24 would be denied but HTTPS traffic from 10.0.0.0/24, 10.0.1.0/24 and 10.0.2.0/24 would be allowed

What if I changed the order preference?

This is where order preference becomes important, so my first rule allows HTTPS from 10.0.0.0/22 and the second rule denies HTTPS from 10.0.3.0/22, in this situation my deny rule would never be used, because 10.0.3.0/24 is part of the Supernet 10.0.0.0/22 and since traffic is always evaluated against that rule first the traffic I wanted to deny would always be allowed.

But I could just list out the rules to allow and deny each /24 subnet as needed…. yes you could but in larger VPC’s and larger AWS environments your NACLs would become unmanageable and you would also likely hit the AWS NACL quota limits of 20 rules (can be increased to a maximum of 40 with a support ticket request)

I noticed there were Outbound Rules as well do I need to worry about these? Yes I am glad you noticed those, Outbound rules are just as important as Inbound for NACLs because NACLs are what we call stateless, Errr Wait what does that mean? Stateless means that the NACL doesn't track the network connection permitted by the NACL, yeah that's not a great explanation lets try an example.

So looking back at our previous Inbound rules, I have a rule the allows HTTPS from 10.0.0.0/22, an example of stateless connections is as follows. If a connection is initiated from 10.0.1.10 to our HTTPS server the initial inbound flow is evaluated by the NACL and then allowed allowed, but when the HTTPS server responds the flow back to our client is not automatically allowed because NACLs are Stateless, to allow the flow back we need to have a corresponding Outbound Rule to allow Ephemeral ports.

Doh!!! What are ephemeral ports?

Ephemeral ports are a known group of high ports between 1025 and 65535, normally this group is smaller depending on the OS or can sometimes be defined in the OS, So when a server responds to a client it does so using an Ephemeral port as the destination port.

So to solve our connectivity problem we need to allow connections from our HTTPS server on 10.0.1.10 back to our client on Ephemeral ports so it will look like the below.

So now with the above we have a complete flow.

So it is always important to remember when you are using NACLs beyond the default you need to ensure that you think about both Inbound and Outbound flows.

So What else do we need to know about NACLs?

By default when a NACL is created when you create a VPC it is associated with all subnets and has a allow all inbound and outbound.

When you create a new NACL by default it only has the implicit deny statements inbound and outbound so you need to add your rules that you want and you also need to associate it with the subnet or subnets you want it to apply to.

NACLs can be associated to multiple subnets which allow for NACL reuse however, a subnet can only be associated to one NACL at a time.

A NACL check is only initiated when traffic leaves or enters the subnet, it is not used when traffic is within the same subnet.

That's the most important stuff about NACL’s there are a few other things that it is worth knowing which you can check out at this AWS Guide under Network ACL Basics

I hope you find this blog useful and look out for my next part in this blog series where we will take a look at Security Groups.