1 18/10/2026 10 min

Su Ubuntu Server 24.04 la strada più lineare per centralizzare i log è usare rsyslog. È ancora il componente più pratico quando vuoi ricevere messaggi da più host, separarli per sorgente e tenerli in file leggibili senza introdurre stack più pesanti. La scelta giusta, però, non è “installo e basta”: un server Syslog esposto in rete va trattato come un servizio di raccolta dati sensibili, quindi conviene decidere subito quali host possono inviare log, su quale porta e se il trasporto deve essere cifrato.

In pratica, il flusso corretto è: installazione del demone, apertura della porta solo dove serve, definizione delle regole di parsing e storage, verifica dei messaggi in arrivo, poi eventuale hardening con TLS. Se salti la parte di osservabilità iniziale, finisci quasi sempre a inseguire problemi di permessi, parsing o firewall con il servizio già in produzione.

Scelta del modello: UDP, TCP o TLS

Prima di toccare il sistema, scegli il comportamento atteso. Syslog su UDP 514 è semplice ma non affidabile: i pacchetti possono perdersi e non hai conferma di consegna. TCP 514 è più robusto, adatto quando vuoi una consegna più prevedibile. TCP con TLS è la scelta sensata se i log attraversano reti non fidate o se contengono dati operativi che non vuoi trasportare in chiaro.

Se il server è interno, nella stessa VLAN o in una rete amministrativa chiusa, TCP può bastare. Se invece raccogli log da host remoti, sedi diverse o ambienti cloud, il trasporto cifrato riduce il rischio di intercettazione e di spoofing. Non è un dettaglio teorico: un server syslog aperto in chiaro su Internet viene individuato in fretta e può essere inondato di traffico spazzatura.

Installazione di rsyslog su Ubuntu Server 24.04

Ubuntu 24.04 include già rsyslog nella maggior parte delle installazioni server, ma conviene verificare e aggiornare i pacchetti prima di configurare tutto. Il servizio gira sotto systemd e i file principali stanno in /etc/rsyslog.conf e in /etc/rsyslog.d/.

sudo apt update
sudo apt install rsyslog

Dopo l’installazione, controlla che il servizio sia attivo e abilitato all’avvio. Questo è il primo check utile: se il daemon non parte, ogni altra modifica è rumore.

systemctl status rsyslog --no-pager
systemctl is-enabled rsyslog

Atteso: stato active (running) e abilitazione enabled. Se vedi errori di unità o di configurazione, la causa è quasi sempre in un file di regole malformato sotto /etc/rsyslog.d/.

Abilitare la ricezione dei log in ingresso

Di default rsyslog su Ubuntu riceve i log locali ma non sempre ascolta come server remoto. Per abilitare l’ascolto, crea uno snippet dedicato invece di sporcare il file principale. È più facile da manutenere e da disattivare se qualcosa va storto.

Crea ad esempio /etc/rsyslog.d/10-server.conf con le porte di ascolto necessarie. Per una base TCP e UDP in chiaro, il contenuto minimo può essere questo:

module(load="imudp")
input(type="imudp" port="514") module(load="imtcp")
input(type="imtcp" port="514")

Dopo il salvataggio, verifica la sintassi prima del riavvio. È un controllo banale ma evita downtime inutile.

sudo rsyslogd -N1

Se il comando restituisce errori, la configurazione va corretta prima di toccare il servizio. Quando il test è pulito, ricarica rsyslog.

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager

Per capire se sta realmente ascoltando, controlla le socket aperte. Qui non devi fidarti del solo status: un servizio può essere attivo ma non avere la porta giusta configurata.

sudo ss -lntup | grep ':514'

Atteso: una riga per TCP e, se abilitato, una per UDP. Se non compare nulla, il problema è nella configurazione di input o nel riavvio del servizio.

Separare i log remoti dai log locali

Mettere tutto in /var/log/syslog funziona solo per prove rapide. In produzione conviene separare i log in file diversi per host o per sottorete, così la ricerca è più veloce e la rotazione più prevedibile. rsyslog permette di farlo con regole semplici e leggibili.

Un approccio pratico è usare template e regole basate su fromhost-ip o hostname. Per esempio, puoi salvare i log di ogni sorgente in un file dedicato sotto /var/log/remote/.

sudo mkdir -p /var/log/remote
sudo chown syslog:adm /var/log/remote
sudo chmod 2750 /var/log/remote

Poi aggiungi una regola, ad esempio in /etc/rsyslog.d/20-remote.conf:

template(name="RemoteLog" type="string" string="/var/log/remote/%fromhost-ip%.log")
*.* ?RemoteLog

Questa impostazione è semplice ma va usata con criterio. Se ricevi molti host, il numero di file cresce rapidamente. In quel caso conviene raggruppare per subnet o per ruolo, per esempio separando web, database e appliance di rete. Il punto non è creare tanti file, ma trovare i log velocemente quando serve davvero.

Dopo aver applicato la regola, riavvia rsyslog e verifica che i file vengano creati quando arriva traffico remoto. Un test veloce da un client Linux è inviarsi un messaggio con logger.

logger -n 192.0.2.10 -P 514 -T "test syslog remoto"

Sostituisci 192.0.2.10 con l’IP del tuo server Syslog. Dopo il test, controlla il file di destinazione sul server.

sudo tail -n 20 /var/log/remote/192.0.2.20.log

Se il file non compare, il problema può essere nel firewall, nella porta sbagliata, nel parsing del messaggio o nel fatto che il client stia inviando su UDP mentre il server ascolta solo TCP, o viceversa.

Firewall e superficie d’esposizione

Un server Syslog non dovrebbe mai essere esposto a chiunque. La regola corretta è aprire la porta solo agli indirizzi che devono inviare log. Se usi UFW, puoi limitare l’accesso per sorgente. Questo riduce sia il rumore sia il rischio di abuso.

sudo ufw allow from 10.0.0.0/24 to any port 514 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 514 proto udp
sudo ufw status numbered

Se il server riceve log da più reti, crea regole specifiche invece di lasciare la porta aperta su tutto il mondo. Dal punto di vista operativo, il controllo più utile è vedere l’elenco reale delle regole attive, non solo la policy teorica.

Quando usi firewalld o regole nftables dirette, il principio non cambia: la porta deve essere accessibile solo dai segmenti autorizzati. Se il server è su cloud, verifica anche eventuali security group o ACL di piattaforma, perché spesso il blocco è lì e non sul sistema operativo.

Verifica del flusso end-to-end

Per validare il servizio, non basta vedere il daemon acceso. Devi testare il percorso completo: client, rete, firewall, socket in ascolto, scrittura su disco e lettura del file. Il modo più semplice è generare un messaggio di prova da un host remoto e osservare il server in tempo reale.

sudo tail -f /var/log/syslog
sudo tail -f /var/log/remote/*.log

Se il messaggio compare in /var/log/syslog ma non nel file dedicato, la regola di routing è sbagliata. Se non compare da nessuna parte, il problema è più a monte: rete, porta, protocollo o autenticazione se hai già attivato TLS.

Un controllo utile lato server è osservare i log di rsyslog tramite journal. In caso di errore di parsing o di permessi, spesso il dettaglio compare qui prima ancora che nel file applicativo.

journalctl -u rsyslog -b --no-pager

Se devi isolare un problema di rete, un tcpdump breve e mirato è più utile di mille tentativi a vuoto. Non serve catturare tutto: basta verificare se arrivano pacchetti sulla porta corretta.

sudo tcpdump -ni any port 514

Assunzione operativa: se i pacchetti arrivano ma i file non si aggiornano, il problema è quasi sempre nella logica di rsyslog o nei permessi della directory di destinazione.

Rotazione, retention e crescita su disco

Un server Syslog serio cresce in fretta. Se raccogli log da decine di host, il collo di bottiglia non è la CPU ma lo storage. Per questo devi definire subito una politica di rotazione e retention. Su Ubuntu, logrotate è lo strumento standard per i file sotto /var/log/.

Se hai creato file personalizzati, assicurati che siano inclusi in una configurazione di rotazione. Un esempio minimale può essere questo:

/var/log/remote/*.log { daily rotate 14 compress delaycompress missingok notifempty create 0640 syslog adm
}

La verifica non si fa “a occhio”: lancia una simulazione e controlla che la configurazione non produca errori.

sudo logrotate -d /etc/logrotate.conf

Se il volume è elevato, tieni d’occhio lo spazio con una soglia minima. Un disco pieno su un server di log ti blocca sia la raccolta sia altri servizi che condividono il filesystem.

df -h
sudo du -sh /var/log/remote

TLS per Syslog: quando vale la pena farlo davvero

Se il server riceve log da ambienti non fidati, il passo successivo è TLS. Qui il punto non è solo cifrare, ma anche autenticare chi invia. Con certificati client e server riduci il rischio di messaggi falsi o di client non autorizzati che riempiono i file.

Su rsyslog il supporto TLS passa normalmente da gtls e da moduli di input TCP. La configurazione completa dipende dalla tua PKI, quindi ha senso tenere separati i certificati, le chiavi e la policy di trust. Evita di mettere chiavi private in percorsi improvvisati o con permessi troppo larghi.

Un’impostazione tipica richiede almeno certificato server, chiave privata, CA fidata e, se vuoi mutual TLS, certificati client. I file vanno protetti con permessi stretti, per esempio leggibili solo da root o dall’utente del servizio se la policy lo richiede. Qui non c’è spazio per scorciatoie: una chiave privata in chiaro con permessi errati è un problema di sicurezza immediato.

Se non hai ancora una PKI interna, la soluzione corretta è costruirla o appoggiarti a una CA già gestita dall’organizzazione. Non è il caso di inventare chiavi self-signed sparse su più host senza una catena di fiducia chiara, perché al primo rinnovo perderai tempo a inseguire errori di handshake.

Hardening operativo e manutenzione

Un server Syslog va trattato come infrastruttura critica. Le misure minime sono aggiornamenti regolari, accesso amministrativo limitato, porte esposte solo dove servono e log del servizio monitorati. Se il server riceve dati da più sistemi, conviene anche definire alert su spazio disco, errori di rsyslog e saturazione della rete.

Per la manutenzione, tieni sotto controllo i file di configurazione sotto /etc/rsyslog.d/ e versionali se possibile. Una modifica fatta senza diff, soprattutto su un server che riceve log da molti host, si trasforma facilmente in un problema di tracciabilità.

Un controllo periodico utile è verificare che il servizio sia sano dopo i reboot e che le regole di firewall siano ancora coerenti con i segmenti di rete autorizzati. In ambienti con change frequenti, questa verifica evita il classico caso in cui il syslog “sembra acceso” ma nessun client riesce più a scrivere.

Checklist finale di validazione

Prima di considerare chiusa la configurazione, fai questa verifica minima:

  1. Il servizio è attivo: systemctl status rsyslog --no-pager mostra active (running).
  2. Le porte sono in ascolto: ss -lntup | grep ':514' mostra TCP e/o UDP in base al modello scelto.
  3. Il firewall consente solo le reti autorizzate: ufw status numbered o regole equivalenti sono coerenti con il design.
  4. Un messaggio di test arriva e finisce nel file atteso sotto /var/log/remote/ o nel percorso definito dalle tue regole.
  5. La rotazione dei file è valida: logrotate -d /etc/logrotate.conf non segnala errori.

Se uno di questi punti fallisce, non andare avanti con il resto dell’implementazione. Il server Syslog è utile solo quando il flusso è prevedibile: riceve, separa, conserva e rende consultabili i log senza perdere controllo su rete e disco.

Una volta stabilizzata la base, puoi aggiungere parsing più raffinato, template per team diversi, TLS con autenticazione reciproca e integrazione con sistemi di alerting. Ma la priorità resta sempre la stessa: vedere arrivare un messaggio, sapere dove finisce e poter dimostrare che non si perde per strada.