An AWS NACL Introduction

In this article, we will learn what NACLs are, why they are important, and how they can deployed, using a variety of AWS mechanisms.

Defense-in-depth is a security best practice that is common across  the IT industry. It specifies that the administrator should design cyber defenses in layers, making it increasingly difficult for an attacker to infiltrate and conduct malicious actions. One of the tools in the AWS security toolkit for enabling defense-in-depth, is the Network Access Control List (NACL). A NACL is a security layer for your VPC, that acts as a firewall for controlling traffic in and out of one or more subnets. Not only does it add a layer of security to the defense-in-depth concept, but it can also assist in Incident Response. Below is an executive summary that describes the subjects we will be covering in this article and compares NACLs against Security Groups, a similar concept that we will soon discuss.

Executive Summary

	NACLs	Security Groups
Purpose	Protect Subnets	Protect Instances
Stateful vs. Stateless	Stateless: Must specify both ingress and egress	Stateful: Return traffic is always allowed, regardless of rule
Operating Level	Process rules in number order	Evaluates all rules
Allow vs. Deny	Both Allow and Deny	Allow rules only
Application	Automatically applies	Application must be specified

NACLs vs. Security Groups

NACLs and Security Groups (SGs) have very similar purposes. They filter traffic based on rules, to ensure that only authorized traffic is routed to its destination. Here we will highlight the differences between the two. Below is a high-level graphic that shows their usage and contrasts the two technologies.

Image comparing a NACL to a  Security Group

NACLs

NACLs are used to controll access to network resources. They sit on subnets and evaluate traffic based on set rules, then determine whether or not that traffic should be allowed to continue. This applies traffic-based access control to your network, and is a powerful way to help secure your environment.

NACLs are “stateless”and require you to create separate rules for both  incoming and outgoing traffic. Just because a particular data stream is allowed in, doesn’t mean it will be allowed out.

NACLs are processed in number order. Therefore, if you need traffic to go both in and out of a protected subnet, you will  need to write rules for both directions.

What is particularly useful about NACLs, is that they are automatically applied to anything that falls under their umbrella. There is no need to apply NACLs to individual resources as they are created.

Security Groups

Security Groups apply to EC2 instances and act as a host-based firewall. Like NACLs, they utilize rules that determine if traffic going to or from a given EC2 instance should be allowed.

This provides granular traffic control for resources that have specific network requirements. Security Groups, unlike NACLs, are stateful; this means that any traffic allowed into your EC2 instance, will automatically be allowed out, and vice versa. All security groups rules are evaluated simulataineously; if no ALLOW exists, then traffic will be blocked.

Security Groups need to be applied at the time of resource creation and must be explicitly configured. This means that planning is necessary in order to ensure functional application of traffic blocking rules.

Similarities and Differences

Both NACLs and Security Groups utilize rules that prevent unwanted traffic in your environment. The rules themselves also look very similar. However, one difference between them, is that NACLs allow for DENY rules to be created.

The largest difference, though,  is where they are applied. This is important, because it helps define their function and how they should be used. NACLs are applied at the subnet level, while Security Groups are applied at the EC2 level. NACLs protect the network while Security Groups help protect the resource. This helps shape your security strategy.

As NACLs are higher in the architecture, they apply to a much wider group of resources. Any rule you create will therefor affect the operation of every resource in the subnet. Security Groups on the other hand, only affect the EC2 instances that they are applied to.

Despite their differences, these two layers work together to create overall defense-in-depth for your cloud environment. When planned appropriately, NACLs can remove the traffic burden from the subnet, improving security and optimizing performance.

They can also provide a means of troubleshooting, as layering traffic makes it easier to segment and investigate. For example, when investigating suspicious traffic: it’s easier to look through the logs of a smaller network segment,  as  you know that it would be impossible for traffic to have gone elsewhere.

Unfortunately, they occasionally work against one other. Bad planning and maintenance can create a web of rules that can be almost impossible to untangle. It is in your best interest to follow the guidance around applying these services, in a way that is effective and maintainable.

When to Use NACLs

We’ll list our best-practices at the end of this article. For now, let’s focus on when to use NACLs and why.

NACLs should be used sparingly. Because they apply to the full set of resources in a subnet, their impact is large. NACLs are most effective for filtering external traffic to internal subnets. However, they have more useful when used to insert traffic controls between the subnets themselves.

In the following sections, we will show you how to configure a NACL in an AWS environment, and then cover some best practices that will help keep you and your organization secure.

Tutorial

Creating a NACL is a fairly straight-forward task. Let’s start with the basics and create one in the AWS Console, that blocks port 22 (SSH).

AWS Console

In your AWS Console, Select VPC.

Image shows AWS console

Then scroll down in the left bar and select Network ACLs.

Image shows location of Network ACLs

Click on the button Create network ACL.

Image shows location of Create network ACL option

Choose a name based on your naming schema and select a VPC

Image shows name and VPC options

Click on the button Create network ACL

Image shows the Create network NACL button

Select the checkbox next to the newly created NACL and click Actions

Image shows location of Actions

In the dropdown, select View details.

Image shows location of View details option

Click on Edit inbound rules, then on the following screen, click Add new rule.

Image shows adding an inbound rule

Fill in the options as shown below. Remember, rules are processed in number order.

Image shows inbound rule options

Click Save changes at the bottom and do the same for Outbound.

Now we need to apply this to subnets.

Select the checkbox by the newly created NACL and then click Actions.

Image demonstrates location of Actions dropdown

In the dropdown, select Edit subnet associations.

Image shows selecting Edit subnet associations option

Choose the subnet(s) you want to associate with the NACL and click Save Changes

Image shows Edit subnet association options

You have now blocked all traffic to and from those associated subnets on port 22.

AWS CLI

Now let’s do the same in the CLI.

Make sure that you have set up your CLI in advance and have your vpc-id ready.

aws ec2 create-network-acl --vpc-id vpc-06e17363d29dc68c1

The result will be something similar to this:

{
"my-test-acl-2": {
"Associations": [],
"NetworkAclId": "acl-5fb85d36",
"VpcId": "vpc-06e17363d29dc68c1",
"Tags": [],
"Entries": [
{
"CidrBlock": "0.0.0.0/0",
"RuleNumber": 32767,
"Protocol": "-1",
"Egress": true,
"RuleAction": "deny"
},
{
"CidrBlock": "0.0.0.0/0",
"RuleNumber": 32767,
"Protocol": "-1",
"Egress": false,
"RuleAction": "deny"
}
],
"IsDefault": false
}
}

Now we will create the rules. First the ingress rule:
aws ec2 create-network-acl-entry --network-acl-id acl-5fb85d36 --ingress --rule-number 200 --protocol tcp --port-range From=22,To=22 --cidr-block 0.0.0.0/0 --rule-action deny

Then the egress (because NACLs are stateless):

aws ec2 create-network-acl-entry --network-acl-id acl-5fb85d36 --egress --rule-number 201 --protocol tcp --port-range From=22,To=22 --cidr-block 0.0.0.0/0 --rule-action deny

You have now created a new NACL, that will block port 22 inbound and outbound using the AWS CLI.

CloudFormation

AWS also has a deployment mechanism called CloudFormation. This is an Infrastructure as Code (IaC) utility and definition templates can be written in either JSON or YAML format. Below is an example of a very simple deployment that uses YAML.

my-test-acl-3:
    Type: AWS::EC2::NetworkAcl
    Properties:
        VpcId: vpc-06e17363d29dc68c1
            Ref:
        Tags:
        - Key: stack
          Value: test

You would then save this as a *.yaml (testNACL.yaml) and deploy via the AWS Console.

Image shows the option to upload a YAML or JSON IaC template to AWS

Best Practices for NACLs

The following are a few best practices that you can use when building or managing your NACLs:

• use NACLs sparingly and try to deploy them based on the function of the subnet they are attached to
• keep NACLs simple and only use them to deny traffic if possible
• ensure that you restrict who can create or modify NACLs through IAM
• build your Security Group rules into your NACLs
• be sure to create inbound and outbound rules that match
• when numbering, remember to leave room for future rules
• audit your rules regularly; get rid of any that are unused or redundant
• use NACLs to control your subnet-to-subnet traffic and ensure logical separation

Conclusion

NACLs are a great tool for controlling traffic over large swathes of your subnet-bound resources, and can provide an extra, well-defined layer to your cloud-based defense-in-depth strategy. However, there are several best practices that should be followed to use NACLs effectively. NACLs are similar to Security Groups, but they do have distinct differences in terms of where they apply and how they control traffic. Finally, as a native AWS service, NACLs can be integrated with a number of other services, like AWS Security Hub, which can enhance Incident Response and Threat Detection.