Security & Hardening

Linux-Server absichern: die Härtungs-Checkliste für deinen Produktivbetrieb

Die Reihenfolge entscheidet: erst SSH und Paketstand, dann sudo und Firewall, zuletzt Logging und Mandatory Access Control. Wer mit SELinux anfängt, hat am Ende ein System, das im Team niemand mehr anfassen will.

Passende Kurse ansehen Persönlich beraten lassen

Zwei Security-Fachleute prüfen ein Dashboard im Betriebsraum

Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team

Worum es geht

Warum eine Standardinstallation noch kein produktionsreifer Server ist

Eine frische Installation von Debian, RHEL oder SLES ist ein funktionsfähiger Ausgangspunkt, kein gehärtetes System. Die Distributionen liefern bewusst zugängliche Standardwerte aus, damit die Erstinbetriebnahme klappt: Passwort-Login über SSH ist in vielen Images noch aktiv, es laufen Dienste mit, die niemand braucht, und Auditing schreibt entweder gar nicht oder in ein Log, das niemand liest. Sobald der Host eine öffentliche Adresse bekommt, treffen ihn innerhalb weniger Minuten die ersten automatisierten Login-Versuche.

In der Praxis scheitert Härtung selten am fehlenden Wissen, sondern an fehlender Reihenfolge und fehlender Dokumentation. Es wird ein Blogartikel abgearbeitet, ein paar Werte in der sshd_config geändert, fail2ban nachinstalliert, und danach weiß niemand mehr, welcher Host welchen Stand hat. Wenn dann ein Audit oder eine Kundenanfrage nach dem Sicherheitskonzept kommt, fehlt die Referenz, gegen die man prüfen könnte.

Die typischen Fehler wiederholen sich: SELinux oder AppArmor wird nach dem ersten Denial auf permissive gesetzt, statt die Policy um ein passendes Modul zu ergänzen. Die Firewall wächst zu einem Regelsatz, bei dem niemand mehr sagen kann, welche Regel zuerst greift. Unattended Upgrades laufen ohne Reboot-Konzept, sodass ein gepatchter Kernel monatelang nicht aktiv wird. Und die Logs bleiben lokal auf genau dem System, das im Ernstfall kompromittiert ist.

Miniatur-Szene: Serverschrank in einer Schutzhülle, Vorhängeschlösser und ein Schild davor

Härtung in sechs Schritten, von außen nach innen

01 Zugang: SSH mit Schlüsseln
02 Angriffsfläche: Dienste und Pakete
03 Updates und Reboot-Konzept
04 Rechte: Benutzer und sudo
05 Netz: nftables default deny
06 Nachweis: Logging, auditd, SELinux

Was du mitnimmst

Die Härtung in der Reihenfolge, die sich im Betrieb bewährt hat

Arbeite die Maßnahmen von außen nach innen ab. Erst der Zugang, dann die Angriffsfläche, dann die Rechte, dann die Nachvollziehbarkeit. Jeder Schritt sollte reproduzierbar sein, also am besten als Ansible-Rolle oder als Kickstart- beziehungsweise AutoYaST-Profil, nicht als Handarbeit auf der Konsole.

SSH als erste Bastion schließen

Deaktiviere PasswordAuthentication und PermitRootLogin, arbeite ausschließlich mit Public-Key-Verfahren oder Zertifikaten und begrenze den Zugang über AllowGroups auf eine dedizierte Gruppe. Auf systemd-Systemen mit socket-basiertem sshd genügt ein Drop-in unter /etc/ssh/sshd_config.d/, das bleibt beim Distributions-Update erhalten. fail2ban oder sshguard reduziert danach nur noch das Log-Rauschen, es ersetzt die Konfiguration nicht.

Angriffsfläche und Paketstand reduzieren

Prüfe mit systemctl list-units --type=service und ss -tulpen, was tatsächlich lauscht, und deaktiviere alles, was keinen Zweck erfüllt. Minimal-Images sind der bessere Startpunkt als eine nachträglich entrümpelte Vollinstallation. Für Updates brauchst du eine Entscheidung: dnf-automatic oder unattended-upgrades mit definiertem Wartungsfenster, und ein Verfahren für Kernel-Reboots, etwa über needs-restarting oder Live Patching.

Benutzer, sudo und Dateirechte sauber trennen

Jeder Mensch bekommt einen eigenen Account, Dienste laufen unter eigenen Systemnutzern ohne Login-Shell. Statt eines pauschalen ALL=(ALL) NOPASSWD schreibst du gezielte sudoers-Regeln in /etc/sudoers.d/ und aktivierst das sudo-Logging. Ergänzend gehören SUID-Binaries inventarisiert und Mount-Optionen wie nodev, nosuid und noexec auf /tmp und /var/tmp gesetzt.

Netzwerkzugriff über nftables statt Einzelregeln steuern

Formuliere den Regelsatz als default deny im Input-Pfad und öffne nur die Ports, die ein Dienst wirklich braucht, idealerweise gebunden an Quellnetze. Ob du direkt mit nftables arbeitest oder mit firewalld beziehungsweise ufw als Frontend, ist zweitrangig, entscheidend ist, dass genau ein Werkzeug den Regelsatz verwaltet und die Konfiguration versioniert vorliegt.

Mandatory Access Control aktiv lassen

SELinux im Enforcing-Modus oder AppArmor im Enforce-Profil begrenzt den Schaden, wenn ein exponierter Dienst kompromittiert wird. Denials analysierst du mit ausearch und audit2allow, passt Booleans und Dateikontexte über semanage an und baust nur dort ein eigenes Policy-Modul, wo die Standard-Policy den Anwendungsfall nicht abdeckt. Abschalten ist keine Lösung, sondern verschiebt das Problem.

Logging, Auditing und Integrität nachvollziehbar machen

Leite journald oder rsyslog auf einen zentralen Empfänger weiter, damit Spuren einen Kompromittierungsversuch überleben. auditd liefert dir mit passenden Regeln die Nachweise für Zugriffe auf sicherheitsrelevante Dateien, AIDE erkennt Veränderungen am Dateisystem. Prüfe den Stand regelmäßig gegen eine Baseline, etwa mit OpenSCAP und einem passenden Profil.

Zum Nachmachen

Server härten, Schritt für Schritt

Härtung ist kein Wochenendprojekt und kein Skript, das du einmal laufen lässt. Sie ist eine Reihenfolge von Entscheidungen, die du begründen und im Zweifel zurücknehmen können musst. Die folgenden Kapitel gehen genau diese Reihenfolge durch: von der Absicherung deines eigenen Zugangs über Kernel, Dienste und Rechte bis zu Auditing, Schwachstellenscans und dem Nachweis gegenüber Prüfstellen. Alle Befehle sind für aktuelle Systeme geschrieben, Unterschiede zwischen RHEL-Derivaten und Debian/Ubuntu stehen jeweils dabei.

Bevor du die erste Zeile änderst

Die meisten kaputten Server nach einer Härtungssitzung sind nicht gehackt, sondern ausgesperrt. Diese vier Regeln kosten dich zehn Minuten und ersparen dir den Gang ins Rechenzentrum.

Eine zweite SSH-Sitzung offen lassenDu testest jede Änderung an sshd in einem neuen Terminal. Sperrst du dich aus, bleibt die alte Sitzung dein Rückweg. Schließe sie erst, wenn die neue Anmeldung nachweislich funktioniert.
Snapshot oder Konfigurationssicherung anlegenBei einer VM ein Snapshot, auf Blech mindestens ein Archiv von /etc. Ohne Rückweg ist jede Änderung ein Risiko, das du nicht kalkulieren kannst.
Konsolenzugriff sicherstellenIPMI, iDRAC, iLO oder die Konsole des Hypervisors. Wenn Netzwerk oder SSH ausfallen, ist das dein einziger Weg zurück.
Eine Änderung nach der anderenWer zehn Maßnahmen gleichzeitig ausrollt und danach ein kaputtes System hat, weiß nicht, welche davon schuld war. Änderung, Test, Protokoll, nächste Änderung.

Sicherung von /etc, datiert

# Vollständige Kopie der Konfiguration, bevor irgendetwas angefasst wird
sudo tar czf /root/etc-vor-haertung-$(date +%F).tar.gz /etc

# Paketstand festhalten, damit du später vergleichen kannst
dpkg -l > /root/pakete-$(date +%F).txt        # Debian/Ubuntu
rpm -qa | sort > /root/pakete-$(date +%F).txt  # RHEL/Rocky/Alma

Lege die Sicherung nicht auf demselben Datenträger ab, den du gerade absicherst. Ein Kopie auf einem anderen Host oder einem Backup-Ziel ist der Sinn der Übung.

Ein Wort zur Reihenfolge: Die Kapitel hier sind nicht beliebig sortiert. Zuerst kommt alles, was deinen eigenen Zugang betrifft, denn ein ausgesperrter Administrator ist ein Ausfall. Danach folgen die Ebenen von unten nach oben, also Partitionen und Kernel vor Diensten und Anwendungen. Zuletzt stehen Auditing und Nachweis, weil sie die vorherigen Schritte protokollieren sollen und nicht umgekehrt.

Bestandsaufnahme: Was läuft hier eigentlich?

Du kannst nur absichern, was du kennst. Vor der ersten Maßnahme steht deshalb eine ehrliche Inventur der Angriffsfläche: offene Ports, laufende Dienste, Benutzer mit Anmelderecht und Programme mit erhöhten Rechten.

Angriffsfläche in fünf Befehlen

# Welche Dienste lauschen nach außen?
ss -tulpn | grep LISTEN

# Welche Units sind aktiv und starten beim Booten mit?
systemctl list-units --type=service --state=running
systemctl list-unit-files --state=enabled

# Wer darf sich anmelden? (Shell weder nologin noch false)
awk -F: '$7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd

# Konten ohne Passwort - das darf keine Ausgabe liefern
sudo awk -F: '$2 == "" {print $1}' /etc/shadow

# Programme mit SUID/SGID-Bit
sudo find / -xdev -type f -perm /6000 -exec ls -l {} \; 2>/dev/null

Schreib dir die Ausgaben weg. Nach der Härtung wiederholst du dieselben Befehle, und die Differenz ist dein Ergebnisnachweis.

Ein erster automatisierter Blick lohnt sich ebenfalls. Lynis ist quelloffen, läuft ohne Agent und liefert dir in wenigen Minuten einen Härtungsindex samt konkreter Vorschläge. Der Wert selbst ist zweitrangig, interessant sind die Einzelbefunde und ihre Begründung.

Lynis-Audit

sudo apt install lynis     # Debian/Ubuntu
sudo dnf install lynis     # RHEL/Rocky/Alma

sudo lynis audit system

# Ergebnis und Vorschläge nachlesen
sudo grep -E 'Suggestion|Warning' /var/log/lynis-report.dat

Arbeite die Vorschläge nicht blind ab. Lynis kennt deinen Anwendungsfall nicht, manche Empfehlungen brechen produktive Dienste.

Partitionen und Mount-Optionen

Getrennte Dateisysteme mit passenden Mount-Optionen sind eine der wirksamsten Maßnahmen überhaupt, weil sie eine ganze Angriffsklasse abschneiden: das Ausführen hochgeladener Programme aus Verzeichnissen, in die jeder schreiben darf.

Empfohlene Trennung und Optionen

Pfad	Optionen	Warum
`/tmp`	`nodev,nosuid,noexec`	Jeder darf hineinschreiben. Ohne `noexec` ist das Verzeichnis die bequemste Startrampe für nachgeladene Schadsoftware.
`/var/tmp`	`nodev,nosuid,noexec`	Gleiche Begründung, wird beim Härten regelmäßig vergessen.
`/dev/shm`	`nodev,nosuid,noexec`	Gemeinsamer Speicher, ebenfalls für alle schreibbar.
`/home`	`nodev,nosuid`	Kein `noexec`, sonst können Nutzende keine eigenen Skripte starten. `nosuid` verhindert Rechteausweitung.
`/var`	`nosuid`	Volllaufende Logs legen so nicht gleich das Wurzeldateisystem lahm.
`/var/log` und `/var/log/audit`	`nodev,nosuid,noexec`	Eigene Partition schützt die Beweislage: Wer die Platte vollschreibt, löscht sonst indirekt deine Protokolle.
`/boot`	`nodev,nosuid,noexec`	Wird im Betrieb nicht gebraucht, kann sogar schreibgeschützt eingehängt werden.

/etc/fstab, Ausschnitt

UUID=...  /tmp       ext4  defaults,nodev,nosuid,noexec  0 2
UUID=...  /var       ext4  defaults,nosuid               0 2
UUID=...  /var/log   ext4  defaults,nodev,nosuid,noexec  0 2
UUID=...  /home      ext4  defaults,nodev,nosuid         0 2
tmpfs     /dev/shm   tmpfs defaults,nodev,nosuid,noexec  0 0

Nach jeder fstab-Änderung sudo mount -a ausführen und die Ausgabe prüfen. Ein Tippfehler hier führt beim nächsten Neustart in den Notfallmodus, und dann brauchst du genau den Konsolenzugriff aus Kapitel 01.

Existiert keine eigene Partition, hilft ein Bind-Mount als Zwischenlösung. Sauberer ist die Trennung beim Aufsetzen des Systems, weshalb sich diese Entscheidung im Installationsprofil oder im Kickstart- beziehungsweise Preseed-Template lohnt statt nachträglich auf jedem Host.

Prüfen, ob die Optionen greifen

findmnt -no TARGET,OPTIONS /tmp /var/log /dev/shm

# Gegenprobe: Ausführen in /tmp muss scheitern
cp /bin/true /tmp/test && /tmp/test; echo "Exit: $?"
# Erwartet: Permission denied

Die Gegenprobe ist wichtig. Eine Option in der fstab, die nach einem Neustart nicht greift, ist eine Maßnahme, die nur auf dem Papier existiert.

Bootloader und physischer Zugriff

Wer an der Konsole steht, hängt sonst einfach init=/bin/bash an die Kernelzeile und ist root. Ein GRUB-Passwort verhindert das Bearbeiten der Startparameter, ohne den normalen Bootvorgang zu stören.

GRUB-Passwort setzen (Debian/Ubuntu)

# Hash erzeugen
sudo grub-mkpasswd-pbkdf2

# Ausgabe in /etc/grub.d/40_custom eintragen:
#   set superusers="admin"
#   password_pbkdf2 admin grub.pbkdf2.sha512.10000.<HASH>

sudo update-grub
sudo chmod 600 /boot/grub/grub.cfg

Auf RHEL-Derivaten heißt der Befehl grub2-setpassword, die Konfiguration wird mit grub2-mkconfig -o /boot/grub2/grub.cfg erzeugt.

Ergänzend gehört der Einzelbenutzermodus abgesichert, damit er nach dem Root-Passwort fragt, und die Verschlüsselung der Datenträger auf die Tagesordnung. Für Systeme außerhalb kontrollierter Rechenzentren, etwa in Außenstellen oder Filialen, ist LUKS keine Kür: Ohne Verschlüsselung ist ein gestohlener Server gleichbedeutend mit einem vollständigen Datenabfluss, samt Meldepflicht nach Artikel 33 DSGVO.

Kernel-Parameter härten

Über sysctl schaltest du eine Reihe von Schutzmechanismen ein, die der Kernel mitbringt, aber aus Kompatibilitätsgründen nicht überall aktiviert. Die folgenden Werte sind auf Servern praxiserprobt und brechen im Normalbetrieb nichts.

/etc/sysctl.d/60-haertung.conf

# --- Speicher und Kernel-Interna ---
kernel.randomize_va_space = 2      # volle Adressraum-Zufälligkeit (ASLR)
kernel.kptr_restrict = 2           # keine Kernel-Zeiger in /proc für Nutzende
kernel.dmesg_restrict = 1          # Kernel-Ringpuffer nur für root
kernel.sysrq = 0                   # Magic SysRq abschalten
kernel.yama.ptrace_scope = 1       # Prozesse dürfen sich nicht gegenseitig auslesen
fs.suid_dumpable = 0               # keine Core-Dumps von SUID-Programmen

# --- Dateisystem ---
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2

# --- Netzwerk IPv4 ---
net.ipv4.tcp_syncookies = 1                   # SYN-Flood abfedern
net.ipv4.conf.all.rp_filter = 1               # Rückpfad-Prüfung gegen Spoofing
net.ipv4.conf.all.accept_source_route = 0     # Quellrouting ablehnen
net.ipv4.conf.all.accept_redirects = 0        # ICMP-Redirects ignorieren
net.ipv4.conf.all.send_redirects = 0          # selbst keine senden
net.ipv4.conf.all.log_martians = 1            # unplausible Pakete protokollieren
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

# --- Netzwerk IPv6 ---
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_source_route = 0

Aktivieren mit sudo sysctl --system, prüfen mit sysctl kernel.randomize_va_space net.ipv4.tcp_syncookies.

Nicht benötigte Dateisystem- und Protokolltreiber lädst du am besten gar nicht erst. Jedes Modul ist Code im Kernel-Kontext und damit potenzielle Angriffsfläche, und mehrere bekannte Rechteausweitungen der letzten Jahre steckten genau in selten genutzten Dateisystemen.

/etc/modprobe.d/haertung.conf

install cramfs /bin/true
install freevxfs /bin/true
install jffs2 /bin/true
install hfs /bin/true
install hfsplus /bin/true
install udf /bin/true
install usb-storage /bin/true   # nur wenn keine USB-Datenträger gebraucht werden

# Selten benötigte Netzwerkprotokolle
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true

usb-storage nur auf Servern sperren. Auf Arbeitsplatzrechnern legst du damit jeden USB-Stick still.

Warum diese Werte nicht ab Werk gesetzt sind, hat einen einfachen Grund: Distributionen müssen auf sehr unterschiedlicher Hardware und in sehr unterschiedlichen Netzen funktionieren. Eine Voreinstellung, die auf einem Router im Rechenzentrum richtig ist, bricht auf einem Laptop mit wechselnden Netzen. Deshalb liegt die Entscheidung bei dir, und deshalb solltest du jede Zeile oben verstanden haben, bevor du sie übernimmst.

Benutzer, Passwörter und PAM

Die meisten erfolgreichen Angriffe brauchen keine Lücke im Kernel, sondern ein schwaches Passwort und genug Versuche. An dieser Stelle greifen Sperren nach Fehlversuchen, Mindestanforderungen und die konsequente Trennung zwischen Konten für Menschen und Konten für Dienste.

/etc/security/pwquality.conf

minlen = 14          # Mindestlänge
minclass = 3         # mindestens drei Zeichenklassen
maxrepeat = 3        # keine langen Wiederholungen
difok = 5            # mindestens fünf neue Zeichen gegenüber dem alten Passwort
enforce_for_root     # gilt auch für root

Auf Debian/Ubuntu vorher sudo apt install libpam-pwquality installieren.

/etc/security/faillock.conf

deny = 5             # Sperre nach fünf Fehlversuchen
fail_interval = 900  # gezählt innerhalb von 15 Minuten
unlock_time = 900    # Sperre gilt 15 Minuten
even_deny_root       # root wird ebenfalls gesperrt

Sperre eines Kontos aufheben: sudo faillock --user name --reset, Status ansehen: faillock --user name.

/etc/login.defs, relevante Zeilen

PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_WARN_AGE   14
ENCRYPT_METHOD  YESCRYPT     # oder SHA512 auf älteren Systemen
UMASK           027

Diese Werte gelten nur für neu angelegte Konten. Bestehende passt du mit sudo chage -M 90 -m 1 -W 14 name an.

Kontenhygiene

Dienstkonten bekommen /usr/sbin/nologin als ShellEin Konto, das nie interaktiv arbeitet, braucht keine Anmeldemöglichkeit. Das schließt einen ganzen Weg für Rechteausweitung.
Direkte Root-Anmeldung abschalten, Administration über sudoNur so lässt sich im Nachhinein feststellen, welche Person welchen Befehl ausgeführt hat. Ein gemeinsames Root-Passwort macht jede Nachvollziehbarkeit unmöglich.
sudo-Regeln so eng wie möglich fassenALL=(ALL) ALL ist bequem und hebt jede Trennung wieder auf. Bearbeitung immer mit visudo, sonst sperrst du dich bei einem Syntaxfehler komplett aus.
Automatische Abmeldung inaktiver SitzungenTMOUT=900 in /etc/profile.d/ beendet vergessene Sitzungen. Verhindert den Klassiker: offenes Terminal, unbeaufsichtigter Arbeitsplatz.
Verwaiste Konten regelmäßig prüfenZugänge ausgeschiedener Mitarbeitender sind ein Standardbefund in jedem Audit. Ein Kalendertermin pro Quartal genügt.

SSH absichern

SSH ist auf fast jedem Server der einzige Weg nach innen und entsprechend das erste Ziel automatisierter Angriffe. Die folgende Konfiguration erledigt den Großteil davon, ohne den Alltag zu behindern.

/etc/ssh/sshd_config.d/99-haertung.conf

# Anmeldung ausschließlich mit Schlüssel
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
PermitEmptyPasswords no

# Zugriff auf eine Gruppe begrenzen
AllowGroups ssh-nutzer

# Brute-Force-Versuche früh abschneiden
MaxAuthTries 3
MaxSessions 4
LoginGraceTime 30

# Verwaiste Sitzungen aufräumen
ClientAliveInterval 300
ClientAliveCountMax 2

# Nicht benötigte Weiterleitungen abschalten
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no

# Rechtlicher Hinweis vor der Anmeldung
Banner /etc/ssh/banner

Ein Drop-in unter sshd_config.d/ überlebt Paketaktualisierungen, anders als Änderungen direkt in der Hauptdatei. Voraussetzung ist die Zeile Include /etc/ssh/sshd_config.d/*.conf in der sshd_config, bei aktuellen Distributionen ist sie bereits vorhanden.

Sicher übernehmen

# Gruppe anlegen und dich selbst eintragen
sudo groupadd -f ssh-nutzer
sudo usermod -aG ssh-nutzer $USER

# Syntax prüfen, BEVOR neu geladen wird
sudo sshd -t

# Erst dann neu laden
sudo systemctl reload ssh      # Debian/Ubuntu
sudo systemctl reload sshd     # RHEL/Rocky/Alma

# In einem NEUEN Terminal gegenprüfen
ssh -v $USER@server

sshd -t ist die wichtigste Zeile im ganzen Kapitel. Sie fängt genau die Tippfehler ab, die dich sonst aussperren.

Bei den Schlüsseln ist ed25519 die richtige Wahl: kurz, schnell und nach heutigem Stand sicher. RSA ist nur noch nötig, wenn Altsysteme im Spiel sind, und dann mit mindestens 4096 Bit. Wichtig ist außerdem eine Passphrase auf dem privaten Schlüssel, sonst genügt der Diebstahl einer Datei vom Notebook für den Zugang zu deinen Servern.

Schlüssel erzeugen und ausrollen

ssh-keygen -t ed25519 -C "vorname.nachname@firma.de"
ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzer@server

# Rechte müssen stimmen, sonst verweigert sshd den Dienst
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Für mehrere Server lohnt sich ein zentraler Ansatz über SSH-Zertifikate oder eine Verzeichnisanbindung. Manuell verteilte authorized_keys sind ab etwa zwanzig Hosts nicht mehr zuverlässig zu pflegen.

Ein häufig gestellte Frage betrifft die Verschlüsselungsverfahren. Aktuelle OpenSSH-Versionen wählen bereits sinnvolle Voreinstellungen, eine eigene Liste von Chiffren und MACs schadet hier eher, weil sie mit der Zeit veraltet und dann schwächere Verfahren festschreibt als die Voreinstellung. Sinnvoll ist eine explizite Liste nur, wenn eine Prüfvorgabe sie ausdrücklich verlangt. Dann gehört ein Kalendereintrag dazu, sie jährlich zu überprüfen.

Zwei Faktoren für den Fernzugriff

Ein gestohlener privater Schlüssel ist ein vollständiger Zugang. Ein zweiter Faktor macht daraus einen halben. Für Server, die aus dem Internet erreichbar sind oder auf denen personenbezogene Daten liegen, ist das inzwischen der erwartete Stand.

Es gibt zwei praktikable Wege. Der erste ist ein Hardware-Token nach FIDO2, also ein YubiKey oder ein vergleichbarer Stick. OpenSSH unterstützt das seit Version 8.2 nativ über die Schlüsseltypen ed25519-sk und ecdsa-sk. Der private Schlüssel verlässt den Token nie, und ohne physischen Besitz plus Berührung des Sensors gibt es keine Anmeldung. Das ist die stärkere und zugleich bequemere Lösung.

FIDO2-Schlüssel für SSH

# Auf dem Arbeitsplatz erzeugen, Token muss gesteckt sein
ssh-keygen -t ed25519-sk -O resident -O verify-required \
  -C "yubikey-vorname"

# Auf den Server ausrollen wie einen normalen Schlüssel
ssh-copy-id -i ~/.ssh/id_ed25519_sk.pub benutzer@server

# Serverseitig erzwingen, dass eine Nutzerbestätigung erfolgt ist
# /etc/ssh/sshd_config.d/99-haertung.conf:
#   PubkeyAuthOptions verify-required

-O resident legt den Schlüssel auf dem Token ab, sodass du ihn auf einem neuen Rechner mit ssh-keygen -K zurückholen kannst. Ohne diese Option ist der Schlüssel an die Datei auf genau diesem Rechner gebunden.

Der zweite Weg ist ein zeitbasiertes Einmalpasswort über PAM, also die klassische Authenticator-App. Das funktioniert ohne zusätzliche Hardware, hat aber zwei Haken: Die Zeit auf dem Server muss stimmen, und du brauchst einen dokumentierten Notfallweg, wenn ein Telefon verloren geht.

TOTP als zweiter Faktor

sudo apt install libpam-google-authenticator   # Debian/Ubuntu
sudo dnf install google-authenticator          # RHEL/Rocky/Alma

# Je Benutzerkonto einmalig einrichten, QR-Code erscheint im Terminal
google-authenticator -t -d -f -r 3 -R 30 -W

# /etc/pam.d/sshd ergänzen:
#   auth required pam_google_authenticator.so nullok

# /etc/ssh/sshd_config.d/99-haertung.conf:
#   KbdInteractiveAuthentication yes
#   AuthenticationMethods publickey,keyboard-interactive

nullok lässt Konten ohne eingerichtetes TOTP weiterhin durch, damit du dich während der Einführung nicht aussperrst. Nach dem Rollout an alle Beteiligten gehört es entfernt.

Automatisierte Angriffe ausbremsen

Jeder Server mit öffentlicher Adresse sieht innerhalb von Minuten die ersten Anmeldeversuche. Mit Schlüsselanmeldung sind die aussichtslos, sie fluten aber deine Protokolle und binden Ressourcen. Zwei Werkzeuge schaffen Abhilfe.

Fail2ban ist der Klassiker: Es liest Logdateien, erkennt Muster wiederholter Fehlversuche und setzt für eine definierte Zeit eine Firewall-Regel gegen die Quelladresse. Es ist überall verfügbar, gut verstanden und arbeitet rein lokal.

/etc/fail2ban/jail.local

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
# Eigene Netze niemals aussperren
ignoreip = 127.0.0.1/8 ::1 10.0.10.0/24
banaction = nftables-multiport

[sshd]
enabled = true
mode    = aggressive

# Wiederholungstäter deutlich länger sperren
[recidive]
enabled  = true
bantime  = 1w
findtime = 1d
maxretry = 3

Status prüfen mit sudo fail2ban-client status sshd, eine Sperre aufheben mit sudo fail2ban-client set sshd unbanip 203.0.113.5.

CrowdSec geht einen Schritt weiter: Es wertet dieselben Logs aus, teilt Angreiferadressen aber anonymisiert mit einem gemeinsamen Netzwerk. Dadurch blockierst du auch Adressen, die bei dir noch nicht auffällig geworden sind. Das Projekt stammt aus Frankreich, die Verarbeitung findet in der EU statt, was die Abstimmung mit dem Datenschutz spürbar erleichtert.

Firewall: nur öffnen, was gebraucht wird

Die Grundregel ist einfach: alles verwerfen, was nicht ausdrücklich erlaubt ist. Welches Werkzeug du nutzt, hängt von der Distribution ab, das Prinzip bleibt identisch.

firewalld (RHEL, Rocky, AlmaLinux, SUSE)

# Zone ansehen
sudo firewall-cmd --get-active-zones

# Nur SSH und HTTPS erlauben
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=https

# SSH auf ein Verwaltungsnetz begrenzen
sudo firewall-cmd --permanent --new-zone=verwaltung
sudo firewall-cmd --permanent --zone=verwaltung --add-source=10.0.10.0/24
sudo firewall-cmd --permanent --zone=verwaltung --add-service=ssh
sudo firewall-cmd --permanent --zone=public --remove-service=ssh

sudo firewall-cmd --reload
sudo firewall-cmd --list-all-zones

Ohne --permanent überlebt keine Regel den nächsten Neustart, und --reload aktiviert die dauerhaften Regeln im laufenden Betrieb.

ufw (Debian, Ubuntu)

sudo ufw default deny incoming
sudo ufw default allow outgoing

# SSH nur aus dem Verwaltungsnetz
sudo ufw allow from 10.0.10.0/24 to any port 22 proto tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

ufw limit 22/tcp bremst wiederholte Verbindungsversuche zusätzlich aus, ist aber kein Ersatz für die Beschränkung auf ein Quellnetz.

Unterhalb beider Werkzeuge arbeitet heute nftables. Wer die Regeln direkt schreibt, gewinnt Übersicht und Geschwindigkeit, verliert aber die Bequemlichkeit der Dienstnamen. Für einzelne Server ist firewalld oder ufw die pragmatischere Wahl, für größere Umgebungen gehören die Regeln ohnehin in die Konfigurationsverwaltung und nicht auf die Kommandozeile.

Netzsegmentierung und Verwaltungszugang

Ein gehärteter Server in einem flachen Netz, in dem jedes Gerät jedes andere erreicht, ist nur so sicher wie der schwächste Drucker. Segmentierung begrenzt, wie weit ein Angreifer nach dem ersten erfolgreichen Schritt kommt.

Der wirksamste Einzelschritt ist ein eigenes Verwaltungsnetz. SSH, IPMI und Monitoring hören ausschließlich dort, erreichbar über einen Sprungserver oder ein VPN. Damit ist der Verwaltungszugang aus dem Anwendungsnetz heraus nicht mehr direkt ansprechbar, und ein übernommener Webserver bietet keinen Weg zu den anderen Systemen.

Dienste an eine Schnittstelle binden

# SSH nur im Verwaltungsnetz anbieten
# /etc/ssh/sshd_config.d/99-haertung.conf:
#   ListenAddress 10.0.10.21

# Datenbank nur lokal
# /etc/mysql/mariadb.conf.d/50-server.cnf:
#   bind-address = 127.0.0.1

# Gegenprobe: worauf lauscht der Dienst wirklich?
ss -tulpn | grep -E ':(22|3306|5432)'
# 0.0.0.0 bedeutet: auf allen Schnittstellen erreichbar

Ein Dienst, der nur auf 127.0.0.1 lauscht, ist von außen selbst dann nicht erreichbar, wenn die Firewall fehlerhaft konfiguriert wurde. Zwei Ebenen, die unabhängig voneinander wirken.

Dienste reduzieren

Jeder laufende Dienst ist Angriffsfläche. Ein Server, der Webseiten ausliefert, braucht keinen Mailserver, keinen Drucker-Daemon und keinen Bluetooth-Stack.

Aufräumen

# Was startet automatisch mit?
systemctl list-unit-files --state=enabled --type=service

# Typische Kandidaten auf Servern
sudo systemctl disable --now cups avahi-daemon bluetooth modemmanager

# Vollständig blockieren, damit nichts sie wieder aktiviert
sudo systemctl mask avahi-daemon

# Was zieht beim Booten Zeit und Fläche?
systemd-analyze blame | head -20

disable verhindert den Start, mask macht das Starten unmöglich, auch als Abhängigkeit eines anderen Dienstes.

Für Dienste, die bleiben müssen, bietet systemd eine oft übersehene Härtungsebene. Über Drop-ins kannst du einzelne Units einsperren, ohne Container einzuführen: eigener Verzeichnisbaum, keine neuen Rechte, kein Schreibzugriff auf das System.

/etc/systemd/system/meindienst.service.d/haertung.conf

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictSUIDSGID=true
RestrictNamespaces=true
MemoryDenyWriteExecute=true
SystemCallFilter=@system-service
ReadWritePaths=/var/lib/meindienst

Nach dem Anlegen sudo systemctl daemon-reload und den Dienst neu starten. Mit systemd-analyze security meindienst.service siehst du eine Bewertung und die verbleibenden Lücken.

Wenn Container im Spiel sind

Sobald Docker oder Podman auf dem Server laufen, verschiebt sich ein Teil der Angriffsfläche. Die Härtung des Wirtssystems bleibt nötig, reicht aber nicht mehr aus.

Die vier wirksamsten Maßnahmen

Rootless betreibenPodman kann Container vollständig ohne Root laufen lassen. Ein Ausbruch landet dann bei den Rechten eines unprivilegierten Kontos statt bei Root auf dem Wirtssystem. Bei Docker erfordert das den Rootless-Modus, der nicht die Voreinstellung ist.
Nicht als Root im Container laufenUSER app im Dockerfile oder --user beim Start. Viele offizielle Images laufen weiterhin als Root, was den ersten Schritt eines Angriffs deutlich vereinfacht.
Dateisystem schreibgeschützt einhängen--read-only plus ein tmpfs für Schreibpfade verhindert, dass nachgeladener Code überhaupt abgelegt werden kann.
Capabilities entziehen--cap-drop=ALL und nur das Nötige wieder hinzufügen. Die Voreinstellung ist deutlich großzügiger, als die meisten Anwendungen benötigen.

Abgesicherter Start und Image-Prüfung

podman run -d \
  --user 1000:1000 \
  --read-only --tmpfs /tmp \
  --cap-drop=ALL \
  --security-opt no-new-privileges \
  --memory 512m --pids-limit 200 \
  meinimage:1.4.2

# Images auf bekannte Lücken prüfen, bevor sie produktiv gehen
trivy image meinimage:1.4.2
grype meinimage:1.4.2

Feste Versionsangaben statt latest sind hier keine Stilfrage: Nur so weißt du, welcher Stand tatsächlich läuft, und nur so ist ein Scanergebnis reproduzierbar.

Dateirechte und SUID-Programme

Falsche Rechte sind der leiseste Fehler: Es funktioniert alles, nur eben auch für Personen, für die es nicht gedacht war. Besonders im Blick zu behalten sind Programme mit gesetztem SUID-Bit, weil sie mit den Rechten ihres Eigentümers laufen.

Prüfen und korrigieren

# Dateien, in die jeder schreiben darf
sudo find / -xdev -type f -perm -0002 -exec ls -l {} \; 2>/dev/null

# Verzeichnisse ohne Sticky-Bit, in die jeder schreiben darf
sudo find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null

# Dateien ohne Eigentümer (Hinweis auf gelöschte Konten)
sudo find / -xdev \( -nouser -o -nogroup \) 2>/dev/null

# Rechte der zentralen Dateien geradeziehen
sudo chmod 644 /etc/passwd /etc/group
sudo chmod 640 /etc/shadow /etc/gshadow
sudo chmod 600 /boot/grub/grub.cfg
sudo chmod 440 /etc/sudoers

Verzeichnisse, in die jeder schreiben darf, brauchen das Sticky-Bit (chmod +t), sonst kann jede Person die Dateien anderer löschen. /tmp ist das bekannteste Beispiel.

Bei SUID-Programmen lohnt sich eine Bestandsliste. Vieles davon ist berechtigt, etwa passwd oder sudo. Auffällig sind Programme, die dort nichts zu suchen haben, und genau die findest du nur, wenn du einmal eine Liste erstellt und mit der einer frischen Installation verglichen hast.

SUID-Bestand aufnehmen

# Aktuelle Liste erzeugen
sudo find / -xdev -type f -perm /6000 2>/dev/null | sort > /root/suid-$(date +%F).txt

# Später gegen den alten Stand vergleichen
diff /root/suid-2026-01-15.txt /root/suid-$(date +%F).txt

# Bei Paketen aus der Distribution: Rechte gegen die Datenbank prüfen
sudo rpm -Va | grep '^.M'          # RHEL/Rocky/Alma
sudo dpkg --verify                 # Debian/Ubuntu

Ein neu aufgetauchtes SUID-Programm, das zu keinem Paket gehört, ist ein ernstzunehmender Hinweis auf eine Kompromittierung.

Eine oft übersehene Ebene sind erweiterte Attribute. Mit chattr +i machst du eine Datei unveränderbar, selbst für Root. Für Dateien, die sich im Normalbetrieb nie ändern, etwa bestimmte Konfigurationen oder Schlüsselmaterial, ist das eine wirksame zusätzliche Hürde. Denk nur daran, das Attribut vor der nächsten geplanten Änderung wieder zu entfernen, sonst suchst du lange nach der Ursache eines fehlgeschlagenen Deployments.

SELinux und AppArmor

Klassische Unix-Rechte kennen nur Eigentümer, Gruppe und Rest. Mandatory Access Control ergänzt eine zweite Ebene: Selbst ein übernommener Dienst kommt nur an das heran, was seine Regel ausdrücklich erlaubt. Genau deshalb sind Abschalten und Ausschalten die falsche Reaktion auf eine Fehlermeldung.

SELinux (RHEL, Rocky, AlmaLinux)

# Zustand prüfen - Ziel ist Enforcing
sestatus

# Verweigerungen der letzten Zeit ansehen
sudo ausearch -m avc -ts recent
sudo sealert -a /var/log/audit/audit.log

# Der häufigste Fall: falscher Kontext nach dem Verschieben von Daten
sudo semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"
sudo restorecon -Rv /web

# Abweichender Port für einen Dienst
sudo semanage port -a -t http_port_t -p tcp 8080

setenforce 0 ist Diagnose, keine Lösung. Muss eine einzelne Anwendung wirklich ausgenommen werden, dann gezielt über semanage permissive -a domain_t statt für das ganze System.

AppArmor (Debian, Ubuntu, SUSE)

sudo aa-status

# Profil scharf schalten
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Bei Problemen zuerst beobachten statt blockieren
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
sudo grep DENIED /var/log/syslog

# Profil aus dem beobachteten Verhalten erweitern
sudo aa-logprof

Der Weg über aa-complain und aa-logprof ist der pragmatische: erst mitschneiden, was die Anwendung tatsächlich braucht, dann das Profil schärfen.

Updates automatisieren

Die überwiegende Mehrheit erfolgreicher Angriffe nutzt Lücken, für die längst ein Patch existiert. Automatische Sicherheitsaktualisierungen sind deshalb keine Bequemlichkeit, sondern die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung.

Debian und Ubuntu

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

# Testlauf ohne Änderungen
sudo unattended-upgrade --dry-run -d

In /etc/apt/apt.conf.d/50unattended-upgrades legst du fest, ob nur Sicherheitsaktualisierungen eingespielt werden und ob die Maschine bei Bedarf selbst neu startet.

RHEL, Rocky und AlmaLinux

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic.timer

# In /etc/dnf/automatic.conf:
#   upgrade_type = security
#   apply_updates = yes

systemctl list-timers dnf-automatic.timer

upgrade_type = security beschränkt die Automatik auf sicherheitsrelevante Pakete, was das Risiko unerwarteter Änderungen im Produktivbetrieb deutlich senkt.

Ein Neustart bleibt für Kernel-Aktualisierungen nötig. Wer sich den nicht leisten kann, kommt um Live-Patching nicht herum, entweder über kpatch beziehungsweise das Red-Hat-Angebot oder über Canonical Livepatch bei Ubuntu Pro. Beides ist kostenpflichtig und ersetzt geplante Wartungsfenster nicht dauerhaft.

Steht ein Neustart aus?

# Debian/Ubuntu
test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs

# RHEL/Rocky/Alma
sudo dnf needs-restarting -r

# Welche Prozesse laufen noch mit alten Bibliotheken?
sudo needs-restarting -s 2>/dev/null || sudo lsof +c0 | grep -i 'DEL.*lib'

Dienste, die nach einem Bibliotheks-Update weiterlaufen, nutzen die alte, verwundbare Version im Speicher. Ein Neustart des Dienstes genügt oft und spart den Neustart des Systems.

Zeitsynchronisation, die Forensik erst möglich macht

Ohne synchrone Uhren sind Protokolle mehrerer Systeme nicht korrelierbar. Nach einem Vorfall entscheidet genau das darüber, ob du den Ablauf rekonstruieren kannst oder im Nebel stocherst. Es ist die am häufigsten übersehene Maßnahme dieser Liste.

/etc/chrony/chrony.conf

# In Deutschland: die Atomuhren der PTB in Braunschweig
server ptbtime1.ptb.de iburst nts
server ptbtime2.ptb.de iburst nts
server ptbtime3.ptb.de iburst nts

# Fallback
pool de.pool.ntp.org iburst

# Abweichungen protokollieren
logdir /var/log/chrony
log tracking measurements statistics

# Große Sprünge nur beim Start erlauben
makestep 1.0 3

nts aktiviert Network Time Security, also authentifizierte Zeitsynchronisation. Die PTB unterstützt das, wodurch sich Zeitmanipulation durch einen Angreifer im Netzpfad ausschließen lässt.

Prüfen

chronyc tracking          # Abweichung und Quelle
chronyc sources -v        # Zustand aller Zeitserver
timedatectl               # Zeitzone und Synchronisationsstatus

# Muss 'System clock synchronized: yes' liefern

Eine Abweichung von mehr als einer Sekunde zwischen Servern macht die Auswertung zusammengehöriger Ereignisse in einem zentralen Log praktisch unmöglich.

auditd: nachvollziehbar protokollieren

Ohne Auditing weißt du nach einem Vorfall nicht, was passiert ist. Mit sinnvollen Regeln siehst du, wer Benutzerkonten geändert, sudo verwendet oder an der SSH-Konfiguration gedreht hat. Für NIS2 und ISO 27001 ist ein solcher Nachweis Pflicht, nicht Kür.

/etc/audit/rules.d/50-haertung.rules

# Änderungen an Konten und Rechten
-w /etc/passwd -p wa -k identitaet
-w /etc/shadow -p wa -k identitaet
-w /etc/group -p wa -k identitaet
-w /etc/sudoers -p wa -k rechte
-w /etc/sudoers.d/ -p wa -k rechte

# Zugriffskonfiguration
-w /etc/ssh/sshd_config -p wa -k ssh
-w /etc/pam.d/ -p wa -k pam

# Zeitmanipulation (verschleiert Spuren)
-a always,exit -F arch=b64 -S adjtimex,settimeofday -k zeit
-w /etc/localtime -p wa -k zeit

# Laden von Kernel-Modulen
-a always,exit -F arch=b64 -S init_module,delete_module -k module

# Fehlgeschlagene Zugriffe
-a always,exit -F arch=b64 -S open,openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k zugriff

# Regeln gegen Änderung schützen (immer als letzte Zeile)
-e 2

-e 2 friert das Regelwerk bis zum Neustart ein. Das ist gewollt: Wer eindringt, soll die Protokollierung nicht einfach abschalten können. Zum Bearbeiten der Regeln brauchst du danach einen Neustart.

Aktivieren und auswerten

sudo augenrules --load
sudo systemctl enable --now auditd

# Nach Schlüsselwort suchen
sudo ausearch -k identitaet -i
sudo ausearch -k rechte -ts today -i

# Zusammenfassungen
sudo aureport --auth --summary
sudo aureport --failed

Plane genug Platz auf /var/log/audit ein und begrenze in /etc/audit/auditd.conf über max_log_file und num_logs, sonst läuft die Partition voll.

Logs zentral sammeln

Protokolle, die nur lokal liegen, helfen dir im Ernstfall nicht: Wer Zugriff erlangt, räumt sie auf. Erst eine Kopie außerhalb des Systems macht Korrelation über mehrere Hosts möglich und ist gerichtsfest verwertbar.

journald dauerhaft speichern

# Ohne dieses Verzeichnis ist das Journal nach jedem Neustart leer
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

# In /etc/systemd/journald.conf:
#   Storage=persistent
#   SystemMaxUse=2G
#   MaxRetentionSec=90day

journalctl --disk-usage

Die Aufbewahrungsdauer richtet sich nach deinen Vorgaben. Für NIS2-Berichtspflichten und forensische Auswertung sind 90 Tage ein üblicher Ausgangswert, in regulierten Bereichen mehr.

Weiterleitung an einen zentralen Server (rsyslog)

# /etc/rsyslog.d/10-zentral.conf
# Verschlüsselt über TCP mit Warteschlange, damit nichts verloren geht

global(
  DefaultNetstreamDriver="gtls"
  DefaultNetstreamDriverCAFile="/etc/ssl/certs/ca.pem"
)

action(
  type="omfwd"
  target="log.intern.firma.de"
  port="6514"
  protocol="tcp"
  StreamDriver="gtls"
  StreamDriverMode="1"
  StreamDriverAuthMode="x509/name"
  queue.type="LinkedList"
  queue.filename="zentral-puffer"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1"
)

Die Warteschlange ist entscheidend: Ohne sie verlierst du sämtliche Meldungen, während der zentrale Server nicht erreichbar ist, also genau in der Situation, in der es interessant wird.

Wohin die Daten fließen, ist eine eigene Entscheidung. Verbreitet sind der Elastic-Stack, Graylog und Loki mit Grafana, im deutschen Behördenumfeld zunehmend auch Wazuh als quelloffene Alternative mit fertigen Regelsätzen. Wichtiger als das Produkt ist, dass jemand die Meldungen tatsächlich ansieht: Ein zentrales Log ohne Alarmierung ist ein Archiv, kein Schutz.

Backup ist eine Sicherheitsmaßnahme

Gegen Verschlüsselungstrojaner hilft keine Härtung zuverlässig, sondern nur eine Sicherung, an die der Angreifer nicht herankommt. Deshalb gehört das Backup in jede Härtungsdiskussion, auch wenn es organisatorisch oft woanders aufgehängt ist.

Was eine Sicherung gegen Erpressung leisten muss

Mindestens eine Kopie außerhalb der Reichweite des ServersEin Backup auf einer eingehängten Freigabe wird mitverschlüsselt. Pull-Verfahren, bei denen der Backup-Server sich die Daten holt, oder ein separates Konto ohne Löschrecht lösen das.
Unveränderbarkeit für einen definierten ZeitraumObjektspeicher mit Object Lock oder ein Bandarchiv verhindern das Löschen auch mit gültigen Zugangsdaten. Ohne diese Eigenschaft löscht ein Angreifer mit Administratorrechten einfach die Sicherungen mit.
Regelmäßige WiederherstellungstestsEine Sicherung, aus der noch nie zurückgespielt wurde, ist eine unbewiesene Annahme. Ein Test pro Quartal mit Protokoll ist das Minimum, und in Audits wird genau danach gefragt.
Verschlüsselung der SicherungsdatenSonst verlagerst du das Problem nur: Wer die Backups erbeutet, hat alle Daten, ohne je den Produktivserver anfassen zu müssen.

Beispiel mit restic und Object Lock

# Repository auf S3-kompatiblem Speicher mit aktiviertem Object Lock
export RESTIC_REPOSITORY="s3:https://s3.eu-central-1.example.com/backup-srv01"
export RESTIC_PASSWORD_FILE="/root/.restic-pass"

restic backup /etc /var/www /var/lib/mysql \
  --exclude-caches --tag taeglich

# Aufbewahrung steuern
restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

# Der entscheidende Schritt: Wiederherstellung testen
restic restore latest --target /tmp/restore-test --include /etc/ssh
diff -r /etc/ssh /tmp/restore-test/etc/ssh

Das Zugangskonto für die Sicherung braucht Schreib-, aber kein Löschrecht. So kann ein übernommener Server neue Sicherungen anlegen, aber keine alten vernichten.

Schwachstellen aktiv suchen: Greenbone und OpenSCAP

Härtung ist eine Momentaufnahme. Neue Lücken entstehen laufend, und ein System, das heute sauber ist, kann es nächste Woche nicht mehr sein. Regelmäßige Scans schließen diese Lücke, und im deutschsprachigen Raum führt daran kaum ein Weg vorbei.

OpenVAS ist der bekannteste quelloffene Schwachstellenscanner und heute Teil des Greenbone Vulnerability Management (GVM). Entwickelt wird er von der Greenbone AG in Osnabrück, die Community Edition ist frei verfügbar. Für Behörden und KRITIS-Betreiber in Deutschland ist das relevant, weil hier ein Scanner mit deutscher Herkunft und deutschsprachigem Support zur Verfügung steht, ohne Datenabfluss zu einem Cloud-Dienst im Ausland.

Greenbone Community Edition per Container

# Schnellster Weg zum Ausprobieren, offizielle Compose-Dateien
curl -f -L https://greenbone.github.io/docs/latest/_static/docker-compose-22.4.yml \
  -o docker-compose.yml
docker compose -f docker-compose.yml -p greenbone up -d

# Erstes Laden der Schwachstellen-Feeds dauert je nach Leitung 30 bis 60 Minuten
docker compose -p greenbone logs -f gvmd

# Oberfläche danach unter https://127.0.0.1:9392

Der erste Feed-Abgleich ist der Grund, warum viele Installationen als kaputt gelten: Vor dem vollständigen Import liefert ein Scan keine sinnvollen Ergebnisse. Geduld ist hier Teil der Installation.

Zur Einordnung der Werkzeuge: Lynis prüft ein System von innen gegen Härtungsempfehlungen und beantwortet die Frage, ob du sauber konfiguriert hast. Greenbone/OpenVAS scannt von außen gegen eine Schwachstellendatenbank und beantwortet, ob deine installierten Versionen bekannte Lücken haben. OpenSCAP prüft gegen einen formalen Katalog und beantwortet, ob du eine Vorgabe erfüllst. Die drei ersetzen einander nicht, sie beleuchten drei verschiedene Fragen.

Welches Werkzeug wofür

Werkzeug	Blickrichtung	Beantwortet	Takt
Lynis	von innen	Ist das System sauber konfiguriert?	nach jeder größeren Änderung
Greenbone / OpenVAS	von außen, mit Anmeldung	Gibt es bekannte Lücken in den installierten Versionen?	monatlich bis quartalsweise
OpenSCAP	von innen, gegen Katalog	Erfüllen wir CIS, STIG oder eine eigene Vorgabe?	vor Audits, danach quartalsweise
auditd + zentrales Log	laufend	Was ist tatsächlich passiert?	dauerhaft, mit Alarmierung

Scans, die sich lohnen

Authentifizierter Scan statt reinem NetzwerkscanMit Anmeldedaten sieht der Scanner installierte Paketstände und findet Lücken, die von außen unsichtbar sind. Der Unterschied im Ergebnis ist erheblich, oft Faktor fünf bei der Zahl der Befunde.
Regelmäßig statt einmaligEin Scan pro Quartal ist der Mindesttakt, monatlich ist besser. NIS2 verlangt ausdrücklich ein fortlaufendes Schwachstellenmanagement, kein einmaliges Projekt.
Ergebnisse priorisieren statt abarbeitenEine Liste mit 400 Befunden erschlägt jedes Team. Sortiere nach CVSS, Erreichbarkeit aus dem Netz und Vorhandensein eines öffentlichen Exploits, und arbeite die oberen zwanzig ab.
Ausnahmen dokumentierenManche Befunde bleiben bestehen, weil eine Anwendung es verlangt. Eine begründete und datierte Ausnahme ist im Audit akzeptabel, ein stillschweigend ignorierter Befund nicht.

Für die Prüfung gegen einen anerkannten Katalog ist OpenSCAP das passende Werkzeug. Es vergleicht dein System gegen maschinenlesbare Profile, etwa die CIS Benchmarks oder die STIG-Vorgaben, und erzeugt einen Bericht samt Korrekturvorschlägen.

OpenSCAP gegen ein CIS-Profil

sudo dnf install openscap-scanner scap-security-guide   # RHEL/Rocky/Alma
sudo apt install openscap-scanner ssg-debderived         # Debian/Ubuntu

# Verfügbare Profile anzeigen
oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Prüfen und Bericht erzeugen
sudo oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_cis \
  --results ergebnis.xml --report bericht.html \
  /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml

# Korrekturskript aus dem Ergebnis erzeugen (vorher lesen!)
sudo oscap xccdf generate fix --result-id "" --fix-type bash ergebnis.xml > fix.sh

Das erzeugte Korrekturskript niemals ungeprüft ausführen. Es setzt sämtliche Vorgaben des Profils um, auch die, die deine Anwendung braucht.

Sieben Fehler, die wir immer wieder sehen

Aus Schulungen und Projekten kennen wir die Muster, an denen Härtungsvorhaben scheitern. Fast keines davon ist ein technisches Problem.

Alles auf einmal ausrollenZwanzig Änderungen an einem Nachmittag, und am Montag läuft eine Fachanwendung nicht mehr. Niemand weiß, welche Maßnahme schuld ist, also wird alles zurückgedreht. Ergebnis nach einem Tag Arbeit: nichts. Besser sind kleine Schritte mit Test dazwischen.
Härtung nur auf dem neuen ServerDie frisch aufgesetzte Maschine wird vorbildlich abgesichert, die zwölf Altsysteme daneben bleiben, wie sie sind. Angreifer suchen sich das schwächste Glied, und das steht dann direkt nebenan im selben Netz.
SELinux oder AppArmor abschalten statt verstehenEin Dienst startet nicht, setenforce 0 löst es scheinbar, und so bleibt es. Damit fällt die Schicht weg, die einen übernommenen Prozess eingesperrt hätte. Der richtige Weg ist der Blick ins Audit-Log, der die fehlende Regel meist in Minuten zeigt.
Keine Dokumentation der AbweichungenEin Jahr später weiß niemand mehr, warum auf diesem Host noexec für /tmp fehlt. Also bleibt es aus Vorsicht so. Eine Zeile Begründung im Ticket oder in der Rolle hätte das verhindert.
Automatische Updates aus Angst vor AusfällenDie Sorge ist berechtigt, die Schlussfolgerung falsch. Ungepatchte Systeme sind die häufigste Einbruchsursache überhaupt. Der Ausweg sind Staging-Ringe und Wartungsfenster, nicht der Verzicht.
Backups im selben VertrauensbereichDie Sicherung liegt auf einer Freigabe, die der Server einhängen kann. Ein Verschlüsselungstrojaner nimmt sie in derselben Minute mit. Ohne Trennung oder Unveränderbarkeit ist es keine Sicherung, sondern eine zweite Kopie.
Niemand schaut in die ProtokolleAuditd läuft, Logs fließen zentral, und keine Person wertet sie aus. Ohne Alarmierung auf definierte Ereignisse ist das ein Archiv für die Aufarbeitung, kein Schutz während des Angriffs.

Nachweisen, dass es wirkt

Eine Maßnahme, die du nicht prüfen kannst, ist eine Behauptung. Zum Abschluss gehört deshalb ein Durchlauf, der belegt, dass die Einstellungen greifen, und zwar nach einem Neustart, nicht nur im laufenden System.

Abschlussprüfung

# 1. Neustart - alles muss auch danach gelten
sudo reboot

# 2. Mount-Optionen aktiv?
findmnt -no TARGET,OPTIONS /tmp /var/log /dev/shm

# 3. Kernel-Parameter gesetzt?
sysctl kernel.randomize_va_space net.ipv4.tcp_syncookies fs.protected_hardlinks

# 4. SSH: Passwortanmeldung muss scheitern
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no benutzer@server
# Erwartet: Permission denied

# 5. Firewall aktiv, nur erwartete Ports offen
sudo ss -tulpn | grep LISTEN

# 6. MAC im Enforcing-Modus
sestatus || sudo aa-status

# 7. auditd protokolliert
sudo auditctl -l | head

# 8. Zweiter Lynis-Lauf zum Vergleich
sudo lynis audit system

Punkt 1 ist der wichtigste. Der häufigste Härtungsfehler ist eine Einstellung, die im laufenden System greift, aber nirgends dauerhaft hinterlegt wurde.

Halte das Ergebnis schriftlich fest: Ausgangswert, umgesetzte Maßnahmen, bewusste Ausnahmen mit Begründung und das Datum. Diese Aufstellung brauchst du in jedem Audit, bei einem Vorfall gegenüber der Aufsichtsbehörde und beim nächsten Durchlauf, wenn du wissen willst, warum eine Einstellung damals so gewählt wurde.

Passende Kurse

Kurse zu Linux-Server-Härtung bei cmt

Diese Kurse vertiefen genau das, an echten Systemen statt nur an Folien. Als Präsenz oder Live-Online, auf Wunsch auch Inhouse für dein Team.

Linux Security Intensivkurs 3 Tage Präsenz nächster Termin 16.11.2026 Garantietermin Zum Kurs SELinux Training: Grundlagen und Administration (SEL1) 2 Tage Präsenz nächster Termin 07.09.2026 Zum Kurs Linux Netzwerk und Netzwerkdienste - Kompaktkurs 5 Tage Präsenz nächster Termin 21.09.2026 Zum Kurs SELinux Training: Konfiguration und Management (SEL2) 3 Tage Präsenz nächster Termin 02.09.2026 Zum Kurs Linux Systemadministration und Shell-Scripting - Kompaktkurs 5 Tage Präsenz nächster Termin 30.11.2026 Zum Kurs

Unverbindlich beraten lassen Alle IT-Security-Kurse ansehen

Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Wissenstest LPI Essentials Quiz Teste dein Wissen zu Linux-Grundlagen mit unserem LPI Essentials Quiz. Finde heraus, welche Schulungen zu dir passen. Quiz starten

Gut zu wissen

Häufige Fragen zu Linux-Server-Härtung

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt

In welcher Reihenfolge sollte ich einen Linux-Server härten?

Beginne beim Zugang, weil dort die automatisierten Angriffe ansetzen: SSH auf Schlüssel umstellen, Root-Login sperren, Zugang auf eine Gruppe begrenzen. Danach reduzierst du die Angriffsfläche über abgeschaltete Dienste und ein minimales Paket-Set, richtest Updates samt Reboot-Konzept ein, ordnest Benutzer und sudo, setzt den Firewall-Regelsatz auf default deny und sicherst zum Schluss Logging, Auditing und Mandatory Access Control ab.

Reicht fail2ban aus, um SSH abzusichern?

Nein. fail2ban sperrt auffällige Quell-IPs und macht die Logs lesbarer, es ändert aber nichts daran, dass ein Passwort erraten werden kann. Die eigentliche Absicherung ist die Umstellung auf Public-Key-Authentifizierung mit deaktiviertem PasswordAuthentication. fail2ban ist danach eine sinnvolle Ergänzung, kein Ersatz.

Soll ich SELinux abschalten, wenn eine Anwendung nicht startet?

Nein, das gibt eine wirksame Schutzschicht auf. Setze das System höchstens vorübergehend auf permissive, sammle die Denials mit ausearch, und löse sie über den passenden Weg: ein SELinux-Boolean, ein korrigierter Dateikontext per semanage fcontext und restorecon, oder ein eigenes Policy-Modul. In den cmt-Trainings SEL1 bis SEL3 gehen wir genau diesen Weg von der Analyse bis zum eigenen Modul durch.

Was unterscheidet nftables von iptables und lohnt der Wechsel?

nftables ersetzt die getrennten Werkzeuge iptables, ip6tables, arptables und ebtables durch eine einheitliche Syntax mit Sets, Maps und einer effizienteren Auswertung im Kernel. Aktuelle Distributionen liefern iptables ohnehin nur noch als Kompatibilitätsschicht über nftables aus. Für neue Systeme lohnt der direkte Einstieg in nftables, bestehende Regelsätze lassen sich mit iptables-translate weitgehend übernehmen.

Wie weise ich den erreichten Härtungsstand gegenüber einem Audit nach?

Beschreibe den Soll-Zustand maschinenlesbar und prüfe automatisiert dagegen. OpenSCAP mit einem Profil aus dem SCAP Security Guide liefert dir Reports pro Host, Konfigurationsmanagement mit Ansible sorgt dafür, dass der Zustand reproduzierbar bleibt, und zentrale Logs samt auditd belegen, wer wann was geändert hat.

Zuletzt geprüft am 26. Juli 2026.

Echte Stimmen aus unseren IT-Kursen

“

Es war eine sehr gute Lernatmosphäre und der Trainer verstand sein Thema sehr gut.

Rückmeldung aus dem Kurs „SELinux Training: Grundlagen und Administration (SEL1)“

“

Der Trainer konnte die Inhalte sehr gut vermitteln. Ich habe dabei viel gelernt.

Rückmeldung aus dem Kurs „Monitoring mit Prometheus und Grafana - Grundkurs“

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

0800 71 20000 E-Mail

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.