Soluzione Open source per la gestione dei LOG |
  
|
Soluzione Open source per la gestione dei LOG |
|
Soluzione open source per gestione dei log
Premesse burocratiche e considerazioni tecniche generali
Secondo la legge, l’amministratore di sistema è la figura professionale finalizzata alla gestione e alla manutenzione di un sistema informatico o di sue componenti. Ai fini del provvedimento vengono considerati tali gli amministratori di database, gli amministratori di reti e di apparati di sicurezza e gli amministratori di sistemi software complessi.
La registrazione degli accessi al sistema informatico da parte degli amministratori di sistema devono essere conservate almeno 6 mesi e devono avere caratteristiche di completezza, inalterabilità e possibilità di verifica della loro integrità adeguate al raggiungimento dello scopo di
verifica per cui sono richieste.
Contenuto Access Log: devono includere account utilizzato, data e ora dell'evento (timestamp), descrizione dell'evento (sistema di elaborazione o software utilizzato, se si tratti di un evento di log-in, di log-out, ecc.). Non occorre tenere traccia delle attività interattive.
Da quanto richiesto dalla legge, per garantire integrità, è necessario garantire sicurezza in tutto il data path del sistema, non solo nel layer di trasporto o in quello di memorizzazione. La raccolta deve perciò avvenire necessariamente in real time (tramite syscall, handles, modifiche di bassissimo livello). Il protocollo di trasporto dovrebbe anch'esso essere affidabile (idealmente con controllo di sequenza anche a livello applicativo; TCP non lo ha) e sicuro (autenticazione e validazione del mittente).
L'amministratore di sistema ha, per definizione, il controllo completo sui sistemi amministrati; è perciò pressoché impossibile essere certi di poter controllare tutte le sue attività.
In ogni caso, come minimo, il sistema che si vuole costruire per la conservazione dei log deve/dovrebbe essere al di fuori di qualsiasi possibilità d'intervento da parte degli amministratori.
In ogni caso, come è logico che sia, se non mi posso fidare del mio amministratore di sistema, i problemi lato sicurezza applicativa sono bel maggiori del soddisfare i requisiti richiesti dal garante.
Gestione utenze amministrative
Se gli amministratori di sistema sono più di uno, è bene innanzitutto notare che le operazioni di amministrazione non possono essere effettuate tutte tramite il generico utente Administrator o root, ma devono poter essere effettuate dagli utenti appositamente designati e tracciati.
Analogamente, anche per l'accesso ai database bisognerebbe istituire regole ben precise, con credenziali d'accesso per manutenzione diverse da quelle impiegate in esercizio.
Lato linux, dunque, in presenza di più amministratori l’account root non può più essere impiegato da più persone, quindi si devono necessariamente usare gli super users da assegnare a tutti gli amministratori di sistema.
La gestione è fortunatamente semplice; creato un generico gruppo “amministratori”, basta fare
useradd -G amministratori -m -s /bin/bash nomeamministratore
passwd nomeamministratore
Nel file /etc/ssh/sshd_config si aggiunge
AllowUsers nomeamministratore
E poi, tramite visudo, si crea la semplicissima policy:
%amministratori ALL=(ALL) ALL
In questo modo gli amministratori dovranno loggarsi con il loro account ed usare il comando sudo per scalare i privilegi.
Fatto questo è possibile modificare la password di root e “metterla in cassaforte” senza la necessità di comunicarla agli amministratori, che non dovranno mai né impiegarla né conoscerla.
Analogamente, su sistemi Windows è necessario prevedere l’impiego di utenti personali per i vari amministratori di sistema ed inibire l’utilizzo dell’utente “Administrator” per le normali operazioni amministrative (ovvero, cambiargli la password predefinita e non comunicarla agli amministratori).
Il log degli accessi amministrativi va registrato non solo per i server ma anche per i sistemi client se su queste macchine si gestiscono dati personali. Per fare questo le macchine client è bene che abbiamo Windows in versione Professional (nb: bisognerebbe vedere se il tool Snare di cui parleremo in seguito funziona anche sulle versioni Home… va provato, non trovo informazioni in merito ma non credo giacché è presumibile che poggi sullo stesso layer del gestore eventi).
Centralizzazione automatica dei log Linux e Windows
Il nostro obiettivo è avere una macchina dedicata (virtuale o fisica) che abbia funzionalità di logserver, in grado di servire sia sistemi Windows che sistemi Linux.
Il progetto si basa sui seguenti componenti:
-il demone rsyslogd per i sistemi Linux, ove possibile;
-il demone syslogd per i sistemi Linux vecchissimi che non supportano rsyslogd;
-il tool Snare per Sistemi Windows; è un demone rsyslogd-like sviluppato per i sistemi MS.
-il demone stunnel per creare, se lo si desidera, un tunnel protetto verso il logserver.
NB: Quis custodiet ipsos custodes? Come misura ulteriore, la macchina log server può non essere resa accessibile agli amministratori di sistema, ma solo ad esempio al titolare del trattamento dei dati.
Gestione log su Linux
Il risultato da raggiungere è costruire una gestione dei log centrale basata sul seguente schema logico: Logclient –> Demone di logging locale à demone di logging remoto à archivio log centralizzato sul logserver.
In particolare, per i sistemi Unix, i processi utenti scrivono su /dev/log, mentre le routine del kernel su /dev/klog; tramite rsyslogd (o anche il più vecchio syslogd, con qualche limite) è possibile reindirizzare i log (o parte di essi tramite un filtro con template) e salvarli in locale o inviarlo via rete ad una terza parte.
Partiamo dal più vecchio tool Syslog; Syslogd lavora in remoto con UPD alla porta 514; ha un funzionamento di tipo best effort. Non è in grado di cifrare i dati, ha un sistema di filtering scarsissimo e non bufferizza.
Il demone syslogd riceve i messaggi relativi agli eventi e confronta gli stessi con quanto presente
in /etc/syslog.conf; ad esempio, una regola elementare è
mail.info /var/log/maillog
mail.* /var/log/verbosemaillog
*.* | /var/log/useless.log
kern.debug root
*.*; authpriv.none /myProgram
Local0.* @192.168.0.1
Di default syslogd lavora solo in locale; per abilitarlo a lavorare in remoto occorre passargli uno switch (SYSLOGD_OPTIONS="-r -m 0" → /etc/sysconfig/syslog)
Per sopperire alle mancanze di syslogd nel 2004 è stato sviluppato rsyslogd come estensione di syslogd; rsyslogd supporta i template, i formati, i filtri, supporta TCP, supporta RELP, è in grado di bufferizzare e lavorare in modalità asincrona (posticipare invio dei log se la macchina è carica di lavoro); rsyslogd in particolare può lavorare in parallelo a stunnel per gestire la RELP.
Per la creazione di un sistema centralizzato di gestione dei log (sia per Linux che per Windows) occorre creare una macchina (Linux) che faccia le funzioni di logserver. Su questa macchina e su tutte gli altri server linux da controllare (che chiameremo logclient) occorre installare rsyslogd e, se non risolto automaticamente come dipendenza, rsyslogd-relp; rsyslog in realtà ha già da tempo preso il posto di syslog nelle distribuzioni moderne, ma è comunque un pacchetto disponibile anche per le più vecchie.
Configurazione rsyslogd lato client
Installato rsyslogd sui client (se non presente), occorre modificare il file /etc/rsyslog.conf inserendo quanto segue nella sezione MODULES
# abilitare il supporto per RELP, UNIX socket e klog
$ModLoad omrelp
$ModLoad imuxsock
$ModLoad imklog
E quanto segue nella sezione RULES
# inviamo i soli log che ci interessano al logserver sulla porta (TCP) 2514
auth.*;authpriv.*;local1.* :omrelp:IPDELSERVERLOG:2514;RSYSLOG_ForwardFormat
Sulle eventuali macchine legaci che non supportassero rsyslogd prevederemo l’invio dei log senza RELP tramite UPD alla porta 514 in modalità best effort; non è purtroppo possibile fare di meglio.
Per queste macchine, sul file /etc/ssyslog.conf bisogna modificare la riga
auth, authpriv.* /var/log/auth.log e farla diventare
auth, authpriv.* @IPDELLOGSERVER
Configurazione rsyslogd lato logserver
Sul log server nel file /etc/sysconfig/rsyslog è bene sostituire SYSLOGD_OPTIONS=”-m 0″ con SYSLOGD_OPTIONS=”-m 0 -r” (è il flag abilitativo alle connessioni remote; per molte distribuzioni è facoltativo e il flag –r viene aggiunto in automatico in caso di server di destinazione non localhost nei file rsyslogd.conf e syslogd.conf).
Il file /etc/rsyslogd.conf occorre abilitare l’UPD server sulla 514 e abilitare l’imuxsock e l’imrelp (sui client, giustamente, si avvia l’omrelp in output):
$ModLoad imudp
$UDPServerRun 514
$ModLoad imrelp
$InputRELPServerRun 9999
$ModLoad imuxsock
$ModLoad imklog
Nel file /etc/rsyslog.conf si può creare un template per organizzare in maniera comoda i log per mese/giorno/host di origine:
$template DynAuth, “/var/log/REGISTRAZIONI/%$MONTH%/%$DAY%/%FROMHOST%.log”
local1.*,user.*,auth.*,authpriv.*,kern.* ?DynAuth
$EscapeControlCharactersOnReceive off
%msg:::space-cc%
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
local3.* /var/log/varie.log
Configurazione lato macchine Windows
Sulle macchine Windows, si può impiegare per prelevare i log un tool chiamato Snare Agent for Windows; è un pacchetto open source che installa un servizio per il log degli eventi su windows ed è amministrabile tramite una pagina web. E’ possibile anche scegliere se permettere o meno l’accesso remoto alla pagina di configurazione del servizio, che si fa via browser su localhost:6161. Utente e password di default sono snare/snare.
La configurazione da impostare per avere il log remoto è sulla pagina network. Basta impostare Destination Snare Server address con l’indirizzo IP del server di log e come destination port la 514. Attivare Enable Syslog Header e selezionare come syslog facility auth, con livello notice.
In questo modo, in /var/log/auth.log verranno registrati login, logout ed errori di login delle macchine configurate.
Gli eventi vengono identificati tramite un ID Event che è 528 per il login,538 per il logout; la variabile “Type” ha valore 2 per accesso locale e valore 3 per accesso effettuato via rete.
Inalterabilità dei log
La non alterabilità è la parte più complessa, dato che perlomeno teoricamente qualsiasi algoritmo crittografico può essere violato; la garanzia di non modificabilità in questo senso non è MAI ottenibile.
Abbiamo due termini da considerare:
-Per cercare di “validare” i log raccolti e proteggerli da modifiche, può essere sufficiente l’idea di fare partire, ogni X ore, sul logserver, un cron che crei un md5 di tutti i file di log, in modo da poter verificare, a posteriori, un tentativo di illegittima modifica dei file di log.
-Per prevenire la modificabilità dei log mentre questi vengono prelevati dai singoli sistemi, occorre impiegare un tunnel di invio cifrato dei log via stunnel, possibile solo per client linux con rsyslogd. Notare che questa strada non mi garantisce l’inalterabilità dei log quando sono sul logserver (che, come detto, è improponibile); stiamo parlando di una opzione integrativa al punto precedente.
Validazione con MD5
Per la validazione, posso creare uno shell script semplicissimo di calcolo degli hash da mettere in /etc/cron.daily/ (o dove meglio credo)
#!/bin/bash
TMP=`/bin/date –date=’1 days ago’ +%m/%d`
FILE_NAME=”MD5-`/bin/date –date=’1 days ago’ +%m-%d`.md5″
DEST_DIR01=”/var/log/REGISTRAZIONI”
DEST_DIR=”$DEST_DIR01/$TMP/”
MD5_DIR=”/var/log/REGISTRAZIONI/HASH/”
cd $MD5_DIR
find $DEST_DIR -type f -exec md5sum {} \; > $FILE_NAME
A questo punto posso far creare un tar.gz e salvare per farne un backup con le modalità da me ritenute più consone.
Tunnel protetto per per il prelievo dei log ^_^
Il punto due si basa sulla creazione di un tunnel locale su client e server tra rsyslog e stunnel; lo schema di comunicazione da creare è questo:
- Il logclient via rsyslog fa il send dei dati (a 127.0.0.1 su 60514)
- stunnel sullo stesso client accetta la richiesta locale e richiede la connessione al logserver via stunnel alla porta 60000
- il server accetta la richiesta dello stunnell del client e via rete si trasferiscono i dati
- i dati vengono passati a rsyslog (127:0.0.1 su 60001).
Setup stunnel sui singoli client
Bisogna installare stunnel, quindi: editare /etc/default/stunnel4 per farlo partire automaticamente tramite il parametro ENABLED=1
Bisogna editare il file /etc/stunnel/stunnel.conf nel seguente modo:
- commentare la riga cert = xxxxx
- rimuovere il commento per client = yes
- commentare le sezioni [pop3s], [ssmtp], [imaps]
- aggiungere le seguenti informazioni:
[rsyslog]
accept = 127.0.0.1:60514
connect = IPDELLOGSERVER:60000
Fare quindi ripartire il servizio: /etc/init.d/stunnel4 restart
Test: verificare che netstat -aln restituisca 127.0.0.1:60514.
Setup stunnel sul logserver
Installare stunnel e editare /etc/default/stunnel4 per far partire automaticamente il servizio col falg
ENABLED=1
Editare il file etc/stunnel/stunnel.conf nel seguente modo:
- commentare le sezioni [pop3s] [ssmtp] e [imaps]
- cambiare cert=/etc/stunnel/mail.pem in cert=/etc/stunnel/stunnel.pem
- aggiungere la seguente sezione:
[ssyslog]
accept = 60000
connect = 127.0.0.1:60001
Dobbiamo ora creare il file /etc/stunnel/stunnel.pem tramite il comando
openssl req -new -x509 -days 365 -nodes -out stunnel.pem -keyout /etc/stunnel/stunnel.pem
Restartare stunnel e verificare che netstat -aln restituisca 0.0.0.0:60001 e 0.0.0.0:60000
Configurare relp per stunnel sui client
Occorre installare rsyslog e modificare il file /etc/rsyslog.conf aggiungendo quanto segue alla sezione MODULES:
$ModLoad omrelp
In /etc/rsyslog.conf aggiungere alla sezione “RULES":
auth.*;authpriv.*;local1.* :omrelp:127.0.0.1:60514
e restartare rsyslog.
Abilitare relp per stunnel sul logserver
Modificare /etc/rsyslog.conf e aggiungere nella sezione "MODULES" :
$ModLoad imrelp.so
$InputRELPServerRun 60001
La sezione RULES di /etc/rsyslog.conf è la stessa vista in precedenza per il trasferimento dati via tcp senza stunnel.
Restartare rsyslog /etc/init.d/rsyslog restart
Gestione log di servizi aggiuntivi aggiuntivi
Abilitare il logging su Oracle 9i
mkdir /var/log/oracle/
chown -R oracle:dba /var/log/oracle/
SHOW PARAMETER audit
ALTER SYSTEM SET audit_trail=OS SCOPE=SPFILE;
ALTER SYSTEM SET audit_sys_operations=TRUE SCOPE=SPFILE;
ALTER SYSTEM SET audit_file_dest=”/var/log/oracle” SCOPE=SPFILE;
AUDIT SESSION;
SHUTDOWN IMMEDIATE
startup
Occorre poi creare un cron sul logserver che filtra solo i login/logout e prelevi i risultati; non è possibile inviare i log a un remote syslog.
Abilitare il logging su Postgres
Bisogna modificare /usr/local/pgsql/data/postgresql.conf come segue:
log_destination = ‘syslog’
syslog_facility = ‘LOCAL1′
syslog_ident = ‘postgres’
log_connections = true
log_disconnections = true
log_duration = true
log_hostname = true
Abilitare il logging su MySql
Dato che mysql non supporta la scrittura di log su syslog si può risolvere nel seguente modo:
nel file /etc/my.cnf
nella sezione [mysqld] aggiungere
log=/var/log/mysql.log
Poi lanciare all’avvio il seguente comando:
tail -f /var/log/mysql.log | egrep –line-buffered ‘Connect|Quit’ | logger -p LOCAL1.info -t mysql &
e lo si salva nell’ rc.local e lo si mette anche nella sezione postrotate del logrotate in
/etc/logrotate.d/mysql-log-rotate
Abilitare il logging su Exchange
Per abilitare il logging sel mailserver:
Gestore sistema Exchange à Gruppi amministrativi à <nome> à server à NomeServer à tasto dx sul server à registrazione Diagnostica à MSExchangeIS à private o cassetta postale à Accessi = minima; Controllo accessi = minima (oppure logons=minima e access control = minima)
Poi su Snare: Creo un nuovo oggetto: à Identify the high level event = Any event(s) àEvent ID Search Term = 1009,1016,1013,1029 à General Search Term = * àSelect the User Match Type = Include à User Search Term = *admin* à Identify the event types to be captured = Success Audit + Failure Audit à Identify the event logs = Security + Application àSelect the Alert Level = Critical