Linux-Härtung 2026: Der Threat-Model-First-Leitfaden

Die meisten Leitfäden zur Linux-Härtung sind Checklisten. Sie sagen Ihnen, welche sysctl-Flags zu setzen, welche Dienste zu deaktivieren, welche Kernel-Module auf die Blacklist zu setzen sind. Sie beantworten selten die vorgelagerte Frage: Gegen welche Bedrohung verteidigen Sie sich eigentlich?

Die Antwort verändert die Arbeit. Ein Journalist, der Quellen vor gezielter Schadsoftware schützt, braucht ganz andere Maßnahmen als ein Sysadmin, der die Angriffsfläche auf einem Server ohne physische Bedrohungen reduziert. Dieser Leitfaden arbeitet vom Bedrohungsmodell zur Maßnahme, nicht von der Maßnahme zur Rechtfertigung.

Er ist in der Sicherheitstradition dieser Domain verwurzelt — dasselbe operative Denken, das die Secure-Desktops-Mailingliste (2015–2017) antrieb, auf der Entwickler von Qubes OS, Tails und Subgraph praktische Härtung ohne das Marketing diskutierten.

Schritt null: Definieren Sie Ihr Bedrohungsmodell

Bevor Sie auch nur eine einzige Konfigurationsdatei anrühren, beantworten Sie diese vier Fragen:

1. Wer ist der Angreifer? Gelegenheitstäter, organisierter Krimineller, Unternehmensermittler, Nationalstaat?
2. Worauf haben sie es abgesehen? Dateien auf der Festplatte, Kommunikation, Zugangsdaten, Ihre Identität, Ihre Kontakte?
3. Wie kommen sie hinein? Netzwerk-Exploit, physischer Zugriff, Lieferkette, Social Engineering?
4. Welche Ressourcen haben sie? Zeit, Geld, Zero-Days, gesetzliche Befugnis?

Die Maßnahmen in diesem Leitfaden sind nach der Bedrohung gruppiert, die sie adressieren. Wenden Sie nur die Schichten an, die zu Ihren Antworten passen. Eine Workstation überzuhärten erzeugt Reibung ohne entsprechenden Sicherheitsgewinn, und Reibung führt dazu, dass Menschen Kontrollen umgehen.

Kernel-Härtung: sysctl-Parameter

Die folgenden Parameter sind für die meisten gehärteten Desktop- und Server-Installationen geeignet. Sie erfordern keine spezialisierte Hardware und haben keine nennenswerte Auswirkung auf die Leistung.

# /etc/sysctl.d/99-hardening.conf

# Restrict kernel pointers from userspace (defeats certain info-leak attacks)
kernel.kptr_restrict=2

# Restrict dmesg access to root (prevents attackers reading kernel memory addresses)
kernel.dmesg_restrict=1

# Disable SysRq key (prevents certain physical-access attacks)
kernel.sysrq=0

# Restrict ptrace to processes with CAP_SYS_PTRACE (limits debug attach)
kernel.yama.ptrace_scope=2

# Disable unprivileged user namespaces (large attack surface, rarely needed on desktops)
kernel.unprivileged_userns_clone=0

# Disable unprivileged eBPF (significant attack surface for CVE exploitation)
kernel.unprivileged_bpf_disabled=1

# Enable TCP SYN cookies (basic DoS resistance)
net.ipv4.tcp_syncookies=1

# Disable ICMP redirects (routing manipulation attacks)
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.default.accept_redirects=0
net.ipv6.conf.all.accept_redirects=0

# Disable source routing (rarely legitimate, used in spoofing attacks)
net.ipv4.conf.all.accept_source_route=0

# Enable reverse path filtering (defeats IP spoofing)
net.ipv4.conf.all.rp_filter=1

# Disable core dumps (prevents memory exposure of crashed processes)
fs.suid_dumpable=0

# Restrict symlink and hardlink following (prevents certain privilege escalation attacks)
fs.protected_symlinks=1
fs.protected_hardlinks=1

Sofort ohne Neustart anwenden:

sudo sysctl -p /etc/sysctl.d/99-hardening.conf

Wovor diese nicht schützen: Dies sind Tunables auf Kernel-Ebene, keine Abwehrmaßnahmen auf Anwendungsschicht. Ein Browser-Exploit, der weder ptrace, User-Namespaces noch eBPF benötigt, ist von den betreffenden Parametern unberührt. Sie sind eine unterstützende Schicht, kein Ersatz für Anwendungsisolierung (siehe Qubes OS, falls Isolierung Ihre primäre Anforderung ist).

Mandatory Access Control: AppArmor vs. SELinux

Sowohl AppArmor als auch SELinux implementieren Mandatory Access Control (MAC): eine Richtlinienschicht, die einschränkt, was Prozesse tun können, unabhängig von Dateiberechtigungen. MAC erzwingt das Prinzip der geringsten Rechte auf Kernel-Ebene.

AppArmor (Standard bei Ubuntu, Debian, SUSE)

AppArmor verwendet pfadbasierte Profile. Jede Anwendung erhält ein Profil, das festlegt, welche Dateien sie lesen, schreiben oder ausführen darf, welche Capabilities sie nutzen darf und welche Netzwerkoperationen erlaubt sind. Profile arbeiten in zwei Modi: enforce (Verstöße werden blockiert und protokolliert) und complain (Verstöße werden protokolliert, aber erlaubt — nützlich während der Entwicklung).

# Check AppArmor status
sudo apparmor_status

# List all loaded profiles
sudo aa-status

# Put a profile into enforce mode
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

# Generate a new profile for an application
sudo aa-genprof /usr/bin/myapp

Die Repositories von Ubuntu und Debian enthalten vorgefertigte Profile für gängige Anwendungen. Installieren Sie sie:

sudo apt install apparmor-profiles apparmor-profiles-extra

Praktische Empfehlung: Stellen Sie auf einem Ubuntu- oder Debian-System sicher, dass AppArmor beim Booten aktiviert ist (überprüfen mit sudo apparmor_status | grep "profiles are in enforce mode") und dass Firefox, Chromium und alle Server-Prozesse (nginx, sshd, cups) mit Profilen im enforce-Modus laufen.

SELinux (Standard bei Fedora, RHEL, CentOS)

SELinux verwendet label-basierte Richtlinien. Jeder Prozess, jede Datei, jeder Socket und jeder Benutzer erhält einen Sicherheitskontext (ein Label), und Richtlinienregeln definieren, welche Kontexte interagieren dürfen. Dies ist feingranularer als AppArmor, aber deutlich komplexer zu pflegen.

Unter Fedora ist SELinux standardmäßig im Enforcing-Modus aktiviert. Überprüfen:

getenforce
# Should output: Enforcing

Deaktivieren Sie SELinux nicht. Eine gängige und falsche Reaktion auf SELinux-Verweigerungen ist setenforce 0. Diagnostizieren Sie stattdessen die Verweigerung:

sudo ausearch -m avc -ts recent | audit2allow -a

Das Werkzeug audit2allow schlägt Richtlinienmodule vor, die die verweigerte Aktion erlauben würden. Prüfen Sie sie, bevor Sie sie anwenden — das Ziel ist zu verstehen, warum die Verweigerung auftrat, nicht sie pauschal zu erlauben.

Kernel-Boot-Parameter

Boot-Parameter (gesetzt in der GRUB-Konfiguration) greifen früher im Boot-Prozess als sysctl und adressieren andere Angriffsflächen.

Fügen Sie sie zu GRUB_CMDLINE_LINUX in /etc/default/grub hinzu und führen Sie dann sudo update-grub aus:

# Disable SMT if you have a high-threat CPU side-channel model (Spectre, MDS)
# Performance cost: significant (up to 30–50% on multi-threaded workloads)
# Only appropriate for threat models involving local co-tenancy or targeted CPU attacks
# mitigations=auto,nosmt

# Enable all CPU vulnerability mitigations (default on most distros, worth verifying)
mitigations=auto

# Randomize page allocation (increases difficulty of certain heap exploitation)
page_alloc.shuffle=1

# Enable kernel lockdown (Integrity or Confidentiality mode)
# Locks down several features used by rootkits; may break some functionality
lockdown=integrity

# Disable old IPv4 network protocols rarely used (reduce attack surface)
ipv6.disable=0   # Keep IPv6 enabled; disable if genuinely unused

# Disable Firewire DMA (physical access attack vector on older hardware)
module.sig_enforce=1

Hinweis zu lockdown=confidentiality: Dieser Modus verhindert, dass selbst root den Kernel-Speicher über /dev/mem und ähnliche Schnittstellen lesen kann. Er bricht einige legitime Anwendungen (bestimmte Treiber, kexec, Hibernation). Verwenden Sie den integrity-Modus, sofern Sie keinen bestimmten Grund für confidentiality haben.

Härtung von Dateisystem und Diensten

Mount-Optionen

Fügen Sie in /etc/fstab wo angebracht Sicherheits-Mount-Optionen hinzu:

# /tmp: no execution, no device files, no SUID bits
tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /var/tmp: same
tmpfs /var/tmp tmpfs defaults,noexec,nodev,nosuid 0 0

# /home: no device files, no SUID (noexec breaks some workflows — test first)
/dev/mapper/home /home ext4 defaults,nodev,nosuid 0 2

Nicht genutzte Dienste deaktivieren

Jeder laufende Dienst ist eine Angriffsfläche. Auf einem Desktop:

# List enabled services
systemctl list-unit-files --state=enabled

# Common candidates for disabling on a desktop with no network service requirements:
sudo systemctl disable cups   # Printing — if you never print
sudo systemctl disable avahi-daemon  # mDNS — if you don't need .local resolution
sudo systemctl disable bluetooth  # If not using Bluetooth

Auf einem Server ist das Prinzip aggressiver: Nur Dienste, die für die erklärte Funktion der Maschine erforderlich sind, sollten laufen. Jeder lauschende Socket sollte einen dokumentierten Existenzgrund haben.

Verified Boot und Secure Boot

Secure Boot mit Ihren eigenen hinterlegten Schlüsseln (nicht nur den standardmäßigen Microsoft-Schlüsseln) schützt vor Bootkits, die vor dem Betriebssystem laden. Unter Fedora und Ubuntu signieren die Distributionen ihren Bootloader und Kernel mit Schlüsseln, denen die UEFI-Firmware standardmäßig vertraut.

Für eine Einrichtung mit höherer Sicherheitsgewähr ersetzen Sie die Standardschlüssel durch Ihre eigenen:

1. Erzeugen Sie Ihren eigenen Platform Key (PK) und Key Exchange Key (KEK).
2. Hinterlegen Sie Ihren Schlüssel in der UEFI-Firmware (der Vorgang variiert je nach Hersteller).
3. Signieren Sie Ihren Bootloader und Ihre Kernel mit Ihrem Schlüssel mittels sbsign.
4. Deaktivieren Sie „Other OS” oder „Compatibility Support Module” in der UEFI-Firmware.

Dies ist operativ komplex und im Allgemeinen nur für Hochrisiko-Einsätze angebracht. Das Heads-Firmware-Projekt und ähnliche Projekte gehen darüber hinaus und erweitern Measured Boot zu einer TPM-gestützten Vertrauenskette.

Checkliste nach Bedrohungsmodell

Gelegenheitstäter / Massen-Schadsoftware: sysctl-Standardwerte von oben, AppArmor/SELinux im Enforcing-Modus, verschlüsselte Festplatte (LUKS), regelmäßige Updates. Das deckt 95 % der gewöhnlichen Bedrohungen ab.

Gezielter Angreifer mit Netzwerkzugriff: Dienstminimierung hinzufügen, restriktive Firewall (nftables/ufw), Anwendungs-Sandboxing (Firejail oder Flatpak), Überwachung des ausgehenden Netzwerkverkehrs.

Angreifer mit physischem Zugriff und Ressourcen: Vollverschlüsselung der Festplatte mit starker Passphrase + Header-Backup, Secure Boot mit eigenen Schlüsseln, Tails OS für sensible Operationen, Qubes OS zur Kompartimentierung erwägen. Lesen Sie die Secure-Desktops-Charta für die operativen Prinzipien hinter diesen Entscheidungen.

Staatsebene / Nationalstaat: Erwägen Sie, ob eine gehärtete Linux-Workstation überhaupt das richtige Werkzeug ist. Qubes OS mit einer sorgfältigen Qubes-Architektur kommt dem angemessenen Instrument näher. Air-Gapped-Maschinen für die sensibelsten Operationen. Kein Single Point of Failure für Schlüsselmaterial.

FAQ

F: Bricht das Deaktivieren unprivilegierter User-Namespaces irgendetwas? A: Es bricht Anwendungen, die ohne root darauf angewiesen sind — insbesondere das Chromium-Sandboxing auf Systemen, die es verwenden, und bestimmte Container-Runtimes (rootless Docker/Podman). Auf Desktop-Ubuntu/-Debian müssen Sie es für Chromium wahrscheinlich wieder aktivieren. Der Kompromiss ist dokumentiert; entscheiden Sie auf Basis Ihres Bedrohungsmodells.

F: Sollte ich einen gehärteten Kernel (linux-hardened auf Arch oder grsecurity) verwenden? A: linux-hardened in Arch Linux wendet einen sinnvollen Satz von Upstream-Härtungspatches an und ist die Verwendung wert, wenn Sie auf Arch sind. Grsecurity-Patches sind nicht mehr öffentlich verfügbar. Der Upstream-Kernel hat seit Ende der 2010er-Jahre viele zuvor grsecurity-exklusive Funktionen aufgenommen (KASLR, Stack Protector, FORTIFY_SOURCE usw.).

F: Ist Fedora oder Ubuntu von Haus aus stärker gehärtet? A: Beide werden mit MAC im Enforcing-Modus ausgeliefert (SELinux bei Fedora, AppArmor bei Ubuntu), modernen Kernel-Mitigation-Standardwerten und automatischen Sicherheitsupdates. Fedora liefert im Allgemeinen neuere Kernel-Versionen schneller. Ubuntu LTS tauscht das Allerneueste gegen langfristigen Support. Für eine gehärtete Workstation ist beides ein sinnvoller Ausgangspunkt; die Maßnahmen in diesem Leitfaden gelten für beide.