Guida per principianti ai Syslog in Linux

Per decenni, la registrazione di Linux è stata gestita dal demone syslogd.

Syslogd raccoglierebbe i messaggi di registro che il sistema elabora e le applicazioni inviate allo pseudo dispositivo /dev/log. Quindi indirizzerebbe i messaggi ai file di registro di testo normale appropriati nella directory /var/log/.

Syslogd saprebbe dove inviare i messaggi perché ognuno include intestazioni contenenti campi di metadati (incluso un timestamp, l'origine e la priorità del messaggio).

Sulla scia dell'implacabile colosso mondiale di systemd, la registrazione di Linux è ora gestita anche da journald. Dico anche perché syslogd non è andato da nessuna parte e puoi ancora trovare la maggior parte dei suoi file di registro tradizionali in /var/log/. Ma devi essere consapevole che c'è un nuovo sceriffo in città il cui nome (dalla riga di comando) è journalctl.

Ma questo articolo non riguarda journald. L'attenzione qui è su systemd, quindi approfondiamo un po' di più.

Registrazione con syslogd

Tutti i log generati dagli eventi su un sistema syslogd vengono aggiunti al file /var/log/syslog. Ma, a seconda delle loro caratteristiche identificative, potrebbero anche essere inviati a uno o più altri file nella stessa directory.

Con syslogd, il modo in cui i messaggi vengono distribuiti è determinato dal contenuto di 50-default.conf file che risiede nel /etc/rsyslog.d/ directory.

Questo esempio da 50-default.conf mostra come i messaggi di registro contrassegnati come relativi a cron verranno scritti nel file cron.log. In questo caso, l'asterisco (*) indica a syslogd di inviare voci con qualsiasi livello di priorità (invece di un livello singolo come emerg o err):

cron.*     /var/log/cron.log

Lavorare con i file di registro syslogd non richiede strumenti speciali come journalctl. Ma se vuoi diventare bravo in questo, dovrai sapere che tipo di informazioni sono conservate in ciascuno dei file di registro standard.

La tabella seguente elenca i file di registro syslogd più comuni e
i loro scopi.

Nome file	Scopo
auth.log	Autenticazione del sistema ed eventi di sicurezza
boot.log	Un record di eventi relativi all'avvio
dmesg	Eventi del buffer dell'anello del kernel relativi ai driver di dispositivo
dpkg.log	Eventi di gestione dei pacchetti software
kern.log	Eventi del kernel Linux
syslog	Una raccolta di tutti i registri
wtmp	Traccia le sessioni utente (a cui si accede tramite i comandi who e last)

Inoltre, le singole applicazioni a volte scrivono nei propri file di registro. Spesso vedrai anche intere directory come /var/log/apache2/ o /var/log/mysql/ create per ricevere i dati dell'applicazione.

Il reindirizzamento del registro può anche essere controllato tramite uno qualsiasi degli otto livelli di priorità, oltre al simbolo * (per tutti i livelli di priorità) che hai visto prima.

Livello	Descrizione
debug	Utile per il debug
informazioni	Informativo
avviso	Condizioni normali
avviso	Condizioni che richiedono avvisi
err	Condizioni di errore
critico	Condizioni critiche
avviso	Richiesta azione immediata
emerge	Sistema inutilizzabile

Gestione dei file di registro con sysglogd

Per impostazione predefinita, syslogd gestisce la rotazione, la compressione e l'eliminazione dei log dietro le quinte senza alcun aiuto da parte tua. Ma dovresti sapere come è fatto nel caso in cui dovessi mai avere registri che necessitano di un trattamento speciale.

Che tipo di trattamento speciale potrebbe mai richiedere un semplice registro? Supponiamo che la tua azienda debba essere conforme alle regole di reporting delle transazioni associate a standard normativi o di settore come Sarbanes-Oxley o PCI-DSS. Se i record della tua infrastruttura IT devono rimanere accessibili per periodi di tempo più lunghi, allora lo vorrai sicuramente
per sapere come orientarsi tra i file chiave.

Per vedere il sistema logrotate in azione, elenca alcuni dei contenuti della directory /var/log/. Il file auth.log, ad esempio, appare in tre diversi formati:

• auth.log - La versione attualmente attiva, con nuovi messaggi di autenticazione scritti su di essa.
• auth.log.1 - Il file più recente che è stato messo fuori servizio a rotazione. È mantenuto in formato non compresso per semplificare il suo rapido richiamo all'azione in caso di necessità.
• auth.log.2.gz - Una raccolta precedente (come puoi vedere dall'estensione del file .gz nell'elenco seguente) che è stata compressa per risparmiare spazio.

Dopo sette giorni, quando arriva la prossima data di rotazione, auth.log.2.gz verrà rinominato auth.log.3.gz, auth.log.1 verrà compresso e rinominato auth.log.2.gz, auth.log diventerà auth.log.1 e verrà creato un nuovo file a cui verrà assegnato il nome auth.log.

Il ciclo di rotazione del registro predefinito è controllato nel file /etc/logrotate.conf. I valori illustrati in questo elenco ruotano i file dopo una singola settimana attiva ed eliminano i vecchi file dopo quattro settimane.

# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# packages drop log rotation information into this directory
include /etc/logrotate.

La directory /etc/logrotate.d/ contiene anche file di configurazione personalizzati per la gestione della rotazione dei log di singoli servizi o applicazioni. Elencando il contenuto di quella directory, vedrai questi file di configurazione:

$ ls /etc/logrotate.d/
apache2 apt dpkg mysql-server
rsyslog
samba
unattended-upgrade

Puoi visualizzare i loro contenuti per vedere che tipo di configurazione hanno sulla rotazione dei log.

💡Molti amministratori scelgono di reindirizzare le voci di registro a server di registro remoti appositamente creati, dove i dati possono ricevere tutta l'attenzione specializzata che meritano. Ciò può liberare i server delle applicazioni per le loro attività immediate e consolidare i dati di registro in un'unica posizione centrale facilmente accessibile.

Come leggere i file syslog

Sai che hai di meglio da fare con il tuo tempo che leggere milioni di righe di voci di registro.

L'uso del gatto dovrebbe essere evitato del tutto qui. Scaricherà semplicemente migliaia di righe sul tuo schermo.

Suggerisco di usare grep per filtrare il testo attraverso i file.

L'uso del comando tail -f consente di leggere il file di registro corrente in tempo reale. Puoi combinarlo con grep per filtrare il testo desiderato.

In alcuni casi, potrebbe essere necessario accedere ai vecchi registri compressi. Puoi sempre estrarre prima il file e quindi utilizzare grep, less e altri comandi per leggerne il contenuto, tuttavia esiste un'opzione migliore. Esistono comandi z come zcat, zless ecc. che ti consentono di lavorare sui file compressi senza estrarli esplicitamente.

Un esempio pratico di analisi dei log

Ecco un esempio ovvio che cercherà nel file auth.log la prova dei tentativi di accesso non riusciti. La ricerca della parola fallimento sarà
restituisce qualsiasi riga contenente la frase autenticazione fallita.

Controllare questo di tanto in tanto può aiutarti a individuare i tentativi di compromissione di un account indovinando la password corretta. Chiunque può sbagliare una password una o due volte, ma troppi tentativi falliti dovrebbero renderti sospettoso:

$ cat /var/log/auth.log | grep 'Authentication failure'
Sep 6 09:22:21 workstation su[21153]: pam_authenticate: Authentication failure

Se sei il tipo di amministratore che non commette mai errori, allora questa ricerca potrebbe risultare vuota. Puoi garantirti almeno un risultato generando manualmente una voce di registro utilizzando un programma chiamato logger. Provalo facendo qualcosa del genere:

logger "Authentication failure"

Potresti anche pre-seminare un errore reale accedendo a un account utente e inserendo la password errata.

Come puoi vedere, grep ha fatto il lavoro per te, ma tutto ciò che puoi vedere dai risultati è che si è verificato un errore di autenticazione. Non sarebbe utile sapere di chi è stato coinvolto l'account? Puoi espandere i risultati grep restituiti dicendogli di includere le righe immediatamente prima e dopo la partita.

Questo esempio stampa la corrispondenza insieme alle linee che la circondano. Ti dice che qualcuno che utilizzava l'account david ha provato senza successo a usare su (cambia utente) per accedere all'account di studio:

$ cat /var/log/auth.log | grep -C1 failure
Sep 6 09:22:19 workstation su[21153]: pam_unix(su:auth): authentication
failure; logname= uid=1000 euid=0 tty=/dev/pts/4 ruser=david rhost=
user=studio
Sep 6 09:22:21 workstation su[21153]: pam_authenticate:
Authentication failure
Sep 6 09:22:21 workstation su[21153]: FAILED su for studio by david

E poi?

Conoscere le basi è una cosa e applicare le conoscenze è una cosa diversa. Tuttavia, la conoscenza dei fondamenti aiuta in varie situazioni.

Ora che conosci gli elementi essenziali dei syslog in Linux, potresti divertirti un po' mentre gestisci i log.

Questo articolo è un estratto dal libro Linux in Action di David Clinton. È pubblicato da Manning Publication e puoi ottenere uno sconto del 30% su qualsiasi libro di Manning utilizzando il codice nlitsfoss22 al momento del pagamento.

Linux in Action Book

Divertiti ad imparare Linux.