Question

Difficulty: HardVPC Security Controls and Traffic Analysis

API instances running on Amazon EC2 in Subnet X (172.16.10.0/24172.16.10.0/24) are unable to establish TCP connections with Redis cache nodes running in Subnet Y (172.16.20.0/24172.16.20.0/24) on port 63796379. The security groups associated with both the API instances and the cache nodes permit all inbound and outbound traffic between the two subnets. To troubleshoot, a SysOps Administrator enables VPC Flow Logs on the elastic network interfaces (ENIs) of the cache nodes. The administrator identifies the following log records:

2 123456789012 eni-0987654321fedcba0 172.16.10.50 172.16.20.200 58291 6379 6 1 60 1781234560 1781234620 ACCEPT OK
2 123456789012 eni-0987654321fedcba0 172.16.20.200 172.16.10.50 6379 58291 6 1 40 1781234560 1781234620 REJECT OK

Which configuration change will resolve the connectivity issue?

  1. A
    Add a rule to the Network ACL associated with Subnet Y allowing outbound TCP traffic to destination 172.16.10.0/24172.16.10.0/24 on port 63796379.
  2. Add a rule to the Network ACL associated with Subnet Y allowing outbound TCP traffic to destination 172.16.10.0/24172.16.10.0/24 on ports 1024655351024-65535.Answer
  3. C
    Add a route to the route table of Subnet Y targeting an Internet Gateway (IGW) for destination 172.16.10.0/24172.16.10.0/24.
  4. D
    Associate Subnet Y's route table with a Gateway VPC Endpoint to route response traffic back to Subnet X.

Answer

The correct configuration change is to add a rule to the Network ACL associated with Subnet Y allowing outbound TCP traffic to destination 172.16.10.0/24172.16.10.0/24 on ports 1024655351024-65535.
The flow logs indicate that inbound traffic from the API instance (172.16.10.50172.16.10.50) to the Redis cache node (172.16.20.200172.16.20.200) on TCP port 63796379 is accepted, but the return traffic from the cache node to the client's ephemeral port (5829158291) is rejected. Since security groups are stateful and automatically allow return traffic, a security group would not log a reject for the return traffic if the inbound request was accepted. Therefore, the block is occurring at the stateless Network ACL level. To allow the response traffic to pass through the Network ACL, an outbound rule must be added to the cache subnet's (Subnet Y) Network ACL allowing outbound traffic to the API subnet (172.16.10.0/24172.16.10.0/24) on the ephemeral port range (1024655351024-65535).

Step-by-Step Solution

1
Analyze the provided VPC Flow Log records to determine where the traffic is being blocked.
The flow logs show that the inbound packet from the client (172.16.10.50172.16.10.50) to the server (172.16.20.200172.16.20.200) on port 63796379 is accepted, but the return packet from the server to the client on port 5829158291 is rejected.
Identifying the direction and port of the rejected traffic is the first step in isolating the misconfigured network control.
2
Compare the behavior of stateful and stateless security controls in a VPC.
Security groups are stateful and would automatically allow the return traffic if the inbound traffic was accepted. Network ACLs are stateless and require explicit rules in both directions.
This allows us to rule out Security Groups as the source of the drop and attribute it to a Network ACL.
3
Determine the correct ports and protocol required for the return traffic rule in the stateless control.
The return traffic goes from the server (source port 63796379) to the client's ephemeral port (destination port 5829158291). The rule must allow outbound traffic on destination ports 1024655351024-65535.
This ensures the return packet can pass through the outbound filter of the subnet's Network ACL.

Key Concept

VPC Security Controls and Traffic Analysis
Rate this question