AWS Security Groups (SGs) and Network Access Control Lists (NACLs) – What’s the Difference?

Security Groups or SGs are an essential part of the task of securing your incoming and outgoing network traffic within a VPC.

 

However, SGs also have limitations and shouldn’t be thought of as the only line of defence.

 

AWS provides a range of additional networking security tools, such as Network ACLs, AWS Network Firewall, DNS Firewall, AWS WAF (Web Access Firewall), AWS Shield, as well as monitoring and compliance tools like AWS Security Hub, GuardDuty, and Network Access Analyzer.

 

Quick Overview of the Main Features of AWS Security Groups

 

Security groups are access control lists (ACLs) that allow network traffic inbound and outbound from an Elastic Network Interface (ENI). SGs serve as a basic firewall system for all AWS resources to which they are attached.

 

Note for exam: Security groups implicitly DENY traffic, they only have “allow” rules, and not “deny” rules.

 

Thus the absence of an “allow” rule will implicitly DENY access

 

Security group rules are “stateful” – meaning that if a server can communicate outbound to a service, the return traffic to that server will also be automatically permitted.

 

This behaviour contrasts with Network ACLs which are “stateless”.

 

Security groups are VPC-specific and thus also region-specific – which means they can only be used within the VPC where they are created.

 

Sole exception to this is where there is a peering connection to another VPC, in which case they can be referred to in the peered VPC.

 

Security groups can be applied to multiple instances within a VPC, and can be valid across subnets within that VPC.

 

When a VPC is first created, a “default” security group is automatically created by AWS for it and within it.

 

This default SG has no inbound rules and just a single outbound rule, which allows all traffic to any destination (0.0.0.0/0).

 

If a new resource is launched within the VPC without association to an SG then it will automatically be assigned to this “default” SG.

 

By default, a new security group attached to a group of instances does not allow these instances to communicate with each other. For this to be possible you need to create new inbound and outbound rules, and then define the source and destination as the security group itself.

 

Note that SGs are allocated to the actual Elastic Network Interface device (ENI) which is attached to an EC2 instance, as opposed to the EC2 / RDS instance itself.

 

You can assign up to five SGs to each Elastic Network Interface. Thus an EC2 instance with multiple ENIs could actually therefore have more than five security groups assigned to it, though this is not best practice.

 

 

Best Practices for Deploying Security Groups

 

Avoid using the “default” security group

 

The “default” security group should not be used for active AWS resources. The reason is that new AWS resources could be inadvertently assigned to it and so be permitted undesired access to your resources. Since you cannot delete the default SG, you should instead delete all inbound and outbound rules in the “default” SG instead.

 

Then create new SGs for your AWS resources. Then ensure any new AWS resources are assigned to the correct SGs you created.

 

Keep the number of your created SGs to a minimum

 

The AWS EC2 Launch Wizard will encourage you to create a new security group for each EC2 instance you create. However, the problem with that is that it can lead to the creation of too many security groups, which then become hard to manage and track.

 

Instead of relying on the Launch Wizard, you should decide on a strategy for creating security groups based on your actual application and service access needs and then assign them in accordance with your requirements.

 

Restrict, restrict, restrict

 

This means you should always strive to ensure all new security groups apply the principle of least privilege. this means for example:

 

Don’t open inbound traffic for the whole VPC CIDR-IP or subnet range unless absolutely necessary.

 

Also avoid allowing all IP addresses (0.0.0.0/0) unless absolutely necessary.

 

Restrict outbound traffic where possible e.g. do not open all ports to the internet, for example, only open HTTP/HTTPS to allow internet webaccess.

 

If allowing a specific service, only open the ports and protocols required for that service. For example, for DNS, you open port 53 for TCP and UDP, and only to the external DNS provider – for example for Google DNS that would be 8.8.8.8/32.

 

Open relevant ports and protocols to other security groups, rather than for IP addresses/subnets. This is because AWS recommends using dynamic IP addresses.

 

Develop a security group strategy

 

Set a strategy for creating and using security groups based on your application and service needs. Then use AWS tools to enforce this strategy.

 

Some examples of strategy options:

 

Decide the best way to set up your security groups.

 

For example: deploy one security group per service type, such as “mysql-db”, “web”, “ssh-access”,“active-directory”. Then assign the required inbound and outbound ports for that service

 

Define one security group per application type, such as “web-servers”, “file-servers”, or “db-servers”. Then assign the ports for that application or service.

 

Define one security group per operating system, such as “linux” or “windows”, then assign the basic ports required for that OS.

Define one or two default SGs to cover access requirements common to all or most of the servers in the VPC. This minimises the total number of security groups required.

 

Example:
if all instances need outbound using HTTP / HTTPS to access the web
if all instances need an inbound port for eg a monitoring system.

Try to use a naming strategy which provides clarity to help avoid confusion if you manage multiple VPCs. If each VPC has a security group called for example “web-servers”, then it can quickly become difficult to keep track of which is which.

 

AWS Firewall Manager can help create security group policies and associate them with accounts and resources. It can also be used to monitor and manage the policies for all linked accounts.

 

AWS Security Hub works with CloudTrail and CloudWatch to monitor and trigger alarms based on security best practice alerts.

 

One indication to watch out for is the rate of change within SG rules – such as ports being opened and closed again within a very short time period.

 

AWS Config can be used to ensure compliance with defined best practices. Config Rules can be created to check and alert for non-compliance, and then perform automated remediation steps.

 

For example, checking for unrestricted security group rules and ensuring the “default” AWS SG has no inbound or outbound rules set.

 

 

 

 

 

An EC2 security group plays the role of a firewall. By default, a security group will deny all incoming traffic while permitting all outgoing traffic

 

 

You define group behavior by setting policy rules that will either block or allow specified traffic types.

 

 

 

You can update your security group rules and/or apply them to multiple instances.

 

 

 

Security groups control traffic at the instance level.

 

 

However, AWS also provides you with network access control lists (NACLs) that are associated with entire subnets rather than individual instances.

 

 

 

Security Groups Simplified

 

Security Groups are used to control access (SSH, HTTP, RDP, etc.) with EC2. They act as a virtual firewall for your instances to control inbound and outbound traffic.

 

 

When you launch an instance in a VPC, you can assign up to five security groups to the instance. 

 

 

Note that security groups act at the instance level, not the subnet level.

 

 

 

 

Security groups filters IP & Port according to rules. 

 

 

This is the basic firewalling system of AWS, this can be modified…

 

 

Security Group INBOUND allows inbound port 22 traffic from your computer

 

 

 

Security Group OUTBOUND allows outbound ANY PORT to ANY IP

 

 

In other words,

 

 

by default in AWS:

 

All INBOUND traffic is blocked by default
All OUTBOUND traffic is authorized by default

 

 

 

 

Security groups can be attached to MULTIPLE EC2 instances, not just assigned to a single EC2.

 

 

 

 

An instance can also belong to multiple security groups.

 

 

They are set for a specific region or VPC combination. So they are NOT cross-regional.

 

 

Security groups operate OUTSIDE the EC2 not inside it – so if the traffic is already blocked then the EC2 won’t see it. So it is not an “app” running on your EC2 but a service running outside of it.

 

 

Best practice is to create a separate security group just for SSH access.

 

 

 

TIP for error-debugging:

 

 

if your application gives a “time out” error, then it is not accessible and this means it is most likely a security group issue.

 

 

if your application gives a “connection refused” error, then it is an application-internal error or the application is not running.

 

 

 

 

Security Groups Key Details

 

 

Security groups control inbound and outbound traffic for your instances (they act as a Firewall for EC2 Instances) while NACLs control inbound and outbound traffic for your subnets (they act as a Firewall for Subnets). Security Groups usually control the list of ports that are allowed to be used by your EC2 instances and the NACLs control which network or list of IP addresses can connect to your whole VPC.

 

 

Every time you make a change to a security group, that change occurs immediately.

 

 

Whenever you create an inbound rule, an outbound rule is created immediately. This is because Security Groups are stateful. This means that when you create an ingress rule for a security group, a corresponding egress rule is created to match it. This is in contrast with NACLs which are stateless and require manual intervention for creating both inbound and outbound rules.

 

 

Security Group rules are based on ALLOWs and there is no concept of DENY when in comes to Security Groups. This means you cannot explicitly deny or blacklist specific ports via Security Groups, you can only implicitly deny them by excluding them in your ALLOWs list.

 

 

Because of the above detail, everything is blocked by default. You must intentionally allow access to certain ports.

 

 

Security groups are specific to a single VPC, so you can’t share a Security Group between multiple VPCs. However, you can copy a Security Group to create a new Security Group with the same rules in another VPC for the same AWS Account.

 

 

Security Groups are regional and CAN span AZs, but can’t be cross-regional.

 

 

Outbound rules exist if you need to connect your server to a different service such as an API endpoint or a DB backend. You need to enable the ALLOW rule for the correct port though so that traffic can leave EC2 and enter the other AWS service.

 

 

You can attach multiple security groups to one EC2 instance and you can have multiple EC2 instances under the umbrella of one security group.

 

 

You can specify the source of your security group (basically who is allowed to bypass the virtual firewall) to be a single /32 IP address, an IP range, or even a separate security group.

 

 

You cannot block specific IP addresses with Security Groups (use NACLs instead).

 

 

You can increase your Security Group limit by submitting a request to AWS

 

 

Reachability Analyzer

 

The Reachability Analyzer is an AWS web-dashboard tool you can deploy to check network reachability from a source and to a destination via a specifically named port. There is a cost incurred of currently 10c per check.

 

This is very useful in debugging any SG or NACL traffic problems.