Configurare un server Syslog su Debian Squeeze

Versioni Compatibili soltanto: Debian 5 "lenny" Debian 6 "squeeze"

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.

Prerequisiti

Nel corso della guida utilizzeremo la funzione del server Syslog che ci permetterà di registrare su database MySQL gli eventi di sistema; installeremo inoltre un'interfaccia web per facilitare la gestione dei log. Per queste ragioni prima di proseguire occorrerà installare sul nostro server un ambiente LAMP, seguendo ad esempio questa guida: Installare un ambiente LAMP: Linux, Apache2, SSL, MySQL, PHP5

Installazione di rsyslog

Il server syslog che prenderemo in considerazione sarà rsyslog. È il syslogd di default su sistemi Debian a partire da "Lenny", questo demone presenta diversi vantaggi:

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

Nelle versioni precedenti a "Lenny" è necessario installarlo con:

# apt-get install rsyslog

L'installazione rimuoverà automaticamente il demone syslog installato di default.
Installiamo anche il connettore per MySQL:

# aptitude install rsyslog-mysql

Durante l'installazione del pacchetto ci verranno chieste alcune cose:

• Configurare il database attraverso dbconfig-common? => Yes
• Inserire la password dell'utente root di MySQL
• Inserire una password per il nuovo utente rsyslog di MySQL

L'installer creerà automaticamente un nuovo database MySQL chiamato Syslog e un nuovo utente MySQL chiamato rsyslog che avrà pieni poteri sul database.

Configurazione del server Syslog

Il file di configurazione di rsyslog è /etc/rsyslog.conf. Per abilitare la ricezione dei log da host remoti della rete occorre aprirlo con un editor e decommentare le linee:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

Riavviamo il demone:

# /etc/init.d/rsyslog restart

e osserviamo il nostro server Syslog in ascolto sulla porta 514:

nmap -v 127.0.0.1

Starting Nmap 5.00 ( http://nmap.org ) at 2011-03-06 20:31 CET
NSE: Loaded 0 scripts for scanning.
Initiating SYN Stealth Scan at 20:31
Scanning localhost (127.0.0.1) [1000 ports]
Discovered open port 3306/tcp on 127.0.0.1
Discovered open port 111/tcp on 127.0.0.1
Discovered open port 21/tcp on 127.0.0.1
Discovered open port 443/tcp on 127.0.0.1
Discovered open port 80/tcp on 127.0.0.1
Discovered open port 25/tcp on 127.0.0.1
Discovered open port 514/tcp on 127.0.0.1
Completed SYN Stealth Scan at 20:31, 0.04s elapsed (1000 total ports)
Host localhost (127.0.0.1) is up (0.0000030s latency).
Interesting ports on localhost (127.0.0.1):
Not shown: 993 closed ports
PORT      STATE SERVICE
21/tcp    open  ftp
25/tcp    open  smtp
80/tcp    open  http
111/tcp   open  rpcbind
443/tcp   open  https
514/tcp   open  shell
3306/tcp  open  mysql

Il database MySQL Syslog creato in precedenza non ha nessun meccanismo per la cancellazione o la rotazione dei log registrati. È possibile utilizzare uno script come il seguente, da mettere nel crontab, per cancellare tutti i log più vecchi di sei mesi:

mysql -h 127.0.0.1 -uroot -pPassword Syslog -e "delete from SystemEvents where ReceivedAt < date_sub(now(), interval 6 month)"
mysql -h 127.0.0.1 -uroot -pPassword Syslog -e "optimize table SystemEvents"

Rendiamolo eseguibile e ricordiamoci di inserirlo nel crontab del server:

# chmod 700 nome/dello/script

Installazione di LogAnalyzer 3.x

Il successore di pgpLogCon si chiama Adiscon LogAnalyzer e, come il suo predecessore, è scritto in PHP ed è liberamente scaricabile dal sito del progetto: http://loganalyzer.adiscon.com/ .
La sua installazione procede essenzialmente in maniera identica a quella di phpLogCon, ma in questo paragrafo esamineremo anche l'utilizzo di un database MySQL di appoggio. Si scarichi innanzitutto la versione più aggiornata dal sito ufficiale: http://www.loganalyzer.adiscon.com/downloads.
Quindi si scompatti l'archivio appena scaricato e si copi la directory src all'interno del nostro server Apache:

# tar -xzvf loganalyzer-3.0.1.tar.gz
# cd loganalyzer-3.0.1
# mv src /var/www/
# mv /var/www/src /var/www/loganalyzer

Prima di continuare con l'installazione di LogAnalyzer occorre creare un database MySQL dove il software registrerà i propri dati di configurazione; possiamo crearlo sia tramite PHPMyAdmin sia tramite la shell mysql>. Nel corso della guida supporremo di aver creato un database con queste caratteristiche:

• Nome database: loganalyzer
• Nome utente database: loganalyzer
• Password: loganalyzerpass

Ora copiamo i due file configure.sh e secure.sh dalla directory contrib all'interno del nostro server Apache, rendiamoli eseguibili e lanciamo gli script:

# cd
# mv loganalyzer-3.0.1/contrib/configure.sh /var/www/loganalyzer
# mv loganalyzer-3.0.1/contrib/secure.sh /var/www/loganalyzer
# cd /var/www/loganalyzer
# chmod +x configure.sh secure.sh
# ./configure.sh

Infine colleghiamoci alla pagina http://127.0.0.1/loganalyzer e completiamo il processo di installazione e configurazione di loganalyzer, abilitando (Step3) un utente database e assegnandogli le credenziali che desideriamo: questa operazione si collegherà al database MySQL loganalyzer creato in precedenza per archiviare le informazioni di configurazione di LogAnalyzer.. Quando arriviamo alla pagina di configurazione dei Log (Step7) completiamo i campi come segue:

• Name of the source = Il nome del nostro Syslog Server
• Source Type = MYSQL Native
• Select View = Syslog Fields
• Table type = MonitorWare
• Database Host = localhost
• Database Name = Syslog
• Database Tablename = SystemEvents
• Database User = rsyslog
• Password = La password impostata in precedenza
• Enable Row Counting = no

Per visualizzare i log del server basterà collegarsi alla pagina http://127.0.0.1/loganalyzer.
LogAnalyzer permette di configurare più sorgenti log, nel caso volessimo tener monitorati, oltre al file syslog, anche altri file di log. Per aggiungere sorgenti log è sufficiente aprire il file di configurazione:

# nano /var/www/loganalyzer/config.php

e spostarci alla fine del file. Lì troveremo configurata la prima sorgente log (Syslog) ma potremo aggiungerne altre. Ad esempio possiamo controllare gli accessi al nostro server creando la seguente sorgente:

$CFG['DefaultSourceID'] = 'Source2';

$CFG['Sources']['Source2']['ID'] = 'Source2';
$CFG['Sources']['Source2']['Name'] = 'Auth Log Server';
$CFG['Sources']['Source2']['ViewID'] = 'AUTHLOG';
$CFG['Sources']['Source2']['SourceType'] = SOURCE_DISK;
$CFG['Sources']['Source2']['LogLineType'] = 'auth.log';
$CFG['Sources']['Source2']['DiskFile'] = '/var/log/auth.log';

Non c'è limite alle sorgenti log che possono essere configurate.

Installazione di Splunk

Un'interfaccia alternativa molto potente è Splunk (http://www.splunk.com/).

ATTENZIONE Splunk è un software proprietario

Per scaricare il pacchetto .deb che viene messo a disposizione (uno per architetture x86 e uno per architetture amd64) occorre effettuare la registrazione gratuita sul sito. Splunk non è opensource, ma è disponibile una versione Free, la cui limitazione è che può processare solo 500 MB di Log al giorno. Durante la configurazione di Splunk sarà possibile scegliere se utilizzare una versione Enterprise di prova o se utilizzare la versione Free.
Per installare Splunk, dopo aver scaricato il pacchetto .deb per la nostra architettura spostiamoci nella directory di download e diamo i comandi:

# apt-get update
# apt-get install libstdc++6
# dpkg -i splunk_package_name.deb

dove package_name corrisponde al numero di versione del pacchetto scaricato.
Per avviare Splunk per la prima volta diamo il comando:

# /opt/splunk/bin/splunk start --accept-license

(potete trovare il testo della licenza qui: /opt/splunk/license-eula.txt).
Una volta terminata l'installazione dirigiamoci all'interfaccia web di Splunk:

http://indirizzo.ip.del.server:8000

e facciamo login con le credenziali:

• user: admin
• password: changeme

Qui trovate tutta la documentazione per utilizzare al meglio questo potente software per l'analisi dei log.
Per creare uno script di avvio automatico del demone possiamo utilizzare questo metodo:

# nano /etc/init.d/splunk

con contenuto:

#!/bin/bash
### BEGIN INIT INFO
# Provides:          splunk
# Required-Start:
# Required-Stop:
# Should-Start:
# Should-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Avvio Splunk
# Description:       Avvio Splunk
### END INIT INFO

case "$1" in
start)  echo "Starting Splunk demon:"
        /opt/splunk/bin/splunk start
        ;;
stop)   echo "Stopping Splunk demon"
        /opt/splunk/bin/splunk stop
        ;;
restart) echo "Non ancora implementato"
        ;;
reload|force-reload) echo "Non ancora implementato"
        ;;
*)      echo "Usage: /etc/init.d/splunk {start|stop|restart|reload|force-reload}"
        exit 2
        ;;
esac
exit 0

Rendiamo eseguibile lo script appena creato e configuriamolo per il boot:

# chmod +x /etc/init.d/splunk
# update-rc.d splunk defaults

Configurazione di logrotate

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

# apt-get install logrotate

/etc/logrotate.conf

Attraverso il file di configurazione di logrotate è possibile definire il comportamento dell'applicazione in due contesti: a livello globale (nella prima parte del file) e a livello locale dove le regole ridefinite prevalgono su quelle globali. Per ogni file di cui si vuole effettuare la rotazione è necessario indicarne il percorso, al quale seguono tra parentesi graffe le direttive di gestione.
Tra le direttive più utili:

• Criteri di rotazione
  • daily: rotazione su base giornaliera;
  • weekly: rotazione su base settimanale;
  • monthly: rotazione su base mensile;
  • size <dimensione>: rotazione in base alla dimensione;
  • notifempty: non esegue la rotazione se il file è vuoto;
  • rotate nn: conserva i file di log per nn rotazioni;
• Compressione
  • compress: una volta archiviato il file di log, viene compresso tramite gzip;
  • compresscmd: indica il programma da utilizzare al posto di gzip;
• Gestione File
  • create <mode> <owner> <group>: immediatamente dopo la rotazione viene creato un nuovo file con il nome identico al precedente. È possibile specificare, modalità di accesso, proprietario e gruppo;
  • copy: crea una copia del file di log e non modifica l'originale che non viene mai rimosso;
  • copytruncate: utilizzata nel caso in cui non sia possibile chiudere il file di log. Viene archiviata parte del file di log mentre ne viene eseguita una copia;
  • olddir <directory>: i file di log vengono spostati nella directory indicata prima di eseguire la rotazione;
• Configurazione
  • include <file o directory>: legge il file oppure tutti i file della directory indicata ed applica le direttive incontrate all'interno di essi. È possibile trovare include /etc/logrotate.d in quanto alcuni pacchetti installano le proprie istruzioni in questa directory;
• Operazioni Pre-log e Post-log
  • postrotate endscript: tramite questo blocco di direttive è possibile eseguire delle operazioni in seguito alla rotazione;
  • prerotate endscript: tramite questo blocco di direttive è possibile eseguire delle operazioni prima che avvenga la rotazione e solo se questa avrà luogo.

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 file di log attualmente in uso (access.log e error.log), i file di log del giorno precedente (access.log.1 e error.log.1) e i file 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 file di configurazione 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 file che vengono interessati dal processo;
2. weekly: i file sono ruotati ogni settimana. Alternativa: daily;
3. rotate nn: saranno conservati non più di nn file;
4. compress: i file 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 file 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.

Se avete necessità di conservare per più tempo i log ruotati potete aumentare il valore dell'opzione rotate, oppure crearvi uno script che vi faccia il backup dei vecchi log in un'altra directory (in questo modo non rischiate che la directory /var/log/ cresca troppo in dimensione).

Programmi utili

Logwatch

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

Il file di configurazione di logwatch è /usr/share/logwatch/default.conf/logwatch.conf: Il file di configurazione generale è piuttosto chiaro e prevede alcune opzioni interessanti, che possono essere sovrascritte dalla riga di comando. Seguono le impostazioni di default, che vanno bene in molti casi:

• LogDir = /var/log Directory di default dove risiedono i log
• MailTo = root A chi vengono inviate le mail di logwatch, può essere un utente locale o un normale indirizzo email
• Print = No Se settato a Yes, l'output di logwatch viene visualizzato a schermo invece di essere inviato via mail
• # Save = /tmp/logwatch Se impostato, l'output viene salvato sul file indicato invece di essere inviato via mail
• # Archives = Yes Specifica se cercare anche nei file di log archiviati (anche gzippati) come /var/log/messages.1 o /var/log/messages.1.gz
• Range = yesterday Indica su quale periodo fare l'analisi dei log: "All" analizza tutti i log (in questo caso si consiglia di impostare "Archives = Yes", "Yesterday" si riferisce ai log del giorno prima (utile quando si crontabba un'esecuzione notturna), "Today" si riferisce alle righe di log relative al giorno corrente.
• Detail = Low Livello di dettaglio dei report. Può essere "Low", "Med", "High"
• Service = All Definisce per quali servizi verificare i log. Può essere "All" o uno o più servizi, da scrivere su più righe, come "pam_pwdb" e "ftpd-messages"
• # LogFile = messages Specifica un singolo file di log da analizzare. Se "Service = All" vengono comunque analizzati tutti i log

La modalità di utilizzo tipica è l'esecuzione in crontab del semplice comando logwatch che si basa sulle impostazioni generali nel file di configurazione. Per test o controlli straordinari si possono comunque passare alcuni argomenti alla command line:

logwatch --print --detail High --archives --range All

Stampa a video (--print) invece che inviare via mail, con il massimo dettaglio (--detail High), includendo anche i log archiviati (--archives) tutti i messaggi di ogni data (--range All)

logwatch --save logwatch.txt --range Today

Salva sul file logwatch.txt (--save logwatch.txt) l'output relativo alla giornata corrente (--range Today), usando per gli altri parametri le impostazioni definite nel file di configurazione.
Se desiderate ricevere le email di logwatch anche su un indirizzo di posta elettronico esterno al sistema da monitorare, modificate il file /etc/aliases come segue:

vostro_utente: vostro_utente indirizzo_esterno@pippo.com

Non dimenticate, alla fine delle modifiche, di lanciare il comando:

# newaliases

Logcheck

Logcheck è un piccolo tool che aiuta a focalizzare automaticamente i problemi e le violazioni alla sicurezza nei propri file di log e spedisce i risultati via e-mail.
L'installazione è semplice:

# apt-get install logcheck

Il suo file di configurazione è /etc/logcheck/logcheck.conf che dovete modificare per cambiare quantomeno l'indirizzo di posta elettronica a cui spedire le analisi dei log.

Altri programmi utili

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, error) 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.
Il tool che consiglio per efficienza e per facilità di configurazione è:

1. Snare Agent, scaricabile da http://www.intersectalliance.com/projects/SnareWindows/index.html

Consiglio anche di aumentare la dimensione massima dei file 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.

---

Guida scritta da: Ferdybassi	Debianized 20%
Estesa da:
Verificata da:
Verificare ed estendere la guida | Cos'è una guida Debianized