how to detect overly permissive security groups
Shows how to find security groups that are too open, like SSH or database ports exposed to the whole internet. Use this when auditing an AWS account and you want a quick list of rules to tighten. Not for designing network architecture from scratch.
TL;DR
Overly permissive security groups are the most common AWS misconfiguration: a database port open to the world, or SSH allowed from everywhere. List all ingress rules, flag anything with the all-interfaces address/0 on sensitive ports, and narrow each one to the source IPs or security groups that actually need it. Do this on a schedule, not once.
The query
how to detect overly permissive security groupsUse this when
- You inherited an AWS account and want to know what is exposed to the internet
- An audit or compliance check asks for a review of network ingress rules
- You are building a recurring cloud security review
- You suspect a breach path through an open management port
Not for
- Redesigning VPC architecture; this is triage on existing rules
- Egress rules review; that is a separate pass with different tradeoffs
- Non-AWS clouds; the concepts transfer but the commands do not
Steps
- List all security groups and their ingress rules. Use the AWS CLI describe-security-groups and dump the output to a file you can grep. Expected output: a complete list of groups with every ingress rule.
- Flag the all-interfaces address/0 on sensitive ports. Search for rules opening SSH (22), RDP (3389), databases (3306, 5432, 6379, 27017), or admin consoles to the whole internet. Expected output: a shortlist of rules that need justification or removal.
- Check each flagged rule's owner. Find out who added it and why; many are leftovers from debugging or demos. Expected output: every flagged rule has an owner and a reason, or is confirmed orphaned.
- Narrow the source. Replace the all-interfaces address/0 with the specific office IPs, VPN ranges, or referencing security groups that need access. Expected output: the rule allows the same legitimate traffic from a tight source.
- Remove what nobody needs. Delete orphaned rules and groups with no attached instances after a grace period. Expected output: the flagged list shrinks to zero or to documented exceptions.
- Automate the check. Run the same scan weekly via a scheduled job and alert on new the all-interfaces address/0 rules. Expected output: new overly-permissive rules get flagged within a week of appearing.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstKgJntUvWa7gRe0qmznk7g