Skip to main content

More Info:

Your AWS EC2 default security groups should restrict all inbound public traffic in order to enforce AWS users (EC2 administrators, resource managers, etc) to create custom security groups that exercise the rule of least privilege instead of using the default security groups.

Risk Level

Low

Address

Security

Compliance Standards

PCIDSS, MAS, APRA

Remediation

How to ensure default Security Group does not allow unrestricted inbound access

Using AWS Console

  1. Open the AWS Management Console and navigate to the Amazon EC2 service.
  2. From the left navigation pane, click on “Security Groups” to view the list of security groups. (In the Cloudanix Console, navigate to “Misconfig” page and look for Affected Assets for “Default Security Groups Should Not Allow Unrestricted Inbound Access” Policy.)
  3. Look for the default security group in the list. By default, it is named “default” and should be associated with your VPC.
  4. Select the default security group by clicking on its name.
  5. In the “Inbound Rules” tab, review the existing inbound rules configured for the default security group.
  6. Identify any rules that allow unrestricted access (such as allowing all traffic from any source).
  7. To remove an unrestricted rule, click on the “X” button next to the rule to delete it.
  8. Alternatively, you can edit the rule by clicking on the “Edit” button and modifying the source IP range or protocol/port to restrict the access.
  9. Repeat the process for all unrestricted inbound rules until the default security group only allows the necessary and restricted inbound access.
  10. Once you have updated the rules, click on the “Save rules” button to apply the changes.

Triage and Remediation

Remediation

Using Console

Below are concise, console-based steps to remediate “Default Security Groups allow unrestricted inbound access” in AWS.

1. Identify default security groups with open inbound access

  1. Sign in to the AWS Management Console.
  2. Go to EC2.
  3. In the left navigation pane, choose Security Groups.
  4. In the filter/search bar, type default and press Enter.
  5. In the Group Name column, look for security groups named default (one per VPC).
  6. For each default SG:
    • Select it and check the Inbound rules tab.
    • Look for rules with:
      • Type = All traffic, All ICMP, SSH, RDP, Custom TCP/UDP, etc.
      • Source = 0.0.0.0/0 and/or ::/0 (unrestricted).

2. Remove unrestricted inbound rules on the default security group

For each default security group that has 0.0.0.0/0 or ::/0 in inbound rules:
  1. Select the default security group.
  2. Choose the Inbound rules tab.
  3. Click Edit inbound rules.
  4. For each rule where:
    • Source is 0.0.0.0/0 or ::/0, and
    • It is not needed for VPC-internal communication:
      • Click the X at the end of the row to remove it.
  5. Make sure that if you need instances in the same security group to talk to each other, you keep (or add) a rule like:
    • Type: All traffic (or the specific required ports)
    • Protocol: All (or needed)
    • Port range: All (or needed)
    • Source: The security group itself (select from dropdown under Custom → SG ID).
  6. Click Save rules.
Note: You cannot delete a default security group, only modify its rules.

3. Create and use dedicated security groups for external access

To avoid using the default SG for internet-exposed services:
  1. In Security Groups, click Create security group.
  2. Enter:
    • Security group name: e.g., web-servers-sg.
    • Description: e.g., Security group for public web servers (HTTP/HTTPS only).
    • VPC: Select the correct VPC.
  3. Under Inbound rules, add only what’s needed, with limited source ranges, for example:
    • Rule 1:
      • Type: HTTP
      • Port: 80
      • Source: Your office IP /32 or specific CIDR (not 0.0.0.0/0 if possible).
    • Rule 2:
      • Type: HTTPS
      • Port: 443
      • Source: As above.
    • For SSH/RDP, use:
      • Type: SSH / RDP
      • Source: Admin IPs only (never 0.0.0.0/0).
  4. Click Create security group.
Attach this new SG to instances instead of using the default:
  1. Go to Instances.
  2. Select the instance currently using the default security group.
  3. Choose ActionsSecurityChange security groups.
  4. Check your new SG (e.g., web-servers-sg) and uncheck the default SG (if safe to do so).
  5. Click Apply.

4. Confirm remediation

  1. Return to Security Groups.
  2. For each default SG:
    • Confirm there are no inbound rules with 0.0.0.0/0 or ::/0.
  3. Optionally, use Reachability Analyzer or test from the internet to ensure ports are no longer globally open.
This ensures default security groups no longer allow unrestricted inbound access while preserving required internal communication and moving internet exposure to dedicated, controlled security groups.
Below is a concise, CLI‑only way to lock down default Security Groups so they don’t allow unrestricted inbound (0.0.0.0/0 or ::/0).

1. Identify default Security Groups that allow unrestricted inbound

Look for:
  • IpRanges with CidrIp: "0.0.0.0/0"
  • Ipv6Ranges with CidrIpv6: "::/0"
These are the rules to remove.

2. Revoke all inbound rules on default Security Groups (safer baseline)

If you’re okay with removing all inbound rules from all default SGs in a region:
This ensures the default SG has no inbound rules (i.e., nothing is allowed in).

3. (Optional) Only remove “unrestricted” inbound rules

If you want to keep other, more restricted rules and only remove 0.0.0.0/0 or ::/0, you need to filter the permissions. One straightforward approach is to manually revoke specific rules once you’ve inspected them.Example: remove a specific inbound rule (TCP 22 from 0.0.0.0/0) from a known default SG:
Similarly for IPv6:
Repeat for each protocol/port combination you find with unrestricted access.

4. (Optional) Add safer, restricted inbound rules

After cleanup, if you need access from a known IP/CIDR:
This leaves the default Security Groups without any 0.0.0.0/0 or ::/0 inbound access.
Below is one straightforward way to remediate this using Python and boto3: identify default security groups that allow 0.0.0.0/0 or ::/0 inbound, then remove those rules.

1. Prerequisites

  1. Install boto3:
  2. Configure AWS credentials with sufficient permissions:
    • ec2:DescribeSecurityGroups
    • ec2:RevokeSecurityGroupIngress
    For example:

2. Python script to remove unrestricted inbound from default security groups

This script:
  • Enumerates all regions.
  • Finds default security groups.
  • Detects inbound rules with:
    • IPv4: 0.0.0.0/0
    • IPv6: ::/0
  • Revokes only those offending rules (leaves other rules intact).

3. Notes / Adjustments

  • If you only want to operate in a single region, replace get_all_regions() with a hard-coded list, e.g. regions = ["us-east-1"].
  • This script only removes the 0.0.0.0/0 or ::/0 inbound rules. It does not add replacement rules; if you need specific allowed CIDRs, add them explicitly with authorize_security_group_ingress.
This change updates the in‑place default security group (no replacement is forced, but rules will be revoked and recreated as needed).Verification: terraform plan should show the aws_default_security_group ingress rules from 0.0.0.0/0 (and/or ::/0) being removed and no new unrestricted inbound rules added.

Additional Reading: