You launch an EC2 instance. It’s your tenth, maybe your fiftieth. You’ve done it a dozen times this week. You tag it properly, give it the right AMI, pick your instance type, and assign it a trusty security group called something like default-ssh. You know the one — it’s been in use since the company’s first sprint. And just like that, you’ve opened up port 22 to the entire internet.
But it’s behind a VPC!
If your security group allows 0.0.0.0/0 on port 22 (SSH), congratulations — you’ve just invited every bored script kiddie, port scanner, and brute-forcer on the internet to say hello.
They’re not even knocking. They’re slamming the door with a battering ram. Repeatedly. Every second. The wild part? You probably won’t notice.
Brute-Force Attacks Are Like Background Radiation
You don’t see them. You don’t feel them. But they’re happening.
Spin up a fresh EC2 instance with SSH exposed to the world, and you’ll start seeing login attempts in /var/log/auth.log within minutes. Not hours. Not days.
Failed password for invalid user admin from 49.88.112.233 port 51123 ssh2
Failed password for root from 185.100.87.65 port 49731 ssh2
Failed password for ubuntu from 93.174.93.56 port 38472 ssh2Who are these people? Nobody you know. Just bots. They’re guessing usernames, passwords, and keys. They don’t care who you are. They don’t even know if your instance is valuable. They’re hoping you’re lazy. Or distracted. And honestly? They’re usually right.
The Bastion Host You Forgot to Lock Down
Let’s say you’re doing things “right.” You’ve got a bastion host. No direct access to private instances.
But then…
- You leave the bastion up 24/7.
- You expose it to the whole internet.
- You forgot to rotate the key pair.
- Or worse: you lose track of who even has the private key.
What you’ve built isn’t a secure gateway. It’s a front door with no deadbolt.
CloudWatch Won’t Warn You
These brute-force attempts? They won’t trip alarms unless you’ve explicitly configured monitoring for them.
And let’s be honest — did you set up fail2ban, intrusion detection, or login attempt metrics in CloudWatch?
No? Then it’s happening right now, and you don’t even know.
You’ll only notice after something breaks, or when a security audit ruins your afternoon.
But We Use Key-Based authentication!
So do most people. That’s not the point. The point is that every open SSH port is an attack vector, and it takes one dumb move — like uploading a private key to a public GitHub repo, or granting an intern access to a shared laptop — to turn your safe-looking setup into a hacked EC2 horror story.
Security isn’t about whether someone can get in. It’s about reducing the number of people who can even try.
How to Fix It Before It Bites You
1. Never, ever, ever allow 0.0.0.0/0 on port 22 in production.
Just don’t. If you must use SSH, whitelist your office IP or use AWS Systems Manager Session Manager (more on that in a second).
2. Use SSM instead of SSH.
Seriously. Systems Manager Session Manager is free, encrypted, logged, and doesn’t require exposing any ports. No SSH. No bastion. No headaches. You can even audit access through CloudTrail.
3. Auto-delete bastion instances when not in use.
If you must use a bastion, treat it like a gas stove: turn it off when you’re done. Use instance lifecycle hooks or automation to spin it up only on demand.
4. Audit your security groups monthly.
Run a scheduled AWS Config rule, or just script a describe-security-groups check and grep for 0.0.0.0/0 + port 22. You’ll be surprised how many pop-ups there are.
5. Rotate and expire SSH keys regularly.
Don’t assume that just because someone has a key, they still should. IAM gets rotated. So should SSH keys. Opening SSH to the internet is like leaving your laptop in a Starbucks bathroom with a post-it note that says “root:root.”
No comments:
Post a Comment