Server Hardening Checklist for Small Teams

Ten controls, one afternoon, no security engineer. Written for the first 1–10 production servers a small team runs — the window when you're visible on the internet and nobody owns security yet.

Small teams don't get attacked by nation-states. They get scanned, continuously, by bots that find the server within hours of the first public IP. The scans look for the boring stuff: password SSH logins, open panels, unpatched CVEs, exposed databases. Almost all of it is stopped by an afternoon of unglamorous configuration — and almost none of it is done, because hardening guides are written for fleets of 500 servers and nobody with three servers reads them.

Here is the small-team version. It assumes nothing about your stack beyond "a Linux box with SSH."

The ten controls that stop most of what's out there

SSH keys only; no passwords; no root login. In /etc/ssh/sshd_config: PasswordAuthentication no, PermitRootLogin no, then systemctl reload sshd. Verify your key works before you close the old session. This one control eliminates the brute-force background noise entirely — check /var/log/auth.log after: it goes from hundreds of attempts a day to zero.
Firewall: default deny, allow only what's public. ufw default deny incoming, allow 22/80/443, allow your own IP for any admin port, ufw enable. Every database, cache, and admin panel stays unreachable from the internet. "But the port has a password" is not a defense; exposed ports are discovered by scanners within hours.
Security patches on autopilot. unattended-upgrades (Debian/Ubuntu) with the -security origin enabled. You still review the weekly log — pair it with the patch management cadence — but CVEs with public exploits should not wait for your monthly window.
Fail2ban on SSH. Not because you're still using passwords (you aren't — control 1), but because it also catches token-stuffing and brute-force on any admin surface you later expose, and it costs five minutes.
Least-privilege service users. Nothing that faces the internet runs as root or as your personal account. One system user per service, no shell, no shared accounts. When you review logs later, "which user did this" needs a one-word answer.
2FA everywhere a human logs in. Hosting console, registrar, DNS, cloud dashboard, version control with deploy keys. The most common small-team breach isn't the server — it's the *control plane*: a phished hosting password, a hijacked domain. The server is only as hard as the console that controls it.
Backups that are tested and off-box. A hardening checklist that doesn't include "the ransomware scenario" is a checklist about the last decade. Encrypted, off-site, versioned — and restored in a drill. The 20-minute restore drill is the version that fits on one page.
Minimal surface: uninstall what you don't run. Every installed package is future CVE homework. If nobody can name what a service is for, it goes — that's the same triage muscle as the what-to-automate-first question.
Logging that survives the incident. Ship auth and application logs off-box (even a nightly copy to object storage). Local-only logs die with the box, exactly when you need them. Retention: 90 days is a fine small-team number.
Expiry watch: certs, domains, cards. An expired certificate or lapsed domain takes everything down with no attacker involved. This is control 4 in the monitoring checklist — if you only adopt one crossover, make it this one.

What you can skip (for now)

SELinux/AppArmor tuning, WAFs, SOC tooling, zero-trust mesh, HSMs — all real, all later. A team of 2–10 with a default-deny firewall, key-only SSH, automatic security patches, tested backups, and 2FA on the control plane is harder to breach than the median company that buys those tools. The gap between "hardened enough" and "compromised" is almost always an unpatched CVE, a reused password, or an exposed panel — not a missing advanced feature.

The 30-minute first-server card

New box? Before it takes traffic: create your user, paste your key, disable password/root SSH, enable ufw with default-deny, install unattended-upgrades, install fail2ban, create the service user, set up the off-box backup job, add the box to the expiry watch. One card, ten minutes, and every future server starts from safe instead of from "we'll harden it later." Later never comes; the scanner's clock starts in hours.

The deeper pattern is the same one behind the incident response plan: decisions made now, written down, are what you'll execute under pressure. Hardening is incident response that happens in advance.

---

The Ops Starter Kit Vol. 2 ($27) includes the full hardening pack — the ten-control checklist, the first-server card, and the patch log template — plus the advanced incident response and continuity templates. Launch week: 30% off any paid kit with code HIVE-LAUNCH30 at checkout.