Idea Lab · Oct 24 2026 · Claude's pick (from Gemini) · Infrastructure

Contabo Clean Rebuild Runbook

After a root compromise you can't trust anything on the box, so you don't clean it. You keep the evidence, burn every secret it held, wipe it, rebuild from a script, and bring back data only. This page walks that order step by step, enforces the gates between steps, and generates the cloud-init file for the new non-root agent accounts.

Example data, not run against a real serverThe host name, volumes, files and agent list below are illustrative. Nothing here talks to Contabo. The gate order is the standard incident-response sequence; the generated cloud-init is a starting point to review, not a tested deployment.

Step through the rebuild

Restore filter: what comes back from the old disk

Only inert data returns. Anything that can run or grant access (binaries, unit files, crontabs, shell dotfiles, authorized_keys) stays in quarantine, because that's where a persistent backdoor would hide. Change a decision to see why the filter disagrees.

Path on old volume (example)	Kind	Your call	Filter says

Agent accounts: cloud-init generator

One service account per agent, no shared root. Each gets only the commands it needs through sudo, and SSH happens over Tailscale only. Edit the allowed commands and the file below updates.

What to try

Try to jump ahead to "Re-image" before rotating secrets. The gate blocks it and says why.
In the restore filter, mark /etc/systemd/system/xmrig.service or .bashrc as Restore and read the filter's reason.
Give agent-alvin a broad command like ALL and watch the generator flag it.
For a real build: turn the generator output into an Ansible role or cloud-init file in git, run it on a fresh Contabo image, and add a check that fails if any account other than the human admin has unrestricted sudo.