Security groups open to the world: how to review SSH and RDP rules

An AWS security group rule that allows 0.0.0.0/0 on port 22 or 3389 lets any internet address try to reach your instances. AWS advises authorizing only specific address ranges for SSH and RDP, avoiding wide port ranges, and limiting who can edit security groups. Review these rules first because they are the easiest to exploit.

How security groups behave

Knowing the model prevents mistakes. From the AWS documentation:

• A security group controls traffic allowed to reach and leave the resources it is attached to.
• Rules say what is allowed. Traffic with no matching allow rule does not get through.
• Security groups are stateful. Responses to allowed requests are permitted regardless of the opposite direction's rules.
• You can attach multiple security groups to a resource, and the same group to many resources.
• Some traffic is not filtered at all, including DNS, DHCP, instance metadata, the Time Sync Service and reserved router addresses.

That last point matters. A security group cannot be your control for the metadata endpoint, which is why instance-level metadata settings exist separately.

What AWS recommends

AWS's own best practices say:

1. Authorize only specific IAM principals to create and modify security groups.
2. Create the minimum number of groups you need, grouping resources with similar functions and requirements.
3. For ports 22 and 3389, allow only specific IP address ranges. Specifying 0.0.0.0/0 for IPv4 or the IPv6 equivalent lets anyone connect from any address using that protocol.
4. Do not open large port ranges. Restrict each port to the sources or destinations that need it.
5. Consider network ACLs as an extra layer.

A review routine

Step 1: list the risky rules. Search every security group in every Region and account for inbound rules with a source of 0.0.0.0/0 or its IPv6 form. Sort by port. SSH, RDP and database ports are first.

Step 2: find what is attached. A wide rule on an unused group is lower urgency than one on a production instance. Check the attached resources.

Step 3: pick the replacement. Options include:

• A specific office or VPN address range.
• A reference to another security group, so only instances in that group can connect.
• A managed access method that does not require an inbound port at all, where your setup supports it.

Step 4: change, then verify. Remove the open rule, confirm the legitimate path still works, and check logs for blocked attempts.

Step 5: stop the repeat. Restrict who can edit groups, and add a detective check or a preventive guardrail that flags new world-open rules on sensitive ports.

Common objections

"We need it open for a vendor." Ask for the vendor's source addresses and allow only those.

"Our team works from home." Use a VPN with a fixed egress range, or a session-based access service, rather than the whole internet.

"It is only a test box." Test boxes have a habit of becoming real. Close it anyway.

Quick check

Sources

• Control traffic to your AWS resources using security groups

Last reviewed: 19 October 2026.