Security groups (SGs) and NACLs act as firewalls for virtual machines in your cloud network plane. SGs act at the machine network interface (NI) and are generally more flexible and useful in day-to-day deployments. SGs can be modified on the fly and rules cascade down to all NIs within the group. SGs by default restrict all incoming traffic (except from other machines in the same SG) and allow all outbound traffic. NACLs are similar, but are applied across a whole subnet and by default allow all traffic.
A detailed comparison between SGs and NACLs is made in the following table:
|
SGs |
NACLs |
|
Operates at the instance level (first layer of defense) |
Operates at the subnet level (second layer of defense) |
|
Supports allow rules only |
Supports allow rules and deny rules |
|
Stateful: Return traffic is automatically allowed regardless of any rules |
Stateless: Return traffic must be explicitly allowed by rules |
|
We evaluate all rules before deciding whether to allow traffic |
We process rules in number order when deciding whether to allow traffic |
|
Applies to instance only if someone specifies the security group when launching the instances, or associates the SG with the instance later |
Automatically applies to all instances in the subnets it's associated with (backup layer of defense, so you don't have to rely on someone specifying the correct SG) |
As shown in the following diagram, security groups should be applied to groups of instances utilizing similar ports for their transport layer communication (layer 4), whereas NACLs should be used when precluding connectivity between two large subnet masks:
In this example, we want the users (over the internet) to connect to Subnet #1, but not to Subnet #2. NACLs would be best to enforce that rule at the subnet level, whereas specific application ports would be set at the security group layer.
When determining how to utilize SGs and NACLs in your deployment, consider these factors while in the design phase:
- What does my subnet pattern look like across the network plane?
- Example: I need private and public subnets to quarantine my non-web applications from the internet.
- Are common servers grouped together in certain subnets?
- Example: A web-tier, an app-tier, and DB-tier subnet.
- Which VM clusters or subnets will not connect outside the private network plane and which will?
- Even in a completely flat network plane, certain VMs' traffic patterns will be similar and can be grouped accordingly.
- Which ports and protocols are used by my applications?
- Understanding applications' common traffic patterns will help create appropriate firewall rules.
- Are any targets in the public network space?
- Understand which applications must reach out in the public domain to get patches/updates and where they must connect to.
With these questions answered, a security and network engineer can better lay the groundwork for enabling a scalable and secure firewall posture for the cloud environment.