A Security Group Referencing Itself Silently Opens Every Port Inside a VPC

Symptom

An internal security review of an AWS VPC finds that a self-referencing security group rule, originally added to allow a database tier to talk to itself on port 5432, actually permits full TCP access between every instance that carries the security group, across every port from 0 to 65535. Traffic that should have been blocked between an application-facing bastion and an internal worker node, both members of the same security group, passes cleanly. VPC Flow Logs show ACCEPT entries for SSH, RDP-equivalent management ports and ephemeral service ports between hosts that operators assumed were isolated from each other by role.

False Assumption

The team assumed that a self-referencing security group rule limits traffic to the specific port written in that rule, because the console workflow for adding an intra-tier rule nudges administrators towards a single port entry. The actual rule stored in the security group used a port range of 0-65535 because an earlier troubleshooting session had temporarily widened the range to rule out a connectivity problem, and nobody narrowed it back down afterwards. Reviewers later reading the rule assumed the self-reference itself was the safety boundary, when the safety boundary is actually the combination of the source and the port range, and the port range had been left wide open.

Root Cause

The security group rule allows inbound TCP traffic from the security group’s own ID as the source, with a port range of 0 through 65535, rather than the single intended port. AWS security groups only restrict traffic to the ports specified in the rule; a self-reference restricts the source to members of the same group but does nothing to narrow the destination ports unless the rule author sets a specific port or a tight range. Because every instance that later gets tagged with this group inherits the same broad rule, the blast radius grows silently every time the group is attached to a new resource, including instances that were never intended to trust each other.

Impact

Every instance sharing the affected security group can reach every other instance in that group on any TCP port, including management protocols, internal APIs and any accidentally exposed service that binds to 0.0.0.0. A single compromised instance within the group, for example through a vulnerable application dependency, can pivot laterally to any other instance in the group without needing to bypass a single additional network control, because the security group itself is the only network boundary between them and it currently permits everything.

Diagnosis

Confirm the finding using read-only AWS CLI calls before changing anything. Describe the security group and inspect its ingress rules for the self-referencing entry and its port range, then cross-reference VPC Flow Logs for ACCEPT records between members of that group on ports outside the intended service range.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 --query "SecurityGroups[0].IpPermissions"

Expected evidence: at least one ingress permission entry whose UserIdGroupPairs source is the same group ID as sg-0123456789abcdef0, with FromPort 0 and ToPort 65535, confirming the rule is broader than a single service port. Also confirm which resources currently carry this security group, since the actual blast radius depends on group membership rather than the rule alone.

aws ec2 describe-network-interfaces --filters Name=group-id,Values=sg-0123456789abcdef0 --query "NetworkInterfaces[].{Instance:Attachment.InstanceId,PrivateIp:PrivateIpAddress}"

Expected evidence: a list of every network interface, and therefore every instance, currently attached to the security group, establishing exactly which hosts trust each other on every port under the current rule.

Correction

The fix scopes the self-referencing rule down to only the port the database tier actually needs, replacing the 0-65535 range with the specific port (5432 in this example) or a narrow range that matches the documented service. This is a state-changing operation on a live security group and must be validated in a non-production copy of the group or a maintenance window with monitoring in place, per the assignment’s isolated-validation prerequisite. Revoke the existing over-broad self-referencing rule and authorise a replacement rule scoped to the required port before removing the broad rule, so there is no window with zero intra-tier connectivity.

aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --ip-permissions IpProtocol=tcp,FromPort=5432,ToPort=5432,UserIdGroupPairs='[{GroupId=sg-0123456789abcdef0}]'

aws ec2 revoke-security-group-ingress --group-id sg-0123456789abcdef0 --ip-permissions IpProtocol=tcp,FromPort=0,ToPort=65535,UserIdGroupPairs='[{GroupId=sg-0123456789abcdef0}]'

Apply the narrow authorise rule first and confirm the intended service still connects before revoking the old broad rule, so the tier never loses connectivity even briefly. Stop immediately if the authorise command fails, if the application layer reports connection errors after the narrow rule is added, or if any dependent service that was relying on an undocumented port inside the old broad range stops working; in that case leave the broad rule in place and escalate to the service owner to identify every port genuinely in use before narrowing further.

Validation

Validation confirms the security group now permits only the documented port between members and that the previously open range is gone. Re-run the describe-security-groups call and confirm the ingress list contains only the narrow FromPort/ToPort pair for the self-referencing rule, with no remaining entry spanning 0-65535 from the same source group.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 --query "SecurityGroups[0].IpPermissions"

Pass condition: the only self-referencing ingress entry has FromPort and ToPort equal to the documented service port, and no entry with FromPort 0 and ToPort 65535 remains. Separately, confirm from an instance in the group that the intended service port still connects and that a previously reachable unrelated port, such as SSH between two peer instances that should not trust each other, is now refused.

Rollback

If narrowing the rule breaks a dependency that was silently relying on the broad range, restore connectivity immediately by re-authorising the original broad rule, then investigate the dependency before attempting to narrow the rule again.

aws ec2 authorize-security-group-ingress --group-id sg-0123456789abcdef0 --ip-permissions IpProtocol=tcp,FromPort=0,ToPort=65535,UserIdGroupPairs='[{GroupId=sg-0123456789abcdef0}]'

This restores the pre-change state exactly, since the narrow rule can coexist with or be revoked alongside the restored broad rule without further data loss; no instance state, data or configuration outside the security group rule set is affected by either the correction or this rollback, so recovery is fully contained to the rule set itself.

Prevention

Treat every security group rule review as a check on the port range, not only the source, since a correctly scoped source combined with an unscoped port range still grants broad access. Add a recurring, read-only audit that lists every security group rule with a FromPort of 0 or a ToPort of 65535 and a self-referencing or otherwise broad source, and require an explicit documented reason before any such rule is approved. Remove temporary troubleshooting widenings from a change ticket checklist item, so a rule opened for diagnosis is never left in place after the diagnosis concludes.