Old:Configurare un server Syslog su Debian

Introduzione

In una serverfarm, ma anche in una piccola rete casalinga, può risultare molto utile riunire i log di tutte le macchine in un unico posto. Si possono in questo modo applicare funzioni di analisi, ricerca e statistica che, in un unico intervento, restituiranno lo stato di tutte le macchine della rete, e sarà inoltre possibile configurare un unico strumento per inviare messaggi di alert quando lo stato di una qualsiasi delle macchine monitorate subisce un'alterazione potenzialmente pericolosa.
Debian, come è lecito aspettarsi, mette a disposizione degli ottimi strumenti per creare un server di log centralizzato.

Installazione di Syslog-ng

Il server syslog che prenderemo in considerazione sarà Syslog-NG. Pur non essendo installato di default su sistemi Debian, dove invece si può trovare syslogd, questo demone presenta diversi vantaggi:

1. Le connessioni possono essere stabilite via TCP al posto di UDP
2. I log tra host syslog-ng possono essere inviati crittati
3. I log possono essere filtrati in base alla criticità del loro contenuto
4. Il demone stesso è altamente personalizzabile

Procediamo quindi alla sua installazione:

# apt-get install syslog-ng

L'installazione rimuoverà automaticamente il demone syslog instalalto di default.

Configurazione del server Syslog

Il file di configurazione di syslog-ng è /etc/syslog-ng/syslog-ng.conf. Occorre aprirlo con un editor e decommentare la linea:

udp();

in modo da abilitare il demone a ricevere log da client remoti.
In questa configurazione è stata presa in considerazione una semplice gestione dei log (di default salvati in /var/log), senza l'implementazione di un database di archiviazione. Si tenga comunque presente che le possibilità di gestione dei log sono molto più avanzate di quelle mostrate in questa guida.

Installazione di phpLogCon

Per facilitare la lettura e la gestione dei log è uso comune ricorrere a interfacce grafiche. Su server senza l'ambiente grafico X installato potrebbe essere comodo ricorrere a un'interfaccia scritta in PHP. La scelta in questa guida è caduta su phpLogCon (http://www.phplogcon.org/), che a mio avviso rappresenta un ottimo compromesso tra funzionalità e facilità di installazione/gestione. Prima di installare phpLogCon è necessario installare e configurare un ambiente LAMP, seguendo ad esempio le indicazioni riportare in questa guida: LAMP: Linux, Apache, MySQL e PHP.
Una volta terminata la configurazione dell'ambiente LAMP si può procedere all'installazione di phpLogCon. Si scarichi innanzitutto la versione più aggiornata dal sito ufficiale: http://www.phplogcon.org/downloads.
Quindi si scompatti l'archivio appena scaricato e si copi la directory src all'interno del nostro server Apache:

# tar -xzvf phplogcon-2.3.11.tar.gz
# cd phplogcon-2.3.11
# mv src /var/www

Prima di continuare con l'installazione di phpLogCon occorre rendere rendere leggibili a phpLogCon i files di log syslog. Creiamo innanzitutto un nuovo gruppo e aggiungiamo l'utente www-data a questo gruppo:

# groupadd logadmin
# usermod -a -G logadmin www-data

Verifichiamo quindi la buona riuscita dei comandi:

groups www-data

Ora apriamo con un editor il file /etc/logrotate.conf e cerchiamo la voce create, modificandola in:

create 640 root logadmin

In questo modo la prossima volta che logrotate verrà eseguito i log diventeranno leggibili di default anche per il nostro webserver.

Configurazione di logrotate

L'utility logrotate è pensata per semplificare l'amministrazione dei files di log. Logrotate permette la rotazione automatica, la compressione, l'eliminazione e l'invio per mail dei files di log; può inoltre essere impostato per l'esecuzione giornaliera, settimanale, mensile o quando i logs raggiungono una certa dimensione predefinita.
Per installare logrotate su Debian:

# apt-get install logrotate

A titolo di esempio possiamo osservare la directory del web server Apache2 su un sistema in cui logrotate è in funzione, /var/log/apache2

root@test:~# ls -1 /var/log/apache2/
access.log
access.log.1
access.log.2.gz
access.log.3.gz
access.log.4.gz
access.log.5.gz
error.log
error.log.1
error.log.2.gz
error.log.3.gz
error.log.4.gz
error.log.5.gz

Si possono notare i files di log attualmente in uso (access.log e error.log), i files di log del giorno precedente (access.log.1 e error.log.1) e i files dei giorni ancora precedenti, che di default vengono compressi e conservati per cinque settimane. Logrotate può essere schedulato utilizzando <cron>. La directory /etc/cron.daily contiene infatti gli script che vengono eseguiti automaticamente ogni giorno dal sistema. Qui si può trovare lo script di logrotate. Ogni giorno questo script, al momento dell'esecuzione, esamina due cose:

1. il file di configurazione /etc/logrotate.conf
2. la directory di configurazione /etc/logrotate.d

Questa directory contiene i files di configurzione per i servizi installati sul server. Per esempio sul server esaminato in precedenza troveremo il file /etc/logrotate.d/apache2.
Un tipico file di configurazione di logrotate è simile a questo:

/var/log/apache2/*.log {
        weekly
        missingok
        rotate 52
        compress
        delaycompress
        notifempty
        create 640 root adm
        sharedscripts
        postrotate
                if [ -f /var/run/apache.pid ]; then
                        /etc/init.d/apache restart > /dev/null
                fi
        endscript
}

Analizziamolo nel dettaglio:

1. /var/log/apache2/*.log indica i files che vengono interessati dal processo.
2. weekly: i files sono rotati ogni settimana. Alternativa: daily
3. rotate nn: saranno conservati non più di nn files
4. compress: i files saranno compressi con gzip. Alternativa: nocompress
5. delaycompress: non comprime i log del giorno prima.
6. notifempty: non esegue la rotazione se il file è vuoto. Alternativa: ifempty
7. create xx user group: imposta proprietario, gruppo e permessi per i nuovi files creati
8. sharedscripts esegue ogni script di prerotate o postrotate su ogni file. Alternativa: nosharedscripts
9. postrotate + endscript: ogni cosa tra queste due voci viene eseguita dopo il processo di rotazione. Alternativa: prerotate

Programmi utili

Per gli amanti delle e-mail si segnala l'esistenza del pacchetto logwatch, uno script in perl che ogni giorno raccoglie gli eventi dei log e li invia all'utente root del sistema (o all'utente specificato in /etc/aliases).

# apt-get install logwatch

Se invece amate avere sott'occhio i log in un terminale, potreste trovare utile il pacchetto ccze, che altro non è che un coloratore di log molto comodo. Per installarlo:

# apt-get install ccze

Il suo utilizzo è molto semplice. Ad esempio:

# tail -f /var/log/messages | ccze

Configurazione dei client della rete

Client Linux

Per forwardare i log di una macchina linux verso un server Syslog possono essere usati sia syslog sia syslog-ng.

1 - Syslog

Si apra il file /etc/syslogd.conf. La sintassi utilizzata in questo file è molto semplice:

facility.level destination

Ad esempio:

*.* 10.58.1.1         # Tutti i log sono forwardati al server syslog 10.58.1.1
kern.alert 10.2.5.8   # Gli alert del kernel sono forwardati a 10.2.5.8

Ricordarsi di riavviare il demone affinchè prenda in considerazione le modifiche:

# etc/init.d/sysklogd restart

2 - Syslog-NG

La configurazione di un client syslog-ng è leggermente più complicata, ma offre più opzioni di personalizzazione.
Iniziamo con installare il demone sul client:

# apt-get install syslog-ng

Il file di configurazione del demone è /etc/syslog-ng/syslog-ng.conf. La sua sintassi è abbastanza semplice:

log
{
source(source_name);
filter(filter_name);
destination(destination_name);
}; 

.

Vediamo alcuni esempi.

1. Tutti i log sono inviati a un server syslog all'indirizzo 10.13.44.44:

source s_all {
internal();
unix-stream("/dev/log");
file("/proc/kmsg" log_prefix("kernel: "));
udp();
};

destination d1 { udp("10.13.44.44"); }; 

log
{
source(s_all);
destination(d1);
}; 

1. Viene utilizzato un filtro per inviare al syslog server solo i messaggi di livello alert e error generati da kernel facility. Come si può notare, per l'invio dei log viene utilizzato questa volta il protocollo TCP:

source s_all {
internal();
unix-stream("/dev/log");
file("/proc/kmsg" log_prefix("kernel: "));
udp();
};

filter filter1 { level(notice, alert, errot) and facility(kern); }; 

destination d1 { tcp("10.15.61.1" port (54321)); }; 

log
{
source(s_all);
filter(filter1);
destination(d1);
}; 

Affinchè tutto funzioni non dobbiamo dimenticarci di istruire il server syslog affinchè si ponga in ascolto anche sulla porta TCP specificata. Modifichiamo perciò il file di configurazione del server, /etc/syslog-ng/syslog-ng.conf:

source s_all {
internal();
unix-stream("/dev/log");
file("/proc/kmsg" log_prefix("kernel: "));
udp();
tcp(port(54321));
}; 

Client Windows

L'incapacità di Windows di mantenere e gestire i log in maniera semplice e unificata è notoria. Di default i log si sfogliano dall'interno del Visualizzatore Eventi (Pannello di Controllo - Strumenti di Amministrazione - Visualizzatore Eventi).
Sfortunatamente ci sono due inconvenienti:

1. i log sono salvati in formato binario, ed è quindi necessario utilizzare il Visualizzatore Eventi per leggerli
2. non esiste un tool di sistema per inviare i log a un server centralizzato

Per nostra fortuna il mondo open-source ha sviluppato diversi tool che, installati come servizi sulle macchine Windows da monitorare, si occupano di tradurre i log in un formato standard e di inviarli a un server centralizzato.
i due tool che consiglio per la loro efficienza e per la loro facilità di configurazione sono:

1. Snare Agent, scaricabile da http://www.intersectalliance.com/projects/SnareWindows/index.html
2. NTSyslog, scaricabile da http://ntsyslog.sourceforge.net/

Entrambi i tool sono facilmente configurabili. Consiglio anche di aumentare la dimensione massima dei files di log di Windows, di default troppo bassa, e di agire su Criteri di Protezione Locali per abilitare un criterio di auditing un po' più efficace di quello attivo nella configurazione di default.

Ferdybassi