4.5 Congurazione
4.5.3 Syslog
Syslog (abbreviazione di System Log) è uno standard per l'invio di messaggi di log in una rete IP. Il termine `syslog' viene utilizzato per indicare sia l'eettivo protocollo Syslog, sia per l'applicazione o la libreria che si occupa della spedizione e della ricezione dei messaggi di log.
Syslog e un protocollo di tipo client/server: il syslog sender invia un piccolo messaggio testuale (al massimo 1 KB o 1024 caratteri) al syslog receiver. Questo syslog receiver viene comunemente chiamato `syslogd', `syslog daemon' o `syslog server'.
I messaggi Syslog possono essere inviati sia via UDP sia via TCP e vengono generalmente spediti in chiaro: sebbene non faccia parte delle speciche del pro-tocollo originario, è possibile utilizzare un wrapper in grado di fornire cifratura alla connessione tramite SSL/TLS. Per fare un esempio, un'applicazione Syslog viene spesso impiegata in simbiosi con stunnel (http://www.stunnel.org/).
Syslog può quindi essere sfruttato per integrare informazioni di log provenien-ti da dierenprovenien-ti sistemi, convogliandole in un'unica repository centralizzata. La porta assegnata dalla IANA (Internet Assigned Numbers Authority) al protocollo Syslog è la 514: bisogna però prestare attenzione in quanto la porta registrata è relativa al solo protocollo UDP, mentre la 514/TCP è allocata al protocollo shell (cmd), assicurandosi comunque che la porta in questione non venga già impiega-ta dalla shell, nulla vieimpiega-ta all'isimpiega-tanza Syslog di utilizzare la porimpiega-ta 514 in TCP. La porta 601, assegnata a syslog-conn (descritto nel RFC 3195), prevede l'utilizzo di entrambi i protocolli di trasporto. Inne, la porta 6514 di TCP è associata all'estensione Syslog over TLS (standardizzato in RFC 5425).
La scelta è quindi stata quella di utilizzare Syslog-NG: un'implementazio-ne open source del protocollo Syslog, che estende le funzionalità dell'originale syslogd, con alcune aggiunte che lo hanno reso piu versatile ed adattabile.
• nuova implementazione di un protocollo standard, • compatibilità col suo predecessore, il daemon `syslogd',
• compatibilità con apparati Linux, Unix-based e molti dispositivi di rete (Sy-slog è presente nativamente nei devices prodotti da Cisco), certi applicativi Windows comunicano con questo protocollo,
• il software è open source ore una buona versatilità a livello di trasporto, permettendo di stabilire se utilizzare TCP oppure UDP (unica opzione nel caso di syslogd),
• il numero della porta è impostabile (514 è la porta di default assegnata dalla IANA per il servizio di Syslog),
• eettua un remote logging di tipo incrementale. Nel nostro caso, questa è una caratteristica molto importante: infatti, considerate le dimensioni che possono raggiungere alcuni dei nostri log (no ad alcuni GB/giorno), costruire il le di log remoto mano a mano che giungono le log entries (alcuni KB/s) è decisamente meno oneroso per la rete rispetto al trasferimento dell'intero le, operazione che rischia di sovraccaricare la rete,
• fornisce la possibilità di eettuare secure logging, adottando meccanismi di crittograa basati sul tunneling SSH oppure su SSL / TLS. Questa proprie-tà può essere ritenuta trascurabile per log che vengono trasferiti all'interno della intranet aziendale, considerata sicura, ma rappresenta invece una ca-ratteristica essenziale qualora le informazioni loggate debbano transitare attraverso la rete internet o altre reti non date,
• fornisce la possibilità di riscrivere, o di aggiungere informazioni, allo stesso header del pacchetto syslog.
Altra soluzione, che potrebbe rivelarsi molto eciente sotto l'aspetto del throu-ghput, potrebbe essere l'instaurazione di una VPN ad-hoc sicura (per esempio tramite IPsec oppure OpenVPN) a supporto di un semplice trasferimento FTP, ma per non complicarsi la vita è stato scelto Syslog. La tabella 4.2 elenca le varie fonti di log e le rispettive logging facilities:
Syslog sui server Radius
Segue, a titolo di esempio di congurazione di un'istanza di Syslog-NG, un estrat-to dal le syslog-ng.conf del server Radius di Padova WiFi, installaestrat-to su una
4.5 CONFIGURAZIONE Tabella 4.2: Log sources
Log source Logging facility Descrizione Authentication auth accessi SSH
Authentication authpriv apertura sessioni SSH Cron cron cron job eseguiti
IPTables kern pacchetti a livello 3 (IP) dhcpd local1 warning errori del demone
DHCP
Coova-Chilli local6 login e messaggi DHCP dhcpd local7 info del demone DHCP sSMTP mail errori del demone di posta
sSMTP
Squid user informazioni provenienti dal web-proxy
Syslog-NG syslog info del demone syslog
macchina Gentoo Linux. I due statement sono quelli relativi alla destinazione cui far pervenire i log, e alla eettiva regola di logging, la fonte, essendo quella di default, non è stata riportata. Interessa far notare che i log vengono trasportati sulla porta 514 (default) di TCP.
Blocco di codice 4.3
destination remote { tcp("**.**.**.**"); }; log { source(src); destination(remote); };
Al Syslog Server pervengono, attualmente, tutte le log entries gestite dal client Syslog-NG montato sul server di Padova WiFi. Le logging facilities denite lo-calmente presso il syslog client sono i valori che danno poi il nome ai le generati dall'istanza di syslog presente presso il Web Server.
Rsyslog di Monselice WiFi Anche il server Radius di Monselice WiFi è stato congurato in modo tale da inviare i propri le di log al Web Server. La macchina server di Monselice WiFi presenta alcune dierenze rispetto a quella di Padova WiFi. Innanzitutto monta un sistema operativo diverso, ossia una Linux Fedora Core. Ad ogni modo, la dierenza più importante per quanto riguarda i nostri
obiettivi, è che questo host non utilizza Syslog-NG, bensì Rsyslog. I comandi fondamentali per perseguire il nostro scopo sono stati i seguenti:
Blocco di codice 4.4
local6.* /var/log/coova.log & @@**.**.**.***
kern.warn;kern.info /var/log/iptables.log & @@**.**.**.***
Il trasferimento avviene via TCP (avendo denito '@@', mentre '@' avrebbe uti-lizzato UDP), ancora una volta sulla porta 514 di default. Vengono spedite tutte le entry relative al Coova-Chilli (associato alla logging facility local6 ) e a IPTa-bles (associato alla logging facility kern), il comando '&' indica di inviare le stesse informazioni in più destinazioni, nel nostro caso sia in remoto che su le locale.