SEC.01

The playbook

The run starts read-only: the recon probes decide what happens next. The steps that follow are adapted to the distribution and state found — a real machine is rarely clean.

1. 01reconthe distribution: apt (Debian/Ubuntu) or dnf (RHEL/Fedora/Rocky/Alma)
2. 02reconUFW installed? already active? existing rules?
3. 03reconthe effective SSH port(s) (sshd_config or ssh.socket on Ubuntu ≥ 22.10) — this port must stay open
4. 04reconwhich ports listen publicly (so as not to cut an expected service)
5. 05reconanother firewall active (firewalld → STOP); Docker (its published ports bypass UFW)
6. 06reconIPv6 handled by UFW (IPV6=yes expected)
7. 07reconopen SSH sessions and the admin IP that must never be blocked
8. 08actInstall UFWverify
9. 09actAllow the SSH port BEFORE anythingverify
10. 10actOpen the requested ports (only if ports are provided)verify
11. 11actDeny incoming by defaultdestructiveverify
12. 12actArm the safety net (auto-disable in 10 min)verify
13. 13actEnable the firewalldestructiveverify
14. 14actDisarm the safety net (after checking SSH access)verify

SEC.02

What it verifies

Each step ships its own check. The run only moves on when the check passes, so what the recipe reports as done is what is actually on the server.

1. 01verifyInstall UFWVerified byufw version
2. 02verifyAllow the SSH port BEFORE anythingVerified byufw show added
3. 03verifyOpen the requested ports (only if ports are provided)Verified byufw show added
4. 04verifyDeny incoming by defaultVerified bygrep -E '^DEFAULT_(INPUT|OUTPUT)_POLICY' /etc/default/ufw
5. 05verifyArm the safety net (auto-disable in 10 min)Verified bysystemctl is-active servor-fw-guard.timer
6. 06verifyEnable the firewallVerified byufw status
7. 07verifyDisarm the safety net (after checking SSH access)Verified bysystemctl is-active servor-fw-guard.timer

SEC.03

Guardrails

Non-negotiable instructions the run must respect, whatever it finds on the server.

SEC.04

Variables

What you choose before launching — the recipe fills in the rest.

SEC.05

How a recipe runs in Servor

Servor is zero-knowledge: the platform cannot execute anything on its own. When you launch this recipe, a run reads the reconnaissance, plans the steps and asks for your approval. Each approved command is signed by your browser — with a key the server never sees — then relayed verbatim to the agent, which verifies the signature locally before executing.

SEC.06

Deploy on Servor button

Maintain UFW firewall or a project that needs it? Put this button in your README or on your site: one click and your users install it on their own server.

SEC.07

More security recipes

1. 01Harden SSHTurns off password login and root password login, keeps keys. Destructive: verify your key access first.
2. 02fail2banfail2ban with the SSH jail on the right port, active and verified.
3. 03Automatic security updatesEnables automatic security updates: unattended-upgrades (Debian/Ubuntu) or dnf-automatic (RHEL/Fedora).
4. 04CrowdSecCrowdSec collaborative IPS, SSH collections and firewall bouncer.
5. 05ClamAVClamAV antivirus with signatures kept up to date, optional daemon.