Zum Inhalt

Linux Host-Baseline & Benutzer-Härtung: Mount-Flags, PAM & Sudoers

Erstellt: 10.11.2026 Aktualisiert: 10.11.2026

Management Summary: Während Netzwerk-Firewalls und Intrusion-Detection-Systeme den äußeren Perimeter absichern, entscheidet die Host-Baseline darüber, ob ein Angreifer nach dem ersten erfolgreichen Exploit im Sandkasten verhungert oder das gesamte System übernimmt. Standard-Linux-Installationen liefern unmaskierte temporäre Verzeichnisse, permissive Passwort-Richtlinien und dutzende überprivilegierte SUID-Binaries aus. Dieser Leitfaden etabliert eine kompromisslose Baseline für Unternehmens-Server: Dateisystem-Härtung über restriktive Mount-Flags (nodev, nosuid, noexec), robuste Authentifizierungsstacks via Pluggable Authentication Modules (PAM) mit pam_faillock, pam_pwquality und modernem yescrypt-Hashing, strikte sudoers-Governance ohne GTFOBins-Ausbruchsvektoren, systematische SUID/SGID-Sanierung sowie Shared-Memory- und Core-Dump-Isolation.

  • Dateisystem- & Mount-Härtung

    Enterprise-Partitionierung und restriktive Mount-Optionen (noexec, nosuid, nodev) auf /tmp, /var/tmp und /dev/shm gegen Payload-Ausführungen.

  • PAM-Tiefenarchitektur

    Der 4-Säulen-Stack (auth, account, password, session), Kontroll-Flags und deterministische Regelabfolgen im Linux-Authentifizierungssubsystem.

  • Brute-Force-Schutz (pam_faillock)

    Automatisierte Kontensperrung nach Fehlversuchen, temporäre Quarantäne, Status-Inspektion und manueller Reset via faillock-CLI.

  • Passwort-Qualität & yescrypt

    Erzwingung starker Passwörter mit pam_pwquality und Migration auf speicher-hartes Passwort-Hashing mit yescrypt in /etc/login.defs.

  • User-Governance & Root-Lock

    Deaktivierung ungenutzter System-Shells (/usr/sbin/nologin), Sperren des interaktiven Root-Passworts und automatische Session-Timeouts (TMOUT).

  • Sudoers-Härtung & Least Privilege

    Sichere sudoers.d-Regeln, PTY-Erzwingung (use_pty), Session-Timeouts und Schutz vor Privilege Escalation über Binaries (GTFOBins).

1. Dateisystem-Härtung & Sichere Mount-Optionen

Temporäre Verzeichnisse wie /tmp, /var/tmp und /dev/shm müssen für alle Systembenutzer und Daemons weltweit beschreibbar sein (chmod 1777). Dies macht sie zum bevorzugten Ziel für Angreifer: Gelingt ein Exploit in einer Webanwendung (z. B. File Upload oder RCE), legt der Angreifer seine Schadsoftware fast ausnahmslos in /tmp oder /dev/shm ab, um sie von dort auszuführen.

Die drei defensiven Mount-Flags

Um diesen Angriffsvektor im Keim zu ersticken, müssen temporäre Partitionen mit drei Kernel-Flags gemountet werden:

  • nodev: Verhindert, dass der Kernel Geräte-Dateien (Block- oder Character-Devices) auf dieser Partition interpretiert. Angreifer können keine Raw-Disks emulieren.
  • nosuid: Ignoriert SUID- und SGID-Bits. Eine Binary auf dieser Partition kann niemals Root-Rechte eskalieren.
  • noexec: Verbietet die direkte Ausführung von Binärdateien und Skripten. Versucht ein Angreifer ./exploit auszuführen, verweigert der Kernel den Systemaufruf mit EACCES (Permission denied).

Gehärtete /etc/fstab-Konfiguration

Öffne /etc/fstab und passe temporäre Dateisysteme wie folgt an:

# /etc/fstab - Gehärtete Mount-Konfiguration für Enterprise-Server

# Separates /tmp Verzeichnis als tmpfs (im RAM) oder Partition
tmpfs   /tmp        tmpfs   defaults,noexec,nosuid,nodev,size=2G,mode=1777   0 0

# Bind-Mount für /var/tmp auf /tmp (verhindert Umgehung)
/tmp    /var/tmp    none    bind,defaults,noexec,nosuid,nodev                0 0

# Shared Memory im RAM strikt absichern
tmpfs   /dev/shm    tmpfs   defaults,noexec,nosuid,nodev,size=1G,mode=1777   0 0

Wende die Änderungen ohne Reboot an:

# Remount der temporären Dateisysteme
sudo mount -o remount /tmp
sudo mount -o remount /dev/shm

Systemweite umask-Härtung

Die standardmäßige Dateierstellungsmaske (umask 022) erteilt allen Benutzern auf dem System weltweite Leserechte (rwxr-xr-x). Für Enterprise-Server gilt der Standard umask 027 (Besitzer: Vollzugriff, Gruppe: Lesen/Ausführen, Welt: Gar kein Zugriff).

Setze die Baseline in /etc/login.defs:

# /etc/login.defs
UMASK           027

Und erzwinge die Maske für alle interaktiven Shells via /etc/profile.d/umask.sh:

# /etc/profile.d/umask.sh
umask 027

2. Pluggable Authentication Modules (PAM) Tiefenarchitektur

Jede Authentifizierung unter Linux – ob lokaler Login, SSH, sudo, su oder grafischer Desktop – wird über das PAM-Framework abgewickelt. PAM modularisiert die Authentifizierung in vier unabhängige Management-Gruppen:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    User_Request["Benutzeranfrage<br/>(Login / sudo / ssh)"] ==> PAM_Entry["PAM API Einstiegspunkt<br/>(/etc/pam.d/<dienst>)"]
    PAM_Entry --> Stack_Auth["1. auth Stack<br/>(Identitätsprüfung / Passwort)"]
    Stack_Auth --> Stack_Account["2. account Stack<br/>(Kontogültigkeit / Zeitfenster)"]
    Stack_Account --> Stack_Password["3. password Stack<br/>(Passwortwechsel / Regeln)"]
    Stack_Password --> Stack_Session["4. session Stack<br/>(Umgebung / Limits / Mounts)"]
    Stack_Session ==> Success["Zugriff gewährt<br/>(Shell / Prozess gestartet)"]

Die vier Kontroll-Flags (Control Flags)

Innerhalb jedes Stacks entscheidet das Kontroll-Flag, wie PAM auf Erfolg oder Misserfolg eines Moduls reagiert:

  1. required: Das Modul muss erfolgreich sein. Schlägt es fehl, schlägt die Authentifizierung fehl, PAM führt aber alle weiteren Module im Stack aus (verhindert Timing-Angriffe).
  2. requisite: Das Modul muss erfolgreich sein. Schlägt es fehl, bricht PAM den Stack sofort ab.
  3. sufficient: Ist das Modul erfolgreich und kein vorheriges required-Modul fehlgeschlagen, gewährt PAM den Zugriff sofort, ohne nachfolgende Module zu prüfen.
  4. optional: Der Rückgabewert wird ignoriert, es sei denn, es ist das einzige Modul im Stack.

3. Brute-Force-Schutz mit pam_faillock

Automatisierte Angreifer versuchen über SSH oder Konsolen, Passwörter per Wörterbuchangriff zu erraten. pam_faillock protokolliert Fehlversuche und sperrt das betroffene Benutzerkonto temporär.

Konfiguration in /etc/security/faillock.conf

# /etc/security/faillock.conf
# Sperre nach 5 aufeinanderfolgenden Fehlversuchen
deny = 5

# Beobachtungszeitfenster: 15 Minuten (900 Sekunden)
fail_interval = 900

# Sperrdauer: 15 Minuten (900 Sekunden)
unlock_time = 900

# Auch den Benutzer root bei lokalen Anmeldefehlern überwachen
even_deny_root

# Root jedoch nur für 5 Minuten sperren
root_unlock_time = 300

# Fehlgeschlagene Versuche im Syslog protokollieren
audit

# Verzeichnis für Zählerdateien
dir = /var/run/faillock

Einbindung in /etc/pam.d/common-auth (Debian/Ubuntu)

Stelle sicher, dass pam_faillock den auth-Stack umschließt:

# /etc/pam.d/common-auth
auth    required    pam_faillock.so preauth
auth    [success=1 default=ignore]  pam_unix.so nullok
auth    [default=die] pam_faillock.so authfail
auth    sufficient  pam_faillock.so authsucc

Administrative Verwaltung mit der faillock-CLI

# Zeige Fehlversuche für einen bestimmten Benutzer an
sudo faillock --user devuser

# Zeige Fehlversuche für alle gesperrten Benutzer an
sudo faillock

# Entsperre ein fälschlicherweise gesperrtes Konto sofort
sudo faillock --user devuser --reset

4. Passwort-Qualität & Modernes yescrypt-Hashing

Schwache Passwörter sind das Haupteinfallstor für Credential-Stuffing-Angriffe. Mit pam_pwquality erzwingen wir kryptografisch robuste Mindestanforderungen.

Konfiguration in /etc/security/pwquality.conf

# /etc/security/pwquality.conf
# Mindestlänge des Passworts
minlen = 14

# Mindestens 1 Ziffer gefordert
dcredit = -1

# Mindestens 1 Großbuchstabe gefordert
ucredit = -1

# Mindestens 1 Kleinbuchstabe gefordert
lcredit = -1

# Mindestens 1 Sonderzeichen gefordert
ocredit = -1

# Maximal 3 identische aufeinanderfolgende Zeichen
maxrepeat = 3

# Keine Teile des Benutzernamens oder GECOS-Felds erlauben
gecoscheck = 1

# Mindestanzahl neuer Zeichen im Vergleich zum alten Passwort
difok = 4

Umstellung auf speicher-hartes yescrypt

Traditionelle SHA-512-Hashes können auf modernen Grafikkarten (GPUs) mit Milliarden Hashes pro Sekunde parallelisiert gecrackt werden. yescrypt ist ein modernes, KDF-basiertes (Key Derivation Function) Hashverfahren, das massiven Speicheraufwand erfordert und GPU-Cracker wirkungslos ausbremst.

Setze den Standardalgorithmus in /etc/login.defs:

# /etc/login.defs
ENCRYPT_METHOD YESCRYPT
YESCRYPT_COST_FACTOR 5

5. User-Governance: Root-Lock & Inaktive Konten

Ein System mit Dutzenden vergessenen Standard-Accounts bietet Angreifern eine riesige Angriffsfläche.

1. Root-Passwort sperren

Auf einem gehärteten Server meldet sich niemand direkt als root an. Administrative Arbeiten erfolgen ausschließlich über sudo:

# Sperre das Passwort des Root-Benutzers (setzt '!' vor den Hash in /etc/shadow)
sudo passwd -l root

2. Systemkonten absichern

Systemkonten (wie daemon, bin, sys, sync, games) dürfen niemals über eine interaktive Login-Shell verfügen. Kontrolliere /etc/passwd:

# Prüfe, ob System-Accounts (UID < 1000) eine echte Shell besitzen
awk -F: '($3 < 1000 && $1 != "root" && $7 !~ /(nologin|false)/) {print $1, $7}' /etc/passwd

# Weise verwundbaren Accounts sofort /usr/sbin/nologin zu
sudo usermod -s /usr/sbin/nologin <accountname>

3. Automatischer Session-Timeout

Verwaiste Terminal-Sitzungen in Rechenzentren oder auf Entwickler-Laptops sind ein massives Sicherheitsrisiko. Erzwinge automatischen Logout nach 15 Minuten Inaktivität via /etc/profile.d/autologout.sh:

# /etc/profile.d/autologout.sh
# 900 Sekunden = 15 Minuten Inaktivitäts-Timeout
TMOUT=900
readonly TMOUT
export TMOUT

6. Sudoers-Härtung & Schutz vor GTFOBins

Das Werkzeug sudo regelt administrative Privilegien. Eine schlampige sudoers-Datei hebelt jedes Sicherheitskonzept aus.

Die goldene Regel: Niemals ALL=(ALL) NOPASSWD: ALL

Konfiguriere sudo niemals pauschal ohne Passwortabfrage. Verwende stets visudo zum Bearbeiten:

# Sichere Bearbeitung der Sudoers-Konfiguration
sudo visudo -f /etc/sudoers.d/enterprise-hardening

Füge folgende gehärtete Standard-Direktiven ein:

# /etc/sudoers.d/enterprise-hardening

# Umgebungsvariablen bei sudo-Ausführung strikt zurücksetzen
Defaults    env_reset

# Sicheren, nicht vom Benutzer manipulierbaren Suchpfad erzwingen
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Zuweisung eines Pseudo-Terminals erzwingen (verhindert TTY-Hijacking via TIOCSTI)
Defaults    use_pty

# Eigenes Audit-Log für alle ausgeführten sudo-Befehle schreiben
Defaults    logfile="/var/log/sudo.log"

# Passwort-Pufferzeit auf 5 Minuten begrenzen (Standard ist oft 15 Min.)
Defaults    timestamp_timeout=5

# Administratoren müssen Mitglied der Gruppe 'sudo' oder 'wheel' sein
%sudo   ALL=(ALL:ALL) ALL

Warnung vor GTFOBins: Niemals Editoren oder Interpreter in sudo erlauben

Erlaube einem Benutzer niemals Befehle wie vi, vim, nano, less, more, awk, find, python oder bash über sudo auszuführen!

Nahezu alle Standard-UNIX-Tools besitzen Escape-Sequenzen. Wer sudo vi /etc/hosts ausführen darf, kann innerhalb von vi einfach :!/bin/bash eingeben und erhält sofort eine interaktive Root-Shell (dokumentiert auf GTFOBins).

7. SUID/SGID-Sanierung & Core-Dump-Isolation

Das SUID-Bit (Set User ID, Oktalwert 4000) bewirkt, dass eine Binärdatei immer mit den Rechten des Dateieigentümers (root) ausgeführt wird – unabhängig davon, wer das Programm startet.

Systematische SUID-Audits

Finde alle aktiven SUID- und SGID-Binaries auf dem Server:

# Suche nach allen Dateien mit SUID- (4000) oder SGID-Bit (2000)
sudo find / -xdev \( -perm -4000 -o -perm -2000 \) -type f -exec ls -ld {} +

Viele Standard-Binaries benötigen auf einem Headless-Server niemals Root-Rechte für normale Benutzer. Entziehe das SUID-Bit:

# Entziehe SUID-Rechte für überflüssige Desktop- oder Legacy-Programme
sudo chmod u-s /usr/bin/chsh
sudo chmod u-s /usr/bin/chfn
sudo chmod u-s /usr/bin/mount
sudo chmod u-s /usr/bin/umount

Core Dumps deaktivieren

Stürzt ein Prozess ab (z. B. durch einen Speicherfehler), schreibt der Kernel ein Abbild des Arbeitsspeichers (Core Dump) auf die Festplatte. Enthielt der Prozess Passwörter, private SSH-Schlüssel oder Datenbank-Tokens, kann ein lokaler Angreifer diese aus dem Dump extrahieren.

Deaktiviere Core Dumps systemweit in /etc/security/limits.conf:

# /etc/security/limits.conf
*       hard    core    0
*       soft    core    0

Und sichere den Kernel über sysctl ab:

# Verbiete Core Dumps von Prozessen mit gewechselter UID/GID
echo "fs.suid_dumpable = 0" | sudo tee /etc/sysctl.d/50-coredump.conf
sudo sysctl -p /etc/sysctl.d/50-coredump.conf

8. Enterprise-Checkliste & Troubleshooting

Bereich Prüfbefehl Soll-Zustand
Mounts mount \| grep -E "(tmp\|shm)" noexec,nosuid,nodev aktiv
Umask umask Gibt 0027 zurück
Faillock faillock Zeigt aktive Kontosperren an
Root-Lock passwd -S root Zeigt L (Locked) an
Sudo-Log tail -n 20 /var/log/sudo.log Protokolliert jeden Befehl mit Timestamp
SUID-Audit find / -xdev -perm -4000 -type f Nur unverzichtbare Binaries (sudo, passwd)

Mit dieser soliden Host-Baseline ist das Fundament gelegt: Lokale Privilege Escalations sind unterbunden, Passwörter gehärtet und Angreifer können keine Skripte in temporären Verzeichnissen ausführen.