Linux Kernel Self-Protection & `sysctl`-Härtung: Speicher, Yama & Netzwerk

Erstellt: 10.11.2026 Aktualisiert: 10.11.2026

Management Summary: Der Linux-Kernel operiert im höchsten CPU-Privilegienring (Ring 0) und besitzt uneingeschränkten Zugriff auf den physischen Arbeitsspeicher, Hardware-Controller und alle ausgeführten Prozesse. Gelingt es einem Angreifer, eine Sicherheitslücke im Kernel auszunutzen, sind alle Sicherheitsgrenzen des User-Space (UIDs, Sandboxes, Container) schlagartig ausgehebelt. Das Kernel Self-Protection Project (KSPP) verfolgt daher das Paradigma, den Kernel strukturell gegen ganze Exploit-Klassen zu immunisieren. Dieser Leitfaden führt durch die kompromisslose Konfiguration von /etc/sysctl.d/: Vollständige Address Space Layout Randomization (ASLR), Speicher- und Ptrace-Isolation über das Yama LSM (ptrace_scope), Schutz vor Symlink- und FIFO-Races im Dateisystem, kryptografische TCP-SYN-Cookies und Spoofing-Schutz (rp_filter) sowie Kernel-Lockdown und Modul-Blacklisting.

ASLR & Speicherschutz

Zufällige Adressraum-Layouts (randomize_va_space = 2), Verhindern von Null-Pointer-Dereferenzierungen (mmap_min_addr) und Zeigerverbergung (kptr_restrict).
Yama LSM & ptrace-Isolation

Blockieren von Memory-Dumps fremder Prozesse (kernel.yama.ptrace_scope), Schutz sensibler Tokens in Daemons und restriktives Debugging.
Schutz vor Link- & FIFO-Angriffen

TOCTOU-Race-Conditions in weltbeschreibbaren Pfaden (/tmp) abwehren mit protected_symlinks, protected_hardlinks und protected_fifos.
Netzwerk-Stack-Härtung (L3/L4)

Abwehr von SYN-Floods (tcp_syncookies), RFC 1337 TIME-WAIT Assassination Schutz und Strict Reverse Path Filtering (rp_filter = 1).
ICMP- & Redirect-Schutz

Verwerfen bösartiger Layer-3-Umleitungen (accept_redirects = 0), Deaktivieren von Source-Routing und Blockieren unberechtigter IPv6-RAs.
Produktions-Drop-In /etc/sysctl.d/

Strukturiertes, atomar aktivierbares Konfigurations-Template (99-security-hardening.conf), Validierung und Container-Kompatibilität.

1. Das Kernel Self-Protection Project (KSPP) & Speicherschutz

Früher reagierte die Open-Source-Community rein reaktiv auf Kernel-Lücken: Ein Bug wurde gemeldet, ein Patch geschrieben. Das Kernel Self-Protection Project (KSPP) bricht mit diesem Ansatz: Der Kernel wird so modifiziert und konfiguriert, dass Exploits selbst dann ins Leere laufen, wenn eine unbekannte Lücke (Zero-Day) im Code existiert.

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    Attacker["Angreifer / Exploit-Payload"] ==> MemCheck{"Prüfung des Adressraums"}
    MemCheck -->|"ASLR = 2 aktiv"| Random["Zufällige Adressen<br/>(Stack / Heap / Libs)"]
    Random --> ExploitFail["Exploit stürzt ab<br/>(SIGSEGV / Kein Jump-Target)"]
    MemCheck -->|"mmap_min_addr >= 64k"| NullTrap["Null-Page gesperrt<br/>(Null-Pointer-Deref unmöglich)"]
    NullTrap --> KernelSafe["Kernel fängt Fehler ab"]

Die drei zentralen Speicher-Schutzparameter

# /etc/sysctl.d/50-security-memory.conf

# 1. Vollständige Address Space Layout Randomization (ASLR)
# 2 = Randomisiert Stack, VDSO-Page, Shared Memory, BSS und den Data-Heap (mmap)
kernel.randomize_va_space = 2

# 2. Null-Pointer-Dereferenzierung unmöglich machen
# Verbietet unprivilegierten Prozessen das Mappen von Adressen unterhalb von 64 KB (0x10000)
vm.mmap_min_addr = 65536

# 3. Kernel-Speicheradressen vor normalen Benutzern verbergen
# Verhindert das Auslesen von Kernel-Adressen via /proc/kallsyms und dmesg
kernel.kptr_restrict = 2

# 4. Zugriff auf dmesg-Puffer nur für Administratoren (CAP_SYSLOG)
kernel.dmesg_restrict = 1

2. Prozess-Isolation & Yama LSM (`ptrace`-Härtung)

Der Systemaufruf ptrace() erlaubt es einem Prozess, die Ausführung eines anderen Prozesses zu überwachen, zu stoppen und dessen gesamten Arbeitsspeicher auszulesen oder zu manipulieren. Debugger wie gdb oder strace nutzen diese Schnittstelle legitim.

Für Angreifer ist unbeschränktes ptrace() das Paradies: Läuft ein Prozess unter derselben Benutzer-ID wie der Webserver oder Entwickler, kann er via ptrace() die Keys aus dem SSH-Agenten, Tokens aus Umgebungsvariablen oder Datenbankpasswörter im RAM abgreifen.

Die 4 Modi von `kernel.yama.ptrace_scope`

Das Yama Linux Security Module (LSM) regelt die Zugriffsrechte auf ptrace:

Modus	Wert	Verhalten	Enterprise-Bewertung
Klassisch	`0`	Jeder Prozess darf alle Prozesse desselben Benutzers tracen.	Gefährlich: Für Server inakzeptabel.
Eingeschränkt	`1`	Nur direkte Elternprozesse dürfen Kinder tracen (`gdb ./programm`).	Desktop-Standard (Ubuntu/Debian).
Admin-Only	`2`	Nur Prozesse mit `CAP_SYS_PTRACE` (Root / Sudo) dürfen ptrace nutzen.	Empfohlen für Server.
Permanent gesperrt	`3`	Kein Prozess darf mehr ptrace ausführen. Kann erst durch Reboot geändert werden.	Hochsicherheit: Debugging unmöglich.

Konfiguration in /etc/sysctl.d/50-security-yama.conf:

# /etc/sysctl.d/50-security-yama.conf
# Erlaube ptrace nur Administratoren mit CAP_SYS_PTRACE
kernel.yama.ptrace_scope = 2

3. Dateisystem-Schutz gegen Symlink-, Hardlink- & FIFO-Angriffe

In weltweit beschreibbaren Verzeichnissen mit Sticky-Bit (wie /tmp oder /var/tmp) können Angreifer bösartige Links anlegen. Wenn ein privilegierter Prozess oder Cronjob unbedarft temporäre Dateien öffnet, kann der Angreifer über Time-of-Check to Time-of-Use (TOCTOU) Race-Conditions Systemdateien überschreiben.

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    Attacker["Angreifer erstellt Link<br/>(/tmp/app.log -> /etc/shadow)"] ==> PrivService["Privilegierter Dienst / Root<br/>Öffnet /tmp/app.log"]
    PrivService --> FS_Check{"Kernel-Prüfung<br/>protected_symlinks"}
    FS_Check -->|"Aktiv (1)"| Block["Zugriff blockiert (EACCES)<br/>Besitzer stimmt nicht überein"]
    FS_Check -->|"Inaktiv (0)"| Danger["/etc/shadow überschrieben<br/>Vollständige Kompromittierung"]

Die vier defensiven Dateisystem-Parameter

# /etc/sysctl.d/50-security-fs.conf

# 1. Symlinks in sticky world-writable Dirs nur dereferenzieren, wenn der
# Ersteller des Symlinks mit dem Besitzer des Ziels oder des Ordners übereinstimmt
fs.protected_symlinks = 1

# 2. Hardlinks dürfen nur auf Dateien erstellt werden, die dem Benutzer selbst gehören
# oder für die er Lese- und Schreibrechte besitzt (verhindert Hardlinks auf /etc/shadow)
fs.protected_hardlinks = 1

# 3. Named Pipes (FIFOs) in weltbeschreibbaren Pfaden nur öffnen, wenn Besitzer übereinstimmt
# 2 = Verhindert unberechtigtes Schreiben in fremde Pipes (Schutz vor Hijacking)
fs.protected_fifos = 2

# 4. Reguläre Dateien in weltbeschreibbaren Pfaden nur öffnen, wenn Besitzer übereinstimmt
# 2 = Verhindert das Unterschieben manipulierter Konfigurationsdateien
fs.protected_regular = 2

4. Kernel-Netzwerk-Stack-Härtung (Layer-3 & Layer-4)

Viele Netzwerkangriffe zielen auf Ressourcen-Erschöpfung im Kernel-Netzwerk-Stack ab, noch bevor Pakete die Anwendungsschicht erreichen.

1. TCP SYN-Flood-Schutz (`tcp_syncookies`)

Bei einem SYN-Flood sendet der Angreifer tausende gefälschte TCP-Verbindungsanfragen, antwortet aber nie auf das SYN-ACK. Der Kernel reserviert Speicher im Verbindungs-Backlog, bis kein legitimer Besucher mehr verbinden kann.

Mit aktivierten SYN-Cookies speichert der Kernel bei vollem Backlog keinen Zustand mehr im RAM, sondern verschlüsselt die Verbindungsparameter kryptografisch in der Sequence-Nummer des SYN-ACK-Pakets:

# /etc/sysctl.d/50-security-network.conf
# Kryptografische SYN-Cookies bei drohender Backlog-Erschöpfung aktivieren
net.ipv4.tcp_syncookies = 1

# RFC 1337: Schutz vor TIME-WAIT Assassination (verhindert Reset-Injection)
net.ipv4.tcp_rfc1337 = 1

2. IP-Spoofing-Abwehr mit Strict Reverse Path Filtering (`rp_filter`)

Wenn ein Paket an einem Interface eintrifft, prüft der Kernel mit Reverse Path Filtering, ob die Quell-IP über dasselbe Interface auch für die Rückroute genutzt werden würde. Ist dies nicht der Fall, handelt es sich um ein gefälschtes (gespooftes) Paket, das sofort verworfen wird:

# /etc/sysctl.d/50-security-network.conf
# Strict Reverse Path Filtering auf allen Interfaces erzwingen (1 = Strict Mode)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

3. Layer-3 Man-in-the-Middle durch ICMP-Redirects unterbinden

Böswillige Router oder kompromittierte Nachbar-Hosts im Rechenzentrum können ICMP-Redirect-Pakete senden, um den Netzwerkverkehr des Servers über ihre eigene IP umzuleiten:

# /etc/sysctl.d/50-security-network.conf
# Niemals fremde Routing-Umleitungen akzeptieren
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# Niemals eigene Redirects versenden (Server ist kein Router)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Source-Routed-Pakete strikt verwerfen (Angreifer darf Route nicht im Header vorgeben)
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

# IPv6 Router Advertisements auf Servern ignorieren (nur statische IPs oder DHCPv6)
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0

5. Kernel-Lockdown & Blacklisting von Legacy-Modulen

Moderne Linux-Kernel bieten das Lockdown LSM, um selbst root daran zu hindern, den laufenden Kernel-Speicher zu modifizieren.

Modul-Blacklisting für obsolete Protokolle

Der Linux-Kernel enthält Treiber für exotische Netzwerkprotokolle aus den 1990er-Jahren. Da diese selten genutzt werden, verbergen sich darin häufig unentdeckte Sicherheitslücken.

Erstelle /etc/modprobe.d/blacklist-rare-network.conf:

# /etc/modprobe.d/blacklist-rare-network.conf
# Deaktiviere obskure und fehleranfällige Transport- und Tunnelprotokolle
install dccp /bin/true
install sctp /bin/true
install rds /bin/true
install tipc /bin/true
install firewire-core /bin/true
install thunderbolt /bin/true

6. Produktions-Drop-In `/etc/sysctl.d/99-security-hardening.conf`

Hier ist die vollständige, schlüsselfertige Konfigurationsdatei für Enterprise-Linux-Server (Debian, Ubuntu, Fedora):

# /etc/sysctl.d/99-security-hardening.conf
# ==============================================================================
# Enterprise Linux Kernel Hardening & Self-Protection Baseline
# ==============================================================================

# --- 1. SPEICHERSCHUTZ & EXPLOIT-MITIGATION ---
kernel.randomize_va_space = 2
vm.mmap_min_addr = 65536
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1
kernel.kexec_load_disabled = 1
kernel.sysrq = 0

# --- 2. PROZESS-ISOLATION & YAMA LSM ---
kernel.yama.ptrace_scope = 2

# --- 3. DATEISYSTEM-SCHUTZ ---
fs.protected_symlinks = 1
fs.protected_hardlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
fs.suid_dumpable = 0

# --- 4. NETZWERK-SCHUTZ (LAYER 3 & 4) ---
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_rfc1337 = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0

# Schutz vor TCP TIME-WAIT Erschöpfung
net.ipv4.tcp_fin_timeout = 15

# ICMP-Smurf- und Broadcast-Schutz
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1

Konfiguration ohne Neustart atomar laden

# Lade alle sysctl-Drop-Ins atomar in den laufenden Kernel
sudo sysctl --system

7. Troubleshooting & Fallstricke

Achtung bei Container-Hosts (Docker / Podman)

Wenn auf dem Server Container betrieben werden, benötigt die Bridge-Netzwerkarchitektur IP-Forwarding. Setze in diesem Fall zusätzlich:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Ohne diese Direktive können Container keine ausgehenden Netzwerkverbindungen aufbauen!

Parameter	Typische Fehlerursache	Fehlerbehebung
`kernel.yama.ptrace_scope = 2`	Entwickler können `strace` oder `gdb` nicht mehr unprivilegiert nutzen.	Mit `sudo strace` starten oder User in Debugger-Gruppe mit `CAP_SYS_PTRACE` aufnehmen.
`fs.protected_symlinks = 1`	Ältere Skripte scheitern beim Lesen von `/tmp`-Symlinks fremder Benutzer.	Pfadstruktur der Anwendung auf benutzereigene Verzeichnisse (`/run/user/$UID`) umstellen.
`net.ipv4.conf.all.rp_filter = 1`	Asymmetrisches Routing (z. B. Multi-Homing mit 2 ISPs) verwirft Antwortpakete.	Auf asymmetrischen Schnittstellen auf Loose Mode (`rp_filter = 2`) lockern.

Mit diesem Kernel-Schutzschild prallen Low-Level-Exploits, In-Memory-Attacken und Netzwerk-Spoofing-Versuche direkt an der innersten Bastion des Linux-Betriebssystems ab.

Linux Kernel Self-Protection & sysctl-Härtung: Speicher, Yama & Netzwerk