Amministratori di sistema: un sistema di log open source

Domani entra in vigore il famigerato decreto sugli amministratori di sistema.

Questa è una soluzione che abbiamo sviluppato e che proponiamo ai nostri clienti per quanto riguarda la parte tecnica, gestione dei log degli accessi degli amministratori di sistema.

Nel pieno rispetto dell’open source presentiamo una soluzione a basso costo utilizzando sistemi liberamente scaricabili da internet.

Sistemi per la gestione dei log ne esistono di tutti i tipi e per tutte le tasche ma, leggendo le caratteristiche di molti a pagamento… abbiamo subdorato che molto spesso sono dei pc embedded con programmi open source venduti a svariati migliaia (se non decine di migliaia) di euro. Vediamo come fare utilizzando la rete.

Prendimao un pc con una buona dotazione di spazio disco (e poi vedremo perchè) e installiamoci una distribuzione open source linux (noi lavoriamo con ubuntu… ma il discorso si puo’ fare con qualsiasi altra distribuzione avendo l’accortezza di utilizzare i comandi adeguati).

A questo punto montiamoci un server MySql e quindi utilizziamo come log server centralizzato il sistema Syslog-ng per salvare tutti i dati sul database menzionato.

Seguendo le direttive trovate sul seguente link:  http://www.openskill.info/infobox.php?ID=1466

Innanzitutto e’ necessario  connettendosi a mysql con il comando mysql -u username -p passwhord -h 127.0.0.1 e creare il database che conterra’ i log con il comando create database db_log;.
Si presuppone che mysql sia in esecuzione sullo stesso sistema del syslog server ed in ascolto sull’indirizzo di loopback.
Una voltra create il database si suggerisce di creare un utente apposito che abbia i privilegi sullo stesso, in modo di evitare di utilizzare l’utenza di root. Anche in questo caso e’ necessario loggarsi al dbms con un mysql -u username -p password -h 127.0.0.1 ed eseguir eil seguente comando:
GRANT ALL PRIVILEGES ON db_syslog.* TO syslog_user@127.0.0.1 IDENTIFIED BY 'syslog_password'.
L’ultima operazione da eseguire sul database e’ la creazione della tabella che conterra’ i messaggi syslog salvati da syslog-ng. Tale operazione puo’ essere portata a termine con il comando mysql -u syslog_user -p syslog_password -h 127.0.0.1 < syslog_table.sql .
syslog_table.sql sara’ un file di testo contenente le istruzione per creare la tabella, e dovra’ contenere le seguenti linee:

#
# Table structure for table `logs`
#

CREATE TABLE logs (

host varchar(32) default NULL,
facility varchar(10) default NULL,
priority varchar(10) default NULL,
level varchar(10) default NULL,
tag varchar(10) default NULL,
date date default NULL,
time time default NULL,
program varchar(15) default NULL,
msg text,
seq int(10) unsigned NOT NULL auto_increment,

PRIMARY KEY (seq),

KEY host (host),
KEY seq (seq),
KEY program (program),
KEY time (time),
KEY date (date),
KEY priority (priority),
KEY facility (facility)

) TYPE=MyISAM;

Ovviamente nel caso il file syslog_table non sia nella stessa directory dalla quale viene lanciato il client mysql sara’ necessario specificare il percorso del file in questione.
Una volta predisposta la parte relativa al database, e’ stata aggiunta la seguente destinazione al file di configurazione di syslog-ng /etc/syslog-ng/syslog-ng.conf:

#file di destinazione con query sql che saranno processate dal feeder
destination file_sql {
file(“/var/log/sqllog/log_sql_$HOUR.$MIN”
template(“INSERT INTO logs (host, facility, priority, level, tag, date, time, program, msg) VALUES ( ‘$HOST’, ‘$FACILITY’, ‘$PRIORITY’, ‘$LEVEL’, ‘$TAG’, ‘$YEAR-$MONTH-$DAY’, ‘$HOUR:$MIN:$SEC’,’$PROGRAM’, ‘$MSG’ );n”)
template_escape(yes));
};

Questa direttiva fa in modo che all’interno del file /var/log/sqllog/log_sql_ORA.MINUTO vengano inserite una serie di istruzioni INSERT SQL che una volta eseguite dal client mysql andranno ad inserire i dati nella tabella logs del database db_syslog.
A meno che nel file di configurazione di syslog-ng non sia posta a yes l’opzione create_dirs sara’ necessario creare la directory /var/log/sqllog ed impostare dei permessi coerenti con le opzioni owner, group, perm, dir_owner, dir_group e dir_perm se definite nel file di configurazione di syslog-ng.
Inoltre, come si puo’ notare dall’opzione file della direttiva destination, non verra’ creato un singolo file ma diversi a seconda dell’ora e del minuto in cui verranno generati. Tale scelta si e’ resa necessaria per semplificare la creazione e l’esecuzione dello shellscript che eseguira effettivamente gli inserimenti nek database e che verra’ successivamente illustrato.

Infine, la nuova destinazione creata dovra’ essere utilizzata all’interno di una direttiva log del file /etc/syslog-ng/syslog-ng.conf perche’ qualcosa possa essere scritto all’interno del file /var/log/sqllog/log_sql_ORA.MINUTO:

#log query per il feeder
log { source(s_all); destination(file_sql); };

Con questa configurazione, pero’, nessun dato viene ancora scritto all’interno del database ma vengono solo scritte delle istruzioni INSERT nei file /var/log/sqllog/log_sql_ORA.MINUTO.
E’ quindi necessario creare uno script che prenda questi file e inserisca effettivamente i log all’interno del database, ad esempio /opt/syslg-db/feeder.sh:

#!/bin/bash
# Script adattato da process_logs di  Casey Allen Shobe

dbhost=”localhost”
dbuser=”syslog_user”
dbpass=”syslog_password”
dbname=”db_log”
datadir=”/var/log/sqllog”

while true; do
logfiles=`find $datadir -name “log_sql_[0-2][0-9].[0-5][0-9]”`
sleep 70 # This is to ensure we don’t screw up a log currently being written.
for logfile in $logfiles; do
cat $logfile | mysql –user=$dbuser –password=$dbpass $dbname
if [ $? -ne 0 ]; then
echo “[ERRORE] Problema nel processare il file $logfile!!!” >> $datadir”/feeder_log.log”
#exit 1 #Comment out this line if you want the script to
else
echo “[OK] $logfile inserito nel db in data `date –rfc-3339=seconds`” >> $datadir”/feeder_log.log”
rm -f $logfile
fi
done
done

Nella parte iniziale dello script vengono definite alcune variabili d’ambiente che indicano i parametri da utilizzare per la connessione al database e la directory dove si trovano i files scritti da syslog-ng contenenti le istruzioni inserti da eseguire.
Un aspetto importante dello script e’ l’istruzione sleep 70 eseguita all’interno del ciclo while dopo avere settato la variabile contenente i nomi dei file da processare durante l’iterazione corrente. Quando eseguita essa sospende l’esecuzione dello script per 70 secondi, in modo da impedire che possa essere processato un file in corso di scrittura da parte di syslog-ng.
Poiche’ la destination definita nel file di configurazione di syslog-ng, prevede la creazione di un nuovo file di log ogni minuto (grazie all’utilizzo della macro $MIN), con una sleep di 70 secondi si avra’ la sicurezza che i files definiti nella variabile logfiles non siano piu’ oggetto di scrittura, essendo trascorsi almeno 60 secondi dalla loro creazione.
Per ognuno di questi file, infine, vengono eseguite le istruzioni INSERT in essi contenute passandole in input al client mysql tramite la linea cat $logfile | mysql --user=$dbuser --password=$dbpass $dbname.
Una volta processato, il file viene rimosso tramite il comando rm -f. Lo script verifica inoltre l’exit code del comando mysql ed in base ad esso scrive l’esito del processing del file in /var/log/sqllog. Questa operazione puo’ anche essere considerata superflua ed evitata semplicemente commentando le due istruzioni echo all’interno del ciclo for.
Infine, per automatizzare l’utilizzo dello script feeder.sh e’ possibile modificare lo script /etc/syslog-ng/syslog-ng in modo da avviare e terminare automaticamente feeder.sh insieme al syslog server:

#!/bin/sh
#
[…]

start() {
echo -n $”Starting $prog: ”
daemon $exec $SYSLOGNG_OPTIONS
retval=$?
echo
[ $retval -eq 0 ] && touch $lockfile
echo “Starting Feeder”
/opt/syslg-db/feeder.sh &
return $retval
}

stop() {
echo “Stopping Feeder”
killall feeder.sh
echo -n $”Stopping $prog: ”
killproc $prog
retval=$?
echo
[ $retval -eq 0 ] && rm -f $lockfile
return $retval
}

[…]

Bene a questo punto il server è a posto, ricordandosi di abilitare la ricezione dei log remoti modificando una riga su /etc/syslog-ng/syslog-ng.conf . La riga in questione comincia con #udp(). Cancellate il carattere #, salvate riavviate il server syslog- Bene il sistema è quasi pronto.

Passiamo ai clients.

Se i client sono linux, nessun problema, installate su tutti il demone syslog-ng e modificatene il contenuto aggiungendo le seguenti righe:

destination d_loghost  { udp(“ip_server_log”);  };

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

Riavviate sui client il demone syslog-ng e il server comincerà a ricevere i log.

Passiamo ai clienti Windows (per client, intendo server windows che manderanno i log sul server di log centralizzato)

Per windows ho testato  Snare Agent per windows, un pacchetto open source che installa un servizio per il log degli eventi su windows ed è amministrabile tramite una pagina web. L’installazione si limita al solito doppio click sull’eseguibile, all’impostazione della password ed alla scelta se permettere o meno l’accesso remoto alla pagina di configurazione del servizio. Per effettuare la configurazione è sufficiente puntare il browser su localhost:6161. Utente e password di default sono snare/snare, da cambiare immediatamente.

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  514. Attivare Enable Syslog  Header e selezionare come syslog facility auth, con livello notice.

Stanchi? un attimo di pazienza tra un po’ è finito.

A questo punto abbiamo tutti i nostri log su un server mysql. La normativa ci impone di salvarli su supporti non modificabili (cd o dvd in pratica).

Lo risolviamo in questo modo:

Scriviamo un piccolo script che ad una certa ora (impostata con cron) viene eseguito per estrarre i dati dal database e scriverli in un file che poi recupereremo per trasferirlo in un cd  e/o DVD.

lo script è il seguente:

#!/bin/bash
dbhost=”localhost”
dbuser=”syslog_user”
dbpass=”syslog_password”
dbname=”db_log”
filebackup=backup-log-$(date +%d-%m-%Y –date=”yesterday”)
/usr/bin/mysql –user=$dbuser –password=$dbpass $dbname < /opt/syslg-db/query.sql > /home/log/$filebackup.txt
gzip /home/log/$filebackup.txt

il contenuto del file sql query.sql è questo:

select * from logs where date=(select curdate() – interval 1 day);

Per recuperare il tutto abbiamo utilizzato il servizio ftp (il server  non ha monitor e/o tastiera). Installiamo il demone proftpd, lo configuriamo e creiamo un utente log. A questo punto, a tempi prefissati, ci recuperiamo i files da scrivere sui CD e/o DVD

Alcune note di prestazione: da un nostro cliente con una decina di server e con circa 100 client con tale sistema in meno di cinque giorni abbiamo un db con oltre 2 milioni di righe!!!!  Diventa importante quindi eseguire ogni tanto un task per cancellare dal db i record vecchi di n giorni ( a questo punto è banale l’implementazione).

Altra nota: il garante ci dice che dobbiamo loggare anche tutti gli accessi degli amministratori sui pc che trattano dati pernonali e/o sensibili.. i log diventeranno ancora di più.

Abbiamo finito, questa è una soluzione che abbiamo ritenuto soddisfacente i requisiti minimi del garante (a seguito anche di incontri con esponenti del Garante stesso). Non saraà perfetta, sarà migliorabile, ma funziona.

Attendiamo commenti

Articoli Correlati

3 thoughts on “Amministratori di sistema: un sistema di log open source

  • 16 Dicembre 2009 at 12:00
    Permalink

    Piccola precisazione sullo script di backup dei log.
    Puo’ capitare (mi è capitato oggi da un cliente) che le righe del log siano troppe. Il client mysql in questa occasione ritorna un errore out of memory.
    per risolverlo occorre aggingere sulla stringa del comando mysql il parametro –quick. Questo parametro risolve il probelam ma ne introduce un altro che è quello di caricare di più il server mysqld.

    Reply
  • 16 Luglio 2010 at 16:25
    Permalink

    La soluzione è interessante ma non ho capito come garantite l’inalterabilità del log tra il momento dell’invio da parte del client e la masterizzazione su supporto digitale(tra le altre cose chi mi garantisce che il supporto sia quello vero e non un tarocco?) Paradossalmente allora è miglio che li tenga in formato protetto sul server AD. Un altro punto riguarda dli accessi degli amministratori di DB come MSSQL e MYsql come vengono gestiti? l’NT agent che usate per windows non controlla gli accessi ai DB.

    Reply
    • 16 Luglio 2010 at 17:49
      Permalink

      Egregio sig. Maido, grazie per lo spunto di riflessione.
      Faccio una premessa.
      Il provvedimento del garante, nel nostro punto di vista, ha voluto cominciare un processo di consapevolezza della sicurezza informatica dei dati personali e/o sensibili, portandolo avanti in maniera egregia. Qualche volta pero’, e questo è il caso, dalle raccomandazioni alla pratica ci possono essere infiniti problemi tecnici. Ho assistito a numerosi convegni di esperti e di legali su tale argomento lasciando pero’ sempre il dubbio di come fare tecnicamente. Dubbio che in parte è stato dipanato dalla pubblicazione delle famose faq su tale argomento.
      Premesso cio’: con le named pipe si puo’ garantire il log anche di database mysql, Snare ha appena fatto uscire un agent per MSSql e quindi un po’ alla volta i problemi tecnici si possono superare. Poi, nessuno mi garantisce che nel processo di trasferimento dal sistema monitorato al disco ottico non ci possano essere manomissioni. Si potrebbe essere sicuri generando al momento della creazione dell’evento di log un hash del log stesso, firmandolo e marcandolo temporalmente in maniera automatica. Ma quanto costerebbe? Ci viene incontro il Garante ammettendo che si deve considerare il rapporto costi/benefici per la gestione di tale sistema. Quindi per sistemi relativamente semplici questo puo’ andare bene alla luce anche del processo di audit che si deve mettere in piedi per monitorare il lavoro dell’AdS.
      Ma i buchi potrebbero esserci anche lo stesso, ad esempio: un utente normale si crea un file excel sul suo pc (anche collegato in dominio) dove registra dati sensibili all’insaputa dell’AdS e di altri solo per agevolare il proprio lavoro (senza fini illeciti quindi in quanto magari non ha ben compreso,o nessuno gli ha spiegato bene il discorso del sistema gestione privacy), come monitoriamo questo “amministratore” di dati personali? Ma lo stesso: abbiamo in azienda vecchi sistemi basati su Access (e sono molti di più di quello che si crede), su DBIII, etc.
      Sarebbe impossibile.
      Quindi un sistema del genere non soddisfa il provvedimento originario del garante ma ragionevolmente va bene alla luce delle faq, considerando che questo è un sistema a costo zero (per chi lo sa fare). Chiamiamolo un tassello nel puzzle del sistema gestione privacy. Nulla di più, nulla di meno.

      Reply

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Time limit is exhausted. Please reload the CAPTCHA.