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.
AWS Security Group Best Practices [Cheat Sheet]
In this 10 page cheat sheet we'll cover best practices for AWS Security Groups in the following areas: Traffic management, Advanced monitoring, Automation and scalability, Security enhancements.
Download Cheat Sheet
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
ALLOWrules, while NACLs accommodate bothALLOWandDENYrules.
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.
AWS Security Foundations For Dummies
Everything you need to know to protect your AWS environment
Download now
Best practices and recommendations
Leverage the least-privilege principle
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:
aws ec2 create-security-group --group-name MySecurityGroup --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:
aws ec2 authorize-security-group-ingress --group-name MySecurityGroup --protocol tcp --port 22 --cidr 201.0.100.0/24Best 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:
aws ec2 authorize-security-group-ingress --group-name WebServerSG --protocol tcp --port 80 --cidr 0.0.0.0/0 aws ec2 authorize-security-group-ingress --group-name WebServerSG --protocol tcp --port 443 --cidr 0.0.0.0/0Consider the stateful nature of SGs
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:
aws ec2 authorize-security-group-ingress --group-name MySecurityGroup --protocol tcp --port 80 --cidr 201.0.100.0/24Actionable AWS Security Best Practices [Cheat Sheet]
This cheat sheet goes beyond the essential AWS security best practices and offers actionable step-by-step implementations, relevant code snippets, and industry- leading recommendations to fortify your AWS security posture.
Download now
Avoid overly permissive rules
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:
aws ec2 authorize-security-group-ingress --group-name MySecurityGroup --protocol tcp --port 22 --cidr 0.0.0.0/0Best 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:
aws ec2 authorize-security-group-ingress --group-name MySecurityGroup --protocol tcp --port 22 --cidr 180.170.1.0/24Carry out regular audits
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 (201.0.111.0/24) has access to port 22:
aws configservice put-config-rule --config-rule '{
"ConfigRuleName": "restricted-ssh",
"Description": "Checks whether security groups allow unrestricted SSH traffic",
"Scope": {
"ComplianceResourceTypes": ["AWS::EC2::SecurityGroup"]
},
"Source": {
"Owner": "AWS",
"SourceIdentifier": "RESTRICTED_INCOMING_TRAFFIC"
},
"InputParameters": "{\"blockedPort1\":\"22\",\"allowedCidr\":\"201.0.111.0/24\"}"
}'Name and describe
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.
aws ec2 create-security-group --group-name MyApp-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:
aws ec2 authorize-security-group-egress --group-id sg-0123456789abcdef0 --protocol tcp --port 443 --cidr 0.0.0.0/0Best 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:
aws ec2 authorize-security-group-egress --group-id sg-0123456789abcdef0 --protocol tcp --port 443 --cidr <Third-Party-Service-IP>/32Integrate with AWS flow logs
Flow logs provide a deep look into your VPC traffic, aiding in monitoring and troubleshooting.
Best practice: Maintain visibility
By analyzing flow logs, you can understand traffic patterns, detect anomalies, and troubleshoot connectivity issues. Enabling flow logs for a VPC is straightforward:
aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-0123456789abcdef0 --traffic-type ALL --log-destination-type cloud-watch-logs --log-group-name MyFlowLogsBest practice: Implement a retention policy
Set up policies for how long to retain your logs, balancing between storage costs and historical data needs. For instance, you can set a retention policy of 30 days for a CloudWatch Logs group:
aws logs put-retention-policy --log-group-name MyFlowLogs --retention-in-days 30Create backup and recovery protocols
Ensuring that your security group configurations are backed up and can be quickly restored is crucial for business continuity.
Best practice: Back up your SG rules
Regularly back up your security group rules to ensure you can quickly recover from misconfigurations or failures. It’s easy to get a security group description and save it as a JSON file:
aws ec2 describe-security-groups --group-names MyWebSG > MyWebSG-backup.jsonBest practice: Plan for disaster recovery
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.
AWS Shield
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).
aws wafv2 create-web-acl --name "MyWebACL" --scope REGIONAL --default-action Allow={} --visibility-config SampledRequestsEnabled=true,CloudWatchMetricsEnabled=true,MetricName=WebAclExample
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.
Other security best practices you might be interested in:
