A new VM was launched with SSH (22) and RDP (3389) open to 0.0.0.0/0. What's the right remediation?
Short answer
Management ports open to the whole internet are scanned and brute-forced within minutes, so the fix is to shrink the attack surface: restrict the security-group ingress to known admin CIDRs or VPN, or remove inbound entirely using a bastion or SSM Session Manager. Moving SSH to a non-standard port is security by obscurity that scanners defeat trivially. A stronger password doesn't reduce the exposed surface or stop credential-stuffing. Trusting a host firewall ignores the attack surface the security group is openly advertising to the internet.
Management ports open to 0.0.0.0/0 are one of the most exploited cloud misconfigurations. The interviewer wants to see that you reduce the attack surface itself, not just make the exposed surface marginally harder to abuse.
Why restricting ingress is correct
The internet is scanned continuously; a fresh VM with 22 and 3389 open to the world will see brute-force and credential-stuffing attempts within minutes. The right fix is to stop advertising those ports to everyone. Restrict the security-group ingress to a small set of trusted admin CIDRs or a VPN range, or — better — remove inbound management access entirely and reach the host through a bastion or AWS SSM Session Manager. SSM is especially strong because it needs no open inbound port at all: access goes through the AWS API with IAM authorization and full audit logging.
Why the distractors fail
- Move SSH to a non-standard port. This is security by obscurity. Mass scanners sweep all ports, so the service is found in seconds; you've gained nothing real while making operations more confusing.
- Set a stronger password. A better password may slow one brute-force vector, but the port is still open to the entire internet, still attracts constant traffic, and is still exposed to any future auth vulnerability or key/password leak. It treats a network-exposure problem as a credentials problem.
- Leave it — the VM has a host firewall. Relying on a host firewall while the cloud security group advertises the port to the world is fragile defense-in-depth done backwards: one misconfigured host firewall, and you're fully exposed. Close it at the network edge.
What interviewers look for
Naming the security group as the control, restricting source CIDRs, and ideally eliminating the open port with a bastion or SSM. Strong candidates also mention finding all offending security groups org-wide, because one open VM usually means the guardrail (an SCP or Config rule blocking 0.0.0.0/0 on 22/3389) is missing.
Likely follow-ups
- Why is SSM Session Manager often better than even a locked-down bastion?
- How would you find every security group exposing 22 or 3389 to 0.0.0.0/0 across the org?
- What does a stronger password fail to protect against here?