AWS Defence System — NACL and Security Groups !!
Network Access Control Lists (NACLs) in the context of Amazon Web Services (AWS) are a type of security control that operates at the subnet level. NACLs are stateless, numbered sets of rules that dictate what traffic is allowed or denied at the subnet level. Each subnet in a VPC (Virtual Private Cloud) must be associated with a NACL, and by default, a subnet associates with the default NACL, which allows all inbound and outbound traffic.
Here’s a brief overview of applying NACLs at different levels:
1. Public Subnet Level:
— In a typical AWS architecture, you might have a VPC with multiple subnets, some of which are public and others private.
— The NACL associated with a public subnet can be configured to allow or deny specific types of traffic entering or leaving that subnet.
— For a public subnet, you might configure rules to allow incoming traffic on specific ports (e.g., HTTP on port 80, HTTPS on port 443) to enable access to resources like web servers.
2. Private Subnet Level:
— Similarly, NACLs can be applied to private subnets to control the traffic entering or leaving those subnets.
— For a private subnet, you might have more restrictive rules, allowing outbound traffic for necessary communication (e.g., outbound traffic to a database server or external services) while denying incoming traffic that should not reach resources in the private subnet directly from the internet.
NACLs are applied at the subnet level, and you can customize the rules for both public and private subnets based on your specific security requirements. It’s common to have different NACL configurations for public and private subnets within a VPC to enforce security policies according to the network architecture.
NACL Rule Numbers:
In Network Access Control Lists (NACLs) in Amazon VPC, rules are evaluated based on their rule numbers. Each rule in a NACL is associated with a unique rule number, and these rule numbers determine the order in which the rules are evaluated. The rule numbers must be unique within a NACL, and they range from 1 to 32766.
Here are some key points about NACL rule numbers and their order of execution:
1. Rule Evaluation Order:
— NACLs have separate inbound and outbound rules, and each rule is evaluated in order based on its rule number.
— The rules are processed starting with the lowest rule number and proceeding in ascending order.
— The first rule that matches the traffic (based on source/destination IP, protocol, and port range) is applied, and further rule evaluation stops.
2. Implicit Deny:
— By default, if there is no rule that explicitly allows the traffic, it is implicitly denied.
— This means that you need to have explicit allow rules for the desired traffic, or it will be denied by default.
3. Stateless Nature:
— NACLs are stateless, which means that for a bidirectional communication (e.g., a response to an outbound request), you need to have both inbound and outbound rules allowing the traffic.
4. Rule Number Range:
— Rule numbers must be unique within a NACL and can range from 1 to 32766. You cannot have two rules with the same rule number in the same NACL.
5. Editing Rules:
— When you edit a NACL and add a new rule, it’s inserted at the specified rule number, and the existing rules are renumbered accordingly.
Here’s a simple example to illustrate rule execution order:
Rule Number :
Rule 100: Allow Inbound SSH from 203.0.113.0/24
Rule 200: Allow Inbound HTTP from 0.0.0.0/0
Rule 300: Deny All Inbound Traffic
Outbound Rules:
Rule 100: Allow Outbound All Traffic
In the above example, inbound traffic is evaluated first. If the traffic matches Rule 100, it is allowed. If it matches Rule 200, it is allowed. If it doesn’t match Rule 100 or Rule 200, it is denied by Rule 300. Outbound traffic is allowed by Rule 100 for all traffic.
What happens when Traffic is allowed at SGs and not in NACL and vice versa ?
Understanding the order of execution is crucial when configuring NACLs to ensure that the desired traffic is allowed and that security policies are appropriately enforced.
Security Groups (SGs) and Network Access Control Lists (NACLs) are both used for controlling network traffic in Amazon VPC, but they operate at different layers and have distinct functionalities. Understanding how they work together can help in designing effective and secure network architectures.
1. Security Groups (SGs):
— Layer: SGs operate at the instance (virtual machine) level, which is a higher layer in the networking stack.
— Stateful: SGs are stateful, meaning that if you allow inbound traffic, the corresponding outbound traffic is automatically allowed, and vice versa.
— Allow Principle: SGs follow the “allow” principle, meaning that you explicitly specify what traffic is allowed, and all other traffic is implicitly denied.
— Rules Applied to Instances:SG rules are applied directly to instances.
2. Network Access Control Lists (NACLs):
— Layer: NACLs operate at the subnet level, which is a lower layer in the networking stack.
— Stateless: NACLs are stateless, meaning that inbound and outbound rules are separate, and you must define rules for both directions independently.
— Allow/Deny Rules: NACLs have both allow and deny rules, and they are explicit about what traffic is allowed and what is denied.
— Rules Applied to Subnets: NACL rules are applied to entire subnets, affecting all instances in that subnet.
Now, let’s consider scenarios where traffic is blocked at one level and allowed at another:
1. Traffic Blocked at SG, Allowed at NACL:
— Suppose you have an SG that blocks inbound traffic on a specific port to an instance.
— If the NACL associated with the subnet allows inbound traffic on that port, the traffic will be allowed at the subnet level, even though the SG blocked it for the specific instance.
2. Traffic Blocked at NACL, Allowed at SG:
— Conversely, if the NACL denies inbound traffic on a specific port to the entire subnet, no instance in that subnet will be able to receive traffic on that port.
— However, if the SG associated with an instance allows inbound traffic on that port, the traffic will be allowed for that specific instance, bypassing the subnet-level block.
It’s important to note that both SGs and NACLs play a role in the overall security posture of your VPC, and they complement each other. In practice, it’s common to use SGs for higher-level, instance-specific controls, and NACLs for broader, subnet-level controls. By combining these two mechanisms, you can create a layered security approach that helps enforce the principle of least privilege and provides defense in depth for your AWS infrastructure.
Happy Learning …Jai Hind ..
