Warum ich einen eigenen Debian-ISO-Builder — CISS.debian.live.builder — und einen eigenen Debian-Installer — CISS.debian.installer — entwickle. Persönliche Betrachtung eines Sicherheits- und Automatisierungsproblems.
1. Ausgangslage – Unsicherheit ab t₀
Stelle ich ein System remote in einem Netzwerk bereit, das nicht unter meiner direkten Hoheit steht, muss ich es vom ersten Takt an wie ein feindliches Terrain behandeln. Im Zero-Trust-Modell – also der Grundannahme, dass jedes Netz potenziell kompromittiert ist, auch das eigene – lautet die zentrale Frage:
Wie verhindere ich, dass bereits der Installationsvorgang eine offene Flanke darstellt?
Greife ich zu meiner CISS.debian.live.builder ISO, startet dort zunächst ein wohldefiniertes, gehärtetes Live-System. Sobald ich jedoch den klassischen Debian Installer (d-i) aufrufe, kollabiert dieser Schutzraum:
| Vor dem Aufruf (CISS.debian.live-System) | Nach dem Aufruf von d-i |
|---|---|
| UFW/NFTables aktiv | Firewallprozesse vernichtet |
Gehärtetes sshd | Kein gesichertes SSH, Password Root Login. |
Logging (journald, rsyslog) | Deaktiviert |
| Aktueller Kernel | Wird ersetzt (eigener Installer-Kernel) |
Der originale Debian Installer (d-i) bootet immer einen eigenen Kernel + initramfs, überschreibt den RAM und ersetzt alle Dienste, die gerade meine Verbindung schützen. Ein Angreifer kann daher genau jene kurze Phase ausnutzen, in der Passwörter eingegeben, Partitionen angelegt oder Schlüssel injiziert werden.
2. Meine Antwort: CISS.debian.live.builder
Um diese Lücke zu schließen, baue ich mir die Live-ISO selbst – deterministisch, reproduzierbar und maximal gehärtet:
- Erreichbarkeit ausschließlich über Jump/Bastion-Hosts, VPN-Nodes und via SSH-Pubkey-Auth.
- KEX
sntrup761x25519-sha512@openssh.com
KEX steht für Key Exchange. Hier werden klassische Elliptische-Kurven-Komponente (x25519) mit einer post-quantum-resistenten NTRU-Variante (sntrup761) kombiniert. Das schützt auch gegen künftige Quantencomputerangriffe. - Cipher
aes256-gcm@openssh.com
Die GCM-Variante von AES-256 ist vom US-NIST bis zur Klassifizierung „Top Secret“ zugelassen und bietet Authentizität + Vertraulichkeit in einem Schritt. - Fail2ban, UFW, SSH-Hardening.
Integritätsschutz:
Bereits der Bootloader verweigert das Starten, wenn irgendeine der mitgelieferten SHA-512/-384/-256-Prüfsummen nicht greift. Optional vergleiche ich zur Laufzeit die AIDE-Datenbank mit einem zur Build-Zeit eingefrorenen Referenzsatz. So entsteht eine immutabile Source-of-Truth, die von außen weder unbemerkt verändert noch ersetzt werden kann.
3. Was an Debian Installer & Calamares für mich nicht genügt
- Moderne Partitionsschemata
LUKS2-Verschlüsselung bereits von/bootan, Verzicht auf LVM, Integration vondropbear-initramfsab t₀ – all das lässt sich im d-i selbst mit fragilenpreseed-early-commandund / oderpartman-early-commandnicht erzwingen oder wird unter Calamares erst gar nicht angeboten. - Unflexible Konfigurationslogik
Preseed-Dateien sind kryptisch und error-prone. Eine lesefreundliche YAML-Syntax erhöht Wartbarkeit und Auditierbarkeit. - Sicherheits-Baseline
Weder d-i noch Calamares setzen konsequent CIS-Benchmarks, Empfehlungen des Linux Kernel Self-Protection Project oder Lynis-Härtungen um. Standard-Installationen sind „offen wie ein Scheunentor“.
4. CISS.debian.installer.secure – Framework Konzeptüberblick
| CISS.debian.live.builder | Umsetzung |
|---|---|
| Deterministischer Build | Vollständig aus statischen Repos auf git.coresecret.dev/msw erzeugt. |
| Härtung ab Werk | SSH-Pubkey only Zugang nur mit einem Satz der stärksten KEX und Ciphers, Inkl. fail2ban und ufw Schutz. Jeweils der aktuellste Backports Kernel, wenn gewünscht. |
| Optional headless | Kein interaktives Buildscript, wenn gewünscht. |
| Integritätsschutz | Zweifach integriert. Zur Boottime mittels umgebauter 0030-verify-checksums Routine. Zur Runtime mittels aide Referenzdatensatz. |
| Audit-Werkzeuge | chkhvg, lsadt, ssh-audit direkt in der Live-Umgebung verfügbar. |
| CISS.debian.installer | Umsetzung |
|---|---|
| YAML-Konfig | Klare, deklarative Syntax statt Preseed. |
| Optional headless | Kein interaktives Installationsscript, wenn gewünscht, vollständig automatisierbar. |
| Härtung ab Werk | CIS + Lynis + CISSP Hardening-Profile. |
| Paketauswahl | Feingranular per debootstrap speisbar. |
| Konfig-Editor | GUI/CLI-Tool in Entwicklung |
Damit klemme ich sämtliche externen Variablen ab: Der Installer bezieht keine fremden Skripte, führt keine ungesicherten HTTP-Downloads aus und erhält seine Instruktionen nur aus der signierten YAML-Datei. Ergebnis ist eine reproduzierbare, prüfbare und kompromisslos-gehärter System-Provisionierung.
5. Fazit — Warum das alles?
Ich baue CISS.debian.live.builder und CISS.debian.installer, weil mir keine bestehende Lösung jene Flexibilität und Sicherheit bietet, die ich für Installationen in unsicheren, oft fremdverwalteten Netzen benötige.
- Ich will vom ersten Bit an kontrollieren, was ausgeführt wird.
- Ich will sicher sein, dass kein Klartext-Passwort den Draht verlässt.
- Ich will Installationen, die prüfbar reproduzierbar sind und bei jedem Audit dieselben Ergebnisse liefern.
- Und ich will das alles ohne stundenlanges Nachhärten eines Vanilla-Systems erreichen.
Der Aufwand eines eigenen Builders und eines Installers mag hoch erscheinen, doch der Preis einer kompromittierten Infrastruktur ist in meinen Augen ungleich höher. Darum investiere ich diese Energie – und setze bewusst auf quelloffene, nachprüfbare Verfahren, und vielleicht kann auch der ein oder andere sicherheitsbewusste Anwender von einer sicheren, modernen Debian-Bereitstellung profitieren.