Security within cloud environments is a critical consideration, and AWS offers robust tools to ensure that your cloud infrastructure remains secure. Two critical components in AWS for managing security are Security Groups and Network Access Control Lists (NACLs). These tools act as virtual firewalls, controlling the traffic that enters and exits your Virtual Private Cloud (VPC). While they serve similar purposes, they operate differently and are used in distinct scenarios to provide layered security.

Security Groups: Instance-Level Security

Security Groups in AWS are designed to control inbound and outbound traffic at the instance level. They are stateful, meaning that if a rule allows an inbound request, the response to that request is automatically allowed, regardless of the outbound rules. This stateful nature simplifies managing traffic rules for instances, ensuring seamless communication for approved connections.

Key Features of Security Groups

• Stateful Nature:  This means that if you allow inbound traffic on a specific port, the corresponding outbound traffic is automatically permitted, eliminating the need for separate outbound rules. Security Groups are also highly scalable, allowing you to apply the same set of rules to multiple instances within a Virtual Private Cloud (VPC)
• Instance-Level Control: Security Groups are primarily associated with Elastic Cloud Compute (EC2) instances but can also be applied to other AWS resources such as Elastic Load Balancers, RDS database instances, and more.
• Immediate Rule Application: Changes to Security Group rules are applied immediately to all associated instances.
• Default Deny: By default, Security Groups deny all inbound traffic and allow all outbound traffic unless specified otherwise.

Network Access Control Lists (NACLs): Subnet-Level Security

NACLs provide an additional layer of security at the subnet level within a VPC. Unlike Security Groups, NACLs are stateless, meaning each packet is evaluated independently. For return traffic to be allowed, corresponding rules must be explicitly set for both inbound and outbound traffic. This stateless nature allows for more granular control but requires careful management of rules.

Key Features of NACLs

• Stateless Nature: Each packet is individually evaluated, requiring explicit rules for both inbound and outbound traffic.
• Subnet-Level Control: NACLs operate at the subnet level, affecting all instances within the subnet.
• Ordered Rules: Rules are processed in numerical order, allowing for a layered strategy in traffic control.
• Blocking Specific IPs: Effective for blocking specific IP addresses or ranges before they reach the instances.

Understanding the nature of Security Groups and Network Access Control Lists (NACLs) is crucial for effectively managing AWS security. Let’s delve into a practical scenario using the default VPC to illustrate these concepts.

We will use the default VPC and an EC2 instance within this VPC. Then, we will configure the Security Groups and NACLs to control traffic and host a simple web server.

Step-by-Step Guide

Launch an EC2 instance with the following configuration:

• Name: MyWebServer

• Instance Type: t2.micro

• AMI: Amazon Linux 2023 AMI

• Key pair: Create a new key pair (if you have not created one yet).

• Network: Use the Default VPC

• Subnet: Default subnet

• Public IP: Enabled

• Firewall (security groups): Check all checkboxes
  • Allow SSH traffic from: My IP
  • Allow HTTPS traffic from the internet
  • Allow HTTP traffic from the internet

• User Data:

  #!/bin/bash
  # Update the package list
  yum update -y
  
  # Install Apache HTTP Server
  yum install -y httpd
  
  # Start the Apache service
  systemctl start httpd
  
  # Enable Apache to start on boot
  systemctl enable httpd
  
  # Create a simple web page
  echo "<h1>Welcome to the MyWebServer</h1>" > /var/www/html/index.html
  
  

Testing and Observations

Test SSH Access and HTTP Connection

• SSH Access Verification: Utilize an SSH client to initiate a connection to the “MyWebServer” instance. This step tests the configuration of the Security Group and NACL, which govern access to the server.
  • A successful connection to “MyWebServer” via SSH indicates that the Security Group settings are properly configured to allow inbound SSH traffic (port 22). The diagram shows that both the NACL and Security Group settings permit this traffic (denoted by green arrows), ensuring that SSH requests can reach and return from the server without being blocked.
• HTTP Connection Check: Open a web browser and navigate to the public IP address of “MyWebServer” to verify the HTTP connection. This step assesses the ability of HTTP traffic to reach the web server.
  • Successful HTTP access confirms that the Security Group settings are correctly configured to allow inbound HTTP traffic on port 80. As visualized in the diagram, both the NACL and the Security Group have rules in place to allow HTTP traffic (shown by green arrows), demonstrating that HTTP requests are permitted to and from the server.

Modify Inbound/Outbound Rules of NACLs

• Deny All Outbound SSH Traffic in the NACL configuration: Deny all outbound traffic of SSH by modifying the NACL outbound rule.  Then, attempt to reconnect via SSH. The connection should fail due to the stateless nature of NACLs blocking return traffic. This demonstrates the stateless nature of NACLs, where each packet is treated independently and must match both inbound and outbound rules to successfully traverse the network. As shown in the diagram below, attempts to reconnect via SSH after this rule modification will fail, highlighting the necessity of explicit return traffic rules in stateless systems.
• Deny All Inbound HTTP Traffic in the NACL configuration: Following the modification for SSH, all inbound HTTP traffic is also denied by updating the NACL settings. This change ensures that any HTTP request initiated towards the web server inside the subnet will be blocked, as depicted by the red cross on HTTP traffic shown in the diagram below. This setup is crucial to demonstrate that without specific inbound rules allowing HTTP traffic, the NACL will block all incoming HTTP requests, regardless of security group settings, which may otherwise allow such connections. The diagram shows the denied HTTP access, reinforcing the role of NACLs in providing an additional layer of traffic filtration.

Security Group Restrictions

• Deny All Inbound SSH Traffic in the Security Group configuration. Then,  similar to Test SSH Access and HTTP Connection section, attempt to connect to “MyWebServer” using an SSH client.  The connection attempt should fail. This failure occurs despite the NACL allowing SSH traffic because the Security Group associated with “MyWebServer” explicitly denies SSH access. This configuration verifies that Security Group rules take precedence at the instance level, blocking unwanted SSH connections even when broader network permissions are granted.
• Deny All Inbound HTTP Traffic in the Security Group configuration. Then,  similar to Test SSH Access and HTTP Connection section, use a web browser to try accessing “MyWebServer” via its public IP address. The HTTP connection attempt should be unsuccessful. Similar to the SSH test, this result is expected because, although the NACL allows HTTP traffic, the Security Group denies all inbound HTTP requests on port 80. This setup confirms that the Security Group’s rules are effectively protecting the server from unauthorized web traffic.

Conclusion

Through this article, we have explored the functionalities and operational roles of Security Groups and NACLs in AWS. These tools offer complementary security mechanisms that work together to protect our AWS environment. Security Groups manage traffic at the instance level with stateful rules, while NACLs provide stateless, granular control at the subnet level. Mastery of these tools enables a proactive approach to network security, ensuring that enterprises can leverage the full potential of cloud computing while mitigating risks effectively.