Network ACLs

Network ACLs

Network Access Control Lists (ACLs) act as a stateless firewall for controlling traffic in and out of subnets (tiers) within a VPC. Unlike Security Groups, which operate at the instance level, Network ACLs apply to all traffic entering or leaving a subnet.

Key Characteristics

• Stateless: Responses to allowed inbound traffic are subject to outbound rules (and vice versa). You must explicitly allow return traffic (e.g., ephemeral ports).
• Subnet-Level: Rules apply to the entire subnet, affecting all instances within it.
• Ordered Evaluation: Rules are processed in numerical order (lowest number first). The first matching rule determines the action (Allow/Deny).
• Default Deny: By default, a new ACL list denies all traffic until rules are added.

Creating an ACL List

1. Navigate to Network > Network ACL Lists.
2. Click Add ACL List.
3. Name: Provide a descriptive name (e.g., “Web-Public-Inbound”).
4. VPC: Select the VPC where this list will be used.

Adding Rules

Once the list is created, click on it to add rules:

• Number: The priority (1-999). Lower numbers are evaluated first.
• CIDR: The source IP range for Ingress (e.g., 0.0.0.0/0 for internet) or destination for Egress.
• Action: Allow or Deny.
• Protocol: TCP, UDP, ICMP, or All.
• Port Range: Single port (80) or range (1024-65535).
• Traffic Type: Ingress (Inbound) or Egress (Outbound).

Example Configuration: Web Tier

Ingress Rules:

1. Prio 100: Allow TCP 80 from 0.0.0.0/0 (HTTP)
2. Prio 110: Allow TCP 443 from 0.0.0.0/0 (HTTPS)
3. Prio 120: Allow TCP 22 from YOUR_OFFICE_IP/32 (SSH Management)

Egress Rules:

1. Prio 100: Allow TCP 1024-65535 to 0.0.0.0/0 (Ephemeral return traffic)
2. Prio 110: Allow TCP 80/443 to 0.0.0.0/0 (Software updates)
3. Prio 120: Allow UDP/TCP 53 to 0.0.0.0/0 (DNS resolution)

Example Configuration: One-Way Access Between Tiers

A common requirement is two networks where one may initiate connections to the other, but not the reverse. For example, tier A (10.0.1.0/24) hosts an existing application that needs to call a service in tier B (10.0.2.0/24), while tier B must not be able to open connections into tier A. Both tiers live in the same VPC, each with its own ACL list. The example below assumes the tier B service listens on TCP 8080; substitute your own ports.

ACL list for Tier B (applied to the 10.0.2.0/24 tier):

Ingress Rules:

1. Prio 100: Allow TCP 8080 from 10.0.1.0/24 (service traffic from tier A)

Egress Rules:

1. Prio 100: Allow TCP 1024-65535 to 10.0.1.0/24 (return traffic for connections tier A opened)
2. Prio 110: Allow TCP 80/443 to 0.0.0.0/0 (software updates, if tier B needs internet access)
3. Prio 120: Allow UDP/TCP 53 to 0.0.0.0/0 (DNS resolution)

ACL list for Tier A (applied to the 10.0.1.0/24 tier):

Ingress Rules:

1. Prio 100: Allow TCP 1024-65535 from 10.0.2.0/24 (return traffic for connections tier A opened)

Egress Rules:

1. Prio 100: Allow TCP 8080 to 10.0.2.0/24 (outbound to the tier B service)

Add further ingress/egress rules to tier A for its own workload (internet access, management SSH, and so on) as in the Web Tier example above. Everything not explicitly allowed is denied, so tier B cannot reach tier A on any service port.

Stateless caveat. Because ACLs are stateless, the return-traffic rules on the ephemeral port range also admit packets that tier B initiates toward ports 1024-65535 on tier A. To close this gap, keep tier A services on ports below 1024 where possible, and run a host firewall on the tier A instances that accepts only established connections from 10.0.2.0/24 (for example nftables or ufw with connection tracking). New connections from tier B are then dropped at the instance even when the ACL admits the packet.

Associating with a Network

To apply the rules:

1. Navigate to Network > VPC.
2. Select your VPC and go to the Networks tab.
3. Edit the desired Tier (Subnet).
4. Change the ACL dropdown to your new list.
5. Save. The changes apply immediately.