Linux-Server-Hardening: CIS Benchmark Anwenden Ohne die Produktion zu Zerlegen
Wie man den CIS Benchmark auf Debian und Ubuntu in Produktion anwendet, jede Kontrolle validiert, Impact misst und das SLA halt, ohne die Nacht im Rollback zu verbringen.
Den kompletten CIS Benchmark auf einen Schlag auf einem Debian 12 auszurollen, der 40.000 Requests pro Minute bedient, ist der schnellste Weg, einen Freitag in einen Sev-1-Vorfall zu verwandeln. Im Basilisk-Team haben wir mehrfach erlebt, wie Firmen das ansible-lockdown-Playbook roh gegen Produktion laufen liessen und um drei Uhr morgens feststellten, dass Kontrolle 5.2.16 den Account abgeschaltet hat, der das Postgres-Backup orchestriert. Ernsthaftes Hardening heisst nicht, 380 Kontrollen aus einem PDF zu kopieren, sondern die 60 auszuwahlen, die das Risiko wert sind, sie in Staging unter realer Last zu replizieren und Telemetrie zu haben, um zu wissen, wie viele Minuten bis zum Rollback bleiben.
Der richtige Einstieg ist, die Kontrollen in vier Buckets zu splitten, bevor man irgendeinen Server anfasst. Bucket 1: Kernel und Boot (sysctl, GRUB, Module), geringes App-Risiko, hoher Gewinn. Bucket 2: Netzwerk und Firewall (nftables, IPv6, ICMP), mittleres Risiko falls nicht alle Ports kartiert sind. Bucket 3: Authentifizierung, PAM und SSH, wo die meisten Post-Hardening-Vorfalle leben. Bucket 4: auditd, syslog und AIDE-Integritat, praktisch null Betriebsrisiko. Erst Bucket 4, dann 1, dann 2, SSH und PAM zuletzt. Falls SSH ohnehin angefasst wird, vorher SSH-Hardening 2026: Algorithmen, Zertifikate und Bastion-Hosts lesen, weil sich die Algorithmen 2026 verschoben haben.
Zur Inventarisierung des Ist-Zustands hilft openscap-scanner mit dem Profil xccdf_org.ssgproject.content_profile_cis_level2_server aus dem ComplianceAsCode-Projekt. Auf einem frischen Ubuntu 24.04 sieht man 110 bis 140 Kontrollen im Fail-Zustand, das ist normal. HTML-Report exportieren, in Jira als eine Epic pro Bucket importieren und Aufwand in Risikopunkten statt Stunden schatzen. Der Trick ist, nie eine Remediation ohne den Rationale zu lesen anzuwenden, denn die Halfte der CIS-Level-2-Empfehlungen zerlegt moderne Workloads. usb-storage zu deaktivieren ergibt auf einem Bastion Sinn, nicht auf einem Host, der verschlusselte Dumps auf einem HSM-Stick fur eine Air-Gap-Ubergabe ablegt.
Die Kernel-Schicht zahlt sich enorm aus, bei geringem Risiko, wenn man weiss, was man tunt. kernel.kptr_restrict=2, kernel.dmesg_restrict=1, kernel.yama.ptrace_scope=2 und fs.protected_hardlinks=1 sind Gratis-Wins. kernel.unprivileged_userns_clone=0 dagegen killt rootless Docker, Podman, Bubblewrap und jede Anwendungssandbox, also wer Container fahrt oder die Techniken aus Linux Anwendungs Sandbox mit Bubblewrap, Firejail und Flatpak nutzt, lasst es auf 1 und dokumentiert die Abweichung formal. Fur stark exponierte Services SELinux in enforcing mit eigener targeted-Policy fahren, exakt wie wir in SELinux ohne Angst: Eigene Policies fur kritische Dienste am Beispiel eines internetexponierten Nginx durchspielen.
Validierung ist der Teil, den niemand sauber macht. Eine Spiegelumgebung in LXD oder Proxmox aufbauen mit identischem Kernel, identischer glibc und identischen Serviceversionen, dann 30 Minuten echten Traffic per tcpdump aufzeichnen und mit k6 oder wrk replayen. Kontrollen in Zehnerbatches anwenden, Test wiederholen, p95-Latenz und Fehlerrate vergleichen. Liegt die Regression uber 3%, isoliert man per Bisektion den schuldigen Controller. Zusatzlich atomic-red-team mit auf MITRE ATT&CK gemappten Techniken laufen lassen, um zu bestatigen, dass das Hardening die Angriffsflache wirklich verkleinert: gleiche Logik wie in Adversary Emulation mit Caldera und MITRE ATT&CK im Unternehmenslab, nur fokussiert auf Post-Exploitation auf dem geharteten Host.
Auditd wird fast immer zum Bottleneck, wenn man das CIS-Ruleset gedankenlos kopiert. Default-Regeln erzeugen 8 bis 15 Tausend Events pro Minute auf einem durchschnittlichen Host, fullen /var/log in sechs Stunden und zwingen journald zum Verwerfen. Das Basilisk-Rezept: execve-Regeln fur bekannte Service-User (postgres, nginx, app) zuruckschneiden und aggressives Monitoring nur fur uid 0, sudo und interaktive Shells behalten. Per auditd-plugin in eine Sigma-Pipeline schicken wie in Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel beschrieben, sonst produziert man teuren Larm ohne jede umsetzbare Detection auf der Konsumentenseite.
Fur Server mit sensiblen Daten oder ohne physischen Zugriff erganzt man das Hardening mit zwangsresistenter Plattenverschlusselung und verifizierten Backups, gemass dem Vorgehen aus Disk-Krypto und Backups: VeraCrypt, LUKS und eine Belastbare 3-2-1-Strategie. LUKS2 mit Argon2id, im TPM2 versiegelter Key gebunden an PCR0+PCR7 und verschlusseltes Offsite-Snapshot losen den physischen Diebstahl im Rechenzentrum. Kombiniert mit Secure Boot, signierten Modulen und passwortgeschutztem GRUB (CIS 1.4.x) hebt man die Kosten eines Hands-on-Angriffs auf ein Niveau, das nur gegen sehr spezifische Ziele lohnt.
Praktisches Takeaway: eine Tabelle pflegen mit jeder angewandten CIS-Kontrolle, der Paketversion zum Zeitpunkt der Anwendung, dem openscap-Ergebnis vorher und nachher und dem in Staging gemessenen Latenz-Delta. Diese Tabelle bei jedem grossen OS-Release (Debian Point Release, LTS Upgrade) erneut durchziehen, weil sich sysctl-Defaults verschieben und auditd neue Felder ergibt. Hardening ist kein Projekt, sondern ein Prozess: wer in sechs Monaten nicht per automatischem Scan beweisen kann, dass die 60 Kontrollen weiterhin aktiv sind, hat kein Hardening, sondern Glauben.