Hardening a Fresh VPS: What to Do in the First Hour
A new server is exposed to automated attacks within minutes. A focused checklist to lock it down before you deploy anything.
The moment a VPS gets a public IP, bots start knocking. Within minutes you will see login attempts against root from all over the world. None of this is personal, it is just the background radiation of the internet, and a fresh box should be hardened before it ever serves a request.
Lock down SSH first
Password logins are the single biggest risk. Switch to keys, create a non-root user, and disable root login and passwords entirely.
adduser deploy && usermod -aG sudo deploy
rsync --archive ~/.ssh /home/deploy/
# in /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
systemctl restart sshClose the doors you are not using
- 1.Enable a firewall and allow only the ports you actually serve.
- 2.Install unattended security updates so patches land without you.
- 3.Add fail2ban to throttle brute-force attempts.
- 4.Take a snapshot now, so you have a known-good starting point.
ufw default deny incoming
ufw allow OpenSSH
ufw allow 443/tcp
ufw enable
apt install -y unattended-upgrades fail2ban
dpkg-reconfigure -plow unattended-upgradesYou cannot patch a door you forgot was open. Start from deny-all and add back only what you can name.
For anything sensitive, keep the admin interfaces off the public internet entirely and reach them over a VPN instead. A database port that is only reachable from inside your private network is a database port that cannot be brute-forced. If you would rather not run this checklist yourself, our managed infrastructure ships hardened by default.