# Ensure VPC security groups do not allow wide-open public IPv4 CIDR ranges (/1 to /23) - Source: https://support.icompaas.com/support/solutions/articles/a_1793292227997584-ensure-vpc-security-groups-do-not-allow-wide-open-public-ipv4-cidr-ranges-1-to-23 - Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224) - Last updated: 2026-10-29 - Publisher: iCompaas, Inc. (https://www.icompaas.com) **Description** Ensure that no Amazon EC2 security group has an inbound or outbound rule that allows a wide public IPv4 range. A range is considered wide open when it is a public (non-RFC1918) IPv4 CIDR block with a prefix length between /1 and /23, for example 52.0.0.0/8. Rules should allow only specific, trusted public addresses (/24 or narrower, preferably /32) or private network ranges. **Rationale** Rules that allow large public address ranges expose resources to many hosts outside your control, increasing the risk of unauthorized access, exploitation and disruption from scanning or abuse. Wide outbound rules also make it easier for compromised resources to reach command-and-control servers or exfiltrate data. Allowing only known addresses, using private connectivity such as VPN, AWS Direct Connect or VPC endpoints, and restricting egress applies least privilege. **Impact** - Reduces the number of external hosts that can reach, or be reached from, your resources - Lowers the risk of unauthorized access and data exfiltration - Clients or destinations within the removed ranges will lose connectivity until their specific addresses are allowed **Default Value** A new security group has no inbound rules and one outbound rule that allows all traffic to 0.0.0.0/0. It has no wide public IPv4 ranges with a prefix length between /1 and /23 unless such rules are added explicitly. **Pre-Requisites** - IAM permissions: ec2:DescribeSecurityGroups, ec2:DescribeSecurityGroupRules, ec2:DescribeNetworkInterfaces, ec2:RevokeSecurityGroupIngress, ec2:RevokeSecurityGroupEgress, ec2:AuthorizeSecurityGroupIngress and ec2:AuthorizeSecurityGroupEgress - A list of the specific public IP addresses or narrow ranges that legitimately need access - Confirmation from the application owner that no required client or destination depends on the wide ranges **Remediation** **Test Plan** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon EC2 console and select **Security Groups** under **Network & Security**. 3. Select a security group and open the **Inbound rules** and **Outbound rules** tabs. 4. Check for any rule whose source or destination is a public IPv4 CIDR block with a prefix length between /1 and /23 (private ranges such as 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16 are not counted). 5. Repeat for each security group in each region in use. 6. If such a rule exists, follow the implementation steps. **CLI:** Check whether a security group is in use (attached to a network interface): aws ec2 describe-network-interfaces --region --filters Name=group-id,Values= --query "NetworkInterfaces\[\].NetworkInterfaceId" List the IPv4 rules of the security group: aws ec2 describe-security-group-rules --region --filters Name=group-id,Values= --query "SecurityGroupRules\[?CidrIpv4!=null\].\[SecurityGroupRuleId,IsEgress,IpProtocol,FromPort,ToPort,CidrIpv4\]" --output table The security group fails if any inbound or outbound rule has a public IPv4 CIDR block with a prefix length between /1 and /23. Rules for 0.0.0.0/0, private ranges and IPv6 ranges are not counted by this control, and only security groups attached to a network interface are evaluated. **Implementation Steps** **Console:** 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Open the Amazon EC2 console and select **Security Groups** under **Network & Security**. 3. Select the security group found in the Test Plan. 4. Choose **Edit inbound rules** and, for each rule with a public IPv4 CIDR block between /1 and /23, either: - change the CIDR to the specific trusted address or a range of /24 or narrower, or - change the source to a private range or a security group, or - delete the rule if it is not needed. 5. Choose **Save rules**. 6. Repeat steps 4 and 5 using **Edit outbound rules** for the outbound rules. 7. Repeat for each affected security group in each region in use. **Backout Plan** Before making changes, save the current rules: aws ec2 describe-security-group-rules --region --filters Name=group-id,Values= > -rules-backup.json To roll back: 1. Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/). 2. Go to **EC2 > Security Groups** and select the security group. 3. Choose **Edit inbound rules** or **Edit outbound rules**. 4. Re-add or restore the changed rules using the saved backup (protocol, port range and CIDR). 5. Choose **Save rules**. Note: rolling back re-exposes the resources to the wide public ranges. Use it only as a temporary measure while access from specific addresses is arranged. **Reference** - [https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) - [https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) - [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-security-group-rules.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-security-group-rules.html) ## Related compliance guidance - [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them. - [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.