Day-5-Aws
Understanding AWS Security Groups and NACLs: A Comprehensive Guide
TLDR: This blog post explores the concepts of AWS Security Groups and Network Access Control Lists (NACLs), detailing their roles in securing AWS environments, how they differ, and practical applications for DevOps engineers.
In the fifth day of the AWS Zero to Hero series, we delve into the critical components of AWS security: Security Groups and Network Access Control Lists (NACLs). This session builds upon the previous day's discussion about Virtual Private Clouds (VPCs) and their importance in AWS architecture.
Recap of Day 4
Before we dive into today's topic, let's quickly recap what we learned on Day 4:
VPC Overview: We explored the concept of a Virtual Private Cloud (VPC) and its components, likening it to a secure gated community.
Traffic Flow: We discussed how traffic flows within a VPC, including the roles of public and private subnets, internet gateways, load balancers, and route tables.
Importance of VPC: VPC is essential for introducing the concept of a private cloud within the public cloud, enhancing security for applications hosted on AWS.
1 private subent -> multiple ec2 instance |
| Security group - > attached to EC2 instance |
| Inbound - > req flow into application (default : all block) |
| Outbound - > req flow out of the application (default : all open, except 25) |
| NACL -> attached to private subnet |
| -> deny all req, except for few required port. |
| If any rules applied to the NACL (private subnet) - > then that rules is indirectly applicable to the |
| All Security group (multiple ec2 instance). |
| So u can directly apply rule to NACL, to avoid manually applying rules to individuals ec2 instance |
| when we create VPC → by default → internet gateway,route table,NACL is created |
| additionally we will create EC2 instance → attach security group |
| play with NACL & security group configuration → to see how traffic flow |
| create VPC |
| search → VPC → VPCs (card) → create VPC |
| vpc setting |
| → resource to create : VPC and more |
| → name tag : demo |
| → ipv4 CIDR block : ( → 65,536 IPs) |
| → no of avalibility zone : 2 |
| → no of public subnet : 2 |
| → no of private subnet : 2 |
| → nat gatway : none |
| → vpc endpt : s3 gateway→ |
| → (checked by default→ enable hostname → enable resolution) |
| → create VPC |
| → [garph like view → (vpc → subnet → route table → network connection)] → keep changing dynamically when option is changed |
| created vpc → resource map → [final garph like view → (vpc → subnet → route table → network connection)] |
| create EC2 instance |
| search →ec2 → instance (resource card) → create Instance |
| name : demo-instance |
| os : ubuntu |
| AMI : v22.04 |
| instance type: t2.micro |
| key value pair : aws_login (selct from dropdown) create key value |
| network setting → edit —→ vpc : demo-vpc → subnet : demo-vpc-public → auto assign public-ip : enable → firewall : create security group |
| → launch instance |
| run python app on ec2 instance |
| created instance → copy public ip |
| ssh -I aws_login.pem ubuntu@<public ip> |
| sudo apt update |
| python3 |
| python3 -m http.server 8000 |
| NACL → 1st layer of security |
| search → vpc → security (sidebar)→ network ACLs → select created one → inbound rules —> [rule no:100 → allowed all] |
| by default it wont open , blocked all inbound by security group→ 2nd layer of security → http://<public ip>:8000 |
| created instance → security → security group → inbound rules → edit inbound → |
| add rule → type : custom TCP → port : 8000 → save rules |
| http://<public ip>:8000 → now you can view page |
for understanding
| NACL → deny req from 8000 |
| search → vpc → security (sidebar)→ network ACLs → select created one → inbound rules —> edit rules |
| rule no : 100 → type : custom TCP → port : 8000 → allow/deny : deny → save changes |
| http://<public ip>:8000 → can’t be opened |
| search → vpc → security (sidebar)→ network ACLs → select created one → inbound rules —> edit rules |
| rule no : 100 → type : All traffic → port : all → allow/deny : allow |
| rule no : 200 → type : custom TCP → port : 8000 → allow/deny : deny —> save changes |
| http://<public ip>:8000 → can be opened |
| priority → lowest rule no will run first → so 100 → allow |
| rule no : 200 → type : All traffic → port : all → allow/deny : allow |
| rule no : 110 → type : custom TCP → port : 8000 → allow/deny : deny —> save changes |
| http://<public ip>:8000 → can’t be opened |
| priority → lowest rule no will run first → so 110 → deny |
Today's Focus: Security Groups and NACLs
Today, we will focus on two key security features within AWS: Security Groups and NACLs. Both serve to enhance security but operate at different levels within the AWS architecture.
What are Security Groups?
Security Groups act as virtual firewalls for your EC2 instances, controlling inbound and outbound traffic. Here are some key points:
Instance Level Security: Security Groups are applied at the instance level, meaning they control traffic to and from individual EC2 instances.
Inbound and Outbound Rules: Security Groups allow you to define rules for both inbound and outbound traffic. By default, all inbound traffic is denied, while all outbound traffic is allowed, except for Port 25, which is blocked to prevent spam.
Configuration: When configuring a Security Group, you can specify which ports and IP addresses are allowed to access your instance. This is crucial for maintaining the security of your applications.
What are NACLs?
Network Access Control Lists (NACLs) provide an additional layer of security at the subnet level. Here’s what you need to know:
Subnet Level Security: NACLs are applied at the subnet level, meaning they control traffic for all instances within a subnet.
Deny and Allow Rules: Unlike Security Groups, NACLs can explicitly deny traffic. This allows for more granular control over what traffic is allowed or blocked at the subnet level.
Order of Rules: NACLs evaluate rules in order, from the lowest numbered rule to the highest. The first rule that matches the traffic will determine whether it is allowed or denied.
Key Differences Between Security Groups and NACLs
| Feature | Security Groups | NACLs |
| Level of Application | Instance level | Subnet level |
| Default Behavior | Deny all inbound, allow all outbound | Allow all inbound and outbound |
| Rule Type | Allow only | Allow and deny |
| Rule Evaluation Order | All rules evaluated together | Rules evaluated in order |
Practical Application
To illustrate the concepts of Security Groups and NACLs, we will walk through a practical example:
Creating a VPC: Start by creating a custom VPC with both public and private subnets. AWS will automatically create an internet gateway and default NACLs.
Launching an EC2 Instance: Launch an EC2 instance within the public subnet and attach a Security Group. Initially, the default Security Group will block all inbound traffic except for SSH (Port 22).
Testing Access: Attempt to access a simple HTTP server running on the EC2 instance. The request will fail due to the Security Group blocking the traffic.
Modifying Security Group: Update the Security Group to allow traffic on the desired port (e.g., Port 8000). After saving the changes, the application should be accessible.
Implementing NACLs: Next, modify the NACL to deny traffic on Port 8000. This will block access to the application, demonstrating how NACLs can enforce security at the subnet level.
Conclusion
Understanding and effectively utilizing Security Groups and NACLs is crucial for any DevOps engineer working with AWS. These tools provide multiple layers of security, ensuring that applications are protected from unauthorized access. As you continue to learn about AWS, remember that security is a shared responsibility between AWS and the users.
Feel free to practice the concepts discussed in this session and reach out with any questions or clarifications. Thank you for joining today's lesson, and I look forward to seeing you in the next session!