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

Die CIS Benchmarks des Center for Internet Security sind Konfigurationsempfehlungen für Betriebssysteme, gegliedert in Level 1 (Grundschutz mit geringen Nebenwirkungen) und Level 2 (strenger, für höheren Schutzbedarf). Für Debian und Ubuntu umfassen sie mehrere hundert Einzelprüfungen. Diese Anleitung setzt die für einen typischen KMU-Server wichtigsten Bereiche mit konkreten Befehlen und prüfbaren Werten um: Bestandsaufnahme, Updates, SSH, Konten und sudo, Firewall, Kernelparameter, Protokollierung und Dateiintegrität. Sie ersetzt nicht den Benchmark selbst, sondern zeigt, wie Sie ihn kontrolliert und nachweisbar abarbeiten.

Voraussetzungen

• Server: Debian 13 (Trixie) oder Ubuntu 24.04 LTS, x86-64 oder ARM64, mindestens 2 CPU-Kerne, 4 GB RAM, 20 GB freier Speicher. Die Befehle gelten für beide Systeme, Unterschiede sind genannt.
• Zugang: ein Benutzer mit sudo-Rechten, SSH-Anmeldung per Schlüssel bereits eingerichtet und getestet, dazu ein Notfallzugang über die Konsole des Hypervisors oder des Hosting-Anbieters.
• Sicherung: ein Snapshot oder Backup vor Beginn, damit Sie eine fehlerhafte Einstellung zurücknehmen können.
• Benchmark: das PDF des passenden CIS Benchmarks von cisecurity.org. Stand 30.09.2026: Ubuntu Linux 24.04 LTS v2.0.0, Debian Linux 13 v1.1.0. Die Texte sind urheberrechtlich geschützt; diese Anleitung nennt deshalb nur Bereiche und eigene Beispielwerte.
• Ubuntu optional: ein an Ubuntu Pro angebundenes System, denn das Ubuntu Security Guide (USG) ist ein Pro-Dienst (sudo pro attach).

Schritt 1: Ausgangszustand messen

Ohne Ausgangswert können Sie weder Fortschritt zeigen noch Nebenwirkungen erkennen. Unter Ubuntu prüft USG das System gegen die CIS-Profile von Canonical:

sudo pro enable usg
sudo apt install usg usg-benchmarks-1
sudo usg audit cis_level1_server

USG legt einen HTML- und einen XML-Bericht in /var/lib/usg/ ab. Für Debian 13 gibt es kein vergleichbares Paket; das OpenSCAP-Paket ssg-debian in Trixie enthält nur Inhalte für Debian 11 und 12. Nutzen Sie dort Lynis als herstellerunabhängige Prüfung. Lynis bewertet nicht nach CIS, zeigt aber dieselben Schwachstellen wie fehlende Updates, offene Dienste oder schwache SSH-Einstellungen.

sudo apt install lynis
sudo lynis audit system --quick
sudo grep '^suggestion' /var/log/lynis-report.dat

Verifizieren: Die Ausgabe von Lynis endet mit „Hardening index“ und „Tests performed“, unter Ubuntu zeigt USG eine Übersicht mit bestandenen und nicht bestandenen Regeln. Notieren Sie beide Werte als Ausgangsstand.

Schritt 2: Sicherheitsupdates automatisieren

Ein aktuelles System ist die erste Forderung jedes Benchmarks. Installieren Sie unattended-upgrades und aktivieren Sie den täglichen Lauf:

sudo apt update && sudo apt full-upgrade
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

Welche Quellen automatisch aktualisiert werden, und ob der Server nach Kernel-Updates selbst neu startet, legen Sie in /etc/apt/apt.conf.d/50unattended-upgrades fest. Details beschreibt Automatische Sicherheitsupdates mit unattended-upgrades.

Verifizieren: 20auto-upgrades enthält die Zeilen APT::Periodic::Update-Package-Lists "1"; und APT::Periodic::Unattended-Upgrade "1";, und sudo unattended-upgrade --dry-run --debug läuft ohne Fehler durch.

Schritt 3: SSH härten

Ändern Sie nicht die Hauptdatei /etc/ssh/sshd_config, sondern legen Sie eine eigene Datei im Verzeichnis sshd_config.d an. Debian 13 und Ubuntu 24.04 binden dieses Verzeichnis in Zeile 12 der Hauptdatei ein. OpenSSH übernimmt bei den meisten Optionen den ersten gefundenen Wert; eine Datei mit niedriger Nummer wie 10- hat daher Vorrang vor später gelesenen Dateien, etwa 50-cloud-init.conf von Cloud-Images.

sudo tee /etc/ssh/sshd_config.d/10-haertung.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
HostbasedAuthentication no
IgnoreRhosts yes
X11Forwarding no
MaxAuthTries 4
LoginGraceTime 60
ClientAliveInterval 300
ClientAliveCountMax 3
LogLevel VERBOSE
EOF
sudo chmod 600 /etc/ssh/sshd_config.d/10-haertung.conf
sudo sshd -t && sudo systemctl reload ssh

Laden Sie den Dienst erst neu, wenn sshd -t ohne Ausgabe endet. Lassen Sie die aktuelle Sitzung offen und testen Sie die Anmeldung in einem zweiten Fenster. Weitere Einstellungen wie Algorithmen und Match-Blöcke vertieft SSH-Hardening Deep-Dive.

Verifizieren: sudo sshd -T | grep -Ei '^(permitrootlogin|passwordauthentication|maxauthtries|x11forwarding)' zeigt permitrootlogin no, passwordauthentication no, maxauthtries 4 und x11forwarding no. Eine neue Anmeldung per Schlüssel gelingt, eine Anmeldung als root wird abgelehnt.

Schritt 4: Kennwortregeln und sudo-Protokoll

Auch wenn SSH nur Schlüssel annimmt, gelten Kennwörter für sudo und die Konsole. libpam-pwquality trägt sich bei der Installation selbst in den PAM-Stapel ein. Setzen Sie eine Mindestlänge von 14 Zeichen:

sudo apt install libpam-pwquality
sudo sed -i 's/^# *minlen.*/minlen = 14/' /etc/security/pwquality.conf
grep '^minlen' /etc/security/pwquality.conf
grep pam_pwquality /etc/pam.d/common-password

Damit nachvollziehbar bleibt, wer mit Administratorrechten was ausgeführt hat, schreiben Sie alle sudo-Aufrufe in eine eigene Protokolldatei. Bearbeiten Sie sudoers-Dateien nur so, dass visudo sie prüft; ein Syntaxfehler sperrt sonst sudo komplett.

echo 'Defaults logfile="/var/log/sudo.log"' | sudo tee /etc/sudoers.d/10-log
sudo chmod 440 /etc/sudoers.d/10-log
sudo visudo -c

Verifizieren: grep zeigt minlen = 14 und die Zeile pam_pwquality.so retry=3 in common-password. visudo -c meldet für jede Datei „parsed OK“, und nach dem nächsten sudo-Aufruf enthält /var/log/sudo.log einen Eintrag.

Schritt 5: Firewall und Dienste

Der Benchmark verlangt eine aktive Host-Firewall mit Standardregel „eingehend verweigern“. Auf Debian und Ubuntu ist ufw der einfachste Weg. Geben Sie SSH frei, bevor Sie die Firewall einschalten:

sudo apt install ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

Prüfen Sie außerdem, welche Dienste überhaupt lauschen, und entfernen Sie alles, was der Server nicht braucht, etwa avahi, rsync-Daemon oder telnet:

sudo ss -tulpn
systemctl list-unit-files --type=service --state=enabled

Wie ufw mit Fail2ban zusammenspielt, zeigt Linux-Server absichern: UFW-Firewall und Fail2ban.

Verifizieren: ufw status verbose zeigt „Status: active“ und „Default: deny (incoming), allow (outgoing)“. ss -tulpn listet nur Dienste, die Sie bewusst betreiben.

Schritt 6: Kernelparameter setzen

Mehrere Empfehlungen betreffen das Netzwerkverhalten des Kernels. Ein Server, der nicht routet, soll keine ICMP-Umleitungen annehmen oder senden und keine quellgerouteten Pakete akzeptieren. Legen Sie die Werte in einer eigenen Datei ab:

sudo tee /etc/sysctl.d/60-haertung.conf >/dev/null <<'EOF'
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_syncookies = 1
net.ipv6.conf.all.accept_redirects = 0
kernel.randomize_va_space = 2
EOF
sudo sysctl --system

Betreibt der Server Docker, einen VPN-Endpunkt oder arbeitet als Router, darf net.ipv4.ip_forward nicht abgeschaltet werden. Solche Ausnahmen gehören in die Dokumentation aus Schritt 8.

Verifizieren: sysctl net.ipv4.conf.all.accept_redirects net.ipv4.tcp_syncookies kernel.randomize_va_space zeigt die Werte 0, 1 und 2, auch nach einem Neustart.

Schritt 7: Protokolle und Dateiintegrität

Debian 13 protokolliert standardmäßig nur über das systemd-Journal, ohne rsyslog und ohne /var/log/auth.log. Sorgen Sie auf beiden Systemen dafür, dass das Journal Neustarts überdauert:

sudo mkdir -p /etc/systemd/journald.conf.d
printf '[Journal]\nStorage=persistent\nCompress=yes\n' | sudo tee /etc/systemd/journald.conf.d/60-haertung.conf
sudo systemctl restart systemd-journald
journalctl --list-boots | tail -3

AIDE erkennt veränderte Systemdateien, indem es Prüfsummen mit einer Referenzdatenbank vergleicht. Legen Sie die Datenbank nach Abschluss der Härtung an, damit die eigenen Änderungen nicht als Abweichung erscheinen:

sudo apt install aide
sudo aideinit -y -f
sudo aide --check --config /etc/aide/aide.conf

Die Prüfung mit auditd auf einzelne Systemaufrufe ordnet der Benchmark Level 2 zu. Für einen typischen KMU-Server genügt zunächst Level 1; auditd planen Sie bei höherem Schutzbedarf gesondert ein.

Verifizieren: journalctl --list-boots zeigt nach einem Neustart mehr als einen Eintrag, und aide --check meldet unmittelbar nach dem Anlegen keine Unterschiede.

Schritt 8: Erneut messen und Abweichungen dokumentieren

Wiederholen Sie die Messung aus Schritt 1. Nicht jede offene Regel ist ein Fehler: Eine eigene Partition für /var/tmp lässt sich auf einem kleinen VPS kaum nachrüsten, und ein Docker-Host braucht IP-Weiterleitung. Halten Sie solche Punkte als bewusste Ausnahme mit Begründung fest. Unter Ubuntu bildet USG das technisch ab: Sie erzeugen eine Tailoring-Datei, schalten einzelne Regeln ab oder ändern Werte und prüfen dagegen.

sudo usg generate-tailoring cis_level1_server tailor.xml
sudo usg audit --tailoring-file tailor.xml

Der Befehl usg fix setzt alle Regeln eines Profils automatisch um. Verwenden Sie ihn nur auf einem Testsystem oder einem frisch installierten Server und nie ungeprüft auf einem produktiven System, weil er auch Einstellungen ändert, die Ihre Anwendungen brauchen.

Verifizieren: Der Hardening index von Lynis beziehungsweise die Quote bestandener USG-Regeln liegt über dem Ausgangswert, und für jede verbleibende offene Regel gibt es einen Eintrag mit Begründung.

Typische Fehler

• Ausgesperrt nach SSH-Änderung: PasswordAuthentication no gesetzt, bevor der Schlüssel funktionierte. Über die Konsole des Anbieters anmelden und die Drop-in-Datei korrigieren. Deshalb immer eine zweite Sitzung offen halten.
• sshd startet nicht mehr: Tippfehler in der Konfiguration. sshd -t meldet ihn vorher, zum Beispiel „Bad configuration option: PermitRootLogn“ mit Exit-Code 255.
• Einstellung wirkt nicht: Eine früher gelesene Datei setzt denselben Wert. sshd -T zeigt den tatsächlich gültigen Wert; die eigene Datei mit niedriger Nummer benennen.
• sudo komplett gesperrt: sudoers-Datei ohne visudo -c geschrieben. Über die Konsole oder den Wiederherstellungsmodus die Datei in /etc/sudoers.d/ löschen.
• Docker-Container ohne Netzwerk: IP-Weiterleitung abgeschaltet. net.ipv4.ip_forward wieder erlauben und als Ausnahme dokumentieren.
• Kein /var/log/auth.log unter Debian 13: Kein Fehler, sondern Journal-Betrieb. Anmeldungen mit journalctl -u ssh auswerten.

Häufige Fragen

Level 1 oder Level 2?

Für die meisten KMU-Server ist Level 1 Server der richtige Start. Level 2 ergänzt unter anderem auditd und strengere Partitionierung und lohnt sich bei höherem Schutzbedarf oder wenn Kunden es vertraglich fordern.

Ist ein CIS Benchmark Pflicht?

Nein, CIS Benchmarks sind Empfehlungen. Sie eignen sich aber gut als nachvollziehbarer Maßstab, wenn Sie gegenüber Kunden, Versicherern oder Prüfern belegen wollen, nach welchem Standard Ihre Server konfiguriert sind.

Kann ich den Benchmark automatisch umsetzen?

Unter Ubuntu mit usg fix, für mehrere Server auch mit Konfigurationsmanagement wie Ansible. Automatisierung ersetzt aber nicht die Prüfung, welche Regeln zu Ihren Anwendungen passen.

Wie oft sollte ich prüfen?

Nach jeder größeren Änderung und mindestens nach jedem Distributions-Upgrade. Ein monatlicher Lynis- oder USG-Lauf per Timer zeigt schleichende Abweichungen.

Fazit

Ein CIS Benchmark wirkt wegen seiner Länge abschreckend, lässt sich aber in wenigen Blöcken abarbeiten: messen, Updates, SSH, Konten, Firewall, Kernel, Protokolle, erneut messen. Entscheidend sind die kleinen Sicherungen dazwischen: sshd -t vor jedem Neuladen, visudo -c für sudo, eine offene zweite Sitzung und eine Liste der bewussten Ausnahmen. So bleibt die Härtung nachvollziehbar und der Server erreichbar.

Weiterführende Anleitungen und Quellen

• SSH-Hardening Deep-Dive: sshd_config, Match-Blöcke und ssh-audit
• Linux-Server absichern: UFW-Firewall und Fail2ban
• Automatische Sicherheitsupdates mit unattended-upgrades
• CIS Benchmarks (Download)
• Ubuntu Security Guide (USG): Audit, Tailoring, Fix
• Lynis-Dokumentation
• OpenSSH: sshd_config(5)