Soluzione Open Source per log Amministratori di Sistema

La recente precisazione del Garante sulla Privacy avrà fatto tirare un sospiro di sollievo a migliaia di piccole e medie aziende e ai relativi amministratori di sistema. Certo e' con un certo fastidio che le aziende vedono continuamente nuovi organismi procedere a definire nuove policy da osservare senza alcun ragionamento logico sulle dimensioni di impresa o sugli effetti che le loro normative introducono nella vita delle imprese incentivando costi burocratici che il piu' delle volte vengono tardivamente riconosciuti come inutili (garante docet!), alla faccia di un ministero creato ad hoc per la semplificazione legislativa (non sarebbe piu' logico limitare i punti di emissione di normative e introdurre un "ufficio simulazione" per verificare costi ed effetti delle norme?).

Tuttavia per molte grandi aziende il ruolo dell'AMMINISTRATORE DI SISTEMA non è un ruolo marginale. Molto piu' che un Amministratore Delegato l'amministratore di sistema ha il pieno controllo sui dati e quindi sulla vera ricchezza aziendale. Per questo deve essere possibile avere un controllo storico sulle operazioni svolte dall'amministratore che peraltro, il piu' delle volte, possono generare effetti penali sull'azienda. Ora le recenti precisazioni del garante introducono alcune chiarificazioni sulla norma:

• le prescrizioni riguardano solo quei soggetti che, nel trattare i dati personali con strumenti informatici, devono ricorrere o abbiano fatto ricorso alla figura professionale dell'amministratore di sistema o a una figura equivalente.
• le prescrizioni non si applicano, invece, a quei soggetti anche di natura associativa che, generalmente dotati di sistemi informatici di modesta e limitata entità e comunque non particolarmente complessi, possano fare a meno di una figura professionale specificamente dedicata alla amministrazione dei sistemi o comunque abbiano ritenuto di non farvi ricorso.

Per quanto concerne, infine, gli aspetti tecnici del provvedimento (in particolare, la conservazione dei log degli accessi effettuati dagli amministratori di sistema), il Garante ricorda come l'adeguamento possa avvenire anche con soluzioni a basso costo, validamente proposte e disponibili in rete (per esempio basate su software gratuito, anche con licenze di tipo open source), che possono costituire valide alternative all'impiego di prodotti commerciali o di apparati più sofisticati.

Certo sono affermazioni alquanto generiche per cui abbiamo provato ad efettuare una ricerca in rete e per la verità abbiamo trovato un articolo su blog.solution.it che potrebbe a nostro avviso fornire indicazioni utili:

 "...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 esere 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:

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.

Fatte queste modifiche si riavvia il demone con

e si verifica che sia effettivamente in ascolto sulla porta UDP 541 con

che deve mostrare qualcosa di simile:

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

in

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."