sudo und minimale Rechte

Modul 3: Benutzer, Rechte und sudo · Lesezeit: 11 Minuten

Lernziel: Nach dieser Lektion können Sie als normaler Benutzer mit sudo arbeiten, sicher einen Administrator hinzufügen, die sudo-Einstellungen ändern, ohne sich selbst auszusperren, und erklären, warum minimale Rechte Ihren Server schützen.

Kernbegriffe: sudo, Gruppe sudo, Gruppe wheel, /etc/sudoers, /etc/sudoers.d, visudo, NOPASSWD, sudo -l, root sperren, Protokoll von sudo, minimale Rechte (least privilege), Dienstbenutzer

Warum nicht einfach als root arbeiten?

Nach der Installation melden Sie sich oft als root an. Das ist bequem: Alles ist erlaubt. Aber genau das ist das Problem:

• Ein Tippfehler genügt. rm -rf / home/anna/oud (beachten Sie das Leerzeichen nach dem ersten Schrägstrich) löscht als root Ihren gesamten Server. Als normaler Benutzer erhalten Sie eine Fehlermeldung.
• Alles läuft als root. Ein Skript, das Sie aus dem Internet einfügen, ein Programm, das Sie testen: Alles erhält volle Rechte.
• Keine Spur. Arbeiten drei Personen als root, weiß hinterher niemand, wer was getan hat.
• Root ist der Name, den jeder Angreifer ausprobiert. Die Anmeldung als root schalten Sie besser ganz ab (Lektion 2.2), aber das geht erst, wenn Sie einen anderen Weg zu Administratorrechten haben.

Dieser andere Weg ist sudo: Sie melden sich als Sie selbst an und setzen nur vor einen Befehl, der Administratorrechte braucht, sudo.

anna@web1:~$ apt update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
anna@web1:~$ sudo apt update
[sudo] password for anna:
Hit:1 http://deb.debian.org/debian trixie InRelease
...

(Ubuntu verwendet seit Version 25.10 standardmäßig sudo-rs, eine neue Implementierung von sudo. Für alles in dieser Lektion funktioniert sie genauso.)

sudo fragt nach Ihrem Passwort, nicht nach dem von root. Danach merkt es sich das standardmäßig eine Viertelstunde lang, sodass Sie es nicht bei jedem Befehl erneut eingeben müssen. Jeder Befehl, den Sie mit sudo ausführen, landet im Protokoll.

Einen Administrator anlegen

Unter Debian und Ubuntu darf jedes Mitglied der Gruppe sudo alles über sudo ausführen. Das steht in /etc/sudoers:

%sudo   ALL=(ALL:ALL) ALL

Lesen Sie das so: Mitglieder der Gruppe sudo (%) dürfen auf allen Rechnern (ALL) als jeder Benutzer und jede Gruppe ((ALL:ALL)) jeden Befehl (ALL) ausführen.

Einen Administrator fügen Sie also in zwei Schritten als root hinzu:

root@web1:~# adduser anna
root@web1:~# adduser anna sudo

Legen Sie anschließend Annas öffentlichen Schlüssel mit dem richtigen Eigentümer und den richtigen Rechten in /home/anna/.ssh/authorized_keys ab:

root@web1:~# mkdir -p /home/anna/.ssh
root@web1:~# cp /root/.ssh/authorized_keys /home/anna/.ssh/
root@web1:~# chown -R anna:anna /home/anna/.ssh
root@web1:~# chmod 700 /home/anna/.ssh
root@web1:~# chmod 600 /home/anna/.ssh/authorized_keys

Vergessen Sie chown nicht: Von root kopiert, gehört die Datei root, und dann kann Anna sich nicht mit ihrem Schlüssel anmelden.

Testen Sie jetzt, während Ihre root-Sitzung geöffnet bleibt, in einem zweiten Fenster:

anna@laptop:~$ ssh anna@192.0.2.10
anna@web1:~$ sudo -l
[sudo] password for anna:
User anna may run the following commands on web1:
    (ALL : ALL) ALL
anna@web1:~$ sudo whoami
root

Erst wenn das funktioniert, setzen Sie in Ihren SSH-Einstellungen PermitRootLogin no (Lektion 2.2). Ab dann melden Sie sich immer als Anna an.

Eines sollten Sie sich merken: Anna braucht jetzt ein Passwort für sudo. Bewahren Sie es in Ihrem Passwortmanager auf. Die Anmeldung erfolgt mit dem Schlüssel, sudo mit dem Passwort: zwei verschiedene Dinge, die ein Einbrecher beide haben muss.

sudo-Einstellungen ändern: immer mit visudo

Ein Fehler in /etc/sudoers kann dazu führen, dass sudo überhaupt nicht mehr funktioniert. Wenn sich auch root nicht anmelden kann, sitzen Sie fest. Deshalb bearbeiten Sie sudo-Einstellungen nie mit einem normalen Editor, sondern mit visudo. Es öffnet eine temporäre Kopie und prüft den Inhalt, bevor es speichert:

root@web1:~# visudo -f /etc/sudoers.d/backup

Verwenden Sie wie bei SSH lieber eine eigene Datei in /etc/sudoers.d/ als die Hauptdatei. Beachten Sie zwei Regeln für dieses Verzeichnis:

• Dateien, deren Name einen Punkt enthält oder auf ~ endet, werden übersprungen. backup.conf funktioniert also nicht, backup schon. Das soll Sicherungskopien von Editoren ignorieren, überrascht aber viele.
• Die Datei muss root gehören und darf für andere nicht beschreibbar sein (440 ist üblich; visudo erledigt das).

Möchten Sie eine bestehende Datei prüfen, ohne sie zu bearbeiten: visudo -c prüft alles.

NOPASSWD: praktisch, aber wissen Sie, was Sie tun

Mit NOPASSWD fragt sudo nicht mehr nach einem Passwort:

anna ALL=(ALL:ALL) NOPASSWD: ALL

Manche VPS-Images setzen das für den Standardbenutzer, sodass Sie nach der Anmeldung mit einem Schlüssel sofort Administrator sind. Prüfen Sie mit sudo -l, was bei Ihnen gilt. Die Folge: Wer Annas Schlüssel hat, ist sofort root. Es gibt kein zweites Schloss mehr. Bei einem persönlichen Server können Sie sich dafür entscheiden, tun Sie es aber bewusst.

Viel besser ist NOPASSWD nur für einen bestimmten Befehl, zum Beispiel für ein Backup-Skript, das automatisch laufen können muss:

backup ALL=(root) NOPASSWD: /usr/local/bin/maak-backup

Der Benutzer backup darf dann genau dieses eine Skript als root ausführen, ohne Passwort, und sonst nichts. Zwei Fallstricke:

• Verwenden Sie immer den vollständigen Pfad. Mit nur maak-backup kann jemand ein eigenes Programm mit diesem Namen vorne in seinen Pfad legen.
• Das Skript selbst darf für diesen Benutzer nicht beschreibbar sein. Sonst ändert er es und führt dann beliebige Befehle als root aus. Dasselbe gilt für Befehle, die selbst eine Shell öffnen können, etwa ein Editor (vim, nano) oder less: Wer diese über sudo starten darf, kann aus dem Programm heraus eine Root-Shell öffnen. Geben Sie solche Befehle nie einzeln über sudo frei.

Was protokolliert wird

Jedes Mal, wenn jemand sudo verwendet, landet eine Zeile im Journal (und auf Systemen mit rsyslog auch in /var/log/auth.log):

anna@web1:~$ sudo journalctl _COMM=sudo --since today
Nov 09 10:31:02 web1 sudo[2214]:     anna : TTY=pts/0 ; PWD=/home/anna ; USER=root ; COMMAND=/usr/bin/apt update

Sie sehen, wer, wo, als wer und welcher Befehl. Das ist einer der Gründe, nicht mit mehreren Personen als root zu arbeiten. Fehlgeschlagene sudo-Versuche ("incorrect password attempts") von einem Konto, das nicht Ihres ist, sind ein Alarmsignal.

Minimale Rechte im Großen

sudo ist eine Anwendung eines allgemeinen Prinzips: minimale Rechte (least privilege). Jeder Benutzer und jeder Dienst erhält genau die Rechte, die nötig sind, und nicht mehr. Auf einem Server bedeutet das unter anderem:

• Sie arbeiten als normaler Benutzer und verwenden sudo nur, wenn es nötig ist;
• jeder Dienst läuft unter einem eigenen Benutzer ohne Shell (Lektion 3.1), nicht als root;
• eine Webanwendung erhält einen Datenbankbenutzer, der nur seine eigene Datenbank verwenden darf, nicht den Administrator des Datenbankservers;
• ein Backup-Skript darf nur den einen Befehl, den es braucht (NOPASSWD mit vollständigem Pfad);
• ein Kollege, der nur die Website aktualisiert, erhält Schreibrechte auf /var/www/example.com über eine Gruppe, nicht sudo.

Die Idee: Geht etwas schief (eine Lücke in einem Plugin, ein gestohlener Schlüssel), bleibt der Schaden auf diesen einen Benutzer oder Dienst beschränkt. In den CIS-Prinzipien und in der Hardening-Lektion (10.1) taucht das immer wieder auf.

Unter AlmaLinux und Rocky Linux

Dort heißt die Administratorgruppe wheel statt sudo: usermod -aG wheel anna. Die Zeile in /etc/sudoers lautet %wheel ALL=(ALL) ALL. visudo und /etc/sudoers.d funktionieren genauso. Sudo-Meldungen stehen dort auch in /var/log/secure.

Zusammenfassung

• Arbeiten Sie als normaler Benutzer und verwenden Sie sudo für die Verwaltung; sudo fragt nach Ihrem eigenen Passwort und protokolliert jeden Befehl.
• Einen Administrator anlegen: adduser anna, adduser anna sudo (wheel bei RHEL-artigen Systemen), Schlüssel mit richtigem Eigentümer und richtigen Rechten, in einem zweiten Fenster testen, erst dann root-Login abschalten.
• Bearbeiten Sie sudo-Regeln nur mit visudo, am besten in einer eigenen Datei in /etc/sudoers.d/ ohne Punkt im Namen.
• NOPASSWD für alles entfernt ein Schloss; verwenden Sie es lieber nur für einen Befehl mit vollständigem Pfad, den der Benutzer nicht ändern kann.
• Minimale Rechte: Jeder Benutzer und Dienst erhält genau das, was nötig ist, damit ein Fehler oder eine Lücke klein bleibt.

Quiz

Aufgabe

Aufgabe O3.2: Ein Administrator mit sudo. Legen Sie auf Ihrem Server einen normalen Administrator an (zum Beispiel anna), legen Sie Ihren Schlüssel richtig ab, testen Sie die Anmeldung und sudo -l in einem zweiten Fenster und schalten Sie anschließend den root-Login über SSH ab (PermitRootLogin no). Haken Sie die Schritte ab, fügen Sie die Ausgabe von id ein (nur Name und Gruppen) und beantworten Sie die Fragen: Welche Regel gibt Ihrem Administrator Rechte, steht irgendwo NOPASSWD, und wie kommen Sie hinein, wenn Sie Ihr Passwort vergessen?

Weiterführende Informationen

Die Schritte in diesen Artikeln gelten für die VPS von WebOké; bei anderen Anbietern funktioniert es ähnlich.

• Ihren VPS absichern: die ersten fünf Minuten
• Kein Zugriff mehr auf Ihren VPS: Was nun?
• DirectAdmin Anleitung 12.2: Datenbank-Benutzer, Berechtigungen und Passwörter
• Ubuntu Server: User management: https://ubuntu.com/server/docs/how-to/security/user-management/
• Debian-Handbuch sudoers: https://manpages.debian.org/trixie/sudo/sudoers.5.en.html