Nel 2012 era abbastanza naturale spiegare il logging Linux partendo dal “file syslog”. Oggi il quadro è più interessante: sui sistemi con systemd gli eventi passano spesso da systemd-journald, mentre rsyslog continua a essere usato per routing, file tradizionali, filtri e centralizzazione remota.
I due strumenti non sono concorrenti in senso stretto. journald raccoglie e indicizza eventi con metadati strutturati; rsyslog può ricevere i classici messaggi syslog e distribuirli verso file, server remoti e altre destinazioni.
Dal file di testo al journal strutturato
Un file come /var/log/syslog è una sequenza di righe. Il journal di systemd conserva invece campi come unità systemd, PID, UID, executable, facility e priority. Questo permette interrogazioni che non dipendono soltanto da grep.
# ultimi eventi
journalctl -n 100
# segui il journal
journalctl -f
# una unità
journalctl -u ssh
journalctl -u apache2
# intervallo temporale
journalctl --since "today"
journalctl --since "-30 min"
# kernel
journalctl -k
# priorità error o più grave
journalctl -p errIl journal è persistente?
La persistenza dipende dalla configurazione. Verifichiamo dove systemd-journald sta conservando i dati:
journalctl --disk-usage
grep -E '^[# ]*Storage=' /etc/systemd/journald.confCon storage persistente i file journal si trovano normalmente sotto /var/log/journal; con storage volatile sotto /run/log/journal. Se vogliamo mantenere gli eventi attraverso i reboot, la persistenza va verificata esplicitamente.
rsyslog: perché esiste ancora
Rsyslog rimane estremamente utile perché sa filtrare, trasformare e inoltrare eventi con grande flessibilità. La configurazione principale è /etc/rsyslog.conf e le regole locali vengono normalmente aggiunte in /etc/rsyslog.d/*.conf.
systemctl status rsyslog
rsyslogd -N1rsyslogd -N1 valida la configurazione senza avviare un’altra istanza, ed è il controllo da eseguire prima di ogni restart.
imuxsock o imjournal?
Rsyslog può ricevere messaggi locali tramite il socket syslog con imuxsock oppure leggere direttamente il journal tramite imjournal. La documentazione rsyslog segnala che imjournal è più costoso e serve soprattutto quando abbiamo bisogno dei metadati strutturati del journal; per i normali messaggi syslog, imuxsock è spesso sufficiente.
# esempio minimale
module(load="imuxsock")
module(load="imklog")
action(type="omfile" file="/var/log/syslog")Facility e severity
Il modello syslog associa un messaggio a una facility, che indica grossolanamente la sorgente logica, e a una severity da debug a emerg.
| Severity | Significato |
|---|---|
| debug | diagnostica molto dettagliata |
| info | informazione normale |
| notice | evento significativo ma normale |
| warning | situazione anomala |
| err | errore |
| crit | errore critico |
| alert | intervento immediato richiesto |
| emerg | sistema inutilizzabile |
Le facility storiche includono auth, authpriv, cron, daemon, kern, mail, user e local0..local7.
Generare un evento di test
logger -p local0.notice -t sicurezza-reti "test logging $(hostname)"
journalctl -t sicurezza-reti -n 20logger è uno degli strumenti più utili per testare una pipeline di logging senza dover aspettare un errore reale.
Separare un’applicazione in un file dedicato
# /etc/rsyslog.d/30-sicurezza-reti.conf
if $programname == 'sicurezza-reti' then {
action(type="omfile" file="/var/log/sicurezza-reti.log")
stop
}rsyslogd -N1
systemctl restart rsyslog
logger -t sicurezza-reti "evento nel file dedicato"
tail -F /var/log/sicurezza-reti.logCentralizzare i log: perché
Conservare i log soltanto sul server che li genera ha un limite evidente: se la macchina viene compromessa o perde il disco, perdiamo anche parte delle prove. Un log server separato migliora retention, correlazione e resistenza alla cancellazione locale.
Client: forwarding TCP con queue
Su una rete amministrativa privata possiamo iniziare con TCP. La queue disaccoppia l’applicazione locale dal server remoto: se il collector è temporaneamente irraggiungibile, rsyslog conserva gli eventi e ritenta invece di bloccare la pipeline principale.
# /etc/rsyslog.d/90-remote.conf
action(
type="omfwd"
protocol="tcp"
target="10.0.20.50"
port="514"
queue.type="linkedList"
action.resumeRetryCount="-1"
)rsyslogd -N1
systemctl restart rsyslogTCP garantisce consegna ordinata a livello di trasporto, ma non cifra il contenuto. Se i log attraversano una rete non fidata utilizziamo TLS o un tunnel/VPN invece del TCP in chiaro.
Server: ricevere i log remoti
# /etc/rsyslog.d/10-remote-server.conf
module(load="imtcp")
template(name="RemoteFile" type="string"
string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
ruleset(name="remote") {
action(type="omfile"
dynaFile="RemoteFile"
createDirs="on")
}
input(type="imtcp"
port="514"
ruleset="remote")mkdir -p /var/log/remote
rsyslogd -N1
systemctl restart rsyslog
ss -lntp | grep ':514'Il firewall del collector deve consentire TCP/514 soltanto dai client autorizzati.
Test end-to-end
# sul client
logger -p local0.notice -t remote-test "messaggio da $(hostname)"
# sul collector
find /var/log/remote -type f -mmin -5 -print
grep -R "messaggio da" /var/log/remoteUDP 514: quando ha senso?
UDP è semplice e leggero ma non offre conferma di consegna. Può essere adatto a reti locali o apparati molto semplici, ma per eventi importanti preferiamo TCP con queue oppure protocolli affidabili e cifrati.
Log remoto non significa SIEM
Centralizzare i messaggi è soltanto il primo passo. Un SIEM aggiunge normalizzazione, correlazione, regole, ricerca e gestione degli alert. Anche senza un SIEM, però, un collector separato ci permette di confrontare timeline tra server differenti e protegge una copia degli eventi dalla macchina che stiamo investigando.
È il complemento naturale del nostro IR Stack: il watcher produce eventi locali, il logging remoto può conservarne una copia fuori dal sistema sorvegliato.
Troubleshooting
# Validazione
rsyslogd -N1
# Servizi
systemctl status systemd-journald
systemctl status rsyslog
# Porte
ss -lntup | grep 514
# Pacchetti
tcpdump -ni any port 514
# Journal rsyslog
journalctl -u rsyslog -f
