AWS Security Group Auditor
Paste your AWS security group rules — either the JSON from aws ec2 describe-security-groups or a plain one-rule-per-line list — and get severity-ranked findings. It flags 0.0.0.0/0 and ::/0 exposure on SSH, RDP and database ports, all-ports-open rules and over-wide CIDRs, each with the risk and a concrete fix. Everything runs in your browser; nothing is uploaded and no host is ever probed.
Parsed and scored entirely in your browser — nothing is uploaded. This is a static read of the rule text you paste; the tool holds no AWS credentials, makes no API calls, and never connects to or probes any host, IP or port.
What this tool is
- A free, in-browser auditor for AWS security groups: paste the JSON from `aws ec2 describe-security-groups` or a plain one-rule-per-line list, and it ranks every ingress and egress rule by severity.
- Open to the whole internet (0.0.0.0/0 or ::/0) on a sensitive port — SSH 22, RDP 3389, MySQL 3306, Postgres 5432, Redis 6379, Mongo 27017, Elasticsearch 9200, MSSQL 1433, Telnet 23, SMB 445 — is flagged critical.
- All-ports-open rules (protocol -1 or 0–65535 to the internet) are critical; public access on any other port is high; an over-wide CIDR (for example a /8) reaching an admin port is medium.
- Every finding names the port and protocol, the source, the concrete risk, and a specific fix: restrict to known CIDRs or security-group references, and reach instances through SSM Session Manager or a bastion instead.
- Everything runs in your browser. No rule text is uploaded, and the tool never connects to AWS or probes any host or IP address.
What is an AWS security group?
A security group is a stateful virtual firewall attached to AWS resources such as EC2 instances, load balancers and RDS databases. It is allow-only: each rule permits traffic, and anything not explicitly allowed is denied. An ingress (inbound) rule names a protocol, a port or port range, and a source — a CIDR block, another security group, or a prefix list. An egress (outbound) rule does the same for destinations. Because the group is stateful, return traffic for an allowed connection is automatically permitted, so you only reason about the direction you open.
Why open ports matter
The single most common and most damaging misconfiguration is a source of 0.0.0.0/0 — "anywhere on the internet" — on a sensitive port. The IPv6 equivalent, ::/0, is identical in effect and is easy to miss. A world-open administrative or database port is reachable by every scanner on the internet within minutes, and it is a recurring root cause in real breach post-mortems and a staple finding of the AWS Well-Architected security pillar and CIS Benchmarks.
How findings are ranked
- Critical. Inbound
0.0.0.0/0or::/0on a sensitive port (22, 3389, 3306, 5432, 6379, 27017, 9200, 1433, 23, 445), or all ports open to the internet (protocol-1/0–65535). - High. Public access on any other single port — still internet-facing, just not one of the known high-value services.
- Medium. An over-wide source CIDR (roughly a /8 or broader) reaching an administrative or database port — a far larger blast radius than the few hosts that need it.
- Informational. Egress to
0.0.0.0/0— common and often fine, but worth confirming for data-exfiltration-sensitive workloads.
The fix, in short: never expose administration or databases to 0.0.0.0/0. Restrict sources to specific corporate or VPN CIDRs, or reference the exact security group that needs access, and reach instances through SSM Session Manager or a hardened bastion rather than a public SSH/RDP port. This tool is a static review of the rules you paste, not a live scan — it never touches your account or any host.
Frequently asked questions
What does this AWS security group audit actually check?
It parses your security group rules and ranks each one by risk. The highest-severity findings are inbound rules that open a sensitive port to the entire internet: SSH (22), RDP (3389), common databases (MySQL 3306, PostgreSQL 5432, Redis 6379, MongoDB 27017, Elasticsearch 9200, Microsoft SQL 1433) and legacy protocols (Telnet 23, SMB 445). It also flags rules that open all ports to the world (protocol -1 or the full 0–65535 range), public access on any other port, and over-wide source ranges such as a /8 reaching an administrative port. Egress to 0.0.0.0/0 is noted as informational because it is common but worth confirming.
What input formats can I paste?
Two. First, the native JSON from the AWS CLI — run `aws ec2 describe-security-groups` (optionally with `--group-ids sg-xxxx`) and paste the output; the tool reads the SecurityGroups[].IpPermissions[] and IpPermissionsEgress[] arrays, including IPv4 ranges, IPv6 ranges, referenced security groups and prefix lists. Second, a simple list with one rule per line, for example `tcp 22 0.0.0.0/0`, `ingress udp 0-65535 10.0.0.0/8`, or `3389/tcp 0.0.0.0/0`. Direction keywords (ingress/egress) are optional and default to ingress.
Why is 0.0.0.0/0 on port 22 or 3389 so dangerous?
A source of 0.0.0.0/0 means any address on the internet can reach that port, and ::/0 is the IPv6 equivalent. SSH (22) and RDP (3389) are direct administrative entry points, so a world-open rule exposes them to continuous automated credential-stuffing and brute-force scanning, and turns any leaked key or weak password into a full host compromise. The same logic applies to databases and caches (3306, 5432, 6379, 27017, 9200, 1433): these often hold the crown-jewels data and were never meant to face the public internet. The fix is to restrict the source to specific corporate or VPN CIDRs or to a referencing security group, and to reach instances through AWS Systems Manager Session Manager or a hardened bastion rather than a public port.
Is a wide CIDR like 10.0.0.0/8 a problem?
It depends on the port. A broad private range such as a /8 or /16 is normal for intra-VPC traffic, so the auditor does not flag ordinary application ports behind one. It does flag a very wide range (roughly /8 or broader) that reaches an administrative or database port, because "anything in 10/8" is a much larger blast radius than the handful of hosts that genuinely need SSH or database access. Narrow the source to the specific security group or subnet CIDR that actually requires the port, and rely on least-privilege references rather than catch-all ranges.
Is anything sent to a server, and does it scan my account?
No. The audit is entirely client-side: the rules you paste are parsed and scored in your browser using JavaScript, and nothing is ever uploaded. The tool holds no AWS credentials, makes no API calls to AWS, and never connects to or probes any host, IP address or port — it only reads the text you give it. That means you can safely paste production security-group output to review it offline, and the findings are a static analysis of the rules, not a live network scan.