Skip to main content
emnode
Sign up
Compliance Critical severity

AWS Security Hub · EC2

EC2.19: Security groups expose SSH, RDP, or database ports to the world

Written and reviewed by Emnode · Last reviewed

What does AWS Security Hub EC2.19 check?

EC2.19 fails security groups that allow unrestricted access (0.0.0.0/0) to high-risk ports: SSH, RDP, database engines, and other sensitive services that should never face the internet.

Why does EC2.19 matter?

These are the ports attackers probe first. A database, cache, or admin port open to the world exposes data and control planes directly, with no application layer in front. Unlike a single SSH rule, EC2.19 catches the whole class, so a FAILED here usually means something sensitive is one scan away from exploitation.

How do I fix EC2.19?

  1. Audit the flagged security group and remove any 0.0.0.0/0 rule on sensitive ports (22, 3389, 1433, 3306, 5432, 9200, etc.).
  2. Scope each rule to the smallest source: a peer SG, a private CIDR, or a load balancer SG.
  3. Add automated detection (Config/EventBridge) so a permissive rule is caught the moment it is created.

Remediation script · bash

# Revoke an over-open admin rule, covering both IPv4 and IPv6 in one call.
aws ec2 revoke-security-group-ingress --group-id sg-0a1b2c3d \
  --ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges=[{CidrIp=0.0.0.0/0}],Ipv6Ranges=[{CidrIpv6=::/0}]'

# Where access is genuinely needed, re-add it scoped to a source security group, not a CIDR.
aws ec2 authorize-security-group-ingress --group-id sg-0a1b2c3d \
  --ip-permissions 'IpProtocol=tcp,FromPort=6379,ToPort=6379,UserIdGroupPairs=[{GroupId=sg-0app1234,Description=app-tier}]'

# Strip a default security group to empty by feeding its current rules back into revoke.
INGRESS=$(aws ec2 describe-security-groups --group-ids sg-0default01 \
  --query 'SecurityGroups[0].IpPermissions')
[ "$INGRESS" != "[]" ] && aws ec2 revoke-security-group-ingress \
  --group-id sg-0default01 --ip-permissions "$INGRESS"

Full walkthrough (console steps, edge cases and verification) in the lesson Harden security groups and restrict ingress.

Is EC2.19 a false positive?

EC2.19's blocked-port list is fixed and not customisable, and it covers a few high ports that double as legitimate public web endpoints: 8080, 8088, and 8888 in particular. A public ALB or reverse proxy security group that intentionally serves traffic on 8080 from 0.0.0.0/0 is doing exactly what it should, yet trips this Critical finding the same way an exposed database would. Don't relocate a deliberately public listener off these ports just to silence the rule; if the open port is a real, hardened internet entry point and the only thing behind it is the intended web service, document that and set the finding's workflow status to SUPPRESSED. Reserve real fixes for the database, cache, and admin ports in the list (1433, 3306, 5432, 3389, 9200/9300), which should never face the internet.

Full lesson Harden security groups and restrict ingress Step-by-step remediation with CLI, code and persona-specific context.
AWS documentation for EC2 controls ↗ Check your own account for EC2.19 →
Part of the learning path Lock down access

More EC2 controls

  • EC2.1 An EBS snapshot is publicly restorable by any account
  • EC2.2 Default security groups still allow traffic
  • EC2.3 Attached EBS volumes are not encrypted at rest
  • EC2.4 Long-stopped instances are abandoned attack surface
  • EC2.6 No VPC flow logs, so there is no network audit trail
  • EC2.7 New EBS volumes are not encrypted by default
  • EC2.8 IMDSv1 lets an SSRF steal instance credentials
  • EC2.9 Instances are directly reachable on public IPv4
  • EC2.10 EC2 API traffic leaves the VPC over the internet
  • EC2.13 SSH (port 22) is open to the entire internet
  • EC2.14 RDP (port 3389) is open to the entire internet
  • EC2.15 Subnets auto-assign public IPs to new instances