The server security checklist
Most break-ins on small servers are not clever. A password login, a database open to the internet, a release nobody updated. Work down this list once and you are ahead of most servers on the internet.
Published . Written for Ubuntu and Debian; most of it carries over to other distributions.
Before you change anything
Every item below touches SSH, the firewall or a running service. Any of them can cut you off. Two habits make that harmless.
- Keep a way back in. Find your provider's web or serial console before you need it, and keep a second SSH session open while you change SSH or the firewall.
- Take a restore point. A provider snapshot, or at least a copy of
/etcand a database dump. See snapshots before changes and database backups.
SSH
SSH is the front door, and it gets knocked on all day. Key-only logins stop password guessing completely.
- Log in with a key, not a password: set up an ed25519 key.
- Turn off password logins, and check that nothing in
sshd_config.dturns them back on: disable password authentication. - Use your own user with sudo and stop logging in as root: a sudo user instead of root.
- Tighten the rest without locking yourself out: SSH hardening.
- Optional: fail2ban to quiet the logs, and a different port if the noise bothers you. Neither replaces key-only logins.
Firewall
Close everything you didn't mean to open. Then check from outside, because the server's own view can be wrong.
- Allow SSH first, then deny the rest: UFW without locking yourself out. If it already went wrong: locked out after ufw enable.
- See what really listens and what the internet can reach: check open ports.
- Running Docker? Published ports skip UFW: Docker bypasses UFW.
- Confused by UFW, iptables and nftables at once: how they fit together.
Updates
Most known holes already have a fix. The server just has to install it, and sometimes restart.
- Install security updates automatically: unattended-upgrades.
- Know when a reboot or a service restart is due: reboot required.
- Know what each apt command does before you run it: upgrade vs full-upgrade.
- Make sure your release still gets fixes at all: end of life and upgrading.
Databases
A database that answers the whole internet is the most common serious finding on small servers. They should listen on localhost or a private network, and need a password even there.
Platforms and people
- Self-hosting panels open ports of their own: Coolify and Portainer.
- Other people log in too? Change SSH and the firewall without cutting them off: changes on a shared server.
Keep an eye on it
- Who tried to get in, and who did: SSH login attempts.
- Don't let HTTPS expire quietly: certificate expiry.
Then come back to this list every few months, and after anything big: a new app, a new teammate, a release upgrade.
Stenvakt works through this list for you. Its Review is a read-only check of every server against these points, and every fix shows a Preview first and runs in safe mode: if a change cuts off your SSH, the server rolls it back by itself. It's a Mac app and isn't out yet: get early access.