# Sudo Mastery: Macht mit Verantwortung

TL;DR / Management Summary Wer unter Linux als Root arbeitet, spielt mit dem Feuer. Der Befehl sudo (substitute user do) erlaubt es uns, administrative Aufgaben mit normalen Benutzer-Accounts durchzuführen. Ein Senior Admin nutzt sudo, um exakt zu definieren, wer welche Befehle ausführen darf – ohne das Root-Passwort preiszugeben. In diesem Modul lernen wir das Härten der sudoers Datei und die Vermeidung von Sicherheitsrisiken bei der Rechte-Eskalation.

# 1. Einführung & Architektur

Warum sudo statt su?

• su (substitute user): Wechselt komplett zum Root-User. Erfordert das Root-Passwort. Keine Kontrolle, was der User danach tut.
• sudo: Führt nur einen Befehl mit Root-Rechten aus. Erfordert das Passwort des Benutzers. Erlaubt detailliertes Logging und granulare Regeln.

# Der Privileg-Fluss (Mermaid)

graph LR
    A[Standard User: admin] -->|Command: sudo systemctl restart nginx| B{Sudo Check}
    B -->|Check 1| C[Is User in Group wheel/sudo?]
    B -->|Check 2| D[Is Password correct?]
    B -->|Check 3| E[Is command allowed in sudoers?]
    C/D/E -->|Success| F[Execute as Root]
    C/D/E -->|Fail| G[Log Incident & Deny]
    F --> H[Log: /var/log/secure]

# 2. Konfiguration mit visudo

Der einzige sichere Weg.

Editieren Sie die Datei /etc/sudoers niemals direkt mit einem normalen Editor! Nutzen Sie immer visudo. Es prüft die Syntax vor dem Speichern und verhindert, dass Sie sich aus dem System aussperren.

# Beispiel: Granulare Berechtigungen

Anstatt einem User “alles” zu geben, erlauben wir nur Nginx-Restarts:

# User 'webadmin' darf Nginx ohne Passwort neustarten
webadmin ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

# 3. Best Practices für Enterprise-Umgebungen

Sicherheit durch Einschränkung.

1. Defaults: Setzen Sie Timeouts für Sudo-Sitzungen. Defaults timestamp_timeout=5 (Sudo fragt nach 5 Minuten Inaktivität erneut).
2. No Aliases: Vermeiden Sie komplexe User-Aliase in Sudoers bei großen Flotten; nutzen Sie stattdessen Gruppen-Zuweisungen (z.B. %wheel).
3. Logging: Stellen Sie sicher, dass jede Sudo-Aktion in das System-Log fließt (Standard in RHEL/SLES).

# 4. Day-2 Operations: Sudo-Session Management

Komfort vs. Sicherheit.

# Das Passwort-Timeout zurücksetzen

Wenn Sie eine Sudo-Sitzung sofort beenden wollen (z.B. bevor Sie den Platz verlassen):

sudo -k

# Als anderer User (nicht Root) agieren

Sudo kann auch genutzt werden, um zu einem anderen Service-Account zu wechseln:

sudo -u www-data php /var/www/html/cron.php

# 5. Troubleshooting & “War Stories”

Wenn Sudo den Dienst verweigert.

# Story 1: “Der Syntax-Fehler in Sudoers”

Symptom: Ein Admin hat die /etc/sudoers manuell editiert und einen Tippfehler gemacht. Jetzt kann niemand mehr sudo oder visudo ausführen. Der Server ist administrativ “tot”. Ursache: Fehlende Syntax-Prüfung. Lösung: Booten Sie in den Single-User Mode (Artikel 012) oder nutzen Sie die Proxmox-Konsole, loggen Sie sich als Root ein und fixen Sie die Datei. Lektion: Nutzen Sie IMMER visudo.

# Story 2: “Die interaktive Falle”

Symptom: Ein Skript mit sudo bricht in einem Cronjob ab. Ursache: sudo versucht, nach einem Passwort zu fragen, hat aber kein Terminal (tty). Lösung: Nutzen Sie das Flag -n (non-interactive) in Skripten. Sudo bricht dann sofort ab, wenn ein Passwort nötig wäre, statt zu hängen. Oder nutzen Sie NOPASSWD für die spezifischen Skript-Befehle.

# 6. Fazit & Empfehlung

• Sicherheit: Deaktivieren Sie den direkten Root-Login via SSH komplett.
• Audit: Überwachen Sie /var/log/secure (RHEL) oder /var/log/auth.log (Debian) auf Fehlversuche bei Sudo.
• Wahl: Nutzen Sie Gruppen für Sudo-Berechtigungen, um das Management via LDAP/AD (Artikel 136) zu vereinfachen.

# Anhang: Cheatsheet