Securing a new VPS: the first hour checklist for startups
A new VPS gets its first SSH login attempt within minutes of going online. Bots scan entire IP ranges continuously, and a fresh server with a default configuration is exactly what they are looking for.
This checklist takes about an hour on Ubuntu or Debian. Do it before you deploy anything.
1. Update everything (5 minutes)
sudo apt update && sudo apt full-upgrade -y
sudo reboot
Provider images are often weeks old. Start from a patched system.
2. Create your own user (5 minutes)
Don't work as root.
adduser alice
usermod -aG sudo alice
3. Use SSH keys, then turn off passwords (10 minutes)
From your laptop:
ssh-copy-id alice@your-server
Check that the key login works in a second terminal, then edit /etc/ssh/sshd_config:
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
sudo systemctl restart ssh
This single change makes brute-force attacks pointless: there is no password to guess.
4. Turn on a firewall (5 minutes)
Open only what you actually serve.
sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable
Databases, Redis and admin panels should never be reachable from the internet.
5. Automatic security updates (5 minutes)
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
This patches the operating system. It does not update your application's dependencies (npm, pip, composer): those need separate tracking.
6. Ban repeat offenders (5 minutes)
Even with keys only, thousands of failed attempts fill your logs and hide real signals. Automatically banning IPs that keep failing keeps the noise down and blocks scanners before they find another door.
7. Know your exposed versions (10 minutes)
List what runs on the server and check it against known vulnerabilities (CVE): web server, language runtime, framework, database. An outdated framework is the most common way into a well-configured server.
8. Decide who looks at the server, and when (10 minutes)
This is the step most startups skip. Everything above is a one-time setup; attacks happen every day. Someone has to notice the CPU at 100 %, the new SSH key, the critical CVE published last night.
Pick a channel your team already reads (Slack, email) and send it a short daily summary rather than a flood of alerts.
The short version
| Step | Why |
|---|---|
| Update + reboot | Start from a patched base |
| Own user, no root login | Limit damage of a stolen session |
| SSH keys only | Brute force becomes impossible |
| Firewall | Hide everything you don't serve |
| Automatic updates | OS patches without effort |
| Ban repeat offenders | Less noise, fewer scanners |
| Track versions (CVE) | Close the most common entry point |
| Daily review | Notice what changes |
Steps 6 to 8 are exactly what FounderMode automates: intrusion blocking, vulnerable-version checks, CPU/RAM/disk and file-integrity monitoring, with one clear report every morning. Install it in one command right after step 5. 14-day free trial.