AWS security groups (SGs) are virtual firewalls for your EC2 instances that control both inbound and outbound traffic.
Wiz Experts Team
8 min read
AWS security groups: A refresher
AWS security groups (SGs) are virtual firewalls for your EC2 instances that control both inbound and outbound traffic. Security groups play a fundamental role in AWS best practices. Each security group consists of rules that filter traffic, allowing or denying requests based on parameters like IP protocol, port number, and source/destination IP address or CIDR block.
When you create an instance, it can be linked to one or more security group(s). AWS automatically supplies a security group for each VPC by default. Still, to adhere to AWS default security group best practices, customize and create security groups tailored to your application needs.
The differences between security groups and network ACLs
Both AWS security groups and network access control lists (NACLs) control inbound and outbound traffic, but they operate at different layers and have distinct characteristics:
Scope: Security groups are associated with EC2 instances, while NACLs are associated with subnets.
Statefulness: Security groups operate in a stateful manner. This means that when an incoming request from an IP is permitted, its response is automatically authorized, irrespective of the outbound rules. On the other hand, NACLs are stateless, so inbound and outbound traffic rules are treated separately.
Rule evaluation: In AWS security groups, rules are evaluated based on the principle that the most specific rule wins. For NACLs, rules are assessed sequentially, beginning with the rule that has the lowest number.
Rule types: Security groups accommodate only ALLOW rules, while NACLs accommodate both ALLOW and DENY rules.
Understanding these differences is a crucial part of designing a robust and secure AWS infrastructure. By harnessing the unique features of both security groups and NACLs, organizations can achieve a more layered and effective defense strategy.
The principle of least privilege ensures that resources are accessible only to those entities that absolutely need it. Follow these three tips to implement the least-privilege principle effectively:
Best practice: Start with a “deny-all” rule
Starting with a ”deny-all” rule blocks unintended traffic. This is a foundational step in AWS best practices for security groups. By denying all traffic by default, you create a secure baseline and then explicitly allow only the necessary traffic. Use this code to create a security group with a "deny-all" default setting:
awsec2create-security-group--group-nameMySecurityGroup--description"My security group with deny-all default"
Best practice: Allow specific IPs or CIDR blocks
Opening up your resources to the entire internet (0.0.0.0/0) is a significant security risk. We always recommend being as selective about access as possible when defining your security group rules. This minimizes your potential attack surface.
When specifying rules, consider the principle of granularity. For instance, if only one IP address needs access to a resource, don't allow an entire CIDR block. Use this code to grant access to a specific CIDR block for SSH (port 22) on your security group:
Best practice: Design SG rules based on user roles
By categorizing your EC2 instances based on their roles, you can design security groups tailored to each role's specific needs. Role-based access ensures that each instance type has only the necessary ports open, reducing potential vulnerabilities.
For instance, a database server might only need its database port (e.g., 3306 for MySQL) open, while a web server might require ports 80 and 443:
Best practice: Know that two-way traffic is allowed
Due to the stateful nature of AWS security groups, if an inbound rule allows traffic from a specific IP, the return traffic is automatically allowed, even if there's no corresponding outbound rule. For instance, the following security group will allow two-way traffic over port 80 for the CIDR range:
Overly permissive rules can expose your resources to unnecessary risks. It's essential to strike a balance between accessibility and security. Follow these two best practices to strike that balance:
Best practice: Mitigate the risks of 0.0.0.0/0
Allowing traffic from all IPs with 0.0.0.0/0 CIDR range can expose your resources to various threats, from brute force attacks to potential data breaches. Sensitive ports like SSH (22) or RDP (3389) should not be made public. (That said, remember to restrict access to only those IPs or CIDR blocks that genuinely need it.) For instance, the following can expose your instances to potential brute force attacks from all over the world:
Best practice: Advocate for adding trusted IPs to your allowlist
Instead of focusing on what to block, focus on what to allow. Adopting an allowlist approach ensures that only known and trusted entities can access your resources. For instance, if you have an API server, allow only traffic on ports 80 and 443 that comes from trusted sources:
As your infrastructure grows and changes, it's crucial to regularly audit your security groups to ensure they still align with best practices and your organization's requirements.
Best practice: Use automation tools
Using tools to automate the audit process can save time and streamline your processes. AWS offers various services, like AWS Config, that can monitor changes in your security groups and ensure they comply with best practices. This proactive approach gives you peace of mind that potential issues are identified and rectified promptly. The following code snippet sets up an AWS Config rule named "restricted-ssh" that checks if security groups allow unrestricted SSH traffic and ensures only the specified CIDR block (220.127.116.11/24) has access to port 22:
Properly naming and describing your security groups can simplify management, especially as your infrastructure grows.
Best practice: Use standardized naming conventions
Adopting a consistent naming convention can help quickly identify a security group's purpose, particularly when you’re dealing with multiple security groups across different environments and projects. For instance, using a format like <ProjectName>-<Environment>-<Role> can provide clarity at a glance. A security group named "MyApp-Prod-WebServer" instantly conveys its purpose.
awsec2create-security-group--group-nameMyApp-Prod-WebServer--description"Production WebServer for MyApp"
Restrict outbound traffic
While a lot of emphasis is placed on controlling inbound traffic, managing outbound traffic from your EC2 instances is equally crucial.
Best practice: Prevent data exfiltration
Unrestricted outbound traffic can lead to potential data breaches, where malicious entities might exfiltrate sensitive data from your instances. For example, it could be helpful to restrict outbound traffic to allow only HTTPS (port 443) traffic:
Best practice: Customize access for third-party integrations
Ensure that your instances communicate exclusively with trusted external services. Unrestricted access can expose your resources to vulnerabilities in third-party services. If you need to integrate third-party services, allow outbound traffic only on a specific external service IP:
In case of emergencies or failures, have a plan in place to restore your security groups from backups. This plan should detail the steps to follow and the personnel responsible for each action. Regularly review and test this plan to ensure its effectiveness.
By following these best practices and regularly reviewing and updating your configurations, you can ensure that your AWS resources remain secure and resilient against potential threats.
Going beyond the basics
As you become more familiar with AWS security groups and start to master foundational best practices, it's essential to explore advanced tools and integrations that can further enhance your security posture. This section delves into these advanced topics, helping you keep your AWS infrastructure not only secure but also efficient and optimized.
Enhanced AWS tools for security groups
AWS offers a range of tools that can complement and enhance the capabilities of security groups, including VPC Traffic Mirroring, Shield, and WAF. Let’s take a look at each:
AWS VPC Traffic Mirroring
This feature allows you to capture and inspect network traffic on your VPC. By mirroring your traffic, you can identify anomalies or suspicious activities that traditional security tools might miss.
As its name suggests, this is a comprehensive service designed to shield AWS-based applications from distributed denial-of-service (DDoS) attacks. Integrating AWS Shield with your security groups can provide an additional layer of protection against DDoS attacks.
AWS WAF (web application firewall)
While security groups act at the instance level, AWS WAF operates at the application layer. It inspects web requests and can block common web-based attacks like SQL injections and cross-site scripting (XSS).
As we’ve seen, there’s a lot to consider when it comes to AWS security groups. To make sure you always have AWS security group best practices at your fingertips, download our comprehensive cheat sheet. This quick reference guide will help you follow the best practices described in this article—whether you're a beginner or an AWS expert.
And to enhance your AWS security posture further, schedule a demo of Wiz. Our industry-leading cloud security platform offers a holistic view of risks across your entire AWS environment. Trust Wiz to secure everything you build and run in the cloud.
Agentless full stack coverage of your AWS Workloads in minutes
Learn why CISOs at the fastest growing companies choose Wiz to help secure their AWS environments.