The Security Group Rule Almost Every AWS Account Still Has
Permissive ingress rules — a security group open to a sensitive port from 0.0.0.0/0 — are one of the single most common findings in this year's cross-cloud misconfiguration research, and they're one of the easiest to check for without any new tooling. The rule almost always has a story: “it was easier during setup,” “it's only temporary,” “nobody would actually scan for it.” Automated scanning finds exposed ports within minutes of them going live, not months.
The five ports worth checking today
- 22 (SSH) and 3389 (RDP) — the two most scanned ports on the internet, full stop. If either is open to 0.0.0.0/0 anywhere in the account, that's an immediate fix, not a backlog item.
- 3306 (MySQL) and 5432 (PostgreSQL) — databases with a public ingress rule are usually the result of a quick fix during a migration or a debugging session that never got closed back up.
- 6379 (Redis) — frequently deployed with no authentication at all by default, which makes an open ingress rule on this port equivalent to handing over the data store directly.
- 9200 (Elasticsearch/OpenSearch) — a repeat entry on every “exposed database” incident list for the last several years, for the same reason as Redis.
Why “it's just for internal tools” doesn't hold up
A security group scoped to 0.0.0.0/0 has no concept of “internal” — it's open to the entire internet, and the fact that only your team knows the URL or IP isn't a control, it's obscurity. The fix is almost always cheaper than the workaround people build instead: scope the rule to a specific CIDR range, a bastion host, or a VPN, or move behind AWS Systems Manager Session Manager for anything that was only open for SSH access in the first place.
Turning this into something ongoing
A one-time audit fixes today's exposure; it doesn't stop the next one from getting created next sprint. AWS Config rules (restricted-ssh, restricted-common-ports) and Security Hub's network reachability checks will flag a new permissive rule the same day it's created, which is the only way this stays fixed rather than becoming next year's audit finding all over again.
Want a second opinion on your own AWS environment?
A free 30-minute call is all it takes to find out if a full review is worth doing.