A network access control list (ACL) contains rules that apply to a vSwitch to control traffic that flows between subnets. You can use network ACLs with security groups to create a defense-in-depth security strategy.
Security risks
Security groups operate at the instance level, specifically at the network interface card (NIC) level, to define access rules based on an instance's service and security needs. In contrast, network ACLs operate at the subnet level and define rules for traffic that flows between subnets based on the subnet's service and security needs. While security groups offer flexible, fine-grained control, network ACLs provide an additional layer of security. This layered approach helps prevent network threats that can arise from misconfigured security group rules or from instances that are not added to a security group.
When traffic enters a virtual private cloud (VPC), it first reaches a vSwitch. A network ACL is applied before a security group or Cloud Firewall. The network ACL filters illegitimate inbound traffic, which saves processing resources. Similarly, outbound traffic to the Internet also passes through the vSwitch first. The network ACL can filter unnecessary outbound traffic, which helps save outbound bandwidth.
Best practice: Supplement security group rules with a network ACL
Background and challenges
In a cloud computing environment, you often need to connect multiple VPCs to enable communication between services. For example, consider two separate VPCs:
VPC1 (10.200.0.0/16): Contains applications that need to access resources in VPC2.
VPC2 (10.1.0.0/16): Hosts various service instances in a complex network environment.
Initially, to simplify development and accelerate service deployment, the security group rules in VPC2 were configured to be permissive. This created some security risks. For example, some security groups opened ports to the entire 10.0.0.0/8 CIDR block. Some Elastic Compute Service (ECS) instances intended only for internal access were even configured with rules that allowed access from all sources (0.0.0.0/0).
When you connect VPC1 and VPC2 with a VPC peering connection, these potential security risks become apparent. The goal is to allow services in VPC1 to access port 80 on the 10.1.38.0/24 cluster in VPC2. However, simply configuring precise security group rules for the target cluster (10.1.38.0/24) is not enough. A peering connection connects the 10.200.0.0/16 CIDR block of VPC1 and the 10.1.0.0/16 CIDR block of VPC2, either partially or entirely. As a result, other misconfigured instances and services in VPC2 could be accidentally exposed to VPC1, which creates security vulnerabilities.
Solution: Use a network ACL to strengthen border security
To solve these problems and establish a clear, reliable security border, you can configure a network ACL on the vSwitch in VPC2 that connects to VPC1. A network ACL is a stateless packet filtering tool that operates at the subnet level to filter traffic that enters or leaves the subnet. It acts as a firewall for the VPC subnet and provides broader security control that is applied before security groups.
The configuration policy is as follows:
Deny by default: First, you can set a default rule in the network ACL to deny all inbound traffic from the VPC1 CIDR block (10.200.0.0/16) and all outbound traffic to VPC1. This establishes a secure baseline and ensures that the two VPCs cannot communicate without explicit permission.
Allow specific traffic: Then, you can add rules with a higher priority to explicitly allow bidirectional communication on port 80 between VPC1 (10.200.0.0/16) and the target cluster in VPC2 (10.1.38.0/24).
Inbound rule: Allow inbound TCP traffic on port 80 from the source address 10.200.0.0/16 to the destination address 10.1.38.0/24.
Outbound rule: Allow outbound TCP traffic (response traffic) from the source address 10.1.38.0/24 to the destination address 10.200.0.0/16 on an ephemeral port range.
With this configuration, the vSwitch first uses the network ACL to filter out all unauthorized access requests. Only legitimate traffic that is explicitly allowed is forwarded to the ECS instances in the subnet. Even if the security group rules attached to some ECS instances are flawed, the instances are not exposed to VPC1. This configuration greatly improves the security of cross-VPC communication.