Skip to content
Shipped®

Playbook / 03

Security basics

No public SSH. Admin access over Tailscale only. Every server gets the same written-down hardening on the day it's created.

Good security is mostly quiet. Nobody notices it until something goes wrong. Here’s what we set up on every server we run, on day one, without anyone having to ask.

No public SSH

A huge share of break-ins start with an SSH port that’s open to the world, hammered with password guesses or opened with a leaked key. The simplest fix is to not have one.

Port 22 doesn’t answer on the public internet. The UFW firewall drops any connection that isn’t coming in over Tailscale.

Admin access over Tailscale

Every server we manage joins the Shipped tailnet. SSH only listens on the tailscale0 interface. Our engineers sign in to Tailscale with single sign-on, and SSH traffic travels inside an encrypted WireGuard tunnel that can’t be reached from outside.

So if someone scans the server looking for a way in, there’s nothing to find. As far as they can tell, SSH isn’t there.

Hardening, by default

On top of closing SSH to the world:

  • Root can’t log in. Engineers sign in as a deploy user with an SSH key and use sudo when needed.
  • Passwords are switched off. sshd only accepts keys. It doesn’t just discourage passwords, it refuses them.
  • fail2ban keeps an eye on the ports that are open (80 and 443) and blocks repeat offenders for a day.
  • Security patches install themselves from the Debian security and updates repositories. Kernel upgrades wait for a planned maintenance window with a person watching.
  • UFW blocks all inbound traffic except 80, 443 and SSH over Tailscale. The rules live in the setup script, so there are no mystery exceptions.

Inside the apps

The server is only half the story:

  • Admin panels sit behind single sign-on and are never linked from the public site.
  • Background services like databases and queues listen on private addresses only, with their own credentials.
  • Kamal Proxy serves real Let’s Encrypt certificates, with Cloudflare in front running Full (strict) SSL.

What we won’t pretend

We aren’t SOC 2 certified, and we don’t hold ISO 27001. Those are formal programs rather than server settings, and when a client needs one we work with their compliance team to get there.

What we can promise is consistency. Every server we run gets the same baseline, applied by a script that’s under version control. Hardening is never left on the to-do list.

Up next in the playbookEmail, done properly

Say hello

Want this playbook working on your next project?

Tell us what you're building and where it stands today. We'll reply with a scoped first step, using the same process and toolkit described on these pages.

How it starts

  1. 01A real person reads your note before the next working day ends.
  2. 02You get straight answers and a few sharp questions back.
  3. 03If we can help, we map out a first release on a 30-minute call.