VPC security groups should not allow ingress from ::/0 to remote server administration ports
An open ::/0 ingress rule on port 22 or 3389 exposes instances to brute-force attacks, credential stuffing, and exploitation of unpatched SSH or RDP vulnerabilities from any IPv6 source on the internet. IPv6 rules get missed because engineers focus on 0.0.0.0/0 and forget dual-stack configurations, leaving an identical attack surface unguarded.
Restrict administrative access to specific trusted IPv6 prefixes, or use AWS Systems Manager Session Manager or EC2 Instance Connect to eliminate the need for open inbound ports entirely.
Implementation
Choose the approach that matches how you manage Terraform.
Use AWS provider resources directly. See docs for the resources involved: aws_vpc_security_group_ingress_rule.
resource "aws_vpc_security_group_ingress_rule" "this" {
cidr_ipv4 = "0.0.0.0/0"
from_port = 443
ip_protocol = "tcp"
security_group_id = "sg-abc12345"
to_port = 443
}What this control checks
The control evaluates aws_vpc_security_group_ingress_rule resources and legacy aws_security_group_rule resources with type = "ingress", checking that no rule pairs cidr_ipv6 = "::/0" with a port range covering port 22 or 3389. from_port and to_port must not encompass either port when the IPv6 CIDR is fully open. A rule with cidr_ipv6 = "fd00::/8" (a ULA prefix) passes; cidr_ipv6 = "::/0" with from_port = 22 and to_port = 22 fails. The same logic applies to port 3389. Inline ingress blocks on aws_security_group are evaluated identically against ipv6_cidr_blocks containing ::/0. To pass, narrow the IPv6 CIDR to a trusted prefix or remove the rule for these ports.
Common pitfalls
Wide port ranges that silently include 22 or 3389
A rule with from_port = 0 and to_port = 65535, or protocol = "-1", paired with cidr_ipv6 = "::/0" fails this control even if ports 22 and 3389 aren't explicitly named. Any range that encompasses those ports triggers a violation.
Inline ingress blocks on aws_security_group
At scale, ipv6_cidr_blocks = ["::/0"] buried inside inline ingress blocks is easy to miss because the rule isn't visible as a standalone aws_vpc_security_group_ingress_rule. Policy engines still catch it, but your own code reviews won't. Migrate to standalone rule resources.
Dual-stack oversight: fixing IPv4 but missing IPv6
The most common pattern: a scan flags cidr_ipv4 = "0.0.0.0/0", the team removes it, and the corresponding cidr_ipv6 = "::/0" rule stays. Both have to go. If your VPC has assign_generated_ipv6_cidr_block = true on aws_vpc, instances can receive IPv6 traffic through those rules regardless of whether you intended it.
Security groups referenced by other resources
Tighten an ingress rule on a security group attached to an ELB, RDS instance, or ECS service without checking dependencies first, and you will break connectivity for workloads that rely on it. Map all aws_network_interface and security_groups references before modifying rules.
Audit evidence
Auditors expect AWS Config rule results (for example, restricted-common-ports or a custom rule targeting IPv6) showing all security groups as compliant, plus aws ec2 describe-security-groups output or a Console export confirming no ingress rules with ::/0 on ports 22 or 3389. AWS Security Hub findings or a CSPM tool configured for IPv6 coverage provide near-real-time detection of non-compliant groups. For change-level proof, CloudTrail events for AuthorizeSecurityGroupIngress and RevokeSecurityGroupIngress show that overly permissive rules were remediated and have not been reintroduced.
Framework-specific interpretation
SOC 2: A security group with ::/0 on port 22 or 3389 fails the boundary protection criteria SOC 2 auditors check under CC6.1 and CC6.6. Both criteria require that access to system components is restricted to authorized users and networks, not the full IPv6 internet.
PCI DSS v4.0: Requirement 1 calls for restricting inbound traffic to only what is necessary and explicitly authorized. Administrative ports open to all IPv6 sources fail that test outright. PCI also specifically limits remote administration access from untrusted networks, and ::/0 is untrusted by definition.
HIPAA Omnibus Rule 2013: 45 CFR 164.312(a)(1) requires access controls on systems that process or store ePHI. Open SSH or RDP from any IPv6 address means any host on the internet can attempt access, which is exactly what the technical safeguard is designed to prevent.
ISO/IEC 27001:2022: A.8.20 and A.8.21 cover network access control and protection of network services, and both expect management interfaces restricted to known sources. Open IPv6 ingress on ports 22 and 3389 violates both controls.
NIST SP 800-53 Rev 5: Unrestricted IPv6 ingress on management ports runs directly against AC-4, SC-7, and CM-7. Rev 5 tightens the least-functionality framing under CM-7: if the capability isn't needed from the open internet, the rule shouldn't exist.
NIST Cybersecurity Framework v2.0: Both Govern and Protect apply here. Govern's policy-driven access control says the rule shouldn't exist; Protect's infrastructure protection objective is what fails when it does.
FedRAMP Moderate Baseline Rev 4: AC-4 and SC-7 both apply. AC-4 enforces information flow policy at the network boundary; SC-7 requires that boundary deny traffic by default. Allowing ::/0 to port 22 or 3389 violates both, opening a management interface to the full IPv6 internet.
Related controls
Tool mappings
Use these identifiers to cross-reference this control across tools, reports, and evidence.
- Compliance.tf Control:
vpc_security_group_remote_administration_ipv6 - AWS Config Managed Rule:
VPC_SG_PORT_RESTRICTION_CHECK - Powerpipe Control:
aws_compliance.control.vpc_security_group_remote_administration_ipv6 - AWS Security Hub Control:
EC2.54 - Trivy Check:
AWS-0107
Last reviewed: 2026-03-09