EC2 Security Groups Audit: Finding and Fixing Dangerous Rules

Security groups are the foundation of EC2 network security, and they're also one of the most reliably mismanaged pieces of AWS infrastructure. Every team starts with tight rules and good intentions. Then comes the debugging session at 11 PM where the fastest fix is opening port 22 to the world, the temporary rule that never gets removed, the copied launch configuration that carries its parent's permissive settings into production. Within a year of serious EC2 usage, most accounts have security groups that would fail any external audit.

This guide covers the full audit process: how to find every security group with dangerous rules, how to evaluate which risks are real versus theoretical, and how to build the monitoring that catches new violations before they sit open for months.

What Makes a Security Group Rule Dangerous

Not every broad rule is dangerous in context. A security group allowing all traffic from a specific VPC CIDR is very different from one allowing all traffic from 0.0.0.0/0. Before auditing, define what you're looking for.

The highest-risk patterns are inbound rules that allow access from 0.0.0.0/0 (all IPv4) or ::/0 (all IPv6) on sensitive ports. SSH (22), RDP (3389), and database ports (3306 for MySQL, 5432 for Postgres, 1433 for MSSQL, 27017 for MongoDB) should never be reachable from the public internet in a production environment. Rules allowing all traffic on all ports (protocol -1, port range 0-65535) from 0.0.0.0/0 are an immediate remediation priority regardless of whether the instance is actually running anything sensitive.

Secondary risks include security groups with no inbound rules that are still attached to running instances — these groups won't cause a breach, but they suggest the environment's network policy isn't being managed intentionally. Also watch for security groups that reference other security groups across account or VPC boundaries in ways that weren't intentional when the peering relationship was established.

Running the Audit with AWS Config

AWS Config provides two managed rules that cover most security group audit needs. restricted-ssh flags any security group with an inbound rule allowing SSH from 0.0.0.0/0 or ::/0. restricted-common-ports checks a configurable list of ports against the same criteria. These rules run continuously — any new security group rule that violates the policy generates a Config finding immediately rather than waiting for a scheduled scan.

For a complete audit that goes beyond what managed Config rules check, use the AWS CLI to pull all security group rules and filter. The following approach works across all regions without assuming any particular tooling:

aws ec2 describe-security-groups   --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`] || Ipv6Ranges[?CidrIpv6==`::/0`]]]'   --output json

This gives you every security group with at least one rule allowing inbound traffic from the internet. The output doesn't tell you which specific rules are problematic — you'll need to review each group's permissions — but it narrows the field from hundreds of groups to the ones that need attention.

Cross-reference the results with your EC2 instance inventory. A security group with a dangerous rule that isn't attached to any running instance is a lower priority than the same group attached to a production database. Use aws ec2 describe-instances with a filter on the security group ID to find associated instances.

Evaluating Real Risk

Security group rules don't operate in isolation. An EC2 instance with a permissive security group is only actually reachable if it also has a public IP address and sits in a subnet with an internet gateway route. Work through this checklist for each flagged security group:

• Are instances using this group in a public or private subnet?
• Do those instances have Elastic IPs or auto-assigned public IPv4 addresses?
• Is there a network ACL or WAF layer that would block the traffic even if the security group allows it?
• Is the relevant port actually listening on the instance (a security group allowing port 22 doesn't create risk if SSH is disabled on the OS)?

Running through this process reveals which findings are genuinely exploitable versus which are defense-in-depth gaps. Both categories need remediation, but they shouldn't be treated with the same urgency.

Remediation Priorities

Start with SSH and RDP rules open to the internet on instances with public IP addresses. These are immediately exploitable. Replace broad source rules with specific IP CIDR blocks (your office's IP range, your VPN egress IP), or better, remove public SSH access entirely and use AWS Systems Manager Session Manager for shell access — it requires no inbound security group rules at all.

For database ports, the remediation is almost always the same: change the source from 0.0.0.0/0 to the security group ID of the instances that need database access. Security group references scale better than CIDR ranges and update automatically as instances launch and terminate.

Document every rule you remediate and the legitimate use case it was serving. Security group rules get added for reasons — debugging sessions, temporary connectivity requirements, forgotten proofs of concept. If you remove a rule without understanding why it was added, you'll spend time troubleshooting broken connectivity later.

Building Ongoing Monitoring

A one-time audit solves today's problem. What prevents the same issues from recurring is continuous monitoring with alerting. Configure AWS Config rules restricted-ssh and restricted-common-ports to run in every region, and create an EventBridge rule that routes Config compliance change events for these rules to an SNS topic. This gives you a notification within minutes of any engineer adding a dangerous security group rule.

Pair this with AWS Config's automatic remediation feature for the most critical rules. When restricted-ssh detects a violation, trigger an SSM Automation document that removes the offending rule and sends an alert. Automatic remediation is aggressive — false positives result in production network changes — so apply it only to rules that are never legitimate (port 22 from 0.0.0.0/0 should never be in production, full stop).

Vigilare continuously monitors security group rules across all regions and accounts, surfacing new violations in a prioritized findings queue with instance context so you can assess real exposure rather than just rule violations. Compare the full range of AWS security monitoring tools to see where security group monitoring fits in a complete stack.

Related Reading

• Essential AWS Config rules for security — the full list of Config managed rules that matter
• GuardDuty findings and response playbooks — what GuardDuty tells you about activity through permissive security groups
• VPC security monitoring — security groups in the context of full network security
• Why AWS accounts get suspended — how open security groups contribute to account risk

FAQ

Can AWS Config automatically fix dangerous security group rules?

Yes. AWS Config supports auto-remediation via SSM Automation documents. You can configure the restricted-ssh rule to automatically revoke any SSH rule allowing access from 0.0.0.0/0 when the rule is detected. Be thoughtful about enabling this — automatic changes to network rules in production can break things. Test the automation document in a non-production account first and ensure you have alerting on when remediation fires.

What's the difference between a security group and a network ACL?

Security groups are stateful and operate at the instance level. They track connection state, so return traffic for allowed outbound connections is automatically permitted inbound. Network ACLs are stateless and operate at the subnet level — you need explicit allow rules for both directions. Security groups are evaluated first. In practice, most EC2 network security is implemented through security groups, with NACLs as a secondary layer for subnet-level controls.

How do I audit security groups across an entire AWS Organization?

Use AWS Config aggregators with a delegated administrator account to collect compliance data across all accounts and regions. The aggregator allows you to run Config rule queries across the entire organization from a single console. For programmatic auditing, assume a cross-account role into each account and run the describe-security-groups query, or use AWS Security Hub to aggregate findings centrally.