Someone put port 22 on 0.0.0.0/0 in a security group
This is how instances get scanned within an hour and compromised within a week. Closing it is today's work, a clean SSH path takes a day.
Try this first
- 1Close the rule now: replace 0.0.0.0/0 with your office IP, or better, remove the rule altogether.
- 2For SSH to private instances use AWS Systems Manager Session Manager, Azure Bastion or GCP IAP. No public SSH needed.
- 3Turn on AWS Config, Defender for Cloud or Security Command Center with a rule that flags port 22 or 3389 on 0.0.0.0/0 as non-compliant.
- 4Review every existing security group and NSG. CloudTrail or Activity Log shows who added the rule, usually worth tracking down.
- 5Write into an SCP or Azure Policy that public SSH/RDP rules are denied, not just flagged.
When to bring us in
If the instance has been open for weeks and has access to production data, treat it as an incident and bring in someone who does forensics.
See also
- Everyone logs in with the AWS root accountRoot is for emergencies and billing. Day-to-day work belongs in IAM users or SSO.
- Every developer has AdministratorAccessAdministratorAccess everywhere is convenient now, painful later. Start with role-based policies.
- Everyone has individual IAM users with their own passwordIdentity Center (formerly AWS SSO) links to your IdP and issues temporary credentials per session.
None of the above fits?
Describe your situation below. We pass your input plus the steps you already saw to our AI and return tailored next-step advice. If it's too risky to DIY, we'll say so.
Or skip the DIY entirely
Our Managed IT clients do not look these things up. One point of contact, a fixed monthly price, resolved within working hours.