200+ SSH Brute-Force Attacks Per Day: What the Attackers Are Trying
My VPS gets over 200 SSH brute-force attempts every day. In 48 hours, fail2ban banned 191 unique IP addresses. Here's what the attackers are doing and where they come from.
The Attackers
Three IPs stood out during my monitoring window. I reverse-scanned each one:
A compromised app server running ancient software: OpenSSH 7.4, nginx 1.20.1, Node.js/Express, PostgreSQL 14 — all exposed. 23 known CVEs. Tagged "eol-product" by Shodan. Classic botnet node: someone's legitimate server got owned and is now scanning the internet.
An Estonian VPN company's IP. No Shodan data (dark IP). Tried usernames: admin, orangepi, root. Either a VPN customer using their service to scan, or a compromised exit node.
Bare-bones Ubuntu VPS running only SSH. No web server, no other services. A disposable box spun up specifically for scanning.
What They Try
20:46:30 Invalid user admin from 149.82.x.x
20:46:31 Connection closed by authenticating user root
20:46:32 Connection closed by authenticating user root
20:46:34 Invalid user x from 149.82.x.x
20:46:35 Invalid user db2fenc1 from 149.82.x.x
20:46:36 Invalid user deploy from 149.82.x.x
Six usernames in six seconds. The interesting ones:
- db2fenc1 — IBM DB2 service account. They're hunting for database servers.
- deploy — CI/CD pipeline account. Looking for DevOps servers.
- orangepi — IoT device default user. Targeting embedded systems.
- caddy — Web server service account. They know common stack names.
- oracle — Database server targeting.
- kafka — Streaming platform targeting.
These aren't random. They're curated wordlists targeting specific technologies.
Why They'll Never Get In
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers ubuntu
Password authentication is completely disabled. They're trying passwords against a door that doesn't accept passwords. It's like trying every key on a keyring against a door that only opens with a fingerprint.
fail2ban bans IPs after 3 failed attempts. UFW blocks everything except needed ports. The attacks are noise — but monitoring them tells you what the threat landscape looks like.
Set Up Your Own Monitoring
sudo apt install fail2ban
# Check banned IPs:
sudo fail2ban-client status sshd
If you're running a public-facing server without key-only SSH and fail2ban, you're one weak password away from compromise.