Soluzione Open Source per log Amministratori di Sistema
novembre 20th, 2009 Pubblicato in Open Source, Privacy, Sicurezza, TecnicaProvo a mettere nero su bianco i test effettuati per l’adeguamento al provvedimento sugli amministratori di sistema emanato dal Garante Privacy la cui scadenza è fissata al 15 dicembre 2009. Ricordo brevemente che, fra le altre cose, il provvedimento richiede la registrazione e conservazione per almeno sei mesi dei log di accesso di ogni account degli amministratori di sistema. Esistono molti sistemi a pagamento che possono fare questo, ma perché spendere se possiamo adeguare i nostri sistemi senza dover acquistare costose licenze software? Ecco dunque, dopo gli spunti di discussione pubblicati mesi fa, dove semplicemente accennavo a quali strumenti potessero essere utilizzati, una traccia operativa per creare un sistema di log centralizzato per sistemi sia Windows che Linux basato su Debian. Intendiamoci. E’ solo una traccia, magari si può desiderare di implementare ulteriori livelli di sicurezza, come ad esempio la trasmissione dei log su connessione cifrata. E’ comunque un punto di partenza e sufficiente per piccole realtà con esigenze limitate.
Ricordo a questo proposito che il provvedimento non prevede specifiche tecniche, lasciando ad ogni titolare di trattamento la scelta su come implementare quanto richiesto.
Per essere compliant alla normativa, ogni utente e quindi ogni amministratore di sistema deve avere il proprio account. Per abilitare utenti diversi ad effettuare operazioni che richiedono i poteri di root si può abilitare il comando sudo, creando un gruppo apposito (su Ubuntu esiste già, è il gruppo admin) e modificando opportunamente con visudo i diritti di root per tale gruppo. Ad esempio:
| $ sudo visudo
# User privilege specification root ALL=(ALL) ALL # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL |
Ovviamente il nome del gruppo di utenti abilitati può essere scelto liberamente. In alcuni sistemi il nome di default è wheel. Quello che resta da fare è aggiungere gli utenti al gruppo admin usando useradd se l’utente deve essere creato da zero oppure usermod se l’utente esiste già.
Su sistemi windows è necessario impedire l’utilizzo dell’accesso come amministratore per il normale uso.
E’ appena il caso di ricordare che 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.
Syslog è il demone installato di default per gestire i log di sistema . Dobbiamo quindi sostituire syslog con un software che abbia delle funzioni in più. Per fortuna su Debian 5 (lenny) rsyslog è il demone di log installato di default.Una alternativa potrebbe essere syslog-ng. Entrambi i software permettono di ricevere i log da server remoti anche via ssl e registrarli su un db come (ad esempio, ma non solo) Mysql.
Su Ubuntu, ad esempio, l’installazione si effettua con il semplce apt-get install rsyslog.
Per abilitare la ricezione dei log da remoto va modificato sul log server il file di configurazione /etc/rsyslog.conf.
Invece il file /etc/default/rsyslog va modificato solo in caso vada mantenuta la compatibilità con vecchi sistemi, altrimenti non va toccato.
Nel file /etc/rsyslog.conf del log server vanno decommentate le righe sotto riportate per mettere il demone in ascolto sulla porta 514 UDP. Attenzione, se il traffico fosse molto elevato, si rischia di perdere delle righe di log. In questo caso va usato il protocollo TCP o RELP.
| # provides UDP syslog reception
$ModLoad imudp $UDPServerRun 514 |
Fatte queste modifiche si riavvia il demone con
| /etc/init.d/rsyslogd restart |
e si verifica che sia effettivamente in ascolto sulla porta UDP 541 con
| netstat -lpu | grep rsyslogd |
che deve mostrare qualcosa di simile:
| udp 0 0 0.0.0.0:514 0.0.0.0:* 2222/rsyslogd |
Per attivare l’invio del log al rsyslog remoto su ogni macchina linux che deve essere loggata va modificato il file /etc/rsyslog.conf modificando la riga
| auth, authpriv.* /var/log/auth.log |
in
| auth, authpriv.* @192.168.1.1 (mettere l’ip del server rsyslog centralizzato) |
La chiocciola davanti all’indirizzo IP indica a quale host deve essere inviato il log.
Per windows ho testato 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. 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.
Se tutto è andato bene, adesso nel file /var/log/auth.log verranno registrati login, logout ed errori di login delle macchine configurate.
Tenete presente che i log sistemi windows sono prolissi e bisogna saperli leggere. Gli eventi vengono identificati tramite un codice (ID Event) che assume il valore 528 per il login e 538 per il logout e distinguono gli accessi locali dagli accessi remoti tramite la variabile “Type” che ha valore 2 per accesso locale e valore 3 per accesso effettuato via rete. Vi sono inoltre vari altri ID e Type legati ad altre situazioni (p.e. errori di login) ed eventuali problemi (quale il mancato log degli eventi con ID 538 al momento della disconnessione). Trovate qui, qui,qui e qui alcuni articoli Microsoft con informazioni in merito.
Una alternativa a Snare Agent può essere ntsyslog, con la differenza che non può essere amministrato da remoto via pagina web come invece Snare Agent.
L’installazione di ntsyslog2 è come d’uso molto semplice. E’ sufficiente scaricare il file di installazione msi e lanciarlo con il classico doppio click per installare il servizio ntsyslog.
La configurazione si fa tramite il programma NTSyslogCtrl.exe (viene creato uno shortcut sul desktop). Selezionare il computer, scegliendo il pc sul quale è installato il servizio. Impostare il server di log tramite il bottone “Syslog Daemon” . Dal menu a scomparsa scegliere Security quale eventlog quindi cliccate sul bottone eventlog per selezionare quali eventi inviare al server remoto. Si può quindi avviare il servizio.
Dato che il provvedimento del Garante richiede il log dei tentativi di accesso, riusciti o meno che siano, è bene disattivare l’invio degli eventlog sistema, applicazioni e internet explorer.
Attenzione: ho notato che su alcuni sistemi Windows è disabilitata la funzione di event log, pertanto nessun evento relativo agli accessi viene registrato. Per attivare la registrazione (e l’invio al syslog remoto) degli eventi di accesso è necessario entrare come administrator sul pc, aprire il pannello di controllo, Strumenti di Amministrazione, Criteri di protezione locali, Criteri locali, Criteri controllo e verificare che sia attivato il flag “Controlla eventi di accesso“. Esiste anche “Controlla eventi accesso account” ma questo controllo non registra i logout.
Altre questioni da valutare sono relative alla gestione dei log una volta registrati sul nostro log server. Ad esempio per adeguarsi al requisito della immodificabilità si può pensare di copiare periodicamente il log su di un supporto non riscrivibile, validando i file con un hash. Ricordatevi di tenere file ed hash in luoghi separati. Un’altra possibile soluzione è avere un log server al quale l’amministratore di sistema non ha accesso ne logico ne fisico. Già sento le risate…ma ricordate che quanto scritto fino qui è solo un contributo, non la soluzione al problema.
Ogni soluzione deve essere calata nel contesto in cui si opera, e deve essere parte di un sistema di Governance dell’IT che comprenda strategie di gestione e di controllo.
L’amministratore di sistema, il professionista IT non deve essere lasciato da solo a “far funzionare il pc” ma deve essere considerato come parte integrante del sistema azienda. In questa ottica, il provvedimento del Garante Privacy deve essere visto come uno stimolo alla diffusione di una maggiore attenzione da parte delle aziende e dei dirigenti verso quelle attività a torto considerate solo come “tecniche” e lasciate alla buona volontà degli informatici.
Infine un “grazie” a Maurizio, che con il suo post mi ha stimolato a scrivere questo articolo.
Addendum: Si è andato creando una specie di “circuito” di soluzioni tecniche per il problema dei log degli Ads. Bella questa cosa.
Ne approfitto quindi per segnalare anche la soluzione proposta da Ivan Zini.
73 Risposte a “Soluzione Open Source per log Amministratori di Sistema”
Scritto da Mauro il nov 23, 2009
articolo molto interessante di attualità in un tema di interesse.
sarà mia cura segnalarlo agli amici informatici per la discussione on line sul blog
saluti da Torino
Scritto da Max il nov 23, 2009
Una soluzione possibile al problema dell’immodificabilita’ e’ un server esterno all’organizzazione, su cui sia installata una applicazione che garantisca il timestamp (data e ora certa), nonche’ immodificabilita’ (perche’ non alterabile dagli amministratori dell’azienda. Volendo, ci starebbe anche una encryption (in fondo, anche le attivita’ degli amministratori sono dai personali protette dal codice, o no?)
Scritto da Daniele il nov 28, 2009
Articolo molto interessante, la ringrazio per la pubblicazione, e per le indicazioni mi ha risolto un immenso problema.
Ing. Daniele Baroni
Scritto da Max il nov 30, 2009
grazie dell’articolo.
di solito le soluzioni efficaci sono sempre le più semplici.
con un pc di recupero sul quale dare i privilegi di root al titolare o al responsabile dei dati, e qualche semplice script per la criptazione dei log si può adempiere alla normativa senza stare a mettere mano al portafoglio.
per realtà aziendali di piccole e medie dimensioni una soluzione come questa è un toccasana che permette di non investire in soluzioni costosissime, che sono certamente necessarie in realtà aziendali complesse dove la tutela dei dati e la loro gestione è cosa fondamentale, ma che per la maggior parte delle imprese è solo un costo e una complicazione inutile.
grazie ancora
Scritto da spataro il dic 11, 2009
Bravo, ottimo articolo, ti segnalo
Scritto da Roberto il dic 12, 2009
Semplicemente geniale….. anche se per le piccole aziende il problema oggi non esiste piu’ vista la precisazione del garante 10/12/2009
mi associo al bravo
Scritto da Stefano Morini il dic 13, 2009
Ringrazio per il contributo che risulta essere stato prezioso. Ho messo a disposzione gli appunti e le ricerche fatte a rigurado che includono SNMP protezione dei file di log centralizzazione ecc… sul sito http://www.log196.com. Ogni contributo alla documentazione è ben gradito. Il tutto naturalmente freeware.
Scritto da giulio il dic 13, 2009
Complimenti , un articolo molto ben strutturato e geniale nel complesso
lo segnalero’ a tutti
Giulio Botta Responsabile marche Federprivacy
Scritto da Norberto il dic 14, 2009
Tralasciando gli aspetti legati all’immodificabilita’ dei log uno dei problemi delle soluzioni basate su syslog “semplice” come Snare (o anche Project Lasso, derivato da Snare) e’ che nelle versioni free non sono presenti sistemi che garantiscono la consegna dei pacchetti syslog inviati (si appoggiano afaik a syslog in UDP e non TCP, per cui non ci sono garanzie sulla consegna dei pacchetti).
Cio’ vuol dire che se si hanno pc non sempre connessi alla rete aziendale (ad es. portatili che contengono dati sensibili) o se ci possono essere malfunzionamenti di rete (o banalmente se devo fare manutenzione sul server che colleziona i log) potrei rischiare di perdere degli eventi.
Nel caso di Snare mi pare che la versione enterprise accoppiata al loro server preveda garanzia di delivery dei messaggi usando il protocollo TCP, ma in questo caso usciamo purtroppo dall’ambito free.
Scritto da Tobia il dic 15, 2009
Concordo con quanto scritto da Norberto. In effetti con Snare (installato e configurato -credo- correttamente) non ho capito da dove riesco ad estrapolare il file di log, se serve un altro programmino o plug in in modo da poter recuperare, salvare e poi scrivere in un supporto non riscrivibile quanto richiesto dal garante.
Non ho poi capito dove si trova la cartella /var/log/auth.log
Scritto da Davide il dic 15, 2009
Il server centralizzato di raccolta log non deve essere accessibile agli amministratori di sistema.
Pertanto la sua configurazione e gestione deve essere affidata a figura esterna all’azienda o perlomeno ad altra figura aventi la necessaria preparazione tecnica. Questo è già un costo di per se, almeno nella stragrande maggioranza dei casi.
Scritto da Paolo Giardini il dic 15, 2009
In risposta a Norberto
Beh, la possibilità di perdita di un evento è insita nel mezzo. Basta staccare il cavo di rete e non è l’uso o meno del protocollo TCP che possa salvaguardare la trasmissione del log. é per questo, ad esempio, che in genere preferisco lasciare attivo il syslog locale. E’ infatti possibile inserire nel rsyslog.conf più server di log remoti e mantenere nello stesso tempo la registrazione del log in locale. E’ evidente che la problematica è la solita, l’amministratore può modificare il log ed allora… Ma si presuppone che il Titolare abbia fatto le nomine ad AdS a ragione veduta.
Per aumentare la sicurezza del traffico si può anche pensare ad un tunnel verso il syslog server, ma l’intendimento del Garante Privacy non è quello di mettere in piedi un sistema di controllo “totale”. Basta leggere le FAQ per trovare questa frase:
Scritto da Paolo Giardini il dic 15, 2009
In risposta a Tobia
Snare Agent invia il log ad un server remoto che deve a sua volta essere configurato per ricevere questi dati, ed è sul sever remoto che si trovano i file di log.
Volendo, se si attiva l’interfaccia web di Snare, è anche possibile vedere i log direttamente puntando il browser all’indirizzo del pc sulla porta 6161.
Il file /var/log/auth.log si trova… dove dice il percorso. Ovviamente non su una macchina Windows, ma come nelle premesse, su una macchina GNU/Linux configurata per fare da remote syslog server.
Si può utilizzare anche una macchina Windows per fare esattamente la stessa cosa, ma non ho approfondito l’argomento preferendo, per mia scelta, utilizzare il più possibile software open source. Ad esempio, syslog server per Windows sono Kiwi syslog, Winsyslog, oppure Syslogserver che è open source.
Non ho affrontato il discorso analisi e conservazione dei log, magari lo farò in un prossimo futuro, ma ritengo che masterizzare un cd con dei file sia alla portata di chiunque.
Scritto da Paolo Giardini il dic 15, 2009
In risposta a Davide
Sinceramente, non mi sembra che quanto dici sia espresso come obbligo in nessun passaggio del Provvedimento del Garante, ne nelle risposte alle FAQ.
E’ peraltro evidente che sia responsabilità dell’azienda scegliere la migliore soluzione in base al contesto operativo (FAQ 13). In pratica, ritengo sia perfettamente lecito incaricare uno o più amministratori di sistema di provvedere a gestire il sistema di log secondo specifiche istruzioni, come lo è affidare l’incarico ad un esterno (che diventa a sua volta amministratore, e quindi…) come pure oppure affidare ad un operatore (non AdS) l’incarico di masterizzare periodicamente il contenuto della cartella di log del syslog server posizionato in una stanza alla quale non ha accesso l’Ads e del quale l’Ads non conosca la password .
Tutto questo deve portare evidentemente ad una maggiore coscienza dell’importanza del ruolo dell’”Informatico” ed ad una reale Governance dell’IT.
Quanti applicano ad esempio il principio del “minimum rights“?
Scritto da michelez il dic 15, 2009
scusate sono u nconsulente per la privacy.
invece di configurare un server remoto. non sarebbe più semplice configurare ‘invio del log di amministratore per email al datore di lavoro.
Si potrebbe fare tramite un semplice script di vb. Sto proprio lavorando su questo, o in alternativa cercare un software che lo faccia già di suo.
cosi si rispetterebbero le indicazioni del garante su tempo di conservazione e immodificabilità
Scritto da Paolo Giardini il dic 15, 2009
In risposta a michelez
E’ una possibile soluzione, come già detto dal Garante Privacy, ogni Titolare è libero di scegliere la soluzione secondo lui migliore per la propria realtà.
Che poi la posta elettronica possa garantire immodificabilità e conservazione dei log,è da verificare. Le ricordo però che in tema di semplicità il Garante si è espresso in questi termini:
(FAQ 12)
Scritto da Norberto il dic 15, 2009
@Paolo: nello specificare TCP sono stato poco preciso. A quanto mi e’ sembrato di leggere su Snare se usi modalita’ TCP usa una sorta di protocollo proprietario, per cui Snare salva localmente i log (cosa che gia’ fa comunque, tant’e’ che li puoi vedere via web) e poi cerca di inviarli “segnandosi” fino a che punto dell’invio e’ arrivato. In caso di malfunzionamento, e’ in grado di riprendere dall’ultimo invio completo.
Nella mia azienda per ovviare a questo problema e rimanere in campo “gratis” abbiamo optato per una soluzione casalinga di questo tipo:
-scheduled task che effettua un dump degli evt di protezione (security) su disco (una sorta di logrotate degli eventi)
-schedulazione da un server dedicato che passa via share a prelevare gli evt dalle postazioni interessate dal monitoraggio per il garante
-caricamento dei dati su un database sql con l’utility LogParser di microsoft prelevando solo gli eventi di interesse per poter avere un sistema su cui fare query agevoli (ma in realta’ puoi anche lavorare direttamente sugli EVT con Logparser)
la nostra idea e’ quella di archiviare gli EVT su WORM (eventualmente con un file di hash di md5 per mostrare che non sono stati modificati, ma gia’ l’EVT non e’ certo modificabile come un log di testo) e avere nel db invece i dati per facile consultazione
Una cosa simile viene fatta anche sui file di trace dei SQL Server aziendali (a tal proposito vi riporto questo interessante articolo:
http://www.ugiss.org/Content/Article/SQL-Server-e-la-legge-sulla-Privacy.aspx
)
Scritto da Ruperto il dic 15, 2009
Scusate l’ignoranza ma, ho installato NTsys sul server ed ho impostato l’indirizzo IP delle stesso server su SYSLOG DAEMON e poi ho impostato su SELECT COMPUTER il server, ora il file di log da copiare su supporti dovrebbe essere sul server ma dove che non riesco a trovarlo (su c: non lo vedo)
grazie e scusate
Scritto da Paolo Giardini il dic 16, 2009
In risposta a Ruperto
Non ho capito quale programma hai installato.Spiegami meglio cosa hai fatto, se vuoi anche in privato. Considera anche che se hai un solo server di dominio, puoi semplicemente esportare i log dell’event log di windows, ad esempio, utilizzando la utility microsoft Logparser.
Scritto da Paolo Giardini il dic 16, 2009
In risposta a Norberto
Grazie della precisazione e del link, molto interessante.
Scritto da Jacopo il dic 16, 2009
Ciao articolo molto interessante … Parliamo anche per quanto riguarda l’integrità dei dati e del salvataggio in un supporto non modificabile?
Inoltre, a fronte di un controllo, cosa bisogna consegnare.
Il Garante in parole MOOOLTO povere vuole sensibilizzare il datore di lavoro di fronte al suo SYSADM, in teoria dovrebbe quindi poterlo “controllare” … c’è modo di rendere un po più leggibile auth.log ?? Io ho provato la tua soluzione, installando Snare solo sul mio client e auth.log è già un MACELLO !!! Comunque non sono miei, ci sono log di CRON e del sistema linux su cui è attivo il demone.
Come si fa a fare un po di pulizia anche solo per dimostrare al datore di lavoro che ho fatto qualcosa perchè così sembra che non ci sia niente, anche se sappiamo che non è così.
Grazie mille!
Scritto da Paolo Giardini il dic 17, 2009
In risposta a Jacopo
Ricordando che stiamo sempre parlando di una soluzione “semplice” adatta a piccole realtà, per la conservazione dei log il Garante suggerisce la semplice masterizzazione su cd/dvd. Una alternativa, più costosa, potrebbero essere i dischi WORM, fino ad arrivare a un log server “non nella disponibilità dell’Ads”.
Per l’analisi, va ricordato che lo scopo di questi log è solo quello della valutazione dell’operato dell’AdS, quindi solo il personale incaricato di questa attività, ed all’interno delle attività previste per la valutazione, può visionarli, previo filtraggio dei dati non pertinenti.
Tecnicamente esistono software in grado di analizzare i log ed estrarre i dati significativi oppure si può fare a mano a colpi di grep ecc.
Sto effettuando dei test in merito, ogni suggerimento è gradito.
Scritto da Marco il dic 17, 2009
Questa soluzione è molto interessante, però non sono stati presi in considerazione i database. Esiste qualche modo per inviare a rsyslog gli eventi di accesso a sqlserver, mysql,… ?
Scritto da Luci0 il dic 17, 2009
Mi domandavo se una stampante ad aghi tolta dalla polvere poteva andar bene …
Scritto da Paolo Giardini il dic 18, 2009
In risposta a Luci0
Rispondendo seriamente: per conservare i log?
Temo di no. Il provvedimento parla di “registrazione degli accessi logici”.
Scritto da Paolo Giardini il dic 18, 2009
In risposta a Marco
Non ho scritto nulla sui database perché la trattazione sarebbe abbastanza ampia. Comunque posso suggerire alcuni spunti, da adattare alla propria situazione.
Postgres può essere configurato per inviare i log ad un syslog server.
Mysql ha qualche problema in più dato che sembra non essere in grado di colloquiare direttamente con syslog. La soluzione potrebbe essere quella di loggare in locale e inviare i dati con uno script ed il comando “logger” al syslog remoto.
Su Oracle si possono creare dei trigger per registrare gli eventi login – logout oppure si può abilitare l’audit. In ogni caso i dati vanno estratti ed inviati ad esempio con logger al syslog server.
Per SQLserver non ho competenze specifiche ma essendo possibile abilitare l’audit si possono estrarre i dati di login dall’event log per inviarli al syslog server configurando Snare Agent.
Resta da verificare se sono soddisfatti tutti i requisiti richiesti dal provvedimento; ovvero registrazione di login, logout, errori di autenticazione.
Scritto da Marco il dic 18, 2009
Grazie per i suggerimenti sui database.
Effettivamente il grosso del problema è far generare i syslog dai sw che non li generano da soli.
Mi hanno suggerito che per i requisiti chiesti dal garante è sufficiente inviare in automatico per ogni accesso una mail con la PEC (posta certificata). Questo risolve il problema dell’inalterabilità e anche della disponibilità per 6 mesi, ma non so quanto sia affidabile.La certezza della consegna c’è solo all’arrivo della ricevuta. Voi che ne dite?
Scritto da Paolo Giardini il dic 18, 2009
In riposta a Marco
La PEC come sistema di log? Mah… In che maniera sarebbero garantiti inalterabilità e conservazione? La conservazione da parte dei gestori si limita ai dati di trasmissione e ricezione ed all’oggetto del messaggio.
La riga di log (sistema, data, ora, utente, evento) dovrebbe essere parte dell’oggetto del messaggio PEC perché ne rimanga traccia.
Senza contare la mole di mail che si potrebbe generare. Ricordiamoci di non complicarci la vita, il Garante non richiede espressamente firme digitali, marche temporali e simili.
Scritto da Norberto il dic 18, 2009
Per SQL Server la cosa piu’ semplice e’ abilitare l’auditing (di default dovrebbe essere attivo solo il logging delle login failure, si puo’ abilitare anche le login ok). Queste login sono registrate
-in un file ERRORLOG presente in
..\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\ che viene pero’ ruotato a ogni riavvio del servizio (e ne mantiene mi pare massimo 7)
-il registro degli eventi (attenzione Application, non security). Il problema e’ che se non si puo’ filtrare direttamente “alla fonte” prendersi tutti gli eventi di tipo Application e’ abbastanza pesante (il 99% dei software loggano li’).
In alternativa si puo’ fare con il server side tracing citato nell’articolo che ho linkato piu’ sopra.
Scritto da Mauro il dic 18, 2009
ciao
complimenti alla discussione e al post
parlando con amministratori in queste settimane da un punto di vista organizzativo e giuridico emergono le seguenti problematiche:
- la problematica della copertura assicurativa di tale ruolo
- i profili relativi al divieto di controllo a distanza previsto dallo statuto
-le sanzioni in caso di omessa conservazione dei file di log
- i profili di responsabilità degli amministratori ..
c’è ancora molto lavoro di apprendimento da fare da parte di tutti..
ad un recente convegno dell’autorità in Veneto sono state preannunciate la pubblicazioni di ulteriori faq.sia tecniche che organizzative
Scritto da massimo il dic 22, 2009
Ho installato SnareSetupVista-1.1.2-MultiArch.exe in un server windows 2008 64bit e quando avvio il servizio snare mi dà il seguente errore: Impossibile avviare il servizio snare su computer locale. Errore 193: 0xc1.
Purtroppo non trovo soluzioni. Posso avere il vostro aiuto. Grazie
Scritto da Paolo Giardini il dic 22, 2009
In risposta a Massimo
Prova a contattare i produttori del software o meglio la community degli utilizzatori sul forum.
Scritto da Roberto il gen 8, 2010
Ho trovato un programmino interessante ” NetWrix Event Log Manager ”
un tool di archiviazione degli eventi log in formato compresso e che può essere spedito ad un indirizzo mail a scelta (ad esempio del titolare)ed ha un filtro di scelta degli eventi da archiviare ed inviare.
E’ un tool di base gratuito….che potrebbe semplificare qualche passaggio….non credete?
http://www.netwrix.com/event_log_archiving_consolidation_freeware.html
Scritto da MauroZ il gen 13, 2010
ciao
nella mia rete aziendale i server sono ancora (purtroppo) dei Windows NT Server. Mi sembra che nel registro eventi non vengano registrati i login/logout degli account, non mi ricordo se c’è modo di abilitarli su WinNT?
Un’altro dettaglio: nel mio caso, ma anche in molti altri credo, raramente faccio logout col profilo di admin sui server, ma li lascio sempre col profilo locked. Quindi credo proprio che vengano registrati pochissimi accessi, questo potrebbe essere un problema?
Scritto da Paolo Giardini il gen 13, 2010
Per abilitare i log devi attivare i servizi di auditing. Troverai gli eventi con ID 528 (login) e 538 (logout).
Dal punto di vista normativo, non esistono disposizioni in merito ad obblighi di logout. Vi è un obbligo di proteggere la postazione incustodita, ad esempio con la pwd del salvaschermo.
Il problema semmai sarà quello di effettuare la valutazione dell’operato dell’AdS dato che deve essere basata anche sui log. Ti consiglio di valutare bene la cosa e nel caso provvedere a redigere una policy adeguata che preveda le modalità di utilizzo dei sistemi, uso del salvaschermo, abbandono della postazione, logout, ecc.
Scritto da Massimiliano Vannocci il gen 15, 2010
Salve,
ringraziando il contributo prezioso di tutti, vorrei chiedere due cose:
1) per le piccole realtà, in caso di salvataggio dei log su supporti non modificabili (CD-ROM), la frequenza dei salvataggi è semestrale o giornaliera?
2) ho installato SnareSetupVista-1.1.2-MultiArch.exe su Windows Vista ma non posso entrarvi via browser tramite altro PC in rete per gestire l’amministrazione del software. Devo settare qualche permesso su Vista per poter gestire Snare da remoto?
Grazie ancora.
Scritto da Paolo Giardini il gen 15, 2010
E’ grazie al contributo di tutti che si cresce
Le tue risposte: E’ il titolare che definisce le modalità del salvataggio, come indicato anche nelle FAQ (punto 12)
Pertanto, dipende comunque dal contesto in cui si opera. Ricorda di documentare scelte, motivazioni, operatività.
Per l’accesso a snare via http, verifica di aver attivato il servizio e di aver configurato il firewall di vista.
Scritto da Luca il gen 18, 2010
Salve,
secondo voi il salvataggio dei dati in pdf potrebbe soddisfare il requisito della “non modificabilità”?
Complimenti per la discussione, molto utile
Ciao
Scritto da Paolo Giardini il gen 23, 2010
In generale i pdf sono modificabili…
A parte questo, quale sarebbe il vantaggio del PDF nei confronti del classico log? Considera che comunque viene prescritta anche la “possibilità di verifica della loro integrità” quindi devi comunque prevedere un hash o altro meccanismo di verifica. Mi sembra che trasformare in PDF un log aggiunga un passaggio in più, forse inutile.
Scritto da Xfilesit il gen 25, 2010
Secondo voi il trasferimento dei log da sistemi linux e windows verso il collettore centrale per essere conforme alle direttive del garante deve essere crittografato ? Inoltre la registrazione di questi log sul server collector centrale è preferibile che avvenga in un database o su fileserver Grazie a tutti
Scritto da Paolo Giardini il gen 26, 2010
In risposta a Xfilesit:
Il Garante non da indicazioni tecniche, lasciando ai singoli Titolari di trattamento la scelta della soluzione tecnica adeguata al tipo di trattamento ed ai dati trattati.
Massima libertà dunque, tenendo d’occhio le misure di sicurezza adeguate.
Scritto da D@ve il gen 27, 2010
Grazie a tutti per le dritte. Sapete in DB2 se c’è un log degli accessi amministrativi? ho trovato questo “list_dbmizar.log” ma non specifica che tipo di accesso è stato effettuato.
Scritto da Xfilesit il gen 28, 2010
In risposta a Paolo Giardini:
Il Garante dice che il log deve essere raccolto in modo sicuro ossia penso significhi crittografato o tramite una vpn.
Ma la cosa più critica è l’hashing del dato che deve essere fatto sui log raccolti centralmente.
Ne approfitto per chiederti se eventualmente la nomina ad AdS più essere non accettata dal ricevente nel caso questi sia il Reasponsabile dei Sistemi Informativi
Scritto da Paolo Giardini il gen 28, 2010
in risposta a Xfilesit:
Il provvedimento non dice precisamente questo, anzi, nelle Q&A (risposta 13) si specifica bene che è compito del titolare applicare le misure che ritenga necessarie al raggiungimento dello scopo.
Sta a te quindi decidere cosa ti serve. Nessuno potrà mai contestarti una scelta tecnica perché non esistono specifiche tecniche prefissate.
Si potrà andare in contenzioso nel caso succeda qualcosa, che so, log alterati o distrutti; in quel caso ti si chiederà conto della mancanza di misure adeguate. Tanto è vero che nei suggerimenti del Garante stesso, si dice che in alcuni casi può essere sufficiente il log di sistema (Q&A risposta 12)
Quindi in certi casi può bastare anche il log dell’event viewer di Windows con eventuale copia su CD o DVD.
In altri casi, questo potrebbe essere insufficiente o inadeguato, ma la valutazione è in carico al Titolare del trattamento.
Per quanto riguarda la nomina, stante il provvedimento che ha forza di legge, chi effettua un determinato tipo di attività è per forza di cose “amministratore di sistema”.
Fra l’altro ritengo questa nomina da un lato un riconoscimento di una attività importante, e dell’altro anche una forma di salvaguardia per l’amministratore stesso che dovrebbe finalmente vedere “nero su bianco” quali siano gli effettivi compiti a lui assegnati e potrà anche contare su una evidenza delle sue attività in caso di contestazioni del suo operato.
Scritto da Roberto Barbolini il gen 28, 2010
Grazie del bellissimo articolo.
I log possono essere visionati dal titolare dell’azienda o dal titolare del trattamento, giusto?
Ma se L’amministratore di sistema
è anche il titolare del trattamento serve fare tutto questo?
Scritto da Paolo Giardini il feb 1, 2010
In riposta a Roberto:
Ciao e grazie.
I log possono essere visionati dal Titolare del Trattamento o dal Responsabile del trattamento per adempiere a quanto prescritto, ovvero la verifica dell’attività dell’AdS.
Come scritto nelle FAQ del Garante (punto 3) , nel caso limite di un titolare che sia anche unico amministratore di sistema, non si è tenuti ad applicare quanto previsto dal provvedimento.
Scritto da zebedeo il feb 1, 2010
Ciao a tutti, sono anch’io impelagato in questa seccatura, sto lavorando a una soluzione in questi termini: snare agent sul server windows 2003, log inviati a una macchina linux con syslog-ng, ruotati ogni notte, conservati in locale e anche inviati in copia via mail a un indirizzo prefissato; sul server linux ho installato anche phplogcon per permettere la consultazione dei log via web dal responsabile. Fino a qui funziona, ma ora vorrei poter inserire una marca temporale a ciascun file di log, qualcuno sa se esistono soluzioni in ambiente linux a costo zero?
saluti a tutti
Scritto da Xfilesit il feb 2, 2010
In risposta a Paolo Giardini:
Non capisco perchè avendo in azienda da lettera di mansione il ruolo di AdS devo essere ancora nominato. Penso comunque che la nomina a responsabile AdS si possa non accettare a differenza di quella a incaricato AdS.
Scritto da Paolo Giardini il feb 2, 2010
In risposta a Xfilesit:
Il provvedimento non differenzia ruoli nella mansione da AdS. Anzi, specifica che si tratta di un ruolo tecnico. Quoto dal primo paragrafo delle considerazioni del provvedimento:
.
Più avanti viene specificato che rientrano nella definizione tutti coloro che per le mansioni affidate possono direttamente od indirettamente “interagire” con dati personali memorizzati sui sistemi che gestiscono.
Non conoscendo la situazione che prospetti, posso dire che un “responsabile EDP” che si occupi esclusivamente della gestione amministrativa del servizio e solo in funzione del ruolo di dirigente, ma non abbia nulla che fare tecnicamente con i sistemi, non rientri nella definizione data dal Garante di AdS ed in questo caso può ovviamente rifiutare una nomina che non avrebbe alcun senso.
Diverso, a mio parere, è il caso di un tecnico o amministratore di rete, o di database, insomma qualcuno che abbia veramente la possibilità di accedere a dati personali. In questo caso infatti, la nomina è necessaria anche se già a ruolo con incarico di AdS in quanto il provvedimento, a differenza di quanto avviene con la nomina ad incaricato del trattamento che prevede la possibilità di considerare incaricato “de facto” le persone per le quali esista una documentata preposizione ad un trattamento (art 30 del codice), prevede che:
Quindi, se si ha accesso a dati personali nei termini indicati dal provvedimento, non credo vi siano molte alternative all’accettare la nomina.
Scritto da Paolo Giardini il feb 2, 2010
In riposta a zebedeo:
Non ho approfondito la cosa, ma esistono servizi che offrono gratuitamente la marca temporale di documenti, ad esempio ho trovato questo link ed anche questo.
A prescindere se si possa mettere in piedi una propria autorità di certificazione interna, è comunque chiaro che una marca temporale non apposta da un ente certificare riconosciuto dallo Stato non ha valore legale.
Scritto da Xfilesit il feb 3, 2010
Vi chiedo :
Nella mia azienda sono stati nominati Responabili del trattamento tutti i Dirigenti
di una specifica Area aziendale e il Consigliere Delegato.I membri del Consiglio di Amministrazione, il Presidente è preferibile nominarli Incaricati o Responsabili ?.
L’ A.d.S. e preferibile nominarlo Responsabile o Incaricato ?
Grazie per i vostri consigli.
Scritto da Paolo Giardini il feb 3, 2010
In risposta a Xilesit:
La scelta della nomina a responsabile o incaricato va fatta in base all’effettivo “organigramma privacy”, ovvero se la persona ha la responsabilità (vedi art. 29 del codice) o meno sulle modalità di effettuazione del trattamento. Se Non ha una mansione “di vigilanza” sul trattamento, è un semplice incaricato anche se è un dirigente. Idem per gli AdS.
Scritto da Olga il feb 12, 2010
@Paolo Giardini Potresti gentilmente indicare il link che tratta la questione del Titolare che nel contempo è anche amministratore di sistema?
Scritto da Paolo Giardini il feb 12, 2010
in risposta ad Olga:
Nelle FAQ del Garante su AdS, risposta n. 3, trovi che nel caso limite di titolare che sia anche unico amministratore di sistema, il provvedimento non si applica.
Ecco il link alla FAQ n.3
Scritto da Olga il feb 12, 2010
@Paolo Giardini Ti ringrazio molto sia per la risposta che per utilissimo articolo.
Scritto da raffaella il feb 18, 2010
Non voglio fare pubblicità, ma andate a vedere il prodotto legallogger, interamente basato su opensource
mysql/syslog-ng/openssl
registra i file di log e vi mette marcatemporale rilasciata dalla camera di commercio dunque valida legalmente, e contando che le marche temporali costano 30 cents ognuna il costo di 30 €/mese non mi sembra insostenibile, soprattutto perche toglie da ogni responsabilità
l’amministratore di sistema.
noi lo abbiamo adottato e a parte qualche problema durante la fase di setup (scambio di certificati ssl etc…) lo abbiamo messo su in mezza giornata e ora siamo in regola ….
ciao
Scritto da Paolo Giardini il feb 19, 2010
in riposta a Raffella:
Ho dato un’occhiata al sito e mi sembra che riporti alcune inesattezze interpretative del provvedimento del Garante.
Non esiste alcun obbligo di apposizione di marca temporale sui log ne si deve “registrare e conservare i log delle attività degli Amministratori di Sistema” ma solo login e logout (ed eventuali condizioni di errore).
Inoltre non è corretto dire che ” la normativa (al punto 4.1 ) pone anche il responsabile o l’addetto al trattamento dei dati sensibili allo stesso livello dell’amministratore di sistema, ” .
Magari si tratta solo di come sono stati espressi i concetti, ma così come scritto possono portare a conclusioni errate.
Ultima cosa: attenzione al fatto che i log vengono conservati presso il server del fornitore del servizio; questo deve essere considerato come trattamento esterno e regolato di conseguenza.
Scritto da Francesco il feb 25, 2010
Blog molto interessante, ho ancora un problema da risolvere con rsyslog: installato phologcon su ubuntu mi invia error 15 (non riesce ad aprire syslog). Potete darmi una mano?
grazie cmq
Francesco
Scritto da Paolo Giardini il feb 28, 2010
in risposta a Francesco
Immagino che PphLogCon, o meglio l’utente che fa girare Apache, non abbia i diritti di lettura del file syslog. Prova a verificare questa cosa.
Nel caso, qui trovi una soluzione.
Scritto da Francesco il mar 1, 2010
in risposta a Paolo Giardini:
Ti ringrazio, adesso ci provo.
Francesco
Scritto da Morini Stefano il mar 18, 2010
Rilasciata una nuova versione freeware del programma log196 per le piccole aziende e studi adatto solo per piattaforma Microsoft.
Scritto da Roberto Pesce il mar 24, 2010
Ho trovato l’articolo molto interessante,
anche se alla fine non sono riuscito a trovare una soluzione che mi convincesse:
cosa ne pensate di Business Log di sysadmin.it ? non e’ freeware, ma ha un costo decisamente accettabile: 199 euro all’anno e forse il fatto di pagare qualcosa tutela di piu’ dal punto di vista dell’assistenza e dal punto di vista legale:
pensavo di adottarlo ma volevo qualche riscontro prima
ciao e grazie
Roberto
Scritto da Marco il apr 29, 2010
Ciao, ottimo articolo! Lo utilizzerò come guida
Un domanda però, forse banale; alla fine dell’articolo scrivi “L’amministratore di sistema, il professionista IT non deve essere lasciato da solo a “far funzionare il pc” ma deve essere considerato come parte integrante del sistema azienda.”
Ma credo che nella maggior parte delle aziende sarà proprio questa figura a realizzare questo sistema di controllo, in quanto una delle poche persone o magari l’unica con le conoscenze tecniche adeguate, quindi potrebbe essere semplice per lui aggirare il sistema o sbaglio? Mi sfugge qualcosa?
Grazie.
Scritto da Marco il apr 29, 2010
Ciao, un’informazione, ho impostato tutti i parametri di rsyslog nel server ubuntu e installato snare agent su una macchina windows, ma non vengono scritti i log in remoto.. Credo sia un problema di permessi, ma non ho capito come far dialogare l’utente windows con il server linux.. Grazie!
Scritto da Paolo Giardini il mag 4, 2010
In risposta a Marco
Si, certamente questo aspetto non sfugge a nessuno, tanto meno al Garante che nelle FAQ ha preso in esame il livello di sicurezza richiesto concludendo che in pratica la sicurezza di un sistema di controllo così come previsto dal provvedimento non è e non può essere garantita. Ma come ho detto in un seminario qualche giorno fa, dareste le chiavi di casa al primo venuto?
Scritto da Paolo Giardini il mag 4, 2010
In risposta a Marco
Ciao.
Il sistema così come descritto nell’articolo funziona; sei sicuro di aver impostato correttamente il server di syslog sull’agent? Verifica con uno sniffer di rete se i pacchetti vengono spediti, così individui dove si trova il problema.
Scritto da Marco il mag 11, 2010
Ciao, grazie della risposta, e problema risolto
Se l’amministratore deve avere accesso al log server, perchè lo gestisce lui, quali potrebbero essere le soluzioni per garantire l’immodificabilità?
Scritto da Paolo Giardini il giu 1, 2010
La garanzia dell’inalterabilità dei log è un requisito che lo stesso Garante ha reso meno stringente, vedi la faq 12, dove scrive che questo “può essere ragionevolmente soddisfatto con la strumentazione software in dotazione, nei casi più semplici, e con l’eventuale esportazione periodica dei dati di log su supporti di memorizzazione non riscrivibili.”. Da qui in poi, vale tutto, fino alla marca temporale e firma digitale. La cosa irrinunciabile è un documento, istruzione, lettera di incarico che specifichi bene le mansioni e le modalità di conservazione dei log.
Scritto da Alias il lug 5, 2010
Caro Paolo,
disposizioni per Amm. di Sist.: devo mantenere i log degli ultimi sei mesi che documentano le fasi di login/logout (con successo e con errore) degli AdS ai pc, server e database dell’azienda. Sta al Titolare del tratt. decidere se masterizzare tali log, crittografare i dati, ecc.
Domande:
1- corrisponde a quanto sai?
2- cosa dovrei fare per i casi in cui l’AdS dovesse entrare localmente in un pc o server, perchè fuori dal dominio o per altri determinati motivi? L’agente, ad es. Snare, dovrebbe comunque registrare tale accesso?
3- anzichè Snare, o altri client, potrei sfruttare Log Parser (che però non conosco bene)?
4- dovendo adeguarmi anche alle disposizioni per provider (sul data retention), e dovendo questa volta crittografare i dati, verificarne l’integrità, ecc., potrei utilizzare (migliorandolo) ciò che si fa per le dispozioni degli AdS?
5- conosci quest’ultima normativa?
Grazie
Scritto da Paolo Giardini il lug 10, 2010
Ciao.
Riesco solo ora a rispondere alle domande di Alias…
1) “Sta al Titolare del tratt. decidere se masterizzare tali log, crittografare i dati, ecc.”
Beh, detto in parole povere è così, ma bisogna tener presente il requisito di inalterabilità e immodificabilità dei log registrati.
2) Vediamo il caso di login su un pc non in rete o comunque dove non è installato un agente per il log remoto.Le disposizioni non cambiano, è sempre necessario effettuare il log dell’accesso ecc. Il discriminante sta nella verifica preventiva sulla presenza o meno di dati personale in tale computer o se il computer viene usato per effettuarne il trattamento. Se non vi è presenza di dati personali, non si applica il provvedimento sugli AdS.
3) Ovviamente per adeguare il tuo sistema al provvedimento poi usare il metodo che preferisci, non vi sono prescrizioni tecniche in questo senso.
4-5) si, conosco la normativa ma è molto più stringente e richiede attività di livello più elevato rispetto al provvedimento sugli AdS. Personalmente non applicherei quanto richiesto per la data retention ai log per AdS.
Scritto da Maido il lug 16, 2010
La soluzione è interessante e anche abbastanza facile da implementare, tra le altre cose esistono distribuzioni leggere che sono già pronte per questo tipo di servizio (zeroshell ad esempio). Ho alcuni dubbi:
1) chi garantisce l’inalterabilità del log tra il momento dell’invido dell’agent di windows al momento della masterizzazione?
2) Il garante se non mi sbagli menziona anche gli amministratori di DB, come vengono controllati? Io ad esempio ho sia DB MSSQL che MYSQL
Grazie.
Scritto da Paolo Giardini il lug 16, 2010
Ciao Maido.
Nessuno garantisce il dato dalla generazione alla fase di conservazione. Il Garante stesso nelle FAQ e nel provvedimento scrive che non si intende richiedere di implementare un sistema rigoroso di controllo, cosa difficile soprattutto nei casi in cui controllato e controllore sono la stessa persona. La masterizzazione è il metodo più semplice per garantire l’inalterabilità del dato una volta registrato.
Tutti coloro che rientrano nella definizione di “Amministratore di sistema” (vale la pena di ricordare che AdS non equivale direttamente a “sistemista”) sono sottoposti alla medesima norma, ovvero registrazione degli accessi al sistema. In questo caso al DB. Trovi qualche spunto nei commenti del 18 dicembre a questo stesso articolo.