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

Der CIS-Benchmark ist kein einzelner Befehl, sondern ein Rahmen für saubere Serverhärtung. Gerade in kleinen und mittleren Umgebungen ist die größte Gefahr nicht, dass zu wenig gehärtet wird, sondern dass Maßnahmen blind übernommen werden und danach etwas Kritisches nicht mehr funktioniert. Genau deshalb ist ein Praxisplan wichtiger als eine starre Checkliste.

Voraussetzungen

• Debian- oder Ubuntu-Server mit sudo-Rechten
• Getesteter SSH-Zugang
• Wartungsfenster oder kontrollierte Testumgebung

Schritt 1: Vor der Härtung den Ist-Zustand sichern

Bevor du etwas änderst, dokumentierst du laufende Dienste, offene Ports, Benutzerzugänge und wichtige Konfigurationsdateien. Ohne diesen Ausgangspunkt wird Rückbau unnötig schwer.

Verifizieren: Der Schritt ist erfolgreich, wenn du nachvollziehbar sagen kannst, welche Dienste laufen, welche Ports offen sind und wie du im Notfall zurückkommst.

Schritt 2: Identität, SSH und Benutzerzugang härten

Dazu gehören sauberer SSH-Schlüsselzugang, eingeschränkte Root-Anmeldung, sinnvolle sudo-Nutzung und das Entfernen unnötiger Konten. Unsere SSH- und Rechte-Grundlagenartikel sind hier direkte Vorstufen.

Verifizieren: Öffne nach jeder SSH-Änderung eine zweite Sitzung und prüfe, dass du dich nicht ausgesperrt hast.

Schritt 3: Dienste, Ports und Firewall minimieren

Ein gehärteter Server bietet nur die Dienste an, die wirklich gebraucht werden. Typisch ist die Kombination aus Dienstprüfung, UFW-Regeln und dem Entfernen unnötiger Pakete.

Verifizieren: Der Schritt ist erfolgreich, wenn die Liste offener Ports kleiner und gleichzeitig weiterhin fachlich korrekt ist.

Schritt 4: Logging, Updates und Integritätskontrolle stärken

Ohne gute Logs und aktuelle Pakete ist Härtung nur halb fertig. Dazu gehören persistente Logs, sinnvolle Update-Strategien und bei höherem Anspruch zusätzliche Integritätswerkzeuge.

Verifizieren: Prüfe, dass Logs auch nach Änderungen sauber geschrieben werden und Update-Mechanismen nachvollziehbar aktiv sind.

Schritt 5: Dateirechte und Mount-Optionen prüfen

CIS betont zu Recht, dass nicht jede Datei und nicht jedes Dateisystem dieselben Freiheiten braucht. Kritische Beispiele sind Rechte auf Konfigurationsdateien oder restriktive Mount-Optionen für bestimmte Bereiche.

Verifizieren: Änderungen an Rechten oder Mount-Optionen sind nur erfolgreich, wenn der Dienst danach weiterhin läuft und die Schutzwirkung gleichzeitig verbessert wurde.

Schritt 6: Änderungen stufenweise testen und dokumentieren

Die eigentliche Härtung ist erst dann belastbar, wenn du jeden Block sauber dokumentiert und gegen den Live-Betrieb geprüft hast. Genau dort trennt sich ein Benchmark-PDF von echter Betriebsfähigkeit.

Verifizieren: Der Schritt ist erfolgreich, wenn jede Maßnahme einem Test oder einer Statusprüfung zugeordnet ist und du den Serverzustand später reproduzieren kannst.

Troubleshooting

• Nach Härtungsmaßnahmen funktioniert SSH nicht mehr: Sofort auf Rettungszugang oder Konsole zurückgreifen und die letzte Änderung isoliert zurücknehmen.
• Dienst startet nach Rechteänderung nicht: Eigentümer, Rechte und Logs gemeinsam prüfen.
• Benchmark passt fachlich nicht zur Rolle des Servers: Dann gilt Praxis vor Formalismus. Nicht jede Empfehlung passt 1:1 auf jede Umgebung.

Häufige Fragen

Muss ich jede CIS-Empfehlung blind umsetzen?

Nein. Der Benchmark ist ein Rahmen, keine magische Wahrheit ohne Kontext.

Warum ist Dokumentation bei Härtung so wichtig?

Weil Sicherheitsänderungen ohne klare Dokumentation später schwer nachvollziehbar und fehleranfällig werden.

Fazit

CIS-Härtung funktioniert in der Praxis nicht als Einmalaktion, sondern als kontrollierte Serie kleiner, prüfbarer Maßnahmen. Genau diese Arbeitsweise macht aus einer abstrakten Benchmark-Liste einen stabilen und betreibbaren Serverzustand.

Weiterführende Anleitungen und Quellen

• Linux-Server absichern: UFW-Firewall und Fail2ban
• SSH-Key-Authentifizierung einrichten
• Logs lesen mit journalctl und /var/log

Quellen: CIS Benchmarks, Debian Security Documentation, Ubuntu Security Guidance.