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. 02reconnftables present?
3. 03reconfirewalld or UFW active → STOP (do not stack two firewalls)
4. 04reconexisting tables (docker, f2b, crowdsec, servor_filter) — the recipe leaves them alone
5. 05reconthe effective SSH port(s) (sshd_config or ssh.socket on Ubuntu ≥ 22.10) — this port must stay open
6. 06reconTCP/UDP ports listening publicly (WireGuard, games… to add or flag)
7. 07reconnumber of established SSH sessions to preserve (adjust the port)
8. 08reconfile loaded at boot: /etc/nftables.conf (Debian/Ubuntu) or /etc/sysconfig/nftables.conf (RHEL)
9. 09actInstall nftablesverify
10. 10actWrite and validate the Servor rulesetverify
11. 11actArm the safety net (auto-removal in 10 min)verify
12. 12actApply the rulesetdestructiveverify
13. 13actLoad at bootverify
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 nftablesVerified bynft --version
2. 02verifyWrite and validate the Servor rulesetVerified bynft -c -f /etc/servor/nftables-servor.nft && echo ok
3. 03verifyArm the safety net (auto-removal in 10 min)Verified bysystemctl is-active servor-fw-guard.timer
4. 04verifyApply the rulesetVerified bynft list chain inet servor_filter input | grep 'tcp dport'
5. 05verifyLoad at bootVerified bynft -c -f /etc/nftables.conf && systemctl is-enabled nftables
6. 06verifyDisarm 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 nftables 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. 03UFW firewallUFW: denies incoming by default, allows the real SSH port + chosen ports, with a safety net. Destructive: keeps SSH open.
4. 04Automatic security updatesEnables automatic security updates: unattended-upgrades (Debian/Ubuntu) or dnf-automatic (RHEL/Fedora).
5. 05CrowdSecCrowdSec collaborative IPS, SSH collections and firewall bouncer.