AWS Security Groups are a flexible tool to help you secure your Amazon EC2 instances. AWS Security Groups are just one of several tools AWS offers to help you secure your cloud environment, but that doesn’t mean AWS security is hands-off. You’re still responsible for securing your applications and data in the cloud, and that means you need to leverage additional tools, such as Threat Stack, to gain better visibility and take a proactive approach to security in the cloud. Threat Stack is an AWS Advanced Technology Partner, offering an intrusion detection platform that’s built in AWS, to serve AWS.
As we found in a recent survey, nearly three-fourths of companies have at least one critical AWS security misconfiguration. That’s why it’s imperative to understand the various tools AWS makes available to users and how to best utilize them to keep your data secure. Here’s a look at how AWS Security Groups work, the two main types of AWS Security Groups, and best practices for getting the most out of them.
Definition of AWS Security Groups
AWS Security Groups act like a firewall for your Amazon EC2 instances controlling both inbound and outbound traffic. When you launch an instance on Amazon EC2, you need to assign it to a particular security group.
After that, you can set up ports and protocols, which remain open for users and computers over the internet.
AWS Security Groups are very flexible. You can use the default security group and still customize it according to your liking (although we don’t recommend this practice because groups should be named according to their purpose.) Or you can create a security group that you want for your specific applications. To do this, you can write the corresponding code or use the Amazon EC2 console to make the process easier.
How AWS Security Groups Differ From Traditional Firewalls
Traditional firewalls can be rigid and limiting. AWS Security Groups, on the other hand, allow you to specify permissive rules. You cannot deny traffic.
This is very important to remember because at its most basic, and without setting rules, all traffic is blocked. If a data packet has no particular rule that permits it to go through, it will be dropped instantly.
How AWS Security Groups Work
You can customize AWS Security Groups according to your needs. You need to give each group a unique name that will allow you to select it from a menu. It’s better if you give a group a descriptive name so you can choose the best one for your needs without having to look into the ruleset for that particular group.
Descriptive names have a 255-character limit and can be alphanumeric only; spaces with some special characters are allowed. Also, you cannot use a name that starts with sg-. You need to use unique names within the same VPC.
You also need to create a security group that is in the same VPC as the resources you want to protect. Remember, however, you can only create a limited number of security groups on every VPC that you have. There is also a limit on the number of rules you can add to one security group. Furthermore, there is a limited number of security groups that you can use with a network interface.
As described above, there are no deny rules in AWS Security Groups, only allow rules. But you can specify different rules for outbound and inbound traffic.
Also, remember that AWS Security Groups are stateful. This means that when you send a request from your instance, you will get a response to that request, disregarding the ruleset for your inbound security group. Meanwhile, replies to allow inbound traffic are going to be allowed to flow out, even if you do not have an outbound rule that explicitly allows it to go out.
Some people make the mistake of thinking that instances using the same security group are able to communicate with one another. This is not necessarily true: You need to create a rule that allows this. The default security group, however, has these rules turned on by default.
The Default AWS Security Group
Every virtual private cloud has a default security group, and each instance you launch will be associated with this default security group. This means that if you don’t do anything, such as associate a different security group, all your instances will be associated with the default security group.
By default, all protocols and port ranges from instances in the same security group are going to be allowed. Also, all traffic going to 0.0.0.0. and ::/0 will be allowed.
You can change these rules as you wish. You cannot, however, delete a default security group from your VPC.
Types of AWS Security Groups
Currently there are two types of AWS Security Groups: Those for EC2-Classic and those for EC2-VPC
If you are currently using Amazon EC2, then you know what a security group is. But you cannot use a security group that you have created for EC2-Classic in EC2-VPC or vice versa. You will need to create a security rule for your VPC even if a similar one has been created for your EC2.
These two types of security groups have a few similarities and differences:
- With EC2-Classic, you can only create inbound rules, but with EC2-VPC, you can create inbound rules and outbound rules.
- When you have already launched an instance, you cannot assign a different security group to it. But with an EC2-VPC, you can change the assigned group.
- Also, when you add a rule to EC2-Classic security groups, you no longer have to specify a protocol. You need to do this with EC2-VPCs.
Best Practices for Using AWS Security Groups
You can leverage a number of best practices and tips to make the most effective use of AWS Security Groups and enhance your overall security posture:
- You should enable flow logging of your VPC. These logs give you full visibility into the type of traffic that goes through the VPC. Flow logging can help you detect problematic traffic and give you valuable insights. It can also help you solve access and security issues. For instance, the flow log can help you see whether there are security groups that are very permissive.
- EC2 security groups should not have large port ranges. If this is the case, vulnerabilities can easily be exposed or exploited.
- Do not allow unrestricted access to RDS instances. RDS will log failed login attempts, but will not block repeated failures. Leaving an instance open to the internet leaves one in danger of brute-force login attacks. You should also restrict access to clusters in Amazon Redshift.
- Use discrete security groups less frequently so you can avoid misconfigurations that could give rise to account compromise.
- Limit outbound access from ports to specific ports or destinations only. Also, do not allow unrestricted inbound access to uncommon ports.
- Do not allow access through port 445, for example, which is commonly used for CIFS (Common Internet File System). Also, only allow FTP transfers through port 20 or 21, and only after being restricted to required entities.
Depending on what technologies, services, and protocols you are using (such as MySQL, Oracle Database, remote desktop, or SMTP), there is a set of best practices to use with AWS Security Groups. Be sure you take time to become familiar with these as well before you start using security groups.