Soluzioni alternative proposte

samba è funzionante (4/5 giorni).

2. Il server andrebbe costruito blindato in quanto sarebbe sulla DMZ, zona a rischio intrusioni.

Al contempo questa soluzione, più semplice a prima vista, potrebbe produrre problemi per quanto riguarda la gestione dei logles, andrebbe implementato lo stesso meccanismo di inoltro/certicazione di log su ogni macchina invece che unicamente sul Server di autenticazione; cosa che andrebbe fatta comunque sulle macchine che contengono DBMS.

Se invece ci fosse a disposizione una macchina unicamente per l'auditing, questa potrebbe essere utilizzata per eettuare tutte le operazioni senzxa che nessuno possa accedervi,risolvendo gran parte dei problemi.

La soluzione di emergenza che è stata proposta è la seconda tra quelle che verranno descritte nella sezione sottostante (7.5.2).

Acquisto soluzione esterna: LegalLogger

Il termine ultimo per adottare una soluzione di auditing a norma di legge è il 15 Dicembre, ed il prolungamento dei lavori è probabile dati i problemi riscontrati su alcune macchine, una soluzione per contenere il problema sarebbe ricorrere a una soluzione esterna, ovvero comprare un pacchetto SW che gestisca il sistema di Auditing, il costo della versione Enterprise è di 1400 Euro per l'acquisto ed un canone di 100 euro mensili. L'oerta è stata descritta nel precedente capitolo.

7.5 Soluzioni alternative proposte

Prima di procedere sono state proposte svariate soluzioni, alcune unicamente di carattere teorico, altre invece fornite di esempi pratici, in ogni caso tutte fattibili nel contesto aziendale, alcune di queste sono state parzialmente implementate nella soluzione reale, lo studio quindi è stato utile all'identicazione di soluzioni veloci da adottare in caso di problemi nell'applicazione della soluzione principale. I metodi di raccolta riguardano la struttura del sistema che si andrà ad im-plementare, le modiche ai sistemi di autenticazione o alla struttura di LDAP presente in azienda attualmente. La raccolta relativa alle macchine interne non presenta problematiche organizzative di rilevanza, sono presenti più Windows Server, sui quali è possibile impostare l'auditing ed inviare i log al server centrale

tramite un qualunque servizio di invio log (i sistemi di trasmissione dei log ver-ranno discussi nel seguente capitolo), le macchine Linux non collegate al dominio verranno collegate tramite OpenLDAP.

7.5.1 Tracciamento degli IP

Questa soluzione organizzativa è la meno invasiva sul sistema generale, ma al contempo non ore miglioramenti, unicamente la raccolta dei log, questa solu-zione non è completamente sicura nella raccolta, essendo relativamente semplice nascondere la provenienza sica di una richiesta di login remoto.

La soluzione consiste nell'eettuare un tracciamento degli Ip di provenienza delle richieste; dentro ogni log relativo ad accessi remoti macchine (server o host) è presente l'ip da cui proviene la richiesta, prelevando questa informazione è possibile capire da che PC proviene la richiesta, essendo le macchine all'interno dell'ucio assegnate a determinate persone, si dovrebbe riuscire a determinare l'utente (l'amministratore) che ha eettuato l'accesso.

Beneci Raccolta centralizzata dei log con relativamente poco lavoro, il sister-ma Log_mining verrà aggiornato e sarà implementata la funzione di lettura dei log riguardanti gli accessi, sfruttando una risorsa già disponibile.

La situazione di Username e password resterà inalterata, il che sarebbe un van-taggio essendo un sistema già assodato e non vengono richieste modiche ad applicativi o altri sistemi che necessitano accessi a questi server.

Problemi Il soddisfacimento della legge sarebbe parziale, infatti non sempre è possibile ricavare il nome di una persona tracciando l'IP delle varie connessioni. Sicurezza del Firewall aziendale ridotta a causa della necessità di aprire porte verso l'interno

Tempi É la soluzione più veloce: attivazione dell'auditing e installazione di Snare sui Windows Servers 1 giorno per server, attivazione di Syslog-ng per l'au-diting su ogni macchina Linux 30 minuti per macchina, congurazione syslog-ng sul Server di raccolta 1 giorno.

I tempi che saranno allungati saranno quelli riguardante l'analisi dei log prodotti, starà infatti all'analizzatore eettuare il tracciamento degli ip memorizzati. Rischi Condivisione user/password

7.5 SOLUZIONI ALTERNATIVE PROPOSTE a conoscenza, non si è in grado di determinare chi le ha conservate male.

Relativo alla DMZ

La rete esposta ad internet è soggetta ad attacchi, questi attacchi restano loca-lizzati all'esterno grazie a Clavister al momento, ma se si desidera inviare Log dalla rete DMZ verso la rete interna per la raccolta, è necessario aprire almeno una porta verso l'interno, il che crea una falla di sicurezza, in quanto, attraverso questa porta, un utente malintenzionato sarebbe in grado di penetrare nella rete interna (la porta è rilevabile in molti modi, ad esempio esiste nmap: un comando che controlla le porte di un rewall/router/pc..); in pratica si lascia un passaggio libero all'interno del Clavister (già molti sono presenti per necessità organizzative e per i servizi forniti), in gura 7.4 è mostrato sia il problema che la sua risoluzio-ne. Il problema è causato dal modo di operare di Syslog (e di ogni altro sistema

di invio log), il syslog centrale (Zabbix) è in ascolto PASSIVO, i vari syslog sui server inviano attivamente pacchetti verso la rete interna, quindi il problema ri-sultante è che Clavister deve restare aperto per traco diretto verso l'interno. Sono stati trovati due sistemi di raccolta e tra questo è stato scelto il secondo essendo più sicuro del primo ma comunque crea un rischio.

Incertezza della provenienza delle richieste

I login remoti possono essere fatti in sequenza, creando catene di sessioni ssh aperte, normalmente è suciente osservare gli orari e gli ip di provenienza per determinare chi ha eettuato un certo accesso e da dove. Ma se venissero eettua-ti accessi sequenziali, ueettua-tilizzando redenziali comuni (come root o administrator), non è possibile determinare chi ha eettuato un accesso già a partire dalla seconda sessione remota in sequenza.

7.5.2 Assegnazione Username personali

Questa soluzione coincide in gran parte con la precedente, l'unica dierenza è che su ogni server presente nella DMZ (e sulle macchine della rete interna ancora con autenticazione locale) sarà presente un elenco di user e password personali, ovvero ogni amministratore avrà un proprio set di user/password.

Beneci Risoluzione dell'incertezza della provenienza delle richieste, un'even-tuale smarrimento di password da parte di un amministratore sarebbe ora as-sociabile non più all'insieme di amministratori ma al solo possessore delle sue credenziali personali.

Raccolta centralizzata: vedi proposta precedente.

Problemi La creazione di un set di user e password per ogni amministratore avrà come conseguenza la modica di ogni database 'users' sulle macchine coin-volte (Server e tutte le macchine non autenticate attraverso il Domain Controller). Vedi problemi soluzione precedente.

Tempi Creazione di un set di credenziali su ogni server nella rete DMZ e su ogni server nella rete interna.

Vedi tempi soluzione precedente.

Rischi Problemi causati dalla modica delle user/password in alcuni sistemi che utilizzano accesso automatico

7.5 SOLUZIONI ALTERNATIVE PROPOSTE

7.5.3 Creazione albero LDAP unico

Questa soluzione utilizza gli alberi LDAP descritti nel capitolo precedente, al momento gli alberi sono attivi e visibili tra loro, ma non formano un albero unico, la struttura che si propone con questa soluzione è rappresentata in gura 7.5 :

Nella quale anche le macchine linux presenti nella rete interna verranno col-legate al Domain Controller tramite OpenLDAP, la raccolta log sarà adata unicamente ai vari LDAP presenti, oppure all'LDAP NET in cima all'albero, mediante Snare per i server Windows e Syslog per i server Linux (OpenLDAP). Beneci Centralizzazione degli accessi senza modicare gran parte della strut-tura già presente, i vari Windows Server verranno a capo di un unico Domain Controller posto alla radice di un albero di Active Directory, la gestione degli ac-count risulta semplicata e centralizzata. I server nella rete interna e nella DMZ non sarebbero più a sé stanti (come autenticazione).

Problemi Il fatto di collegare la rete esterna con la rete interna può creare falle di sicurezza, una volta che un malintenzionato entra all'interno di un server nella DMZ sarebbe in grado di accedere alla rete interna, cosa che al momento è molto più complicata. Andrebbe incrementata la sicurezza.

Creare un albero unico avrà la necessità di ridenire un elenco degli amministra-tori : quali solo di un ramo e altri che avranno diritti di root dell'active directory. Mettere in comunicazione OpenLDAP con Windows Server crea spesso problemi causati dal formato della comunicazione, un sistema alternativo per comunicare col Windows Server è WinBind, grazie al quale è possibile denire un template per la comunicazione col Server, è una soluzione meno pulita rispetto all'OpenL-DAP, ma funzionante, quindi verrà presa in considerazione in caso di problemi di interazione OpenLDAP-Windows Server (un'alternativa è installare un hot-x fornito da Windows appositamente per questo bug, ma essendo il Domain Controller attuale datato, ogni modica potrebbe creare problemi).

Tempi Installazione di OpenLDAP su ogni Server DMZ, creazione di un Server OpenLDAP (slapd) per i server esterni > 2 settimane.

Installazione di OpenLDAP sulle macchine Linux dentro la rete interna e colle-gamento di queste col Window Server della rete interna > 2 settimane.

7.5 SOLUZIONI ALTERNATIVE PROPOSTE con un'altro LDAP (da creare) posto in cima alla gerarchia che avrà il ruolo di root.

Rischi Collegare mediante Active Directory la rete esterna con la rete interna rappresenta un rischio sulla sicurezza.

Problemi su applicativi che utilizzano il sistema attuale di autenticazione.

7.5.4 Single Sign On

Creare una macchina che funga da autenticazione centralizzata, questa poi invie-rà certicati a tutte le altre macchine, i certicati saranno accettati e il livello di accesso garantito da un raggruppamento: ogni certicato potrà essere di tipo amministratore, utente, poweruser, ecc..

É una soluzione migliorativa, centralizzare completamente gli accessi, come illu-strato in gura 7.6, renderà la vita più facile agli amminiillu-stratori, in quanto non sarà richiesto di autenticarsi nuovamente ad ogni accesso alle macchine esterne, una volta eettuato l'accesso ad inizio giornata il successivo scambio di certicati tra macchina centrale di autenticazione e tutte le altre, le autenticazioni risulte-ranno trasparenti.

Capire chi è connesso e dove, sarà più semplice, è suciente che la macchina centrale memorizzi ogni azione login/logout a che utente è associata e verso che macchina è diretta. Questa macchina centrale sarà l'unica che avrà il diritto di autenticarsi, verrà eliminata la possibilità di autenticazione tramite ssh, telnet, ecc..,questo per evitare catene di autenticazione da una macchina all'altra, cosa che renderebbe più complesso rintracciare il vero utente che ha compiuto l'accesso già dopo il secondo login sequenziale sulla stessa shell.

Si potrebbe applicare solo parzialmente, ovvero creare un albero interno di LDAP ed un SSO esterno relativo unicamente alle macchine presenti sulla DMZ e mantenerli separati, i log raccolti dal LDAP verranno inviati direttamente allo Zabbix, quelli raccolti dalla macchina SSO attraverseranno il Calvister (creando la falla di sicurezza prima descritta).

Beneci Centralizzazione degli account, Sicurezza interna aumentata,

controllo accessi semplicato,

7.6 SISTEMI PER LA RACCOLTA DEI LOG