Client Linux

Per le macchine linux le soluzioni in prima battuta erano sembrate più facili e meno problematiche in termini di installazione e congurazione rispetto alle soluzioni Windows.

Eettuando dei test sono state riscontrate delle problematiche sia per le necessità dei software per eettuare l'installazione che nelle soluzioni provate in quanto non rispettano il carattere di completezza che i log devono avere. Le soluzioni trovate sono le seguenti :

1. Snare 0.98 2. Snare 1.5.0 3. Syslog Snare 0,98

Soluzione presa in considerazione inizialmente per le stesse motivazioni del caso windows. Ipotesi scartata in fase di analisi a causa della richiesta di eettuare un patch di ogni kernel, operazione lunga e dispendiosa, che potrebbe inoltre causare problemi ad applicativi più importanti per l'azienda.

Snare 1,5,0

Descrizione : Soluzione presa in considerazione, la validità del Software è in-dubbia, inoltre questa versione, unicamente per Linux, ore più personalizzazione della precedente, richiede l'aggiornamento delle macchine al kernel 2,6,13

Beneci : Software compatibile con la versione Windows. Stessi vantaggi di windows

Problemi : Richiede l'aggiornamento di ogni macchina al kernel 2,6,13 o su-periori, operazione molto lenta e spesso pericolosa a causa dell'incompatibilità di alcuni pacchetti con versioni nuove degli stessi.

Tempi : L'aggiornamento può richiedere più giorni per ogni macchina. La successiva installazione circa un'ora per macchina(con testing)

Rischi : Creare problemi ad applicativi Core per l'azienda a causa dell'aggior-namento generale che viene richiesto, come è successo per una macchina Gen-too quando è sorta la necessità di aggiornarla a causa delle librerie obsolete che conteneva.

Syslog Scelta attuale

Soluzione più intuitiva, non richiede l'installazione di nessun software aggiun-tivo, quindi il requisito di leggerezza sarebbe ampiamente soddisfatto, sarebbe necessaria una congurazione singola e personalizzata per ogni macchina, con conseguente aggiornamento (macchina per macchina) ad ogni eventuale modica dell'elenco degli amministratori.

Beneci Attesi : Semplicità della soluzione, non necessita prodotti esterni ed è un sistema built-in di linux

Problemi : Struttura dei log raccolti completamente diversi tra Linux e Win-dows; Necessita aggiornamenti delle librerie presenti per l'autenticazione e una modica del contenuto di queste. Richiede un aggiornamento di massa oppure la creazione di un modulo apposito per le librerie PAM (la libreria utilizzata per eettuare l'autenticazione). Questo modulo va creato compatibile con tutte le versione passate, presenti e possibilmente future della libreria PAM, oppure uno dierente per ogni versione, ma non assicura la risoluzione del problema.

Difetto rilevato in fase di testing : I login vengono correttamente rilevati e raccol-ti, il logout, se la sessione è di login remoto e proviene da una macchina Windows, non viene notato dalla macchina, questo viene risolto aggiornando le librerie PAM di sistema.

Il problema è riscontrato unicamente in macchine non aggiornate da più di un anno

Tempi : Variabili, dipendentemente dai problemi che si riscontreranno in te-sting.

In prima battuta era sembrata la soluzione ideale, rapida ed eciente, ma si è rivelata incompleta.

Se tutto va liscio si congura ogni macchina in circa mezz'ora (testing compreso). Rischi : Creare problemi nell'autenticazione se si modicano le librerie PAM

7.6 SISTEMI PER LA RACCOLTA DEI LOG

7.6.4 Database

Seguono i due sistemi identicati come validi per memorizzare gli accessi eseguiti nei Database.

Trigger

Ogni DBMS ore la possibilità di implementare Trigger, in questo caso si atti-verebbero all'accesso e alla disoconnessione, un problema è stato rilevato verso i trigger di Mysql, il quale rileva correttamente i login ma non i logout, una pos-sibile soluzione era : creare una tabella nella quale salvare per mezzo dei trigger l'ora di inizio di ogni sessione e ad ogni query inserita aggiornare la data di ne sessione, questa modalità avrebbe se non altro memorizzato la data dell'ultima azione compiuta, che solitamente è equivalente alla disconnessione.

Beneci : Risoluzione del problema.

Problemi : Per ogni operazione eseguita (in mysql) si attiva il trigger che mo-dica la riga nella tabella degli accessi, a lungo andare raddoppiano le operazioni eseguite, con conseguente rallentamento delle base dati.

Una volte che il DBMS inserisce i dati nella tabella va trovato il sistema di estrarre i dati dal DB ed inoltrarli via syslog al server di raccolta.

Tempi : Dipendenti dai problemi che si riscontreranno.

Mediamente la creazione dei 4 trigger 5/6 ore per ogni DBMS, a causa della necessità di identicare gli eventi specici di ogni DBMS e risolvere eventuali problemi.

Rischi : Tabella accessibile a tutti prima dell'invio. Rallentamenti eccessivi.

Problemi con la lettura del Database e nell'invio tramite syslog. Acces Log : Scelta Attuale

Questa soluzione prevede di attivare su ogni DBMS l'archiviazione di ogni ope-razione all'interno di log, e adare a syslog-ng la la lettura di questo logles e l'invio delle righe utili al server di raccolta

Beneci : Questa soluzione al contrario dei Trigger non cera rallentamenti, salva ogni comando che riceve all'interno di un logle, coprendo, senza eettuare operazioni non necessarie, le cogenze di legge.

Problemi : Crea all'interno di ogni macchina grandi quantità di log che non ser-vono allo scopo, si può risolvere con un CronJob atto all'eliminazione giornaliera dei logles.

Tempi : Per ogni DBMS è suciente modicare il le di congurazione ag-giungendo questa opzione, e syslog-ng per l'invio al server di raccolta.

Rischi : Rallenamento di Syslog a causa del controllo continuo sugli access log di ogni DBMS.