AWS Security Groups Guide

Originally published by Sysdig.

Written by Brett Wolmarans, Sysdig.

AWS Security Groups (and Network ACLs and VPCs) are some of the fundamental building blocks of security in your cloud environment.

They are similar to firewalls, but are ultimately different. You have to understand this topic very well before you begin building in the cloud, because there are some subtle differences in how they are used, and you need to follow best practices.

You should know your public cloud provider is contractually bound to honor its side of a shared responsibility model. But security groups are your responsibility. By default, when you launch an EC2 instance, the only default rule is port 22 for SSH access for Linux instances.

You’re going to need more. For example, you might be creating a web server that listens on both port 80 for HTTP and port 443 for HTTPS. And you want to make your web server available to the entire Internet, or 0.0.0.0/0 as we like to call it. Without security groups allowing traffic from 0.0.0.0/0 to port 80 and port 443, this traffic will not be allowed and your web service will basically be isolated.

So, not only do you need Security Groups in terms of attack surface, you also need to configure these correctly just to get basic traffic working.

In this blog post, you will learn the information and best practices you need for configuring and securing your network in your AWS cloud.

What are Security Groups in AWS?

In AWS, a security group is a collection of rules that control inbound and outbound traffic for your instances. When you launch an instance, you can specify one or more security groups.

NOTE: We can’t talk about security groups without mentioning Amazon Virtual Private Cloud (VPC). Amazon VPC is a virtual network that resembles a traditional network. Like a traditional network, your VPC has IP addresses, subnets, route tables, Internet gateways, and more. Of course, it also has firewalls, which in this case means security groups.

If you don't specify a security group, Amazon EC2 uses the default security group. For example, after you associate a security group with an EC2 instance, inbound and outbound traffic for that instance will follow the rules of the security group. Security Groups apply to just instances, not the whole subnet.

Security Groups are stateful, ingress equals egress. Traffic that matches a rule for one direction will also be allowed automatically in the opposite direction.

Security groups are part of the EC2 Service in the AWS Console:

Security Groups are also found under the EC2 Service in the AWS CLI. Here we create a security group:

aws ec2 create-security-group --group-name web-pci-sg --description "allow SSL traffic" --vpc-id vpc-555666777

And here we add a rule to our security group:

aws ec2 authorize-security-group-ingress \
    --group-name web-pci-sg \
    --protocol https \
    --port 443 \
    --cidr <IP Subnet/Netmask>

Here is an example of AWS Security Groups associated with an instance:

Note that you can’t create deny rules for security groups - you can only create allow rules. Deny is by default. Below, notice you can only create “allow” rules, and anything not permitted is denied. This can be confusing for beginners:

Why do you need Security Groups?

You need Layer 3 and Layer 4 filtering in the cloud, just as you would in the physical world. And traditional firewalls might work, but a virtual firewall that is not cloud native might add administrative overhead and cost.

Security groups have several advantages. An obvious advantage is they are free, you can use as many of them as you like. They can be applied on top of different services, you can create them beforehand, and they are reusable. Create security groups like you would categories, then apply them to groups of instances that need a common filtering strategy.

Contrast this to configuring local firewalling such as iptables on individual instances. You would have to try to do it through scripting, userdata injection, or some other method, and security groups start to look like a better approach.

Which services need Security Groups?

Although most commonly used with compute instances, there are several AWS services that rely on security groups.

Of these services, Amazon EC2 is one of the most widely used. You should look further into this if you are wondering how to secure Amazon EC2 in general, especially if you want to fully understand securing SSH on Amazon EC2.

But more than just Amazon EC2, all of the following AWS services rely on Security Groups in some way:

• Amazon EC2 instances
• AWS Lambda
• AWS Elastic load balancing
• Databases (Amazon RDS, Amazon Redshift)
• Other (ElastiCache, CloudSearch, Elastic Beanstalk, Elastic MapReduce)
• Container and Kubernetes services (ECS and EKS)

What are Network Access Lists?

In AWS, Network access control lists (NACLs) are a collection of rules that control inbound and outbound traffic for subnets. NACLs’ rules are similar to security groups, but they apply to the whole subnet, not individual instances.

NACLs are stateless, ingress does not equal egress. Traffic that matches a rule for one direction will not be automatically allowed in the opposite direction. You would have to add an outbound rule.

Like security groups, NACLs are part of the EC2 service, as shown here in the AWS CLI:

Using the AWS CLI, we create a NACL:

aws ec2 create-network-acl --vpc-id vpc-a01106c2

And here we create a rule for our NACL:

aws ec2 create-network-acl-entry --network-acl-id acl-5fb85d36 --ingress --rule-number 100 
--protocol udp --port-range From=53,To=53 --cidr-block 0.0.0.0/0 --rule-action allow

However, and this is important, in the AWS Console, you won’t find NACLs in the EC2 service. Instead, you find them under the VPC Service:

Here is an example of some NACLs and as you can see, they are associated with subnets, not with instances:

And here is an example of NACL showing the rules associated with a subnet:

Remember that unlike security groups which only have allow rules, NACLs have both allow and deny rules:

How do AWS Security Groups and NACLs work together?

AWS security groups and AWS network access control lists can be used to secure your network — on their own and together. When following best practices, NACLs and security groups provide effective protection at Layers 3 and 4. Just remember, they do not protect against volumetric DDOS or any sophisticated attacks. For this type of protection at Layers 3 and 4, you could consider options such as AWS Shield. For Layer 7 protection, you should look into some type of Web Application Firewall. AWS security groups and Network ACLs will not help at Layer 7.

How are these two filtering services similar, and how are they different? There are several key areas to look at:

It can be helpful to visualize the stateful nature of AWS security groups vs. the stateless nature of NACLs.

Here, we see that without any outbound rules on the network ACL, traffic is blocked outbound. But with the outbound rule added, traffic flows correctly.

Whereas with the security group, because it is stateful, traffic is permitted outbound automatically once the inbound connection is established.

AWS CIS Benchmarks

Once you have understood and deployed your security groups, you should consider checking them against one or more benchmarks. Particularly do this if you have a large cloud where it is difficult to keep track of which security groups are configured correctly.

There are several benchmarks that have requirements and controls for AWS Security Groups. Here, we will look at two of these: CIS AWS Foundations Benchmark and PCI-DSS Standards.

Security Groups in the CIS AWS Foundations Benchmark 1.5

This CIS AWS Guidelines and Benchmarks 1.5 includes the following controls for security groups and NACLs. To obtain the latest version of this guide, including steps on how to configure these recommendations, please visit https://benchmarks.cisecurity.org and check the page for updates.

AWS Security Groups in the PCI-DSS Standard

Another important standard if you are taking payment cards on your website is the PCI Standard. This standard was created by the payment card brands. Validation of compliance is performed annually or quarterly. The full PCI standard is available at https://www.pcisecuritystandards.org/

AWS describes the following PCI controls for security group rules on its page, and more details can be found there on how to configure these controls. You can check that page for updates.

AWS Security Groups best practices

The following best practices are general guidelines. They may not cover all your use cases, but are a good, helpful starting point.

• Security group rules should not have large port ranges. Doing so makes your attack surface much larger.
• VPC flow logs should be, at a minimum, enabled on inter-VPC flows and internet flows. Logging traffic within the same VPC can be useful for debugging. For more information, see Publish flow logs to CloudWatch Logs.
• Remove unused security groups. Large numbers of unused or unattached security groups create confusion and invite misconfiguration. Remove any unused security groups.
• Limit modification to authorized roles only. Not every IAM user or role should be able to modify security groups.
• Monitor the modification of security groups. It is important to know when a security group is created or deleted or changed, as this has security implications.
• Don’t ignore the outbound or egress rules. Limit outbound access to just the subnets that are needed. For example, in a three-tier web application, the app layer likely shouldn’t have unrestricted access to the internet, so configure the security group to allow access to only those hosts or subnets needed for the application to function correctly.

If you want to dig deeper, take a look at AWS VPC best practices.

Managing AWS Security Groups

You need constant monitoring and visibility of your security groups to keep them correctly configured.

If you have more than a few security groups, you will need to use the AWS CLI or AWS API as these are much easier than using the AWS console, which can be very tedious and error prone.

You also have the option of enabling and deploying AWS Firewall Manager, which in some ways addresses this pain. But it comes with an additional cost, and has preconditions such as requiring AWS Organizations. If you can handle it, AWS Firewall Manager will allow you to audit existing security groups for your Amazon EC2, Application Load Balancer (ALB), and ENI resource types, and configure new security groups.

Verifying AWS Security Groups

You may have a small or large cloud, but no matter the size, it can be very painful to try to manually confirm you have security groups configured in a safe manner. Instead, consider using Cloud Security Posture Management (CSPM) tools to help you understand if your security groups are correctly configured.

Even basic CSPM is helpful, but you should also be aware of advanced policy tools that allow you to create custom policies. And no mention of CSPM is complete without also mentioning continuous threat detection. Continuous scanning helps you understand risky changes to your cloud between CSPM scans.

AWS CloudTrail, by default, does a great job of logging all changes, and continuous cloud threat detection can be built on top of this. If you would like to learn more, you should read our AWS Threat Detection blog post.

Conclusions

Knowing how security groups and NACLs work together is extremely important for controlling network traffic to your instances and subnets. If you do not understand this, you will run into difficulties.

Once you deploy your security groups the right way, you need to validate your deployment and check for threats and drift. One good approach is by using CSPM tools that run daily scans combined with continuous scanning of AWS CloudTrail logs to surface any risky or non-compliant activity.

AWS security groups and NACLs are not hard to use once you understand them.

Follow the AWS security groups best practices listed in this article and get your security groups under control.