So lesen Sie Linux-Protokolle ohne Root-Rechte (Berechtigungsleitfaden)

In den meisten Distributionen decken zwei Gruppenmitgliedschaften fast alle Anforderungen eines Analysten ab: adm für die Textprotokolle in /var/log unter Debian und Ubuntu und systemd-journal für das vollständige Systemjournal. Fügen Sie das Konto mit sudo usermod -aG adm,systemd-journal <user> hinzu und starten Sie eine neue Anmeldesitzung. Einige Protokolle bleiben aus Designgründen nur für root zugänglich, insbesondere /var/log/secure und /var/log/messages auf Systemen der Red-Hat-Familie und alles unter /var/log/audit. Verwenden Sie dafür einen eng umschriebenen sudo, keine root-Shell.

Jemandem root-Rechte zu geben, nur damit er Protokolle lesen kann, ist genau die Art von Abkürzung, die im nächsten Audit oder beim nächsten Vorfall auffällt. Dieser Leitfaden behandelt die Methode mit den geringsten Rechten sowie die Fallstricke, die „einfach einer Gruppe hinzufügen“ schwieriger machen, als es klingt.

Kostenlos starten

Wer kann was lesen

Die genaue Eigentümerschaft variiert je nach Distribution und Version. Überprüfen Sie daher auf dem System selbst:

id
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
getfacl /var/log/journal 2>/dev/null

Option 1: Gruppenmitgliedschaft

sudo usermod -aG adm,systemd-journal analyst

Zwei Details sind wichtig. Das -a ist nicht optional: Ohne dieses ersetzt usermod -G die Gruppen des Benutzers anstatt sie hinzuzufügen. Und Gruppenänderungen gelten nur für neue Sitzungen. Melden Sie sich ab und wieder an, oder starten Sie eine neue Login-Shell, bevor Sie testen. „Ich habe die Gruppe hinzugefügt und es sagt immer noch Zugriff verweigert“ ist fast immer eine alte Sitzung. the user’s groups instead of adding to them. And group changes only apply to new sessions. Log out and back in, or start a fresh login shell, before testing. “I added the group and it still says permission denied” is almost always an old session.

Auf Systemen der Red-Hat-Familie entsperrt adm nicht /var/log/secure oder /var/log/messages. Diese Dateien sind dort nur für root. Verwenden Sie Option 2 oder 3.

Option 2: Enges sudo für root-only-Protokolle

Gewähren Sie spezifische Befehle, nicht eine Shell. Erstellen Sie mit visudo -f /etc/sudoers.d/log-readers:

%logreaders ALL=(root) NOPASSWD: /usr/sbin/ausearch, /usr/local/bin/read-secure-log

read-secure-log ist ein kleines root-gehörendes Skript (Mode 0755, im Besitz von root), das genau eine Sache tut:

#!/bin/sh
exec /usr/bin/zcat -f /var/log/secure /var/log/secure-*

Warum ein Wrapper anstatt cat /var/log/secure* in sudoers? Weil ein * in einem sudoers-Argument alles, einschließlich Leerzeichen, matcht. cat /var/log/secure /etc/shadow matcht cat /var/log/secure*. Ein Wrapper ohne Argumente hat keine solche Sicherheitslücke.

Gewähren Sie nicht journalctl über sudo. Es öffnet einen Pager (less), und !sh in less gibt Ihnen eine root-Shell. Für den Zugriff auf das Journal verwenden Sie stattdessen die systemd-journal Gruppe.

Option 3: Gruppenbesitz, der Rotation überlebt

Das direkte Setzen einer ACL funktioniert bis zur nächsten Rotation: sudo setfacl -m g:logreaders:r /var/log/secure. Dann wird die Datei neu erstellt und die ACL ist verschwunden. Um den Zugriff zu behalten, lassen Sie neue Dateien gleich mit der richtigen Gruppe erstellen, an beiden Stellen, die sie erstellen:

• logrotate, im Abschnitt der Datei: create 0640 root logreaders
• rsyslog, bei der Aktion, die es schreibt: action(type=“omfile“ file=“/var/log/secure“ fileGroup=“logreaders“ fileCreateMode=“0640″)

Testen Sie es mit logrotate -f auf einem Nicht-Produktionssystem, bevor Sie es anwenden.

Container

Fügen Sie Analysten nicht zur Docker-Gruppe hinzu, nur um Container-Protokolle zu lesen. Die Mitgliedschaft in Docker ist effektiv root auf diesem Host. Holen Sie die Container-Protokolle von Ihrem Protokollsammler oder SIEM oder fragen Sie das Plattformteam nach Lesezugriff.

Wenn es schiefgeht