VPC Network Access Control Lists

VPC Network Access Control Lists

VPC Network Access Control Lists (NACL) functions as a firewall in that it contains inbound and outbound rules to allow traffic based on a source or destination CIDR, protocol, and port. Also, each VPC has a default NACL that can’t be deleted.

But the similarities end there. A NACL differs from a security group in many respects. Instead of being attached to an ENI, a NACL is attached to a subnet. The NACL associated with a subnet controls what traffic may enter and exit that subnet. This means that NACLs can’t be used to control traffic between instances in the same subnet. If you want to do that, you have to use security groups. A subnet can have only one NACL associated with it. When you create a new subnet in a VPC, the VPC’s default NACL is associated with the subnet by default. You can modify the default NACL, or you can create a new one and associate it with the subnet. You can also associate the same NACL with multiple subnets, provided those subnets are all in the same VPC as the NACL. Unlike a security group, which is stateful, a NACL is stateless, meaning that it doesn’t track the state of connections passing through it. This is much like an access control list (ACL) on a traditional switch or router. The stateless nature of the NACL is why each one is preconfigured with rules to allow all inbound and outbound traffic, as discussed in the following sections,VPC Network Access Control Lists.

Related Products:– AWS Certified Solutions Architect | Associate

Inbound Rules
Inbound rules determine what traffic is allowed to ingress the subnet. Each rule contains the following elements:

  • Rule number
  • Protocol
  • Port range
  • Source
  • Action

VPC Network Access Control Lists, The default NACL for a VPC with no IPv6 CIDR comes prepopulated with the two inbound rules listed in

defoult NACL-infosavvy

NACL rules are processed in ascending order of the rule number. Rule 100 is the lowest numbered rule, so it gets processed first. This rule allows all traffic from any source. You can delete or modify this rule or create additional rules before or after it. For example, if you wanted to block only HTTP (TCP port 80), you could add the following rule:

before or after it. For example, if you wanted to block only HTTP (TCP port 80), you could add the following rule:

Rule Number       Protocol      Port Range           Source                  Action

90                         TCP                     80                   0.0.0.0/0               Deny

This rule denies all TCP traffic with a destination port of 80. Because it’s the lowest numbered rule in the list, it gets processed first. Any traffic not matching this rule would be processed by rule 100, which allows all traffic. The last rule in Table 4.5 is the default rule. It’s designated by an asterisk (*) instead of a number and is always the last rule in the list. You can’t delete or otherwise change the default rule. The default rule causes the NACL to deny any traffic that isn’t explicitly allowed by any of the preceding rules. Complete Exercise 4.6 to create a custom NACL.

Outbound Rules

As you might expect, the outbound NACL rules follow an almost identical format as the inbound rules. Each rule contains the following elements:

  • Rule number
  • Protocol
  • Port range
  • Destination
  • Action

Each default NACL comes with the outbound rules listed in Table 4.6. Notice that the rules are identical to the default inbound rules except for the Destination element.

In most cases you will need these rules whether you use the default NACL or a custom one. Because a NACL is stateless, it won’t automatically allow return traffic. Therefore, if you permit HTTPS traffic with an inbound rule, you must also explicitly permit the return traffic using an outbound rule. In this case, rule 100 permits the return traffic. If you do need to restrict access from the subnet—to block Internet access, for example—you will need to create an outbound rule to allow return traffic over ephemeral ports. Ephemeral ports are reserved TCP or UDP ports that clients listen for reply traffic on. As an example, when a client sends an HTTPS request to your instance over TCP port 80, that client may listen for a reply on TCP port 36034. Your NACL’s outbound rules must allow traffic to egress the subnet on TCP port 36034. The range of ephemeral ports varies by client operating system. Many modern operating systems use ephemeral ports in the range of 49152–65535, but don’t assume that allowing only this range will be sufficient. The range for TCP ports may differ from the range for UDP, and older or customized operating systems may use a different range altogether. To maintain compatibility, do not restrict outbound traffic using a NACL. Use a security group instead. If your VPC includes an IPv6 CIDR, AWS will automatically add inbound and outbound rules to permit IPv6 traffic.

Using Network Access Control Lists and Security Groups Together

You may want to use a NACL in addition to a security group so that you aren’t dependent upon users to specify the correct security group when they launch an instance. Because a NACL is applied to the subnet, the rules of the NACL

Apply to all traffic ingressing and egressing the subnet, regardless of how the security groups are configured.

When you make a change to a NACL or security group rule, that change takes effect immediately (practically, within several seconds). Avoid changing security groups and NACLs simultaneously. If your changes don’t work as expected, it can become difficult to identify whether the problem is with a security group or NACL. Complete your changes on one before moving to the other. Additionally, be cautious about making changes when there are active connections to an instance, as an incorrectly ordered NACL rule or missing security group rule can terminate those connections. Refer to Exercise 4.5 for a demonstration. Note that in a NACL rule you can specify a CIDR only as the source or destination. This is unlike a security group rule wherein you can specify another security group for the source or destination.

Public IP Addresses

A public IP address is reachable over the public Internet. This is in contrast to RFC 1918 addresses, which cannot be routed over the Internet but can be routed within private networks. You need a public IP address for an instance if you want others to directly connect to it via the Internet. You may also give an instance a public IP address if you want it to have outbound-only Internet access. You don’t need a public IP address for your instances to communicate with each other within the VPC infrastructure, as this instance-to-instance communication happens using private IP addresses. When you launch an instance into a subnet, you can choose to automatically assign it a public IP. This is convenient, but there are a couple of potential downsides to this approach. First, if you forget to choose this option when you launch the instance, you cannot go back and have AWS automatically assign a public IP later. Also, when you stop or terminate the instance, you will lose the public IP address. If you stop and restart the instance, it will receive a different public IP. Even if you don’t plan to stop your instance, keep in mind that AWS may perform maintenance events that cause your instance to restart. If this happens, its public IP address will change. If your instance doesn’t need to maintain the same IP address for a long period of time, this approach may be acceptable. If not, you may opt instead for an elastic IP address.

Elastic IP Addresses

An elastic IP address (EIP) is a type of public IP address that AWS allocates to your account when you request it. Once AWS allocates an EIP to your account, you have exclusive use of that address until you manually release it. Outside of AWS, there’s no noticeable difference between an EIP and an automatically assigned public IP.

Also Read:– TCP/IP Networking Model

When you initially allocate an EIP, it is not bound to any instance. Instead, you must associate it with an ENI. You can move an EIP around to different ENIs, although you can associate it with only one ENI at a time. Once you associate an EIP with an ENI, it will remain associated for the life of the ENI or until you disassociate it. If you associate an EIP to an ENI that already has an automatically assigned public IP address allocated, AWS will replace the public IP address with the EIP.

Questions related to this topic

Which rules are present in a default nacl?
What is nacl in networking?
What is NACLs?
What is the use of nacl in AWS?
Explain VPC Network Access Control Lists?


This Blog Article is posted by

Infosavvy, 2nd Floor, Sai Niketan, Chandavalkar Road Opp. Gora Gandhi Hotel, Above Jumbo King, beside Speakwell Institute, Borivali West, Mumbai, Maharashtra 400092

Contact us – www.info-savvy.com

https://g.co/kgs/ttqPpZ

Leave a Comment

Your email address will not be published. Required fields are marked *