Punti chiave
- Syslog è il protocollo standard con cui sistemi, apparati di rete e applicazioni inviano i propri messaggi di evento a un server centrale, chiamato collector, eventualmente passando per uno o più relay.
- Ogni messaggio porta una priorità calcolata come facility per 8 più severity: la facility (da 0 a 23) dice quale parte del sistema parla, la severity (da 0, Emergency, a 7, Debug) quanto è grave l'evento.
- Esistono due formati: il BSD descritto dalla RFC 3164 (2001), con un timestamp senza anno né fuso orario, e quello standard della RFC 5424 (2009), con data completa, fuso, versione e dati strutturati.
- Il trasporto storico è UDP sulla porta 514, senza conferma di consegna né cifratura; la RFC 5424 chiede a ogni software conforme di supportare TLS (porta TCP 6514, RFC 5425) e ne raccomanda l'uso.
- Un server syslog va impostato su cinque punti: trasporto cifrato con autenticazione di entrambe le parti, orologi sincronizzati, formato RFC 5424, code per non perdere messaggi e controllo delle sorgenti che smettono di scrivere.
- Syslog trasporta i log, non li analizza: è la filiera che alimenta un log management o un SIEM, che poi devono interpretare il contenuto di ciascuna sorgente.
Syslog è il protocollo standard con cui server, firewall, switch e applicazioni inviano i propri messaggi di evento a un server centrale che li raccoglie. Ogni messaggio porta una priorità, data e ora, il nome dell'host e un testo. Viaggia tradizionalmente su UDP, porta 514, ma lo standard attuale, la RFC 5424, chiede di supportare il trasporto cifrato su TLS e ne raccomanda l'uso.
Qui trovi com'è fatto un messaggio, come si legge la priorità, i due formati in circolazione, porte e protocolli e cosa controllare su un server syslog, con gli RFC dell'IETF come fonte.
Cos'è syslog
Con la parola syslog si indicano tre cose legate fra loro: il protocollo per trasmettere messaggi di evento, il formato di quei messaggi e il servizio che sui sistemi Unix e Linux li produce e li riceve. Nato sui sistemi BSD, è stato portato su molti altri sistemi operativi e apparati di rete, come ricorda la RFC 3164.
La RFC 5424 descrive tre ruoli:
- Originator: il sistema che genera il messaggio, per esempio un firewall che blocca una connessione.
- Relay: un sistema intermedio che riceve messaggi e li inoltra ad altri relay o a un collector.
- Collector: il sistema che raccoglie i messaggi per l'analisi. È quello che comunemente si chiama server syslog.
I tre ruoli possono stare sullo stesso sistema, e lo stesso messaggio può essere inviato a più collector. Un principio va tenuto a mente fin da subito: la RFC 5424 dice che il protocollo non prevede alcuna conferma di consegna. Chi invia non sa se il messaggio è arrivato.
Com'è fatto un messaggio syslog
La RFC 5424 divide il messaggio in tre parti: un'intestazione (HEADER), i dati strutturati (STRUCTURED-DATA) e il testo libero (MSG). L'intestazione contiene, in quest'ordine, la priorità, la versione del protocollo, data e ora, il nome dell'host, il nome dell'applicazione, l'identificativo del processo e l'identificativo del tipo di messaggio.
Questo è uno degli esempi della RFC 5424 (sez. 6.5):
<165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %% It's time to make the do-nuts.
Si legge così: priorità 165, versione 1, generato il 24 agosto 2003 alle 5:14:15 con fuso orario a meno sette ore da UTC, dall'host 192.0.2.1, applicazione myproc, processo 8710, nessun identificativo di messaggio, nessun dato strutturato, poi il testo.
Priorità: facility e severity
Il numero fra parentesi angolari è la priorità e unisce due informazioni. La facility dice quale parte del sistema ha generato il messaggio e va da 0 a 23: 0 è il kernel, 4 e 10 sono i messaggi di sicurezza e autorizzazione, 13 è il log audit, e i valori da 16 a 23 (local0-local7) sono liberi per gli usi locali. La severity dice quanto è grave l'evento e va da 0 a 7:
- 0, Emergency: il sistema è inutilizzabile.
- 1, Alert: serve un intervento immediato.
- 2, Critical: condizioni critiche.
- 3, Error: condizioni di errore.
- 4, Warning: condizioni di avvertimento.
- 5, Notice: evento normale ma significativo.
- 6, Informational: messaggi informativi.
- 7, Debug: messaggi di debug.
La priorità si calcola moltiplicando la facility per 8 e aggiungendo la severity. Nell'esempio, 165 è facility 20 (local4) per 8, cioè 160, più severity 5 (Notice). Più il numero di severity è basso, più l'evento è grave.
I due formati: RFC 3164 e RFC 5424
Il primo è il formato BSD, descritto dalla RFC 3164 del 2001. Non è uno standard: la RFC stessa dichiara di descrivere il comportamento osservato dei software esistenti. Questo è il suo esempio (sez. 5.4):
<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8
Priorità 34 vuol dire facility 4 (sicurezza e autorizzazione) e severity 2 (Critical): un tentativo fallito di ottenere i privilegi di root. Il limite si vede nella data: ora locale, senza anno e senza fuso orario. La RFC 3164 riporta che chi archiviava i log per lunghi periodi aggiungeva l'anno a posteriori, per esempio con uno script, e che nessuno di questi rimedi risolve il problema del fuso. Il pacchetto, inoltre, non deve superare i 1024 byte.
Il secondo è il formato della RFC 5424, del 2009, che rende obsoleta la 3164. Porta un campo versione, una data completa nel formato della RFC 3339 con fuso orario e frazioni di secondo, il nome dell'applicazione e i dati strutturati: coppie nome-valore fra parentesi quadre che un programma può leggere senza interpretare il testo libero. Fra quelli previsti dalla RFC c'è timeQuality, con cui l'originator dichiara se conosce il proprio fuso e se il suo orologio è sincronizzato con una fonte esterna, per esempio via NTP.
Nella pratica i formati BSD variano molto da un sistema all'altro. L'appendice A.1 della RFC 5424 nota che l'unico elemento su cui concordano tutti è la priorità fra parentesi angolari all'inizio del messaggio.
Come viaggia: UDP, TCP e TLS
La RFC 5424 definisce il formato e lascia il trasporto ad altri documenti. Le strade sono tre.
UDP, porta 514
È il trasporto tradizionale, descritto dalla RFC 5426: un messaggio per datagramma, sulla porta UDP 514. È leggero e lo supportano quasi tutti i dispositivi, ma la RFC stessa ne elenca i limiti:
- non c'è alcun meccanismo per accorgersi che un datagramma è andato perso;
- non c'è controllo della congestione, quindi un picco di messaggi può saturare il percorso;
- i messaggi possono arrivare in un ordine diverso da quello di invio;
- il contenuto viaggia in chiaro.
Un ricevitore deve accettare almeno 480 ottetti su IPv4 e 1180 su IPv6, e dovrebbe arrivare a 2048. La RFC 5426 ammette UDP solo su reti gestite in cui il percorso è stato dimensionato per quel traffico; in tutti gli altri casi rimanda al TLS.
TCP
Syslog su TCP semplice si usa da anni, ma è cresciuto senza uno standard. La RFC 6587 del 2012 descrive come TCP è stato usato per syslog, con la categoria Historic: documenta una pratica esistente, non definisce uno standard. TCP ritrasmette i pacchetti persi, ma non cifra niente e non autentica nessuno.
TLS, porta 6514
La RFC 5424 chiede a ogni software conforme di supportare il trasporto su TLS descritto dalla RFC 5425 e raccomanda di usarlo. Usa la porta TCP 6514 e risponde a tre minacce che la RFC 5425 indica come principali:
- Masquerade: un mittente non autorizzato che invia messaggi falsi, o un ricevitore non autorizzato che si fa mandare i log.
- Modification: qualcuno sul percorso che modifica i messaggi in transito.
- Disclosure: qualcuno che legge il contenuto, che può includere dati utili a un attaccante.
Il TLS funziona davvero solo se mittente e ricevitore si autenticano a vicenda con certificati: la RFC 5425 sconsiglia le configurazioni in cui una delle due parti accetta qualsiasi certificato. Ammette anche certificati autofirmati, riconosciuti tramite la loro impronta, per chi non ha un'infrastruttura a chiave pubblica. La RFC 9662 del 2024 ha aggiornato i requisiti crittografici: TLS 1.2 resta obbligatorio, TLS 1.3 andrebbe supportato e, se presente, preferito.
Un limite resta: il TLS copre il tratto fra due nodi, non garantisce chi ha scritto il messaggio. L'identità del certificato, precisa la RFC 5425, non coincide per forza con il nome host scritto nel messaggio.
Server syslog: cosa controllare
Ricevere messaggi syslog è semplice. Quello che richiede attenzione è riceverli in modo affidabile, perché molti guasti non producono errori. Cinque punti, ricavati dalle sezioni sulla sicurezza degli stessi RFC:
- Trasporto cifrato e autenticato. TLS con autenticazione di entrambe le parti dove i dispositivi lo supportano. Dove resta UDP, la RFC 5426 suggerisce di accettare messaggi solo da indirizzi IP noti, per limitare il rischio che il server venga sommerso di messaggi.
- Orologi sincronizzati. Un log con l'ora sbagliata non si mette in relazione con gli altri. Tutte le sorgenti vanno agganciate alla stessa fonte di tempo, e conviene preferire il formato RFC 5424, che porta il fuso orario.
- Code invece di scarti. La RFC 5424 raccomanda che un relay o un originator che non riesce a spedire tenga i messaggi in coda invece di buttarli, e che, se proprio deve scartare, sacrifichi prima quelli di severity meno grave. La RFC 5426 avverte del rischio opposto: un ricevitore sommerso da messaggi poco importanti può perdere quelli gravi.
- Destinazioni verificate. La RFC 5424 riporta casi di dispositivi configurati per errore verso il relay o il collector sbagliato. Va verificato che ogni sorgente arrivi davvero al server previsto.
- Sorgenti che tacciono. Siccome syslog non conferma la consegna, un dispositivo che smette di inviare non genera nessun errore. La RFC 5424 ricorda che i messaggi possono anche essere intercettati e scartati da un attaccante per nascondere ciò che sta facendo. Un controllo che segnali le sorgenti silenziose da troppo tempo è l'unico modo per accorgersene.
Non tutte le sorgenti parlano syslog in modo nativo: per quelle servono un agente o una raccolta via API.
Syslog, log management e SIEM
Syslog trasporta i log, non li analizza. Il server syslog è il primo anello di una filiera: dopo vengono la conservazione, la ricerca e, se l'obiettivo è accorgersi di un attacco mentre è in corso, la correlazione. Dove passa il confine fra archiviare i log e usarli per il rilevamento, e cosa chiedono le regole italiane sui log, è spiegato nel confronto fra log management e SIEM.
Quando i messaggi syslog entrano in un SIEM, il lavoro difficile è nel testo libero. La priorità e l'intestazione dicono chi parla e quanto è grave, ma l'indirizzo IP, l'utente o la regola del firewall stanno nel MSG, scritto in modo diverso da ogni produttore. Per questo un SIEM ha bisogno di un parser per ciascun tipo di sorgente, ed è anche per questo che i dati strutturati della RFC 5424 sono utili quando i dispositivi li usano. Come un SIEM normalizza e correla gli eventi è descritto nella guida su cos'è un SIEM e come funziona; se stai valutando di far crescere il collector fino a uno strumento di rilevamento, le opzioni open source sono confrontate nella pagina sul SIEM open source.
In sintesi: syslog è il protocollo con cui i sistemi inviano i propri eventi a un collector. Ogni messaggio porta una priorità, data e ora, host e testo. Il formato standard è quello della RFC 5424, che sostituisce il BSD della RFC 3164. UDP sulla porta 514 è il trasporto più diffuso ma non conferma la consegna e non cifra; gli RFC raccomandano TLS sulla porta 6514 con autenticazione reciproca. Un server syslog affidabile richiede orologi sincronizzati, code al posto degli scarti e un controllo sulle sorgenti che smettono di scrivere.
Se i log li raccogli già e manca chi li guardi a ogni ora per riconoscere un attacco, trovi come lavoriamo su monitoraggio, rilevamento e risposta agli incidenti nella pagina dei servizi di cybersecurity.