VPC security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports (IPv4)
Exposing SSH or RDP to the entire internet is one of the most common vectors for unauthorized access. Automated scanners continuously probe 0.0.0.0/0-open port 22 and port 3389 endpoints, and a single compromised credential or unpatched vulnerability gives an attacker direct shell or desktop access to your instance. Brute-force attempts against these ports are constant and fully automated.
Restricting ingress to known CIDR blocks, bastion hosts, or AWS Systems Manager Session Manager removes this attack surface. The fix is a CIDR change or a Session Manager migration; the cost of not fixing it is a publicly reachable admin port.
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
This control inspects every aws_vpc_security_group_ingress_rule and aws_security_group_rule (with type = "ingress") resource in the plan. It fails when cidr_ipv4 (or the legacy cidr_blocks) includes "0.0.0.0/0", the port range covers port 22 or 3389, and ip_protocol is "tcp", "udp", or "-1" (all traffic). To pass, either narrow the CIDR to a specific range (e.g., your corporate VPN block), change the destination ports to exclude 22 and 3389, or remove the rule entirely.
The same logic applies to inline ingress {} blocks inside aws_security_group, evaluated against each block's cidr_blocks, from_port, to_port, and protocol arguments. Rules using referenced_security_group_id or source_security_group_id instead of a CIDR are not flagged. Rules that set from_port = 0 and to_port = 65535, or ip_protocol = "-1", also fail because those ranges cover both 22 and 3389.
Common pitfalls
Port ranges that silently include 22 or 3389
Wide port ranges from debugging sessions are a common source of this finding. A rule with from_port = 0 and to_port = 65535 (or ip_protocol = "-1") covers all ports, 22 and 3389 included. The control flags these correctly even though the port numbers aren't explicitly named. Scope rules to the minimum required range before they reach production.
Legacy inline ingress blocks in aws_security_group
Migrating from inline ingress {} blocks to standalone aws_vpc_security_group_ingress_rule resources is worth doing regardless of this control. Inline blocks can't be managed individually, and Terraform doesn't detect conflicts between inline blocks and standalone rule resources. That mismatch leads to drift and unexpected overwrites during applies.
IPv4 only, missing IPv6 coverage
This control only checks 0.0.0.0/0. If your VPC has IPv6 enabled, a rule allowing ::/0 to port 22 or 3389 won't be caught here. A separate control covers the IPv6 case. Don't treat a clean result from this check as full coverage if dual-stack VPCs are in scope.
Security groups attached to unused ENIs
Get this wrong and you'll find the remediation is required even for groups with no attached interfaces. Auditors and automated scanners don't check attachment status. A 0.0.0.0/0 rule on port 22 fails this control regardless of whether the group is currently in use. Remove or restrict the rule rather than relying on the group being unattached.
Audit evidence
Auditors look for AWS Config rule evaluations, specifically restricted-ssh and restricted-common-ports, showing all security groups as COMPLIANT. Output from Prowler or Security Hub listing zero findings for unrestricted SSH/RDP access across all regions is strong supporting evidence. VPC Flow Log summaries showing no inbound connections from 0.0.0.0/0 on ports 22 or 3389 further corroborate the control.
Supporting artifacts include a Security Hub "Security standards" dashboard screenshot with this check passing, or an export of all security group rules via aws ec2 describe-security-groups filtered for port 22 and 3389 with 0.0.0.0/0, returning empty results.
Framework-specific interpretation
SOC 2: CC6.1 and CC6.6 are what examiners check for logical access and system boundary controls. Unrestricted ingress to management ports on any in-scope system is a clear CC6.6 boundary failure. Network-level restrictions are expected as the first control layer, not a compensating control.
PCI DSS v4.0: Requirements 1.2.7 and 1.3.1 both say inbound traffic must be limited to what is necessary. Requirement 7 adds least-privilege access to cardholder data environment components. Open SSH or RDP from the internet to any in-scope system fails all three.
HIPAA Omnibus Rule 2013: On systems that store or process ePHI, allowing 0.0.0.0/0 access to port 22 or 3389 violates the technical access control requirements at 45 CFR 164.312(a)(1). Restricting security group ingress to known networks is the baseline network-level safeguard HIPAA expects for any system in scope.
ISO/IEC 27001:2022: A.8.20 (Network Security) and A.8.21 (Security of Network Services) require that network access be managed and controlled. A.8.21 specifically calls out securing network services against unauthorized access, which is exactly what this rule tests. Unrestricted internet access to administrative ports fails both controls on their face.
NIST SP 800-53 Rev 5: SC-7 (Boundary Protection) and AC-4 (Information Flow Enforcement) both apply here. Security groups are boundary devices, and permitting 0.0.0.0/0 to administrative ports fails the requirement to control communications at managed interfaces. AC-17 (Remote Access) adds that remote access methods must be controlled and monitored, which an open port 22 clearly is not.
NIST Cybersecurity Framework v2.0: PR.AA and PR.PS together cover identity and access control alongside platform security. Blocking public access to administrative ports is a direct PR.PS measure. It removes an unauthorized remote access pathway before authentication is even in play, which is exactly the layered defense both subcategories call for.
FedRAMP Moderate Baseline Rev 4: At the Moderate baseline, SC-7 and AC-4 require security groups to restrict administrative access to authorized source addresses only. FedRAMP assessors verify this during the assessment, and open 0.0.0.0/0 rules on port 22 or 3389 land as high-severity findings in the Security Assessment Report.
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_ipv4 - AWS Config Managed Rules:
VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS,VPC_SG_PORT_RESTRICTION_CHECK - Powerpipe Controls:
aws_compliance.control.vpc_security_group_remote_administration,aws_compliance.control.vpc_security_group_remote_administration_ipv4 - AWS Security Hub Control:
EC2.18 - Trivy Check:
AWS-0107
Last reviewed: 2026-03-09