5 Not-to-Ignore Best Practices for AWS NACLs (Network Access Control Lists)  
Tags: awssecurity, nacls, securitygroup, firewall
Published: 2018-10-05 15:27:02

---
title: 5 Not-to-Ignore Best Practices for AWS NACLs (Network Access Control Lists)  
published: True
description: AWS NACLs act as a firewall for associated subnets, controlling both inbound and outbound traffic. But before configuring them, one must keep few recommendations and best practices in mind. Here are the top five best practices you can never ignore.
tags: AWS Security, NACLs, Security Group, firewall,  
---

<span style="font-weight: 400; color: #000000;">Time and again, Amazon Web Services (AWS) practitioners recommend to have the right combination of AWS NACLs (Network Access Control Lists, also pronounced as “Nakles”), VPC, and AWS Security Groups (SGs) to secure resources 24X7 from unwanted attacks. </span>

<span style="font-weight: 400; color: #000000;">AWS NACLs act as a firewall for associated subnets, controlling both inbound and outbound traffic. Whereas SGs acts as firewall at resource level.</span>

<span style="font-weight: 400; color: #000000;">In one of our previous posts, we spoke about </span><a href="http://blog.totalcloud.io/5-not-ignore-best-practices-aws-security-groups/"><span style="font-weight: 400;">5 Not-to-Ignore Best Practices for AWS Security Groups</span></a><span style="font-weight: 400; color: #000000;">. In this post, we will walk you through few best practices for NACLs.</span>

&nbsp;
<h1><span style="color: #000000;"><b>The Stateless Beauty of AWS NACLs</b></span></h1>
<span style="font-weight: 400; color: #000000;">Before applying the best practices for AWS NACLs, it is important to understand its basic characteristics as well as the ability to fine-tune traffic through its stateless behavior.</span>

<span style="font-weight: 400; color: #000000;">Unlike SGs that are stateful, AWS NACLs are stateless. On that account, changes applicable to an incoming rule will not be applicable to the outgoing rule. That is, if you want your instances to communicate over port 80 (HTTP), then you have to add an inbound as well as an outbound rule allowing port 80. </span>

<span style="font-weight: 400; color: #000000;">Before configuring NACLs, one must keep few recommendations in mind, such as:</span>

&nbsp;
<h2><span style="color: #000000;"><b>#1 Be Mindful of Default NACLs, Especially the Ones with Production Servers</b></span></h2>
<span style="font-weight: 400; color: #000000;">When you create a VPC, it comes with a default Network ACL that allows all inbound and outbound rules. And if you create a custom NACL, both Inbound and Outbound rules are denied. If you have not created a custom network ACL, then the subnets will be associated with VPC’s default ACL automatically. This will ‘Allow’ all traffic to flow into and out of the network. </span>
<blockquote><span style="color: #000000;"><b><i>“ Cautiously allow traffic into or out of NACLs, especially if you are running a production server. Above all, keep a continual check on NACLs that allow all inbound traffic.”  </i></b></span></blockquote>
<span style="font-weight: 400; color: #000000;">Here’s an example: Assign a NACL to a public subnet with instances that can receive and send Internet traffic over port 80 (HTTP) and ephemeral ports 1024-65535. And block the traffic over port 2049 (NFS) or ports vulnerable to denial of service attacks.</span>
<blockquote><span style="color: #000000;"><b><i>“Always ensure you do not use a wide range of ports or overly permissions to NACLs during configuration, unless your applications or containers that require a wide range of ports, like Kubernetes.” </i></b></span></blockquote>
&nbsp;
<h2><span style="color: #000000;"><b>#2 Use it in Combination with Security Groups Inside a VPC for Perfected Security</b></span></h2>
<span style="font-weight: 400; color: #000000;">Configuring SGs and NACLs in VPC helps reduce the attack surface of your applications hosted on AWS. They mutually complement each other, because SGs allow defining the traffic to resources within the applications while NACLs allow defining the port, protocol, and source of traffic that should be explicitly denied at the subnet level. </span>

<span style="font-weight: 400; color: #000000;">Here is an example to show how SGs and NACLs complement each other. Say, you have a two-tier web application with web servers in one SG and a database in another. The inbound NACL rules allow connections to web servers from around the world, while the database allows inbound connection from only a list of web servers. So, web servers allow port 443 connections, while the database allows inbound 3306 connections for MySQL.</span>
<blockquote><span style="color: #000000;"><b><i>“ To prevent the servers from initiating connections over the internet, you can remove both the web server and the database SGs’ outbound rule. This way, the web servers will allow all outbound traffic to establish sessions. And the database must limit outbound connections to the web server’s private subnet IP range.”</i></b></span></blockquote>
&nbsp;
<h2><span style="color: #000000;"><b>#3 Keep an Eye on Ineffective NACL ‘ Deny’ Rule</b></span></h2>
<span style="font-weight: 400; color: #000000;">Ineffective or misconfigured DENY rules promotes ‘ overly-permissive’  access to a VPC. This results in attacks such as DoS or DDoS. Be mindful of the order of the DENY rules within your Network ACLs. This is crucial, as ACLs are evaluated in order. For example, in the below image, the DENY rule is defined to block inbound traffic to vulnerable port 2049. If the rule does not block access to everyone (0.0.0.0/0), the inbound DENY rule is declared ineffective and should be reconfigured to protect against attacks.</span>

&nbsp;
<h2><span style="color: #000000;"><b>#4 Take Limitations into Consideration</b></span></h2>
<span style="font-weight: 400; color: #000000;">It is always best to know the limitations around NACLs before configuring them in your AWS infrastructure. Here are few limitations you must never ignore:  </span>

<span style="font-weight: 400; color: #000000;">- There is a default limit of 20 to both inbound and outbound rules per list. AWS provides additional rules on request, however the absolute maximum is 40. </span>

<span style="font-weight: 400; color: #000000;">- The top end limit to number of network ACLs per VPC is 200.</span>

&nbsp;
<h2><span style="color: #000000;"><b>#5 Keep a Check on Unrestricted Outbound Traffic on NACLs</b></span></h2>
<span style="font-weight: 400; color: #000000;">While creating/applying the network ACL, you can apply either inbound restriction or outbound restriction. During configuration, take care of outbound rules that allow traffic from all ports. Limit access to the required ports or port ranges. This gives least privileges to unwanted roles and reduces the possibility of unauthorized access, at the subnet level.</span>

&nbsp;
<h1><span style="color: #000000;"><b>Play by the AWS NACL Rules</b></span></h1>
<span style="font-weight: 400; color: #000000;">While best practices helps in avoiding errors or unwanted traffic, there are few NACL rules you must never ignore, such as:</span>

<span style="font-weight: 400; color: #000000;">- NACLs are always read in ascending order, with each rule applied against matching packets. These rules apply regardless of whether a later rule might also match. It is important to carefully sequence the NACL rules with an organized numbering system.</span>

<span style="font-weight: 400; color: #000000;">- AWS Network ACL Rules (both inbound and outbound) are defined in terms of the DESTINATION port</span>

<span style="font-weight: 400; color: #000000;">- The numbering can start at one and go as high as 32766. While assigning, it is recommended to leave a gap of at least 50 numbers between each of the NACL rules, so that there’s enough room for additional rules in the sequence for use later. Plus, never forget to apply an outbound reply rule to permit responses to inbound requests while creating the rules. </span>

<span style="font-weight: 400; color: #000000;">- Each Network ACL includes a rule numbered asterisk (‘*’ ). This rule ensures the inbound/outbound traffic is denied if a packet does not match any of the other numbered rules. This rule can neither be modified nor removed. </span>

<span style="font-weight: 400; color: #000000;">- Specify the port range for the assigned protocol to use while creating a custom rule.</span>

&nbsp;
<h1><span style="color: #000000;"><b>Conclusion: </b></span></h1>
<span style="font-weight: 400; color: #000000;">As a second layer of defense, NACLs run by the rules. But you will need to configure them aptly under different scenarios. AWS has documented rules for the below scenarios: </span>

<a href="https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario1.html"><span style="font-weight: 400;">Scenario 1: VPC with a Single Public Subnet</span></a>

<a href="https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html"><span style="font-weight: 400;">Scenario 2: VPC with Public and Private Subnets (NAT)</span></a>

<a href="https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario3.html"><span style="font-weight: 400;">Scenario 3: VPC with Public and Private Subnets and AWS Managed VPN Access</span></a>

<a href="https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario4.html"><span style="font-weight: 400;">Scenario 4: VPC with a Private Subnet Only and AWS Managed VPN Access</span></a>

&nbsp;

<span style="font-weight: 400; color: #000000;">Additionally, using Terraform, you can program NACLs rules. This helps in creating a secure infrastructure and preserving it in Infrastructure as a Code (IaaC) format. </span>

<span style="font-weight: 400; color: #000000;">Taking all the above rules into consideration and applying the best practices, you can always improve your AWS security posture and reduce attack surface. </span>

<span style="font-weight: 400; color: #000000;">But configuring the NACLs as per best practices alone is not enough. Keeping a continual check on these is of paramount importance. It doesn’t matter if you are using Terraform code or a tool like </span><a href="https://github.com/capitalone/cloud-custodian"><span style="font-weight: 400;">Cloud-custodian</span></a><span style="font-weight: 400; color: #000000;"> to monitor and verify NACL rules. </span>

<span style="font-weight: 400; color: #000000;">What matters the most is how you analyze route table and NACL configurations and further map the entire inbound and outbound traffic between subnets and NACLs continually to maintain AWS security in real-time.</span>

&nbsp;
<blockquote>
<h3><span style="color: #000000;"><em><strong>Having said that, switching between multiple tabs and dashboards or lines of code is effort-intensive. Using a single visual console that can analyze and show the entire AWS network topology right from VPC level to resource level is the best way forward. </strong></em></span></h3>
</blockquote>
<h2></h2>
<h2><span style="font-weight: 400; color: #000000;">TotalCloud Inc. will be soon rolling out a new view that will provide a focused visual environment with real-time cues to security loopholes in a 3D space. So stay tuned with us!   </span></h2>
<span style="font-weight: 400;">--END--</span>
<h6><span style="font-weight: 400;">References: </span></h6>
<h6><a href="https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html"><span style="font-weight: 400;">https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html</span></a></h6>
<h6><a href="https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf"><span style="font-weight: 400;">https://d0.awsstatic.com/whitepapers/aws-security-best-practices.pdf</span></a></h6>
<h6><a href="https://www.cloudconformity.com/conformity-rules/VPC/network-acl-deny-rules.html"><span style="font-weight: 400;">https://www.cloudconformity.com/conformity-rules/VPC/network-acl-deny-rules.html</span></a></h6>
<h6><a href="https://www.cloudconformity.com/conformity-rules/VPC/network-acl-outbound-traffic-all-ports.html"><span style="font-weight: 400;">https://www.cloudconformity.com/conformity-rules/VPC/network-acl-outbound-traffic-all-ports.html</span></a></h6>
&nbsp;

<span style="color: #000000;"> Note: Originally published at <a href="https://blog.totalcloud.io/5-not-to-ignore-best-practices-for-aws-nacls-network-access-control-lists/" target="_blank" rel="noopener"> blog.totalcloud.io </a> on September 20, 2018.
</span>