Se volete anche voi risparmiare qualche migliaio di € , evitando l’acquisto di costose appliance che fanno più o meno la stessa cosa, questo sistema di logging centralizzato, che ho ideato un annetto fa circa, dovrebbe rispondere fedelmente alle direttive del decreto sulle “misure e accorgimenti prescritti ai titolari dei trattamenti effettuati con strumenti elettronici relativamente alle attribuzioni delle funzioni di amministratore di sistema” del 27 novembre 2008 – (G.U. n. 300 del 24 dicembre 2008).
L’aspetto fondamentale che questo sistema dovrà esaudire è cio’ che viene prescritto nel capitolo 4.5:
sulla “Registrazione degli accessi”
“Devono essere adottati sistemi idonei alla registrazione degli accessi logici (autenticazione informatica) ai sistemi di elaborazione e agli archivi elettronici da parte degli amministratori di sistema. Le registrazioni (access log) devono avere caratteristiche di completezza, inalterabilità e possibilità di verifica della loro integrità adeguate al raggiungimento dello scopo di verifica per cui sono richieste.”
Il sistema infatti si occuperà di delegare verso un unico server tutti gli accessi degli amministratori (root per macchine UNIX/LINUX e administrator su Domain controller e/o servers Windows ) della vostra rete, utilizzando un syslog centralizzato e un sistema di memorizzazione a scelta tra:
– i piu costosi devices WORM (Write Once Read Many);
– il gratuito UDF (anche lui scrivibile una sola volta come sui sistemi WORM…. anzi in realtà il 99% dei device WORM usano proprio UDF eheheh );
– ISO9660 magari incapsulandolo in una comunissima immagine ISO;
– o addirittura il performantissimo e almeno per me “nuovo” NILFS (che uso ultimamente sulle /etc dei miei servers linux) , un filesystem a snapshot continui ( http://www.nilfs.org/en/ – “NILFS is a log-structured file system supporting versioning of the entire file system and continuous snapshotting which allows users to even restore files mistakenly overwritten or destroyed just a few seconds ago.”);
Il tutto “accompagnato” magari da un bel HASH corrispondente 😉
Partiamo subito con qualche specifica:
Il sistema potrà essere composto da un normalissimo pc i386 (non servono grossi requisiti hardware) con installata una qualsiasi distribuzione linux totalmente hardenizzata..
io per ulteriore sicurezza ho utilizzato un kernel 2.6.27-10 patchato con grsecurity/pax in modo da limitare (attraverso apposite ACL) perfino le operazioni di root (quando avro’ tempo magari vi parlero’ di grsec 😀 ) e non ho lasciato, nessun servizio in ascolto (ovviamente nemmeno sshd).
Il servizio di logs centralizzato è servito dal demone syslog che riceve sulla porta 514 UDP i logs delle autenticazioni
da tutte le macchine del nostro CED (nel mio caso gli os maggiormente usati: tru64, hpux e windows).
Il file di configurazione del syslog centralizzato sarà quindi:
#
# /etc/syslog.conf
#*.emerg *
*.err /var/log/errors
kern.* /var/log/kernel
authpriv.* /var/log/auth
mail.* /var/log/mail
*.!err;mail,kern.none /var/log/messages
auth.info /var/log/SERVERSlogs/auth.info
# Log everything to vc12
# *.* /dev/vc/12# End of file
In questo post in merito alla fase della memorizzazione dei logs utilizzero’ il filesystem Iso9660 incapsulato in un immagine ISO (inalterabile nel contenuto come vuole il decreto) e sopratutto “depositata” corrispondentemente ad un HASH (ho usato SHA256).
[Piu’ avanti, in merito alla memorizzazione dei logs, se avro’ tempo magari vi descrivero’ altri metodi utilizzando per esempio UDF, WORM o sopratutto NILFS….]
Tale filesystem è stato scelto sia per la sua particolare caratteristica “WORM” ( Write Once Read Many ) sia per la sua compatibilità a sistemi operativi diversi sia ,non meno, alla possibilità di organizzare ogni 6 mesi o prima (come descrive il decreto stesso) una masterizzazione su CD/DVD..
(Io ho preferito utilizzare le immagini ISO ma potremmo perfettamente scrivere direttamente sul DVD senza passare per le ISO utilizzando il già citato UDF e considerando che per aggiungere dati ad un dvd contente altri dati possiamo usare il comando:
# growisofs -M /dev/dvd /tmp/file_da_aggiungere
😉 )
..ecco gli scripts che opportunamente inseriti in crontab si occuperanno di fare cio’ che ho descritto:
(PS: occupatevi di crearvi prima le directory 😛 )
#!/bin/bash
chattr -i -R /root/StoricoLogs
mv /var/log/SERVERSlogs/auth.info /root/StoricoLogs/complauth.info
egrep ‘(dmin|root)’ /root/StoricoLogs/complauth.info > /root/StoricoLogs/`date +%Y%h%d_%H%M`
shasum /root/StoricoLogs/`date +%Y%h%d_%H%M` > /root/StoricoLogs/hashlog`date +%Y%h%d_%H%M`
rm /root/StoricoLogs/complauth.info
chattr +i -R /root/StoricoLogs/*
/etc/rc.d/syslogd restart
questo catalogherà i logs ricevuti su syslog, li filtrerà (prenderà tutto cio’ che riguarda l’auth di utenti root e administrator) e infine creerà un HASH corrispondente allo STEP attuato, riavviando successivamente syslog..
#!/bin/bash
chattr -i /root/StoricoLogs/*
mkisofs -input-charset=utf-8 -J -l -V “`date +%Y%h%d`_Log” -o /root/IsoLogs/`date +%Y%h%d`.iso /root/StoricoLogs/
rm /root/StoricoLogs/*
rm /root/auth
Quest’altro produrrà l’ISO corrispondente allo “STEPlogs” in corso utilizzando come “etichetta” la data/orario di produzione e cancellando successivamente le tracce in modo da ricominciare con un nuovo STEP successivo.
Passiamo adesso alla configurazione dei Client da dove prelevare i logs:
ovviamente @Logserver è l’host corrispondente al nostro serverlogs (inserite la corrispondenza host->ip sul file /etc/hosts oppure nello script inserite @ip)
HPUX 11.x o Linux:
# @(#)B11.23_LR
#
# syslogd configuration file.
#
# See syslogd(1M) for information about the format of this file.
#
mail.debug /var/adm/syslog/mail.log
*.info;mail.none /var/adm/syslog/syslog.log
*.alert /dev/console
*.alert root
*.emerg *
auth.info @logserver
Tru64 4*:
#
# @(#)$RCSfile: syslog.conf,v $ $Revision: 4.1.8.1 $ (DEC) $Date: 2000/10/19 19:13:52 $
#
#
# syslogd config file
#
# facilities: kern user mail daemon auth syslog lpr binary
# priorities: emerg alert crit err warning notice info debug
kern.debug /var/adm/syslog.dated/kern.log
user.debug /var/adm/syslog.dated/user.log
mail.debug /var/adm/syslog.dated/mail.log
daemon.debug /var/adm/syslog.dated/daemon.log
auth.debug /var/adm/syslog.dated/auth.log
auth.info;auth.debug @logserver
*.info;syslog.debug /var/adm/syslog.dated/syslog.log
lpr.info /var/adm/syslog.dated/lpr.logmsgbuf.err /var/adm/crash/msgbuf.savecore
kern.debug /var/adm/messages
*.alert;kern.debug /dev/console
*.emerg *
e infine lo “zoccolo duro” ehhmmm scherzo 😛 WINDOWS:
Per windows (nel mio caso 2003 server e) dovremmo trovare un buon prodotto in grado di “tradurre”
il sistema dei logs microsoft (EVENTLOGS) per il nostro sistema (SYSLOG)..
esistono diverse possibilità, io ho optato per questa: https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys
installatelo e configuratelo seguendo queste semplicissime istruzioni http://eventlog-to-syslog.googlecode.com/files/Readme_4.1.rtf 😉
il sistema è pronto per l’uso date la passwd di root al vostro incaricato e ditegli di cambiarla:
da questo momento solo lui, sarà in grado di visualizzare/conservare (ma non modificare) i logs accedendo esclusivamente fisicamente alla console della macchina..
io ho installato una GUI minimale (lxkde) e un frontend di masterizzazione (k3b o brasero) per rendergli le operazioni piu’ semplici 😉
ciao!