Importance of Security Groups (SGs) and Network Access Control Lists (NACLs) in AWS
Tags: aws, security, cloud, devops
Published: 2024-04-25 09:41:33

**Note**: If I'm mistaken or if you disagree with any point, please feel free to share your thoughts. My aim is to highlight the importance of these concepts for newcomers and individuals starting their journey in the cloud.

-1-. So let's assume you're going to the office. When you enter the office premises, firstly, the security guard identifies your identity and allows you to proceed. Then, as you enter the building, another guard verifies your identity before you swipe your card to gain entry. Of course, swiping your card marks your attendance, but it also verifies that you are indeed the right person to enter the office.

-2-. Now, you are part of the cybersecurity analyst team, and you have a lot of responsibilities. For this, you have a separate team to monitor security. When you enter the office, everyone can access it, but the security room is accessible only to those who have the authority. This adds another level of security. Your card includes these additional steps, so when you enter that room, it will check if you are an authorized person to access the room, ensuring that not everyone can access this area.

-3-. Now, these last two security steps are most important and play a very crucial role in the organization, right?

-4-. Now, the point I'm making is, consider this: You have an application inside your VPC, which consists of various components like IGW, subnets, ELB, route tables, SG, NACL, NAT gateway, etc. Now, let's relate all of these to the story I mentioned earlier. What I'm trying to convey is that, just like in the story where multiple security checkpoints were in place before reaching a secure area, in your VPC environment, there are similar security measures. The last two security points I mentioned - subnet-level security and instance-level security - act as crucial checkpoints. These ensure that user requests are securely directed to your application or server after passing through these layers of protection.

-5-. Of course, before reaching the subnet and instance level security, there are several other security checks you can implement. However, in today's blog, I'm focusing more on Security Groups, which operate on the instance level, and Network Access Control Lists (NACLs), which work on subnet-level security. I'll delve into how you can set up these security measures in your organization or application layer.

-6-. In AWS, security is a mutual responsibility shared between AWS and the user. AWS follows the principle of denying all inbound traffic by default when launching instances. If you want to allow inbound traffic, you must specifically allow access to particular ports. However, opening ports to all traffic can pose security risks. It's essential to restrict access to specific IP addresses or employ other secure methods to ensure a safer environment.

-7-. As a DevOps engineer or AWS admin, managing Security Groups (SGs) for all instances individually can be time-consuming. However, Network Access Control Lists (NACLs), which operate at the subnet level, offer a solution. By defining port and traffic rules at the subnet level, changes automatically apply to all instances within that subnet. This not only reduces administrative tasks but also enhances security by providing consistent rules across multiple instances.

-8-. In this blog, we'll walk through the process of creating a Virtual Private Cloud (VPC) on AWS. Within this VPC, we'll set up an EC2 instance and deploy a Python application. Throughout the tutorial, we'll explore the configuration of Security Groups (SGs) and Network Access Control Lists (NACLs) to better understand their roles in securing our infrastructure.

-9-. Let's begin by logging into your AWS account and navigating to the 'VPC' service. "click on create VPC"

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/838vgod7i1mfj4ybepmv.PNG)

-10- Next, select the 'VPC and more' option, as we're currently focusing on creating a VPC. Provide a name for the VPC, specify the CIDR block, choose the Availability Zone (AZ), select subnets including private subnets, and set up a VPC endpoint as an S3 gateway. Finally, click on 'Create VPC' to complete the process.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7hch6pom8cfkahpds3hi.png)

-11-. You'll also have a visual representation of your VPC, subnets, route tables, and network connections, which helps you understand how traffic flows within the VPC.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ndsbbsyqv1ufrj25wmkb.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/knv3xae1c2v0afyc9ziv.png)

-12-. After creating the VPC, navigate to the EC2 service and launch a t2.micro instance with default settings. Simply choose the VPC you created and any public subnet, then proceed to launch the instance.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6d0xdfmz5f68bkptb80d.png)

-13-. After launching the instance, wait for it to start. Once it's running, log in to your server. Since I am using an Ubuntu image, update your machine to ensure you have the latest version of Python installed.

`sudo apt-get update`

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lutntzpe54krakoan8ef.png)

-14-. Run the following command to start a simple Python server:
`python3 -m http.server 8080`

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3fpfvz0pjqxr6dizyf5s.png)

-15-. If you copy the public IP and try to access the application using port 8080, you may find it inaccessible. As I mentioned earlier, AWS implements mutual security measures, so by default, all traffic is denied when you launch a server. To address this, navigate to the "Security" tab and click on your "SG-Name". You'll notice that by default, only port 22 is allowed for server login.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hrr6lk38rl1ktkivdz0q.png)

-16-. To access the application, click on the Security Group (SG) associated with your instance. Then, select "Edit Inbound Rules" and allow port 8080 for all traffic. Keep in mind that opening all traffic is not recommended for production environments; instead, you can choose to allow traffic only from specific IP addresses. However, for study purposes, we're opening all traffic.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f81gjc26pyt0wnec30ap.png)

-17-. After saving the rule, copy the public IP address and access it on port 8080. You should now be able to see your application.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/e6cofskapzofp4jxev05.png)

-18-. Up until now, you've witnessed the importance of Security Groups at the instance level in providing security. Of course, we opened all traffic for study purposes, but I must reiterate that opening all traffic is not recommended. You should allow access only from specific IP addresses to enhance security. Keep this in mind as you proceed.

-19-. In an organization with numerous instances running across different environments like dev, prod, and uat, managing each instance's security group policies individually becomes impractical. Developers may also launch instances for their purposes and define their own rules, potentially conflicting with organizational security policies.

To address this challenge, defining rules at the subnet level becomes crucial. By setting up Network Access Control Lists (NACLs) at the subnet level, you can control the traffic entering and leaving that subnet. This way, regardless of how many instances are launched within the subnet, they all adhere to the defined rules, ensuring consistent and manageable security across your infrastructure.

-20-. let's navigate back to the VPC console and select "Network ACLs". Then, open the VPC that you created earlier.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ujcsaay9uev4yztipbzy.png)

-21-. In the "Inbound Rules" section, you'll notice that rules start from Rule 100 and continue with an asterisk (*), indicating that they follow the order from 100 until N. To modify the inbound rules, let's first remove Rule 100. Then, click on "Add New Rule" and set it to deny port 8080.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xaxku6v7fklkd56kx7wm.png)

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9emxu0qdth2yzkizrvzx.png)

-22-. Now, if you refresh the application page, you'll notice that the application is no longer accessible on port 8080. Although we allowed port 8080 at the instance level, modifying the rule at the subnet level denied traffic for all instances within that subnet. Even if someone launches an instance and allows traffic on port 8080, it won't work due to the NACL policy we set up. This demonstrates the importance of NACLs in VPC from a security standpoint, as they provide an additional layer of control over traffic flow within subnets, ensuring consistent security policies across instances.

-23-. Exactly, by modifying the NACL rules to allow traffic, the application will be accessible again. This flexibility in NACL rules allows you to adjust security measures as needed while maintaining control over traffic flow within your VPC.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m993tobwrr9xufyez636.png)

-24-. n the NACL group, if I set Rule 100 to deny port 8080 and Rule 200 to allow traffic for port 8080, will our application be accessible or not? The answer is within this blog. Feel free to try it out and let me know.