Mist Network
VPS Security Checklist: 12 Steps to Harden a New Server
A fresh VPS is scanned by bots within minutes of going online. This 12-step checklist covers what to lock down in the first hour and what to keep doing every month.
A VPS security checklist is the list of steps you run on every new server before you put anything important on it: lock down SSH, enable a firewall, keep the system updated, limit what runs and make sure you can recover. Automated bots start probing new IP addresses within minutes, so the first hour matters more than any later tuning.
The steps below assume a Linux VPS such as Ubuntu or Debian with root access. Commands are examples; adapt them to your distribution. Work through them in order and keep a second SSH session open while you change login settings, so a mistake cannot lock you out.
Why a new VPS needs hardening
A virtual private server gives you full control, which also means full responsibility. Unlike shared hosting, nobody patches your packages or watches your logins for you. The most common real-world compromises are not clever exploits but simple ones: weak SSH passwords, an outdated web app, an exposed database port or a forgotten test service.
The first hour: 8 essential steps
- Update everything — run
apt update && apt upgrade(or your distribution's equivalent) and reboot if the kernel changed. - Create a non-root user — add a user with sudo rights and use it for daily work instead of root.
- Use SSH keys — generate a key pair on your computer and copy the public key to the server with
ssh-copy-id. - Disable password and root login — in
/etc/ssh/sshd_configsetPasswordAuthentication noandPermitRootLogin no, then restart SSH after testing the key login in a second session. - Enable a firewall — with ufw, allow only what you need, for example
ufw allow OpenSSH,ufw allow 80,443/tcp, thenufw enable. - Turn on automatic security updates — on Debian/Ubuntu install and enable
unattended-upgrades. - Install fail2ban — it bans IPs that repeatedly fail to log in, slowing brute-force attempts.
- Set the time zone and hostname — correct timestamps make logs and certificates reliable.
Ongoing hardening: 4 more steps
- Remove what you do not use — uninstall unneeded packages and stop services you do not need. Check listening ports with
ss -tulpn. - Keep databases private — bind MySQL, PostgreSQL or Redis to 127.0.0.1 or a private network, never to the public internet.
- Back up off the server — copy backups to another location and test a restore. A snapshot on the same machine is not a backup.
- Watch logs and resources — review auth logs, set up simple uptime and disk-space alerts, and look into unexpected CPU spikes.
Checklist at a glance
| Area | Action | How often |
|---|---|---|
| Access | SSH keys only, no root or password login | Once, then review keys quarterly |
| Network | Firewall with only required ports open | Every time you add a service |
| Updates | Automatic security updates plus manual upgrades | Automatic daily; manual monthly |
| Brute force | fail2ban or similar | Once, check bans occasionally |
| Services | Remove unused software, bind databases locally | Monthly review |
| Recovery | Off-server backups with tested restores | Daily backups; restore test quarterly |
| Web | HTTPS, updated CMS and plugins | Weekly |
Securing the web layer
If the VPS hosts a website, the application is often the weakest point. Keep your CMS, plugins and frameworks updated, use HTTPS with a free certificate, and run each site under its own system user so one compromised site cannot read the others. Add a CAA record to your domain so only your chosen certificate authority can issue certificates, and point the domain correctly using our guide on pointing a domain to a VPS.
Store secrets such as API keys and database passwords in environment files with restricted permissions, never in a public web directory or a Git repository.
Access for teams and multiple admins
Servers rarely stay single-user for long. As soon as a colleague, freelancer or deployment tool needs access, the way you hand out credentials becomes part of your security.
- One key per person — every admin gets their own user account and SSH key. Never share a root password or a single key across a team.
- Separate keys for automation — CI pipelines and backup jobs get their own restricted keys, limited to the commands or directories they need.
- Remove access the same day — when someone leaves a project, delete their user and key immediately. Review
authorized_keysfiles every quarter. - Log privileged actions — sudo records who ran what, which makes mistakes and incidents much easier to trace.
- Protect the control panel too — your provider account can reinstall or delete the server, so give it a strong unique password and two-factor authentication where available.
What to do if you suspect a breach
- Do not delete evidence straight away; take a snapshot or copy logs first.
- Rotate every password and SSH key that touched the server.
- Check for unknown users, cron jobs, SSH keys and processes.
- When in doubt, rebuild from a clean image and restore data from a backup made before the incident.
A secure base with mistREG VPS
mistREG runs KVM VPS servers in Slovenia (EU) on NVMe SSD and AMD EPYC hardware. KVM gives each server its own kernel, so you can use any firewall, kernel setting or security tool you like. Provisioning is automatic: about 60 seconds after payment the IP address and root password appear in your panel, ready for the checklist above. Learn more in our guide to offshore VPS hosting.
Create an account, top up with crypto or card and pick a server on the plans section. Questions? Our team is on Telegram at @mistnetwork.
