journald – jak działa system logowania w Linux i dlaczego zastąpił klasyczne logi

Logi systemowe są jednym z najważniejszych elementów administracji Linux. Bez nich trudno odpowiedzieć na podstawowe pytania podczas awarii lub incydentu bezpieczeństwa:

• Dlaczego usługa się zatrzymała?
• Kto wykonał zmianę konfiguracji?
• Dlaczego serwer przestał odpowiadać?
• Czy ktoś próbował się włamać?

W starszych systemach Linux administrator pracował głównie z plikami tekstowymi:

/var/log/messages

/var/log/syslog

/var/log/auth.log

Współczesne dystrybucje coraz częściej wykorzystują systemd-journald, czyli centralny system zbierania i przechowywania logów.

Czym jest journald?

journald jest komponentem projektu systemd, odpowiedzialnym za zbieranie logów z całego systemu.

Zbiera informacje między innymi z:

• kernela Linux,
• usług systemowych,
• aplikacji,
• procesów użytkowników,
• mechanizmów bezpieczeństwa.

Schemat:

Aplikacje

   ↓

systemd services

   ↓

journald

   ↓

Journal database

   ↓

journalctl

Dlaczego powstał journald?

Tradycyjne logi tekstowe miały kilka problemów.

Przykład:

Jul 16 10:15:33 server sshd: Failed password

Administrator widzi komunikat, ale brakuje wielu informacji:

• jaki PID?
• jaki użytkownik?
• jaka usługa systemd?
• jaki kontekst bezpieczeństwa?
• jaki numer jednostki?

journald zapisuje logi jako ustrukturyzowane dane.

Przykład:

MESSAGE=Failed password
_PID=2451
_UID=0
_SYSTEMD_UNIT=sshd.service
_BOOT_ID=xxxx
_MACHINE_ID=xxxx

Dzięki temu można bardzo precyzyjnie filtrować zdarzenia.

Architektura journald

Główny komponent:

systemd-journald

Sprawdzenie:

systemctl status systemd-journald

Pliki:

Logi trwałe:

/var/log/journal/

Logi tymczasowe:

/run/log/journal/

journalctl – podstawowe narzędzie

Do przeglądania logów służy:

journalctl

Przykład:

journalctl

pokazuje wszystkie dostępne wpisy.

Najważniejsze filtrowanie logów

Logi od najnowszych

journalctl -r

Ostatnie zdarzenia

journalctl -n 100

Logi na żywo

Odpowiednik:

tail -f

w świecie journald:

journalctl -f

Logi konkretnej usługi

Jedna z najczęściej używanych funkcji.

Przykład:

journalctl -u nginx

Tylko nginx:

nginx.service

Przykład diagnostyki:

Usługa nie startuje:

systemctl restart nginx

Błąd:

Job failed

Sprawdzenie:

journalctl -u nginx -xe

Parametr -xe

Bardzo przydatna opcja:

journalctl -xe

Pokazuje:

• ostatnie błędy,
• dodatkowy kontekst,
• informacje diagnostyczne.

Często jest pierwszym poleceniem administratora po awarii usługi.

Logi kernela Linux

Kernel również zapisuje zdarzenia.

Polecenie:

journalctl -k

Przykłady:

• problemy ze sprzętem,
• sterowniki,
• błędy pamięci,
• problemy sieciowe.

Odpowiednik:

dmesg

Logi poprzedniego uruchomienia systemu

Bardzo przydatne po awarii.

Sprawdzenie:

journalctl -b -1

oznacza:

poprzedni boot.

Aktualny:

journalctl -b

Lista uruchomień:

journalctl --list-boots

Przykład:

-2  123abc
-1  456def
 0  789xyz

Poziomy logów

journald obsługuje standardowe poziomy:

Przykład:

Tylko błędy:

journalctl -p err

journald a bezpieczeństwo

Logi są bardzo ważne podczas analizy incydentów.

Przykład:

Atakujący próbuje SSH:

Failed password for root

Sprawdzenie:

journalctl -u ssh

Możemy znaleźć:

• adres IP,
• czas próby,
• użytkownika,
• liczbę prób.

journald i auditd

Te dwa systemy często pracują razem.

journald:

rejestruje zdarzenia usług i systemu.

auditd:

rejestruje działania bezpieczeństwa na poziomie syscall.

Przykład:

Administrator usuwa plik:

rm /etc/passwd

journald:

sudo command executed

auditd:

unlink syscall
file=/etc/passwd
user=root

Razem dają pełniejszy obraz zdarzenia.

journald i systemd services

Każda usługa systemd ma własny strumień logów.

Przykład:

systemctl status ssh

pokazuje ostatnie wpisy.

Pełna historia:

journalctl -u ssh.service

Konfiguracja journald

Główny plik:

/etc/systemd/journald.conf

Przykład:

[Journal]

Storage=persistent

SystemMaxUse=1G

MaxRetentionSec=30day

Logi trwałe vs tymczasowe

Domyślnie niektóre systemy przechowują logi tylko w RAM.

Po restarcie:

❌ logi znikają.

Aby włączyć trwałe logowanie:

mkdir -p /var/log/journal
systemctl restart systemd-journald

Ograniczanie rozmiaru logów

Serwery produkcyjne generują ogromne ilości danych.

Kontrola:

SystemMaxUse=2G

oznacza:

maksymalnie 2 GB na logi.

Przesyłanie logów do centralnego systemu

W większej infrastrukturze jeden serwer to za mało.

Schemat:

Serwer 1

journald

   ↓

Serwer logów

   ↓

SIEM

Popularne rozwiązania:

• Elastic Stack,
• Splunk,
• Graylog,
• Microsoft Sentinel.

Przydatne polecenia administratora

Największe wpisy:

journalctl --disk-usage

Czyszczenie starych logów:

journalctl --vacuum-time=30d

Logi konkretnego użytkownika:

journalctl _UID=1000

Logi procesu:

journalctl _PID=1234

Logi według czasu:

Od:

journalctl --since "today"

Do:

journalctl --until "1 hour ago"

journald w kontenerach

W środowiskach:

• Docker,
• Kubernetes,

logowanie jest często przekazywane dalej.

Przykład:

Kontener

↓

stdout/stderr

↓

runtime

↓

journald

↓

log collector

Najczęstsze błędy administratorów

1. Brak trwałych logów

Po restarcie:

„nie ma historii”.

2. Brak rotacji

Serwer działa rok.

Logi zajmują:

200 GB

3. Brak centralnego monitoringu

Jeżeli atakujący uzyska dostęp do serwera, lokalne logi mogą zostać zmodyfikowane.

4. Ignorowanie logów

Samo zbieranie danych nie zwiększa bezpieczeństwa.

Trzeba:

• analizować,
• tworzyć alerty,
• reagować.

journald vs klasyczne syslog

Podsumowanie

systemd-journald stał się jednym z najważniejszych elementów współczesnej administracji Linux.

Daje administratorowi:

• centralne logowanie,
• szybkie wyszukiwanie problemów,
• informacje o usługach,
• dane potrzebne podczas analizy incydentów.

W połączeniu z:

• auditd – śledzenie działań użytkowników,
• SELinux/AppArmor – kontrola dostępu,
• nftables – ochrona sieci,
• systemd – zarządzanie usługami,

tworzy kompletną podstawę monitorowania i zabezpieczenia serwera Linux.

Dla administratora produkcyjnego znajomość journalctl jest dziś tak samo ważna jak znajomość ssh, systemctl czy nft.

Polecane wpisy

Audyt bezpieczeństwa systemu Linux przy pomocy darmowego narzędzia Lynis

Audyt bezpieczeństwa systemu Linux przy pomocy darmowego narzędzia Lynis Bezpieczeństwo systemów Linux jest jednym z kluczowych elementów, na które administratorzy Czytaj dalej

Jak stworzyć lokalny serwer DNS w Linuksie za pomocą Bind9 lub dnsmasq – konfiguracja krok po kroku

🌐 Jak stworzyć lokalny serwer DNS w Linuksie za pomocą Bind9 lub dnsmasq – konfiguracja krok po kroku Lokalny serwer Czytaj dalej