Configurare un server Syslog su Debian Squeeze

Da Guide@Debianizzati.Org.
Versione del 6 mar 2011 alle 20:32 di Ferdybassi (discussione | contributi) (Creata pagina con '{{Versioni compatibili|Lenny|Squeeze}} == Introduzione == In una serverfarm, ma anche in una piccola rete casalinga, può risultare molto utile riunire i log di tutte le macchine...')
(diff) ← Versione meno recente | Versione attuale (diff) | Versione più recente → (diff)
Vai alla navigazione Vai alla ricerca
Edit-clear-history.png Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.

Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.


Debian-swirl.png Versioni Compatibili

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. 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 rsyslog 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 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

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 rendere rendere leggibili a LogAnalyzer i files di log syslog. Creiamo innanzitutto un nuovo gruppo e aggiungiamo l'utente www-data a questo gruppo: 

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

Verifichiamo quindi la buona riuscita dei comandi: 

groups www-data

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

Inoltre dobbiamo configurare un nuovo database MySQL. Apriamo quindi l'interfaccia phpMyAdmin che abbiamo installato seguendo la guida apposita, facciamo login con le credenziali configurate e creiamo un nuovo database, chiamandolo loganalyzer.
Infine colleghiamoci alla pagina http://127.0.0.1/loganalyzer e completiamo il processo di installazione e configurazione di loganalyzer. Quando arriviamo alla pagina di configurazione del supporto database 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

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

create 640 root adm

Modifichiamo infine anche il file /etc/logrotate.d/rsyslog, cercando la sezione relativa a syslog e modificandola come segue: 

/var/log/syslog {
   rotate 7
   daily
   compress
   create 640 root adm
   postrotate
      /etc/init.d/rsyslog reload >/dev/null
   endscript
}

In questo modo la prossima volta che logrotate verrà eseguito i log diventeranno leggibili di default anche per il nostro webserver. Per visualizzarli 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/).
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.

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 rotati 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 filescreati;
  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

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 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

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.

Ferdybassi
Estratto da "https://guide.debianizzati.org/index.php?title=Configurare_un_server_Syslog_su_Debian_Squeeze&oldid=24383"