❯ Hardening a Small Server: 5 Cheap Wins That Block Most Attacks

2026-09-09 · Ops, Founder ·3 min read

by Jonas Reyes — the builder's desk, Side Quest Studios September 10, 2026

Five cheap wins that block most attacks on a small server

You are not a bank, but you are on the internet — and almost everything that finds you is automated, looking for the easy door. These five things are free, take an afternoon, and stop the overwhelming majority of that noise.

The framing matters: this is not about defeating a targeted attacker. It is about not being the cheapest host on the network to compromise. Nearly every real intrusion is opportunistic — a scanner finds an open port, tries the default password, and moves on if neither works.

1. Keys, not passwords, for SSH

A password can be guessed; a key cannot. If you still log in as root with a password, that is the door everything is rattling. Keys only, and turn password login off once they work — PasswordAuthentication no in sshd_config(5). Turn it off after you have confirmed the key works in a second session, not before, or you will lock yourself out of your own server.

And disable root login entirely. Use a normal user with sudo. It costs nothing and removes the one account every scanner knows exists.

2. Move SSH off the obvious port

Port 22 is scanned constantly. Moving it is not real security — a determined scanner will find it — but it removes you from the background noise entirely. See the SSH port explainer, and the full set of options in sshd_config(5).

What it actually buys you is log volume. A host on port 22 collects tens of thousands of failed-login lines a week, and that noise is what makes people stop reading their logs. Moving the port trades a real (small) security gain for a much larger operational one: you can now see the attacks that matter.

3. A firewall that denies by default

Allow the ports you actually use; drop everything else. A default-deny rule means a service you forgot about is not silently exposed. This is the single highest-value change on the list, because it fixes the mistakes you have not made yet.

Every service that binds to a port is a decision, and most of them are made accidentally — a database that ships listening on all interfaces, a debug endpoint that never got turned off, a metrics port with no auth. A default-deny firewall overrules all of them without you having to remember any of them.

4. Patch on a schedule, not on a scare

Unattended upgrades for the OS, and a plan for your applications. The bug that gets you is usually not new — it is one you did not install the fix for. Debian and Ubuntu will do this for you with unattended-upgrades; set it to apply security updates and to tell you what it did.

A calendar reminder is not a patch strategy. The whole value of unattended upgrades is that it removes the decision from a human who is busy on exactly the day the update drops.

5. Watch the door

You cannot fix what you do not see. Log failed logins and check them. The point is not paranoia; it is that an alert you actually read beats a report you never open.

The useful signal is not volume — it is change. Failed logins are constant background radiation. What deserves attention is a new source address that suddenly succeeds, or a spike from one address that suggests a targeted attempt rather than a scanner.

Try it once

lastb | head            # recent failed logins (root)\nss -tulpn | head        # what is actually listening

If something is listening that you cannot explain, that is the afternoon's work. Do the port inventory before you change the firewall — otherwise you will lock out a service you forgot you were running.

What this list is not

This will not stop a determined attacker with a specific interest in you. It will stop the automated majority, which is what finds most small servers. If you are targeted specifically, the answer is a different conversation — segmentation, monitoring, and someone whose job it is.

Small servers are not less safe by nature — they are just usually less watched.

Related read: OpenClaw security checklist — from Claw Guide, our OpenClaw research desk.

References

AI-assisted, curated for Side Quest Studios.