Jak czytać logi Linuxa bez uprawnień root (Przewodnik po uprawnieniach)

Na większości dystrybucji dwa członkostwa w grupach obejmują niemal wszystko, czego analityk potrzebuje: adm dla logów tekstowych w /var/log na Debianie i Ubuntu oraz systemd-journal dla pełnego dziennika systemowego. Dodaj konto z sudo usermod -aG adm,systemd-journal <user> i rozpocznij nową sesję logowania. Kilka logów pozostaje dostępnych tylko dla roota z założenia, zwłaszcza /var/log/secure i /var/log/messages na systemach z rodziny Red Hat oraz wszystko pod /var/log/audit. Dla nich używaj ograniczonego sudo, a nie powłoki roota.

Nadanie komuś uprawnień roota tylko po to, aby mógł odczytać logi, to rodzaj skrótu, który pojawia się podczas kolejnego audytu lub incydentu. Ten przewodnik obejmuje sposób najmniejszych uprawnień, oraz pułapki, które sprawiają, że „wystarczy dodać ich do grupy” jest mniej proste niż się wydaje.

Rozpocznij za darmo

Kto może czytać co

Dokładna własność różni się w zależności od dystrybucji i wersji, sprawdź zatem na samym urządzeniu:

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

Opcja 1: Członkostwo w grupie

sudo usermod -aG adm,systemd-journal analyst

Dwa szczegóły mają znaczenie. Opcja -a nie jest opcjonalna: bez niej, usermod -G zastępuje grupy użytkownika zamiast dodawania do nich. I zmiany grup dotyczą tylko nowych sesji. Wyloguj się i zaloguj ponownie, lub rozpocznij nową powłokę sesji, przed testowaniem. „Dodałem grupę i nadal mówi, że odmowa dostępu” to niemal zawsze stara sesja.

Na systemach z rodziny Red Hat, adm nie odblokowuje /var/log/secure ani /var/log/messages. Te pliki są tam tylko dla roota. Użyj Opcji 2 lub 3.

Opcja 2: Ograniczone sudo dla logów tylko dla roota

Przyznaj określone komendy, nie powłokę. Utwórz /etc/sudoers.d/log-readers za pomocą visudo -f:

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

read-secure-log to mały skrypt należący do roota (tryb 0755, należący do roota), który robi dokładnie jedną rzecz:

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

Dlaczego owijka zamiast cat /var/log/secure* w sudoers? Ponieważ * w argumencie sudoers dopasowuje cokolwiek, w tym spacje. cat /var/log/secure /etc/shadow dopasowuje cat /var/log/secure*. Owijka bez argumentów nie ma takiej dziury.

Nie przyznawaj journalctl przez sudo. Otwiera pager (mniej), a !sh w środku daje ci powłokę roota. Dla dostępu do dziennika użyj grupy systemd-journal zamiast tego.

Opcja 3: Własność grupy, która przetrwa obrót

Ustawienie ACL bezpośrednio działa aż do następnego obrotu: sudo setfacl -m g:logreaders:r /var/log/secure. Następnie plik jest tworzony na nowo, a ACL znika. Aby dostęp się utrzymał, niech nowe pliki będą tworzone z odpowiednią grupą na pierwszym miejscu, w obu miejscach, które je tworzą:

• logrotate, w sekcji pliku: create 0640 root logreaders
• rsyslog, na akcji, która to zapisuje: action(type=”omfile” file=”/var/log/secure” fileGroup=”logreaders” fileCreateMode=”0640″)

Przetestuj to z logrotate -f na niewielkom produkcyjnym urządzeniu zanim wdrożysz.

Kontenery

Nie dodawaj analityków do grupy docker tylko po to, aby mogli czytać logi kontenerów. Członkostwo w docker jest w istocie rootem na tym hoście. Pobierz logi kontenerów od swojego kolektora logów lub SIEM, lub poproś zespół platformy o dostęp tylko do odczytu tam.

Kiedy coś idzie nie tak