Ein CIS Benchmark ist eine frei erhältliche Sammlung von Härtungsempfehlungen des Center for Internet Security, für Debian 13 gibt es eine eigene Fassung. Gehärtet wird in fünf Schritten: Ist-Stand messen, jede Regel bewerten, die Regeln automatisiert mit Ansible umsetzen, erneut messen und Ausnahmen begründet dokumentieren. Von Hand gehärtete Server driften mit der Zeit ab, automatisiert gehärtete lassen sich jederzeit nachprüfen.
01Was ein CIS Benchmark ist
Das Center for Internet Security (CIS) veröffentlicht für Betriebssysteme und Anwendungen Empfehlungen, wie man sie sicher einstellt. Sie entstehen im Konsens von Fachleuten und sind in der Branche der verbreitetste Maßstab für Härtung.
Wichtig zu wissen:
- Profile: Level 1 enthält Regeln, die den Betrieb kaum einschränken und fast überall passen. Level 2 geht weiter und ist für Systeme mit höherem Schutzbedarf gedacht.
- Fassungen: Jedes System hat seinen eigenen Benchmark. Für Debian 13 gibt es seit Ende 2025 eine eigene Fassung. Prüf auf der Seite des CIS, welche Version gerade aktuell ist.
- Zugang: Die Benchmarks gibt es nach einer kostenlosen Registrierung als PDF. Lesen und anwenden ist frei, den Text selbst darf man nicht weiterverbreiten. Deshalb erklärt dieser Artikel die Regeln in eigenen Worten.
02Warum automatisiert statt von Hand
Ein von Hand gehärteter Server ist nach einem halben Jahr selten noch so, wie er am ersten Tag war. Updates, schnelle Änderungen und vergessene Ausnahmen lassen ihn langsam abdriften. Mit Ansible steht die Härtung als Code im Repository:
- Wiederholbar: Jeder neue Server bekommt dieselbe Härtung.
- Prüfbar: Ein Lauf im Prüfmodus zeigt jederzeit, ob ein Server noch dem Soll entspricht.
- Nachweisbar: Für Audits nach ISO 27001 oder NIS2 ist der Code zugleich die Dokumentation.
03Härten in fünf Schritten
1. Benchmark und Profil wählen
Lade den CIS Benchmark für Debian Linux 13 herunter und entscheide Dich für ein Profil. Für den Einstieg nimm Level 1 Server.
2. Ist-Stand messen
Bevor Du etwas änderst, misst Du. Dafür gibt es zwei einfache Wege:
- Wazuh: Der Wazuh-Agent bringt eine Prüfung nach CIS mit (Security Configuration Assessment, für Debian 13 die Richtlinie cis_debian13). Nach der Installation siehst Du im Dashboard für jede Regel „bestanden“ oder „nicht bestanden“ und einen Gesamtwert.
- CIS-CAT Lite: das kostenlose Prüfwerkzeug des CIS selbst.
Notier Dir den Gesamtwert. Das ist Dein Ausgangspunkt.
3. Jede Regel bewerten
Nicht jede Regel passt zu jedem Server. Geh die nicht bestandenen Regeln durch und entscheide für jede:
- Umsetzen: der Normalfall.
- Ausnahme: Die Regel würde eine Funktion brechen, die der Server braucht. Dann schreibst Du auf, welche Regel, warum und wer das entschieden hat.
Eine begründete Ausnahme ist kein Fehler. Eine unbegründete schon.
4. Mit Ansible umsetzen
Schreib für die Regeln eine eigene Ansible-Rolle. Lass sie zuerst im Prüfmodus laufen (--check --diff) und sieh Dir an, was sie ändern würde. Erst dann spielst Du sie wirklich ein.
Ein Beispiel für die Regel „keine direkte Anmeldung als root über SSH“:
- name: SSH-Anmeldung als root verbieten
ansible.builtin.copy:
dest: /etc/ssh/sshd_config.d/50-haertung.conf
content: |
PermitRootLogin no
owner: root
group: root
mode: "0600"
notify: SSH neu laden
- name: SSH-Konfiguration pruefen
ansible.builtin.command: sshd -t
changed_when: falseFür fertige Umsetzungen gibt es Rollen aus der Community, etwa aus dem Projekt Ansible Lockdown. Sie sind ein gutes Nachschlagewerk. Prüfe aber, ob es schon eine Fassung für Debian 13 gibt, und übernimm nichts, was Du nicht verstehst.
5. Erneut messen
Lass die Prüfung in Wazuh oder CIS-CAT erneut laufen und vergleiche mit Deinem Ausgangswert. Jede Regel, die noch rot ist, ist entweder eine dokumentierte Ausnahme oder eine offene Aufgabe.
04Vier Beispielregeln, in eigenen Worten
- SSH ohne root: Wer sich anmelden will, nutzt einen eigenen Benutzer mit Schlüssel und wechselt bei Bedarf mit sudo. So ist jede Handlung einer Person zugeordnet.
- /tmp ohne ausführbare Dateien: Das temporäre Verzeichnis darf jeder beschreiben. Wenn dort nichts ausgeführt werden kann, hat ein Angreifer einen Ablageort weniger. Unter Debian 13 ist /tmp standardmäßig ein tmpfs, die Optionen setzt man über eine Ergänzung der systemd-Einheit tmp.mount.
- Protokollierung mit auditd: Wichtige Ereignisse wie Änderungen an Benutzern oder an der Zeit werden protokolliert. Ohne Protokoll lässt sich ein Vorfall später nicht aufklären.
- Kennwortregeln: Mindestlänge und Komplexität für lokale Kennwörter, umgesetzt mit libpam-pwquality.
05Typische Fallen
- Selbst ausgesperrt: Wer die SSH-Härtung einspielt, bevor die Anmeldung per Schlüssel funktioniert, kommt nicht mehr auf den Server. Deshalb immer zuerst prüfen, dann einspielen, und eine zweite Sitzung offen halten.
- Dienste brechen: Manche Programme legen ausführbare Dateien in /tmp ab. Nach der Härtung starten sie nicht mehr. Teste jeden Dienst, bevor Du die Regel überall ausrollst.
- Regeln, die sich gegenseitig blockieren: Eine Regel lässt den Server anhalten, wenn die Protokollierung nicht mehr schreiben kann. Zusammen mit einer anderen Härtung, die Protokolldateien schreibgeschützt macht, fuhr in einem Fall ein Server danach bei jedem Start sofort wieder herunter. Deshalb vor jeder Härtung einen Snapshot anlegen.
- Falsche Fehlermeldungen der Prüfung: Auch Prüfwerkzeuge irren sich. Für die Wazuh-Prüfung cis_debian13 sind Regeln bekannt, die auf korrekt eingestellten Systemen als nicht bestanden gelten, etwa weil sie ein Programm unter einem Pfad suchen, den Debian anders nutzt. Prüf jede auffällige Meldung selbst nach, bevor Du etwas änderst.
06Übung
- Setze eine Debian-13-VM auf und mach einen Snapshot.
- Installiere den Wazuh-Agenten und notiere den Gesamtwert der CIS-Prüfung.
- Schreib eine Ansible-Rolle mit fünf Regeln aus dem Benchmark, darunter SSH ohne root und /tmp ohne ausführbare Dateien.
- Lass sie im Prüfmodus laufen, dann wirklich.
- Miss erneut und vergleiche.
- Schreib für jede Regel, die Du bewusst nicht umsetzt, eine Ausnahme mit Begründung.
Geschafft, wenn: Dein Wert gestiegen ist, ein zweiter Ansible-Lauf nichts mehr ändert und jede verbleibende rote Regel begründet ist.
07Häufige Fragen zur CIS-Härtung
Was ist ein CIS Benchmark? Eine Sammlung von Konfigurationsempfehlungen des Center for Internet Security für ein bestimmtes System, zum Beispiel Debian 13. Jede Empfehlung beschreibt, was eingestellt wird, warum, und wie man es prüft.
Was ist der Unterschied zwischen Level 1 und Level 2? Level 1 ist die Grundhärtung, die sich auf fast jedem Server ohne große Nebenwirkungen umsetzen lässt. Level 2 geht weiter und ist für Systeme mit hohem Schutzbedarf gedacht; dort kann es Funktionen einschränken, die eine Anwendung braucht.
Muss ein Server alle Empfehlungen erfüllen? Nein. Ziel ist ein bewusster Stand: Jede Regel ist entweder umgesetzt oder als Ausnahme mit Begründung dokumentiert. Ein Server mit 90 Prozent und sauber begründeten Ausnahmen ist besser als einer, bei dem niemand weiß, warum etwas fehlt.
Womit messe ich den Stand meines Servers? Zum Beispiel mit der Konfigurationsprüfung von Wazuh oder mit CIS-CAT Lite. Wichtig ist, vor und nach jeder Änderung mit demselben Werkzeug zu messen, damit die Zahlen vergleichbar sind.
08Weiter im Lernpfad
Zurück zur Übersicht: Lernpfad IT-Infrastruktur. Wenn Du in der Umschulung zum Fachinformatiker bist und so etwas gern beruflich machen willst: Härtung ist Teil unseres Praktikums Fachinformatiker Systemintegration. Alle Praktikumsplätze stehen auf der Karriereseite.
Zuletzt geprüft: Oktober 2026
