Understanding the AWS Security Groups and Best Practices to use them

AWS Security Groups are one of the most fundamental aspects of Amazon Web Services. They are widely used in AWS and are also an important topic if you are aiming to clear the AWS Certification. Therefore, it is indispensable to have a good understanding about them.

In this post, we will understand what AWS Security Groups are and how you can use them. Also, we will look at some best practices while these security groups.

What are AWS Security Groups?

Security Groups are the fundamental base of network security in AWS. A security group acts as a firewall for our EC2 instances.

In other words, security groups control how traffic is allowed into or out of our EC2 instances. The below illustration shows a high-level view of the security group.

AWS Security Groups are region specific and VPC specific. This means that if we create a security group in one region or VPC, we can only use it in that same region or VPC. Also, when we launch a new EC2 instance, we need to specify a security group that’s created for that particular VPC.

New security groups can also be added or modified after they are attached to EC2 instances. In such a case, the new or modified security group rules are automatically applied to all the instances that are associated to the security group.

AWS Security Groups in Action

To get a clearer picture of AWS Security Groups, let’s see them in use.

When we create a new EC2 instance, in one of the steps we have to choose or create a security group. See below screenshot from EC2 instance creation workflow where we add a new security group.

Security groups can also be added or removed after the instance has been created. For example, we can add a new rule to an existing security group after the EC2 instance is up and running.

As can be seen in the above screenshot, we are adding a new rule to an existing security group. Apart from the SSH rule, we also add a rule about HTTP access over port 80.

Defining a Security Group Rule

To add a rule to an AWS security group, we need to provide a few details.

Let’s look at what those details are:

• Protocol/Type – This is the first information needed for a rule. Here, we specify the protocol that we wish to allow. Example could be SSH, HTTP, HTTPS
• Port Range – To specify the port or range of ports to allow. Example could be port 22 for SSH, 80 for HTTP or any other port numbers as per the need.
• Source or Destination – To specify the source or destination for the traffic. We can specify a IPv4 address, IPv6 address, range of IPv4 or IPv6 addresses, another security group and so on.
• Description – To add some description to the rule for documentation purposes.

Patterns for Security Groups

There are a couple of common patterns or illustrations that can demonstrate how security groups work. Let’s look at them in detail.

Pattern 1 – Access Based on IP Address

In this pattern, we look at the approach where access to EC2 Instance is given according to the IP Address of the connecting computer. This pattern can be seen for SSH Access if we only wish a certain machine to access our EC2 instance. See below illustration.

Here, we have a T2 Micro Instance. It has a Security Group with rules regarding Inbound and Outbound Access.

As per the rule only our computer with a certain IP address can access the EC2 instance over port 22. All other computers are unauthorized. By default, the outbound access is open.

This approach is known as Filtering based on IP and Port.

Pattern 2 – Access Based on Referencing Security Groups

This is an advanced pattern for implementing AWS Security Groups. In this approach, we provide access to one instance from another instance based on the security groups assigned to them.

As can be seen in above illustration, we have an EC2 instance with Security Group 1. We have authorized Security Group 1 & 2 to have inbound access to the same. Now, other EC2 instances associated with Security Group 1 & 2 can access the first EC2 instance. However, the third EC2 instances having Security Group 3 cannot access the first EC2 instance.

This pattern is pretty useful when we want to connect EC2 instances or other AWS resources.

Rules for AWS Security Groups

Now that we have seen AWS Security Groups in action, we can look at some rules for these security groups.

• By default, the security groups allow all outbound traffic. This is traffic from our EC2 instance to the outside world. Also, the default security group allows all inbound traffic from other instances using the same default group.
• We cannot delete the default security group.
• Security Groups are permissive in nature. In other words, we can’t create rules that deny a certain type of access.
• We can add or remove rules at any time. The changes are automatically applied to all instances associated to the security group.
• We can assign multiple security groups to one instance. In such a case, all the rules within the security groups are aggregated to form 1 set of rules.
• With EC2-classic, we can only specify inbound rules. With EC2-VPC, we can specify inbound as well as outbound rules.
• If more than one rule is specified for a particular port then the most permissive rule holds precedence. For example, if you have a Rule 1 that allows access to port 22 from IP address 192.168.0.1 and Rule 2 that allows access to port 22 from everyone, Rule 2 will be effective. Everyone will have access to port 22.

Connection Tracking in AWS Security Groups

Connection tracking is an important feature of AWS Security Group and one that is often overlooked.

But what is connection tracking?

In essence connection tracking implies that the rules are applied based on the connection state to decide whether access should be granted or not. This allows security groups to be stateful.

In other words, responses to inbound traffic are allowed to flow out of the instance regardless of outbound security rules and vice versa.

For example, if we initiate an ICMP ping from our computer to the EC2 instance that allows inbound ICMP ping then the connection is tracked. The response is not tracked as a new request but as an existing connection. Due to this, the response is allowed to flow out of the instance even if outbound rules restrict ICMP traffic.

Best Practices about AWS Security Groups

Being a very important piece of the overall AWS eco-system, is is important to know some best practices when dealing with AWS Security Groups.

• Security Groups should avoid having large port ranges. This increases the attack surface and increases vulnerability of your EC2 instances.
• Limit outbound access from ports to specific ports or other destinations.
• It is good to maintain one security group for SSH Access to your instances since SSH is a critical access.
• While working with database instances such as RDS, don’t allow unrestricted access to the RDS. Doing so increases the risk of brute-force login attacks.
• Delete unused security groups as soon as possible. It is a good practice to have regular clean-up exercise on your AWS project environment to ensure there are no unused security groups.
• Restrict access to security group modification or creation using appropriate IAM policies.

Conclusion

Proper management and use of AWS Security Groups is essential for the security of your applications. Any miss in security groups can make your applications vulnerable to attacks or misuse.

In this post, we took a deep dive into AWS Security Groups and how they are created. We explored a few important patterns on using security groups.

Lastly, we also understood the rules behind security groups and also looked at the best practices while working with Security Groups.

I hope the post was useful. If you have any queries or comments, do sound off in the comments section below.

Happy Learning!