Exposed management ports (SSH/RDP)
Management ports are the doors you use to administer a system, and SSH (22), RDP (3389), and their relatives — WinRM (5985/5986), VNC (5900), and the admin ports of databases and orchestrators — grant privileged, interactive control the moment someone gets through them. In the cloud these ports slip open one convenience at a time: a "temporary" 0.0.0.0/0 rule opened during an incident, a public IP left on an instance that only ever needed internal traffic, a default security group that was never tightened. Because the entire internet is continuously scanned, an exposed management port is found quickly and subjected to automated credential-stuffing and daemon-level exploit attempts, so the exposure is not theoretical — it is being tested constantly. This sub-topic is specifically about how administrative access reaches your hosts, and whether that path is a standing public rule or a brokered, identity-gated, logged connection. We inventory every place management access is reachable from outside a trusted boundary and how it is authenticated, so the finding is about the door itself, not just the wall around it.
Overview
What this check looks like in practice
Management ports such as SSH (22) and RDP (3389) exposed to the internet are among the most reliably exploited cloud findings, because they offer direct administrative access and are constantly scanned and brute-forced. The safe pattern is to reach admin surfaces through a bastion, a managed connection service, or just-in-time access rather than a standing public rule. We identify every host and service where these ports are reachable from outside a trusted boundary.
Why it matters
Exposed management ports collapse the distance between a stolen or guessed credential and full administrative control of a host — there is no application layer, no business logic, and often no second factor standing in the way. To an attacker they are among the highest-value targets on a scan because success yields an interactive shell or desktop rather than just a foothold; to an auditor they are a first-page failure because unrestricted or standing public access to 22/3389 contradicts nearly every hardening baseline. The risk compounds when the same permissive rule rides on a shared security group across a fleet, so one misconfiguration exposes many hosts at once, and again when access relies on long-lived keys or password authentication with no MFA and no session record. Cyber insurers now routinely ask whether RDP and SSH are exposed to the internet and commonly condition, adjust, or decline coverage for accounts that leave them open, making this one of the few technical findings with a direct line to financial consequence at renewal. Closing it is also cleanly demonstrable evidence, mapping to CIS network hardening, PCI-DSS restrictions on administrative access, NIST CSF protective controls, and ISO 27001 secure access requirements.
What we assess
What we look for
- SSH (22), RDP (3389), WinRM (5985/5986), or VNC (5900) reachable from 0.0.0.0/0, ::/0, or broad public ranges
- Instances carrying public IPs that expose management ports directly instead of routing admin access through a broker
- Standing public rules where a managed access service (SSM Session Manager, Azure Bastion, IAP) or bastion should mediate, so the port is open permanently rather than just-in-time
- Database, cache, and orchestrator admin ports — PostgreSQL 5432, MySQL 3306, MSSQL 1433, Redis 6379, MongoDB 27017, Kubernetes API 6443, Docker 2375 — reachable from the internet
- Management access authenticated by long-lived static keys or passwords/NTLM rather than short-lived, identity-bound credentials with MFA
- Administrative sessions that are not logged to an audit trail, leaving no record of who connected to what and when
- "Temporary" or break-glass ingress rules left in place with no expiry, and default security groups still permissive on production resources
- Overly broad allowlists — large corporate CIDRs, VPN egress ranges, or vendor IP blocks — treated as a trusted source for management access
Across your clouds
AWS, Azure & Google Cloud
AWS
Check EC2 security groups and network ACLs for ingress on 22/3389 from 0.0.0.0/0, and prefer AWS Systems Manager Session Manager over any open port — Session Manager needs no inbound rule, no public IP, and no SSH key, gating access through IAM and logging every session to CloudTrail and CloudWatch Logs/S3. EC2 Instance Connect Endpoint is a further keyless option that reaches private instances without a public IP or open management port. Where a network path is genuinely required, AWS Client VPN or a hardened bastion in a public subnet should front private instances, and Service Control Policies or AWS Config rules can flag or block the reintroduction of public management rules.
Azure
Inspect network security group (NSG) rules for inbound 3389/22 from Internet or Any, and replace direct exposure with Azure Bastion, which brokers RDP/SSH over TLS through the portal or native client so the VM needs no public IP and no open management port. Microsoft Defender for Cloud's just-in-time VM access can time-box any remaining direct access to a requested window and source, and Azure Policy can deny NSG rules that open management ports to the internet.
Google Cloud
Review VPC firewall rules and hierarchical firewall policies for 0.0.0.0/0 ingress on 22/3389, and use Identity-Aware Proxy (IAP) TCP forwarding so SSH/RDP is tunneled through Google's identity layer with the firewall scoped to IAP's 35.235.240.0/20 range rather than the open internet. Pair IAP with OS Login for centralized, IAM-bound, key-managed SSH, and use organization-level firewall policies to keep projects from publishing management ports.
Example finding
SSH (22) open to 0.0.0.0/0 on a shared security group fronting an Auto Scaling group, with password authentication permitted and no session logging
Risk: A single security group with a standing public SSH rule exposes every instance in the scaling group at once, so the blast radius grows automatically as the fleet scales. Because password authentication is allowed and there is no MFA, automated brute-force and credential-stuffing traffic — which reaches the port shortly after it opens — can succeed against one weak or reused password, and because sessions are not logged there would be no record of who connected or what they did. This is direct administrative access to production, brute-forceable from the entire internet, with no second factor and no forensic trail.
Fix: Remove the 0.0.0.0/0 ingress on port 22, disable password authentication, and route administrative access through AWS Systems Manager Session Manager (or an equivalent broker) so there is no open port, access is gated by IAM with MFA and short-lived credentials, and every session is recorded to the audit trail. Add an AWS Config rule or SCP that alerts on or blocks any future security group opening 22/3389 to the internet so the exposure cannot silently return.
Remediation
How to close it
- 1 Inventory every internet-reachable management port across all accounts, subscriptions, and projects — 22, 3389, 5985/5986, 5900, and the admin ports of databases and orchestrators — and identify which instances hold public IPs that exist only for administration.
- 2 Remove standing public ingress on those ports, disable password/NTLM authentication where it is enabled, and strip public IPs from hosts that only require internal reachability.
- 3 Stand up a brokered access path — Systems Manager Session Manager, Azure Bastion, or IAP TCP forwarding — so administrators reach hosts through cloud identity rather than an open port, and retire any classic bastion that is itself internet-brute-forceable.
- 4 Bind access to identity with MFA and short-lived credentials, and route administrative sessions to the audit trail so every connection is attributable and reconstructable.
- 5 Add preventive guardrails — Service Control Policies, Azure Policy, or organization/hierarchical firewall policies — that deny public management-port rules, and alert on any new 0.0.0.0/0 ingress to 22/3389.
- 6 Convert any genuinely required direct access to just-in-time, time-boxed, source-restricted grants with a defined expiry and periodic review, so break-glass rules cannot become permanent.
Questions
If we use SSH keys instead of passwords, is it safe to leave port 22 open to the internet?
Key-based authentication is stronger than passwords, but it does not make an exposed port safe. The port itself is still reachable by every scanner and exploit attempt on the internet, so a vulnerability in the SSH daemon, a stolen or leaked private key, or a misconfigured authorized-keys file becomes directly exploitable with no network barrier in front of it. Reachability is the exposure; the durable fix is to remove the open port and broker access through an identity-gated service rather than to rely on the credential type alone.
We restrict RDP and SSH to our office IP range — is that good enough?
Source-restricting to a known range is meaningfully better than 0.0.0.0/0 and worth doing immediately, but it is not equivalent to a brokered path. Large corporate or VPN egress CIDRs are broad and often shared, roaming and remote administrators tend to push those ranges wider over time, and an allowlist still gives you no per-session identity, MFA, or audit record of who actually connected. A just-in-time, identity-gated broker removes the standing open port entirely and produces the access log auditors and insurers ask for.
How is a managed access service safer than running our own bastion host?
Services like Session Manager, Azure Bastion, and IAP remove the public management port altogether: access is authorized through cloud IAM with MFA, credentials are short-lived, and each session is logged to the audit trail. A traditional bastion is still an internet-facing host with an open port that you must patch, monitor, and defend against the same brute-force and exploit traffic — it narrows the exposure to one box rather than eliminating it. Both are far better than exposing every host directly, but the managed services close the door instead of guarding it.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
