Specifying inbound and outbound network flows by using security group rules and network ACL rules

Can you explain the difference between Security Groups and Network Access Control Lists (NACLs) in terms of statefulness?

Security Groups are stateful, meaning that if an inbound traffic rule is defined to allow traffic, the return traffic for established connections is automatically allowed, regardless of outbound rules. Network ACLs, on the other hand, are stateless, which means inbound and outbound traffic must be defined separately and return traffic isn’t automatically allowed.

How does the rule evaluation process differ between Security Groups and NACLs?

For Security Groups, all rules are evaluated collectively and as long as there is a rule that allows the traffic, it is permitted. Security Groups don’t deny traffic, the absence of an allow rule functions as an implicit deny. For NACLs, rules are evaluated in numerical order, starting from the lowest numbered rule, and as soon as a rule is matched that either allows or denies traffic, the evaluation stops.

What is the recommended practice for configuring security groups and NACLs for a public-facing web server in a VPC?

For a public-facing web server, the recommended practice is to configure the Security Group to allow inbound HTTP and HTTPS traffic from desired sources while allowing all outbound traffic. The associated NACL should be configured to allow inbound traffic on ports 80 (HTTP) and 443 (HTTPS), and outbound traffic on ephemeral ports to support responses to clients’ requests.

Is it possible to block specific IP addresses using Security Groups, and if not, how can this be achieved?

No, Security Groups do not support the ability to block specific IP addresses; they can only define ‘allow’ rules. To block specific IP addresses, you should use Network ACLs, which can set ‘allow’ and ‘deny’ rules, providing the capability to explicitly deny traffic from specific IP addresses.

In the context of AWS VPC, can you describe one scenario where you might use NACLs over Security Groups?

One scenario could be the requirement to provide a layer of stateless network traffic filtering, such as creating a subnet-level boundary to prevent traffic between subnets, or when a need arises to create rules that explicitly deny certain types of traffic based on IP protocol or port, regardless of connection state.

If you had to create a default deny-all outbound rule for a certain type of traffic in a VPC, would you use a Security Group or a NACL, and why?

You would have to use a NACL for this purpose since it allows both ‘allow’ and ‘deny’ rules and is evaluated based on rule number order. Security Groups, being stateful, only support allow rules, and by default, they allow all outbound traffic.

How are ephemeral ports used in relation to Security Groups and NACLs, and what do you need to consider when configuring rules involving them?

Ephemeral ports are the ports used by the client system when initiating outbound connections. When configuring NACLs, ephemeral ports must be explicitly allowed for outbound traffic to enable return traffic on these ports from services outside the VPC. For Security Groups, since they are stateful, return traffic is automatically allowed and explicit rules for ephemeral ports are not necessary.

What is the maximum number of Security Groups and NACLs that can be attached to a VPC or its resources?

Each VPC supports up to 500 Security Groups, and each instance can be associated with up to 5 Security Groups. For Network ACLs, you can have up to 200 per VPC, with each subnet in a VPC needing to be associated with exactly one Network ACL.

Would you use a Security Group or a NACL (or both) for defining fine-grained access controls for instances within the same VPC?

Security Groups are typically used for defining fine-grained access controls for instances within the same VPC, as they allow for instance-level traffic filtering and can be tailored to specific instances or groups of instances within a VPC.

Can you modify the default NACL associated with a VPC, and should you?

Yes, you can modify the default NACL associated with a VPC. However, a best practice is to leave the default NACL as is (allowing all traffic) and create custom NACLs for any subnet that requires specific ingress or egress rules.

How would you temporarily restrict access to your instances in a private subnet during a security event using security groups or NACLs?

During a security event, you can quickly apply temporary restrictions using Network ACLs by adding deny rules for the suspected traffic types or sources at the subnet level. This is often a quicker solution than modifying Security Groups, especially if multiple instances across different security groups are affected. Adjusting NACLs can provide a rapid, broad-brush response while more fine-tuned changes are applied through Security Groups.

What elements need to be considered when specifying Security Group rules to ensure only intended traffic is allowed?

When specifying Security Group rules, you need to consider the protocol (TCP/UDP/ICMP), the service port or port range, and the source CIDR range or security group (for inbound rules) / destination CIDR range or security group (for outbound rules). It is also important to limit the source and destination to the necessary IP ranges or security groups to adhere to the principle of least privilege.