Skip to content
Martin Aziz®

Playbook / 03

Security baseline

Public SSH is closed. Admin access is via Tailscale. Every server is hardened to the same documented baseline, on day one.

Security is the part of operations that’s invisible until it isn’t. The choices below are what we do for every client server, automatically, on the first day of an engagement.

Public SSH is closed

The most common cause of compromised servers on the internet is an exposed SSH port being brute-forced or hit by a credential leak. So we close it.

Port 22 is not accessible from the public internet. The host firewall (UFW) rejects every connection that doesn’t come through Tailscale.

Admin access via Tailscale

Every server we operate joins the Martin Business Consultants tailnet. SSH is reachable only over tailscale0, the Tailscale virtual interface. Our operators authenticate to Tailscale with single-sign-on; SSH itself runs through Tailscale’s WireGuard tunnel, which is end-to-end encrypted and not addressable from the open internet.

The practical result: an attacker scanning the internet for SSH services on this server will see nothing. The port simply doesn’t exist for them.

Hardened defaults

Beyond closing public SSH:

  • No root login, ever. Operators authenticate as a deploy user with sudo via SSH key.
  • No password authentication. Public keys only. Passwords aren’t merely deprecated, sshd is configured to refuse them.
  • fail2ban watches for anomalous activity on any port we do expose (currently 80 and 443). Repeat offenders get banned for 24 hours.
  • Unattended security upgrades are enabled for the Debian security and updates repositories. Kernel updates are applied during a scheduled maintenance window with a real human in the loop.
  • UFW firewall is configured to deny everything inbound except 80, 443, and Tailscale-only :22. The configuration is committed in the deploy script, no untracked rules.

Application-layer security

In addition to the host:

  • Vaultwarden is configured with admin signups disabled and an Argon2-hashed admin token.
  • ONLYOFFICE runs behind Kamal Proxy with its own service-account credentials, never exposing its internal services to the public internet.
  • Kamal Proxy terminates TLS with a real Let’s Encrypt certificate (Cloudflare in front, Full Strict SSL mode).

What we don’t claim

We don’t claim SOC 2. We don’t claim ISO 27001. Those are programs, not technical baselines, and we work alongside clients’ compliance advisors when those programs are needed.

What we do claim is this: the baseline above is the same on every server we operate, applied automatically by a deploy script that’s version-controlled. There’s no “we’ll get to hardening later.”

Next in the playbookHow we handle email

Get in touch

Want the same operational discipline applied to your business?

Tell us where you are now. We'll come back with a concrete plan using exactly the architecture, stack, and process you've just read about.

What to expect

  1. 01We read every inquiry within one business day.
  2. 02A candid reply with follow-ups, no boilerplate.
  3. 03If there's a fit, we scope the work on a short call.