Linux-Server härten nach CIS-Benchmark: Praxisplan für KMU (Debian/Ubuntu)

Der CIS-Benchmark für Ubuntu und Debian umfasst über 200 nummerierte Kontrollen – auf den ersten Blick ein schier endloser Katalog. Für KMU-Administratoren fehlt aber meist die Zeit, jede Kontrolle einzeln zu bewerten. Dieser Leitfaden zeigt, wie du mit einem priorisierten Stufenplan in realistischer Zeit eine solide Sicherheitsbasis erreichst: Was Level 1 wirklich bringt, wo Level 2 Dienste brechen kann, wann der Ubuntu Security Guide (USG) die bessere Wahl ist als ein manueller Ansatz – und wie du aus dem Audit-Report einen verwertbaren Nachweis für NIS2 oder die Cyberversicherung machst.

Voraussetzungen

• Ubuntu Server 24.04 LTS (Noble Numbat) – für USG-Unterstützung; Debian-Systeme nutzen OpenSCAP/Lynis manuell, da USG Ubuntu-exklusiv ist
• Root- oder sudo-Berechtigungen auf dem Zielsystem
• Ubuntu Pro Token (kostenlos für bis zu 5 Maschinen unter ubuntu.com/pro) – nur für USG benötigt; OpenSCAP und Lynis laufen ohne Pro
• Konsolenzugang (Cloud-Webkonsole, IPMI, physischer Zugang) als Fallback vor Beginn der SSH-Härtung
• Aktueller Snapshot oder Backup des Systems – zwingend vor dem ersten Härtungslauf
• SSH-Schlüsselpaar auf dem Zielsystem eingerichtet und getestet (ed25519 empfohlen)
• Staging-Umgebung für Level 2 oder produktive Anwendungsserver
• Netzwerkzugang zu ubuntu.com für pro attach und apt

Schritt 1: Level 1 vs. Level 2 – die richtige Stufe wählen

Bevor du einen einzigen Befehl ausführst, lohnt die Entscheidung: Welche CIS-Stufe ist für diesen Server sinnvoll? Die folgende Tabelle gibt die Orientierung für typische KMU-Szenarien.

Kriterium	Level 1	Level 2
Anzahl Kontrollen (Ubuntu 24.04)	~100	~200
Betriebsrisiko	Gering – gezielt praxistauglich	Mittel bis hoch – testet Anwendungen
Typische Zielumgebung	Webserver, Fileserver, allg. KMU-Server	Server mit personenbezogenen Daten, regulierte Branchen
Staging-Umgebung nötig	Empfohlen	Zwingend
Bekannte Problemzonen	SSH-Sperrung, cron.allow	noexec/nosuid Mounts, AppArmor Enforce, Kernel-Parameter
NIS2-Nachweis geeignet	Ja (Art. 21 „Stand der Technik")	Ja (stärker)

Für die meisten KMU-Produktivserver ist Level 1 die richtige Wahl. Level 2 lohnt sich explizit für Systeme, auf denen personenbezogene Daten nach DSGVO Art. 32 verarbeitet werden, oder für Systeme in regulierten Branchen.

Schritt 2: Vorbereitung und Sicherheitsnetz spannen

Dieser Schritt ist keine Option – er verhindert, dass du nach der Härtung ausgesperrt bist. Gehe die folgende Checkliste vor dem ersten Härtungsbefehl durch.

1. Konsolenzugang testen (Cloud-Dashboard oder IPMI): Kannst du dich einloggen, wenn SSH komplett ausfällt?
2. SSH-Key hochladen und Anmeldung per Key verifizieren – vor dem Deaktivieren der Passwort-Authentifizierung
3. System-Snapshot erstellen (Cloud-Image, VM-Snapshot oder rsync-Backup)
4. Offene Ports und laufende Dienste dokumentieren

SSH-Key anlegen (falls noch nicht vorhanden) und auf den Server übertragen:

# Lokal: Ed25519-Key erzeugen
ssh-keygen -t ed25519 -C "admin@firmenname"

# Key auf den Server kopieren
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip

# Anmeldung per Key testen (noch BEVOR Password-Auth deaktiviert wird!)
ssh -i ~/.ssh/id_ed25519 user@server-ip

Offene Ports und laufende Dienste prüfen und nicht benötigte deaktivieren:

# Lauschende Ports anzeigen
ss -tlnp

# Laufende Dienste auflisten
sudo systemctl list-units --type=service --state=running

# Nicht benötigte Dienste deaktivieren (Beispiele)
sudo systemctl disable --now avahi-daemon cups bluetooth

# SUID-Dateien im System finden
find / -xdev -type f -perm -4000 -ls 2>/dev/null

Wie du SSH-Keys generell einrichtest, erklärt die Anleitung SSH-Key-Authentifizierung einrichten (Linux & Windows).

Schritt 3: SSH-Härtung als erste Priorität

SSH ist der primäre Angriffsvektor für externe Angreifer und die Kontrolle mit dem höchsten Schutzwert in Level 1. Verwende Drop-in-Dateien statt der direkten Bearbeitung von /etc/ssh/sshd_config – das erleichtert Rollbacks erheblich.

# Drop-in-Datei anlegen (sicherere Methode)
sudo nano /etc/ssh/sshd_config.d/10-cis-hardening.conf

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
X11Forwarding no
AllowTcpForwarding no
ClientAliveInterval 300
ClientAliveCountMax 0
MaxAuthTries 3
MaxSessions 10
LogLevel VERBOSE
PermitEmptyPasswords no
IgnoreRhosts yes

# Syntax IMMER prüfen, bevor SSH neu gestartet wird
sudo sshd -t && sudo systemctl restart ssh

# Anmeldung in einem zweiten Terminal testen – bestehende Session NICHT schliessen!

Wichtig: Öffne nach dem Neustart des SSH-Diensts ein zweites Terminal und verifiziere die Anmeldung, bevor du die bestehende Session schließt. Wenn du jetzt ausgesperrt bist, hilft nur noch der Konsolenzugang aus Schritt 2.

Schritt 4: Sysctl-Kernel-Parameter härten

Kernel-Parameter sind schnell gesetzt und reversibel – ein gutes Einstiegsfeld für Level-1-Härtung. Lege eine dedizierte Datei an, um Rollbacks zu vereinfachen:

sudo nano /etc/sysctl.d/60-cis-hardening.conf

net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.all.rp_filter = 1
kernel.randomize_va_space = 2
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.sysrq = 0
fs.suid_dumpable = 0
# ACHTUNG: ip_forward = 0 bricht Docker/Container-Networking!
# Auf Docker-Hosts diese Zeile weglassen oder auf 1 setzen.
net.ipv4.ip_forward = 0

# Parameter sofort anwenden
sudo sysctl --system

# Verifikation einzelner Parameter
sysctl kernel.randomize_va_space
sysctl kernel.kptr_restrict

Hinweis zu Docker-Hosts: net.ipv4.ip_forward = 0 unterbricht das Container-Networking vollständig. Auf Systemen mit Docker oder anderen Container-Runtimes muss dieser Wert auf 1 belassen werden.

Schritt 5: Mount-Optionen für /tmp und /dev/shm

noexec auf /tmp ist die wirksamste Einzelmaßnahme gegen Post-Exploitation-Payloads, die Binärdateien in /tmp ablegen und ausführen. Ergänze die /etc/fstab:

sudo nano /etc/fstab

tmpfs   /tmp      tmpfs  defaults,nodev,nosuid,noexec  0 0
tmpfs   /dev/shm  tmpfs  defaults,nodev,nosuid,noexec  0 0
none    /var/tmp  tmpfs  defaults,nodev,nosuid,noexec  0 0

# Sofort wirksam machen ohne Reboot
sudo mount -o remount /tmp
sudo mount -o remount /dev/shm

Achtung: Einige apt-Postinstall-Hooks entpacken temporär ausführbare Dateien nach /tmp. Workaround vor apt upgrade:

sudo mount -o remount,exec /tmp
sudo apt upgrade
sudo mount -o remount,noexec /tmp

Schritt 6: auditd einrichten

Das Linux Audit Framework protokolliert sicherheitsrelevante Ereignisse auf Kernel-Ebene. Der Immutabilitäts-Flag -e 2 am Ende der Regeln verhindert, dass root die Audit-Regeln ohne Reboot deaktiviert – ein kritisches Detail, das oft vergessen wird.

sudo apt install -y auditd audispd-plugins
sudo nano /etc/audit/rules.d/40-cis-hardening.rules

-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /var/log/lastlog -p wa -k logins
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time-change
# WICHTIG: Erst nach vollstaendigem Test aktivieren!
# -e 1 = nicht immutable (zum Testen)
# -e 2 = immutable (fuer Produktion – kein Aendern bis Reboot!)
-e 2

# Regeln laden und prüfen
sudo augenrules --load
sudo auditctl -l

Hinweis: Für die erste Inbetriebnahme zunächst -e 1 statt -e 2 verwenden, bis alle Regeln getestet sind. Sobald -e 2 aktiv ist, können Audit-Regeln bis zum nächsten Neustart nicht mehr geändert werden – auch nicht von root.

Schritt 7: Ubuntu Security Guide (USG) für automatisierte Härtung

Auf Ubuntu 24.04 LTS lässt sich mit dem Ubuntu Security Guide der Großteil der CIS-Level-1-Kontrollen automatisiert anwenden. USG setzt Ubuntu Pro voraus – das ist für bis zu 5 Maschinen kostenlos.

# Ubuntu Pro aktivieren
sudo apt install -y ubuntu-advantage-tools
sudo pro attach <DEIN-TOKEN>   # Token von ubuntu.com/pro
sudo pro enable usg
sudo apt install -y usg

# Option A: Direkt auf CIS Level 1 haerten
sudo usg fix cis_level1_server

# Option B: Tailoring-Datei erzeugen und anpassen (empfohlen fuer Produktionssysteme)
sudo usg generate-tailoring cis_level1_server hardening.xml
# hardening.xml bearbeiten: spezifische Kontrollen deaktivieren
sudo usg fix --tailoring-file hardening.xml

# Audit nach der Haertung
sudo usg audit cis_level1_server

# Reports pruefen (HTML und XML fuer Compliance-Nachweise)
ls /var/lib/usg/

AIDE-Warnung: Der erste usg fix-Lauf löst eine AIDE-Datenbankinitialisierung (aide --init) aus. Auf kleinen VMs mit 1 vCPU und 2 GB RAM kann das 90 Minuten und mehr dauern – das ist normales Verhalten. Den Prozess nicht unterbrechen, sonst ist die AIDE-Datenbank korrupt und muss manuell gelöscht werden (/var/lib/aide/aide.db).

Schritt 8: OpenSCAP ohne Ubuntu Pro (Alternative für Debian und Nicht-Pro-Umgebungen)

Für Debian-Systeme oder Ubuntu ohne Pro-Lizenz bietet OpenSCAP mit dem SCAP Security Guide (SSG) einen vollwertigen Audit ohne Lizenzkosten:

sudo apt install -y libopenscap8 ssg-base ssg-ubuntu

sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
  --results /tmp/cis-results.xml \
  --report /tmp/cis-report.html \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2404-ds.xml

Der erzeugte HTML-Report enthält Profil-Name, Versionsnummer und Datum – genau das, was für einen NIS2-Artikel-21-Nachweis oder eine Cyberversicherungs-Dokumentation benötigt wird. Für Lynis als ergänzendes Tool ohne CIS-Zertifikat:

sudo apt install lynis
sudo lynis audit system --report-file /var/log/lynis/$(date +%F)-report.dat

Hinweis: Der Lynis Hardening Index (0–100) ist kein offiziell akkreditierter CIS-Compliance-Bericht. Für Cyberversicherungen und NIS2-Nachweise ist ein OpenSCAP- oder USG-Report mit explizitem CIS-Profil und Versionsnummer deutlich aussagekräftiger.

Schritt 9: Cron-Zugriff beschränken und AppArmor prüfen

Zwei Level-1-Maßnahmen, die im Alltag oft Probleme verursachen, wenn man die Nebeneffekte nicht kennt:

# Cron-Zugriff auf root beschraenken (CIS Level 1)
sudo rm -f /etc/cron.deny
echo 'root' | sudo tee /etc/cron.allow
sudo chmod 600 /etc/cron.allow

# Gleiches fuer at
sudo rm -f /etc/at.deny
echo 'root' | sudo tee /etc/at.allow
sudo chmod 600 /etc/at.allow

Wichtig: Alle Dienste-Accounts, die Cronjobs benötigen (z. B. www-data, backup-user), müssen explizit in /etc/cron.allow eingetragen sein – sonst werden ihre Jobs stumm gesperrt.

# AppArmor-Status pruefen
aa-status
sudo systemctl enable --now apparmor

# Level 2: Alle Profile in Enforce-Modus setzen
sudo aa-enforce /etc/apparmor.d/*

# Status kontrollieren
sudo aa-status | grep -E '(enforce|complain)'

Troubleshooting / Typische Fehler

• SSH-Aussperrung nach PasswordAuthentication no: Passiert, wenn kein SSH-Key in ~/.ssh/authorized_keys (Rechte 0600) hinterlegt war. Lösung: Konsolenzugang nutzen, Key manuell in authorized_keys eintragen, Berechtigungen setzen (chmod 600 ~/.ssh/authorized_keys), SSH neu starten.
• dpkg: error: subprocess installed post-installation script returned error exit status 1: Ursache ist fast immer noexec auf /tmp, das Postinstall-Hooks blockiert. Fix: sudo mount -o remount,exec /tmp, dann nochmals apt install / dpkg --configure -a, danach sudo mount -o remount,noexec /tmp.
• USG-Fix hängt seit Stunden: Kein Fehler – das ist die AIDE-Initialisierung. Mit ps aux | grep aide prüfen ob aide noch läuft. Nicht abbrechen; auf schwacher Hardware (1 vCPU, 2 GB RAM) bis zu 90 Minuten normal.
• Cron-Jobs von Dienste-Accounts laufen nicht mehr: /etc/cron.allow wurde gesetzt, aber der Dienste-Account fehlt darin. Fix: Account in /etc/cron.allow eintragen, z. B. echo 'www-data' | sudo tee -a /etc/cron.allow.
• Container/Docker ohne Netzwerk nach Sysctl-Härtung: net.ipv4.ip_forward = 0 in /etc/sysctl.d/60-cis-hardening.conf. Fix: Zeile auf net.ipv4.ip_forward = 1 ändern, sudo sysctl --system ausführen.
• AppArmor blockiert proprietäre Anwendung nach Level-2-Härtung: In /var/log/syslog nach apparmor=DENIED suchen. Profil temporär in Complain-Modus: sudo aa-complain /etc/apparmor.d/<Profil>. Mit sudo aa-logprof erweitertes Profil aus Logs generieren, dann wieder in Enforce: sudo aa-enforce /etc/apparmor.d/<Profil>.
• Rollback SSH-Drop-in: sudo rm /etc/ssh/sshd_config.d/10-cis-hardening.conf && sudo sshd -t && sudo systemctl restart ssh
• Rollback Sysctl: sudo rm /etc/sysctl.d/60-cis-hardening.conf && sudo sysctl --system

Häufige Fragen

Brauche ich Ubuntu Pro für den Ubuntu Security Guide?

Ja, USG ist Bestandteil von Ubuntu Pro. Allerdings ist Ubuntu Pro für bis zu 5 Maschinen kostenlos mit einem persönlichen Token unter ubuntu.com/pro. Für größere Infrastrukturen gibt es Unternehmenslizenzen. Wer kein Pro nutzen will oder Debian einsetzt, kann OpenSCAP mit dem SCAP Security Guide (Pakete libopenscap8 und ssg-ubuntu) vollständig kostenfrei als Audit-Tool einsetzen – ohne jede Lizenzbeschränkung.

Was ist der Unterschied zwischen Level 1 und Level 2 – welches soll ich nehmen?

Level 1 bietet für KMU-Server eine sehr gute Sicherheitsbasis ohne relevantes Betriebsrisiko. Level 2 empfiehlt sich nur für Systeme mit erhöhtem Schutzbedarf, etwa wenn personenbezogene Daten nach DSGVO Art. 32 verarbeitet werden oder regulatorische Anforderungen dies verlangen. Level 2 erfordert zwingend eine Staging-Umgebung, da restriktive Mount-Optionen (noexec, nosuid), vollständiges AppArmor-Enforcement und verschärfte Logging-Regeln bestehende Anwendungen beeinträchtigen können.

Kann ich den Audit-Report als NIS2-Nachweis verwenden?

Ja. Ein datierter USG- oder OpenSCAP-HTML-Report mit explizitem CIS-Profil und Versionsnummer (z. B. „CIS Ubuntu 24.04 v1.0.0 Level 1") ist ein geeigneter technischer Nachweis für NIS2-Artikel-21-Anforderungen zum „Stand der Technik". Für Cyberversicherungen ist zusätzlich eine quartalsweise Wiederholungsauditierung und Dokumentation von begründeten Ausnahmen empfehlenswert. Ein Lynis-Bericht allein reicht dafür nicht aus, da er keinen akkreditierten CIS-Bezug enthält.

Wie stelle ich sicher, dass ich mich nach der Härtung nicht aussperren?

Checkliste vor Härtungsbeginn: 1. Konsolenzugang testen. 2. SSH-Key in authorized_keys eintragen und per Key einloggen – verifiziert. 3. System-Snapshot erstellen. 4. Konfigurationsänderungen ausschließlich über Drop-in-Dateien, nicht direkt in Hauptdateien. 5. Nach jeder SSH-Änderung sudo sshd -t ausführen. 6. Dienste einzeln neustarten statt sofort rebooten.

Wie lange dauert die Ersthärtung nach CIS Level 1?

Für einen erfahrenen Administrator: manuelle Basishärtung (SSH, sysctl, fstab, auditd, Firewall) ca. 2–3 Stunden. Per USG automatisiert ca. 30–60 Minuten inklusive AIDE-Initialisierung. Die Hauptinvestition liegt in der nachgelagerten Dokumentation von Ausnahmen und dem Testen der Anwendungen. Wer eine Staging-Umgebung vorab nutzt, spart erheblichen Aufwand in der Produktion.

Was tun, wenn AppArmor nach Level-2-Härtung Anwendungen blockiert?

In /var/log/syslog oder per dmesg | grep apparmor nach apparmor=DENIED-Einträgen suchen. Das betreffende Profil temporär in Complain-Modus setzen: sudo aa-complain /etc/apparmor.d/<Profil>. Mit sudo aa-logprof aus dem Paket apparmor-utils ein erweitertes Profil aus den Logs generieren. Anschließend wieder in Enforce überführen: sudo aa-enforce /etc/apparmor.d/<Profil>.

Welche CIS-Kontrollen kann ich für KMU-Server typischerweise auslassen?

Dokumentierte Ausnahmen per Tailoring-Datei sind professioneller als das mechanische Anstreben von 100 % Compliance. Typische Ausnahmen für KMU: Blacklisting von Dateisystem-Kernel-Modulen (USB/cramfs) auf Cloud-VMs ohne lokale Hardware, IPv6-Deaktivierung auf modernen Netzen, Compiler-Entfernung bei Container-Build-Systemen, passwortbasierte Komplexitätsregeln bei reinen Key-only-SSH-Umgebungen sowie GUI-spezifische Kontrollen auf reinen Server-Systemen.

Fazit

Ein CIS-Level-1-gehärteter Ubuntu-Server ist kein Selbstzweck – er ist eine solide, dokumentierbare Sicherheitsbasis, die für die meisten KMU-Produktivserver das richtige Verhältnis aus Schutzwirkung und Betriebsstabilität bietet. Der entscheidende Unterschied zum blinden Abarbeiten aller 200+ Kontrollen liegt in der Priorisierung: SSH-Härtung und Sysctl-Parameter zuerst, noexec auf /tmp als hochwirksame Einzelmaßnahme, auditd mit Immutabilitätsflag für lückenlose Protokollierung. Level 2 lohnt sich gezielt für Systeme mit erhöhtem Schutzbedarf – aber immer mit Staging-Umgebung und dokumentierten Ausnahmen. Das Beste daran: Der erzeugte Audit-Report aus USG oder OpenSCAP ist sofort als NIS2- und Cyberversicherungsnachweis einsetzbar, ohne zusätzlichen Dokumentationsaufwand.

Weiterführende Anleitungen und Quellen

• SSH-Key-Authentifizierung einrichten (Linux & Windows) – Voraussetzung für sichere SSH-Härtung
• Linux-Server absichern mit UFW und Fail2ban – Firewall-Grundlagen als Ergänzung zur CIS-Härtung
• Logs lesen mit journalctl und /var/log – auditd-Ausgaben und AppArmor-Denied-Einträge verstehen
• Linux-Benutzer, Gruppen, Rechte: chmod, chown, sudo – Berechtigungsgrundlagen für cron.allow und sshd_config

Quellen: Canonical – „Hardening automation for CIS benchmarks now available for Ubuntu 24.04 LTS" (ubuntu.com/blog); Ubuntu Security Guide – Offizielle Dokumentation (documentation.ubuntu.com/security/compliance/usg/); CIS Benchmark Ubuntu Linux – Center for Internet Security (cisecurity.org); Lynis – Security auditing tool – CISOfy (cisofy.com/lynis/).