AWS - NACL
Amazon Web Services (AWS) offers numerous security layers to safeguard cloud resources. Among these is the Network Access Control List (NACL), which serves as a firewall for managing inbound and outbound traffic at the subnet level of a Virtual Private Cloud (VPC). NACLs offer an added layer of security in addition to Security Groups, providing granular control over traffic.
NACL :
A Network Access Control List (NACL) is an optional security feature that allows stateless filtering of traffic coming in or going out of a subnet. In contrast to Security Groups, which act at the instance level, NACLs act at the subnet level, affecting all instances in that subnet.
Important Features of NACLs:
Stateless: In contrast to Security Groups, NACLs are not session stateful. This implies that inbound and outbound rules have to be defined explicitly for bidirectional communication.
Rule-Based Filtering: Numbered rules are employed by NACLs to permit or block traffic. The rules are checked in increasing order, i.e., beginning from the lowest-numbered rule.
Default Deny Rule: There is an inherent deny all rule at the end of every NACL to block any traffic not specifically permitted.
Association with Subnets: One subnet may be associated with only one NACL, but a single NACL may be attached to many subnets.
Customizable Rules: Allow or Deny rules can be defined for certain IP addresses, protocols, and ports by users.
Default vs. Custom NACLs
When you launch a VPC in AWS, it generates by default a Network ACL with the following rules:
Inbound Rule: Permits all incoming traffic.
Outbound Rule: Permits all outgoing traffic.
But you can make custom NACLs with particular rules for improved security. Custom NACLs begin with a deny all traffic rule until you put in the necessary permissions manually.
NACL Rules and Numbering
NACLs filter rules in ascending numerical order from the lowest rule number. The first applicable rule decides whether the traffic is denied or permitted. If there isn't a match, the default deny all traffic rule is followed.
Use Cases for NACLs
Subnet-wide Traffic Filtering: Limit access to certain subnets with controlled communication allowed.
Blocking Malicious IPs: Use deny rules for known malicious IP addresses or regions.
Multi-tier Application Security: Establish various rules for public and private subnets (e.g., permitting public web traffic but limiting database access).
DDoS Mitigation: Establish deny rules to prevent anomalous traffic patterns from reaching the instances.
AWS - SG (Security Groups)
An AWS security group is a virtual firewall for your EC2 instances to manage incoming and outgoing traffic. Inbound and outbound rules manage traffic to and traffic from your instance, respectively.
How AWS Security Groups Work
AWS Security Groups assist you in securing your cloud environment by determining how traffic will be permitted into your EC2 instances. Through Security Groups, you can have all the traffic that passes at the instance level only through your defined ports and protocols.
When creating an instance on Amazon EC2, you must assign it to a specific security group. You can insert rules into each security group to permit traffic to or from specified services including the related instances.
Similar to whitelists, security group rules are always permission-oriented. It is never possible to define rules that will reject traffic. Let's say you have traffic from an Elastic Load Balancer (ELB) to a subnet running web servers. Your AWS Security Group can specify that ELB as their only allowed source.
Security groups are stateful. That is, if the incoming request is passed through, then the outgoing request will also be allowed through Specifying Multiple AWS Security Groups
You can identify one or more security groups per EC2 instance, up to a maximum of five per network interface. Besides, each instance in a subnet within your VPC can belong to a distinct set of security groups. When allowing traffic to an instance, Amazon EC2 considers all the rules from all the security groups assigned.
When rules are added or updated, they will automatically be enforced across all instances that are part of the security group.
With CloudGuard, you can see your cloud security posture at the infrastructure level (VPCs, security groups, EC2 and RDS instances, Amazon S3 buckets, Elastic Load Balancers, etc.) and detect configuration drift interactively.
Key Characteristics of Security Groups:
- Stateful: If a rule allows incoming traffic, the corresponding response traffic is automatically allowed, and vice versa.
- Instance-Level Security: Security Groups are attached to individual instances, unlike Network ACLs, which operate at the subnet level.
- Implicit Deny: By default, Security Groups deny all inbound traffic and allow all outbound traffic unless specified otherwise.
- Multiple Attachments: An instance can be associated with multiple Security Groups, and each Security Group can apply different sets of rules.
- Flexible Rule Configuration: Security Groups support IP-based filtering and allow traffic based on CIDR blocks, specific IP addresses, or AWS services.
Default vs. Custom Security Groups
When a VPC is created, AWS automatically assigns a default Security Group with the following rules:
- Inbound Traffic: Denied by default.
- Outbound Traffic: Allowed for all destinations.
- Instances in the same Security Group can communicate with each other.
Custom Security Groups allow administrators to define specific rules for enhanced security and access control.
Security Group Rules
Security Groups use rules to control network traffic. Each rule specifies:
- Protocol (TCP, UDP, ICMP, etc.)
- Port Range (e.g., 22 for SSH, 80 for HTTP, 443 for HTTPS)
- Source/Destination (IP address range, another Security Group, or AWS service)
Allow/Deny Action (AWS Security Groups only support allow rules; deny rules are not explicitly defined)
AWS - Instance
Private EC2 Instances
Amazon EC2 (Elastic Compute Cloud) is a core AWS service that allows users to deploy virtual machines (instances) on the cloud. These instances can be categorized as public or private based on their network accessibility. Understanding the difference between public and private EC2 instances is crucial for designing a secure and efficient cloud infrastructure.
Public EC2 Instance?
A public EC2 instance is an instance that has direct access to the internet. It is launched in a public subnet and assigned a public IP or Elastic IP (EIP). The instance can send and receive traffic over the internet through an Internet Gateway (IGW).
Characteristics of Public EC2 Instances
- Has a Public IP or Elastic IP assigned automatically or manually.
- Accessible from the internet (if security settings allow).
- Uses an Internet Gateway (IGW) for internet communication.
- Typically used for web servers, bastion hosts, and application frontends.
Configuring a Public EC2 Instance
- Launch the EC2 instance in a public subnet.
- Assign a Public IP or Elastic IP.
- Ensure the route table includes a default route (0.0.0.0/0) pointing to the Internet Gateway (IGW).
- Configure security groups to allow inbound access for required services (e.g., HTTP, HTTPS, SSH).
What is a Private EC2 Instance?
A private EC2 instance is an instance that does not have direct internet access. It resides in a private subnet and can only communicate with other instances within the VPC unless configured to access external networks through a NAT Gateway or VPN.
Characteristics of Private EC2 Instances
- No Public IP or Elastic IP.
- Cannot be accessed directly from the internet.
- Uses a NAT Gateway or VPN for outbound internet traffic.
- Typically used for databases, internal applications, backend services, and sensitive workloads.
Configuring a Private EC2 Instance
- Launch the EC2 instance in a private subnet.
- Do not assign a Public IP.
- Ensure the route table does not include a direct internet route.
- Use a NAT Gateway in a public subnet if outbound internet access is required.
- Use a Bastion Host or VPN for secure remote access.
Best Practices for Using Public and Private Instances
- Limit Public Instance Usage: Assign public IPs only to instances that require direct internet access.
- Use Private Instances for Sensitive Data: Deploy databases and internal applications in private subnets.
- Implement a Bastion Host: Instead of exposing private instances, use a bastion host in a public subnet for SSH access.
- Use NAT Gateway for Outbound Access: Allow private instances to access the internet securely for software updates.
- Configure Security Groups and NACLs: Restrict access with tight firewall rules to minimize security risks.
Conclusion
Public and private EC2 instances serve different purposes in an AWS environment. Public instances provide internet-facing services, while private instances enhance security by keeping critical resources isolated. By designing your AWS architecture with the right balance of public and private instances, you can achieve a secure, scalable, and efficient cloud infrastructure.
