Using an AWS Network ACL versus an SG for access control?

Question

I have an Ubuntu EC2 instance running on AWS. I have always used the Network ACL to control access to port 22 instead of using Security Groups.

Question 1: For the use case of a single EC2 instance, are there any pros and cons between using a NACL vs SG for access control? (Besides stateful vs stateless and the other differences on the AWS VPC security doc.)

Question 2: How does a large environment handle this? Is there a best practice? (I know one larger company has their NACL totally open and controls everything with SGs.)

First thing I did to try and find an answer was reading AWS's VPC Security docs: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Security.html

I see a couple methods for access control in my use case:

Option 1: Restrict the NACL ingress to ports 80, 443, and ephemeral ports to 0.0.0.0/0. Add port 22 access per IP address. Deny all other traffic. (This is what I have always done.) If I wanted a private subnet instance, I would then restrict down the Private Subnet via SG to the Public Subnet's internal CIDR.

Option 2: Open the NACL up to the world and use SG for access control to the EC2 instance.

Option 3: Be redundant and use both.

When I go to a new location (coffee shop) and want to SSH to my instance, I log into the AWS console and add a new NACL rule to allow the IP address port 22 access. Adding a rule to both an NACL and SG seem to be the same amount of mouse clicks and typing.

Regarding actual environment creation, I use terraform. Setting up a resource is pretty easy using either option, so I wouldn't consider that a pro or a con.

NACL resource:

  ingress {
    protocol   = 6
    rule_no    = 300
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 80
    to_port    = 80
  }

SG resource:

ingress {
    from_port = 80
    to_port = 80
    protocol = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

The only big advantage I see to the NACL is if there are multiple Public SGs, it's easier to blacklist IP addresses in an NACL if handled manually via the console.

Answer 1

Access Control and securing VPCs is a big topic and there are many best practices that AWS suggest you use for different scenarios (for example, Bastion Hosts)

For the simple case of accessing a single EC2 in a public subnet from your coffee shop computer, you will need to change the security group to allow SSH from the coffee shop ip.

Using the console, the general steps are:

1. Under VPC dashboard -> Security -> Security Group -> blue button: Create Security Group. Name it Coffee SG, describe it and choose the appropriate VPC to associate it to and click create.
2. Once the SG is created, click inbound rule tab at the bottom and click the Edit Rules button
3. For Type, select SSH
4. For source select "my ip" if you are at the coffee shop computer. The browser will fill in the form with the computer ip automatically. To allow any ip, you can use 0.0.0.0/0 (not recommended) to allow a range, use CIDR.
5. Click Save Rules.
6. When you launch your ec2 instance, select Coffee SG for your security group.

If your EC2 is already running, go to the security group and start at step 2 above. For more details see the AWS guides:

This guide provides the steps you need to take for Linux instances. This guide provides the steps you need to take for Windows instances.

Answer 2

NACL operates at the subnet level, SG operates at the instance level as it says in the docs you reference so for a subnet with a single instance in it then NACL having explicit deny is the only difference in functionality. I suggest AWS cli for your coffee shop example, choose between NACL and sg based on which command is easier for you.

A large environment would have more than one instance in a subnet so SG gives instance level allows. I also think SG being the dynamic, cloud native option makes it preferable because SG membership rather than IP addresses can be used in rules. This makes infra as code portable between regions, vpcs and azs because addressing can be dynamic or overlap but your stack will still work the same.

Answer 3

Now from above diagram it's very clear :

Internet Gateway > To control inbound and outbound rules at VPC level . In that case all the resources within VPC will be impacted. all Ec2 instances will be impacted.

Nacl > To control inbound and outbound rules at Subnet level . In that case all the resources within subnet will be impacted. For NACL1 > Ec-1 , Ec-2 and Ec-3 will be impacted and for NACL2 Ec2-4 will be impacted. So Nacl is more restrictive as compared to Internet Gateway.

Security group > To control inbound and outbound rules at resource level. In that case all the resources attached to the security group will be impacted . For Security Group-1 Ec2-1 and EC2-2 will be impacted , For Security Group-2 Ec2-3 will be impacted.

So Internet gateway , Nacl and Security Group all act as firewall at different levels