Score:0

Do network acls block inter-subnet traffic as well?

in flag

I have VMs placed in different AZs on AWS. In order to be able to do this, you need a subnet in each AZ.

If I'm creating a network acl for the entire setup (ie to be associated with all subnets) do I need to specify allow rules from all the subnet CIDR ranges? If I don't, will the network acl block inter-subnet traffic based on my port rules?

I'm assuming they will...but want confirmation.

Score:1
in flag

Network ACLs DO NOT block intra-subnet traffic. You can consider them as if they were applied to the router interface on that subnet. So the ACL only affects traffic in and out of the subnet.

ndtreviv avatar
in flag
Awesome - thanks!
Tim avatar
gp flag
Tim
This answer says "intra" subnet traffic, the question was about inter-subnet traffic.
Score:0
gp flag
Tim

I believe the answer from Ron is correct, but does not answer your question.

If you have instances in multiple subnets and your instances need to communicate your NACLs need to account for this with allow rules. I haven't tested this, but I've worked with AWS a long time and I'm fairly sure this is the way it works.

Interestingly, security groups are a firewall that can be thought of as around each network interface. So if you want instances in a security group to communicate you need a rule to allow ingress from the security group to itself.

Answers to comments in questions:

Ports You only need to open ports 80 / 443 on your web server security group. The 1024 - 65535 part is ephemeral ports, which you should read up on if you want to understand them. Start with Wikipedia but then move on to something easier to understand if you need to.

AWS Inspector This page says the following

The Amazon Inspector agent initiates all communication with the Amazon Inspector service. This means that the agent must have an outbound network path to public endpoints so that it can send telemetry data. For example, the agent might connect to arsenal..amazonaws.com, or the endpoint might be an Amazon S3 bucket at s3.dualstack..amazonaws.com. Make sure to replace with the actual AWS Region where you are running Amazon Inspector. For more information, see AWS IP Address Ranges. Because all connections from the agent are established outbound, it is not necessary to open ports in your security groups to allow inbound communications to the agent from Amazon Inspector.

ndtreviv avatar
in flag
So I have instances in the same security group, but different subnets. They appear to be talking so far even though the nacl doesn't explicitly allow rules between the different subnet CIDR blocks, however I had to open such a massive port range for amazon services to work it seems almost pointless doing this at all, and that's probably why it's all still working. Are you saying that, with instances in the same security group, different subnets, same nacl I'd have to open port ranges between the different subnet CIDR ranges for comms to work?
Tim avatar
gp flag
Tim
You shouldn't be opening a lot of ports, it's usually just 443 unless it's something like AD. Lots of destination IPs, sure. I think that instances in different subnets that need to communicate need both NACLs and SGs to allow the communication.
ndtreviv avatar
in flag
Perhaps I'm misunderstanding this: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#nacl-ephemeral-ports ? Particularly the "Requests originating from Elastic Load Balancing use ports 1024-65535" bit?
ndtreviv avatar
in flag
Not only that, but it seems that if you lock it right down the AWS Inspector doesn't even run ‍♂️
Tim avatar
gp flag
Tim
I have edited my question to answer your comments.
Score:0
in flag

In general, it is recommended that you leave Network ACLs at their default "Allow All" settings and instead use Security Groups for network security.

A NACL represents a traditional router that sites between subnets, controlling what traffic goes in/out of the subnet. NACL rules are stateless, meaning that they need to be defined in both directions. NACLs only apply to traffic going between subnets.

Security Groups are a new innovation in cloud computing. They are a firewall on each individual resource in the VPC (more accurately, on each Elastic Network Interface). This allows much more fine-grained security control. Rules are stateful, meaning that that requests sent out will automatically allow a response to come in.

Security Groups can also reference each other. For example, consider an Amazon EC2 instance and an Amazon RDS database. A security group can be placed on the EC2 instance allowing incoming web traffic. A security group can be placed on the RDS instance allowing incoming SQL queries only from the security group associated with the EC2 instance. This is much more precise than NACL rules.

The bottom line is:

  • Always use Inbound Security Groups to secure resources
  • Optionally limit Outbound Security Groups (since you can typically trust apps running on an instance)
  • Never change NACL rules unless you have a very specific security need, such as creating a DMZ
ndtreviv avatar
in flag
This advice is out of line with the AWS Inspector reachability package.
pl flag
This advice is also impossible to follow in many cases where security groups don't work (e.g. across Transit Gateway, inter-region VPC peering).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.