↓ Skip to main content
u-random
u-random
  1. Concetti/

journald - systemd-journald

·3 mins
base
System Observability
Alessio Barnini
Author
Alessio Barnini
Table of Contents
journald - systemd-journald

Cosa fa
#

Demone del sistema che raccoglie log da tutte le sorgenti — kernel, servizi systemd, applicazioni — e li indicizza in un database binario strutturato in /run/log/journal/ (volatile) o /var/log/journal/ (persistente). Non si legge con cat o grep — si usa journalctl. Si distingue da auth.log per la resistenza alla manomissione grazie a FSS.

TL;DR
#

kernel
servizi systemd (sshd, cron, sudo...)
applicazioni che scrivono su syslog
         │
         ▼
  systemd-journald
         │
         ▼
  /var/log/journal/   ← database binario strutturato
         │
         ▼
  journalctl          ← unico modo per leggerlo correttamente

journal vs auth.log — differenza chiave
#

auth.log                          journal
─────────────────────────         ──────────────────────────────
file di testo                     database binario
grep funziona direttamente        si legge con journalctl
scritto da rsyslog                scritto da systemd-journald
solo eventi autenticazione        TUTTI gli eventi di sistema
alterabile con > auth.log         FSS — modifiche rilevabili

FSS — Forward Secure Sealing (sigillatura sicura in avanti)
#

FSS e' il meccanismo che rende il journal resistente alla manomissione. Ogni blocco di log viene firmato crittograficamente con una chiave che cambia nel tempo — anche se un attaccante modifica voci vecchie, la firma non torna valida.

# Verificare l'integrita' del journal
journalctl --verify

# Output atteso su journal integro:
# PASS: /var/log/journal/xxxx/system.journal

auth.log non ha questo meccanismo — puo' essere svuotato silenziosamente:

> /var/log/auth.log    # svuota senza traccia

La modifica al journal lascia una firma non valida rilevabile con --verify.

Dove vivono i log
#

/run/log/journal/    # volatile — sparisce al riavvio (default su alcuni sistemi)
/var/log/journal/    # persistente — sopravvive al riavvio

# Verificare quale e' attivo
ls /var/log/journal/
# se vuoto o assente → i log sono solo in /run (volatili)

# Abilitare la persistenza
sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Sorgenti dei log
#

SORGENTE                    COME ARRIVA A JOURNALD
────────────────────────    ─────────────────────────────────────
kernel                      /dev/kmsg
servizi systemd             stdout/stderr dei processi
applicazioni tradizionali   socket /run/systemd/journal/syslog
                            (rsyslog lo legge da qui e scrive auth.log)

Questo spiega perche' auth.log e journal si sovrappongono per gli eventi SSH e sudo — entrambi ricevono gli stessi messaggi PAM, ma attraverso percorsi diversi.

Scenario Reale
#

Un attaccante con accesso root svuota auth.log per coprire le tracce:

> /var/log/auth.log

L'analista controlla auth.log e lo trova vuoto — nessuna traccia di accesso. Ma controlla anche il journal:

sudo journalctl -u ssh --since "2 hours ago"

Il journal mostra tutti i login SSH delle ultime 2 ore, incluso quello dell'attaccante. La firma FSS e' integra — nessuno ha manomesso il journal. auth.log era l'unico target perche' e' il piu' ovvio, ma il journal e' sopravvissuto.

Important

La vera soluzione contro la manomissione dei log e' il forwarding esterno — mandare i log in tempo reale a un server separato (Wazuh al mese 3). Se la macchina e' compromessa, anche il journal locale non e' abbastanza.

Dove l'ho incontrato
#

  • journalctl — il comando per leggere il journal
  • auth-log — alternativa basata su file di testo

Collegato a
#

  • system — categoria
  • log — categoria
  • journalctl — comando per interrogare il journal
  • auth-log — alternativa file di testo per gli eventi di autenticazione
  • pam — genera eventi che finiscono sia in auth.log che nel journal
  • systemctl — gestisce il demone journald

Related