C apitolo 3
A nalisi del rischio nei sistemi dedicati alla condivisione di file
Indice del capitolo
3.1 La politica di sicurezza per la condivisione di file tra macchine virtuali...52
3.2 Contesto e assunzioni...55
3.3 Analisi degli asset...56
3.4 Analisi delle vulnerabilità...57
3.5 Analisi degli attacchi...58
3.5.1 Attacchi alla confidenzialità...59
3.5.2 Attacchi alla integrità...60
3.5.3 Attacchi alla disponibilità...61
3.5.4 Attacchi alla autenticazione...62
3.6 Analisi delle minacce...62
3.7 Requisiti...63
3.1 - La politica di sicurezza per la condivisione di file tra macchine virtuali
Il punto fondamentale nella definizione di una qualsiasi politica di sicurezza[59] è di individuare cosa proteggere e chi e definire quante risorse è conveniente investire per
Analisi del rischio nei sistemi dedicati alla condivisione di file
ottenere una protezione adeguata al rischio, cioè alla probabilità di un attacco con successo ed al conseguente impatto.
A questo scopo è necessario definire un insieme di regole che cercano di mitigare il rischio, limitando componenti e comportamenti pericolosi e forzare il rispetto di queste regole attraverso l'implementazione di controlli, distribuiti sui componenti del sistema. Un classico esempio è appunto la definizione di una politica per il controllo degli accessi al file system, che permette di attribuire diritti ai programmi e, di contro, configurare appropriatamente migliaia di file e risorse presenti nel sistema.
Una architettura basata su macchine virtuali e su Virtual Machine Monitor rappresenta invece un approccio fondamentalmente diverso dall' isolamento, perché riduce la complessità derivata dalla esigenza di regolare la condivisione e, in particolare, gli accessi a oggetti memorizzati in uno spazio di indirizzamento comune a tutti i processi[4].
Per rispettare il principio di defaul-deny[75], ogni macchina virtuale risiede su uno spazio di indirizzamento privato che rende impossibile l'accesso alle risorse da parte delle altre macchine virtuali, tranne nel caso in cui sia stata esplicitamente indicata la risorsa da condividere. Si elimina così la causa che rende complessa gestione della politica di sicurezza e quindi i problemi di cui soffrono maggiormente i sistemi tradizionali, dove vale il principio del default-allow.
Di contro, queste architetture non sono intrinsecamente capaci di realizzare servizi strettamente associati al livello di astrazione del sistema operativo o delle applicazioni supportate, ad esempio interagire con file e socket TCP/IP.
Per creare una politica di controllo degli accessi alle risorse virtuali, occorre individuare gli attori:
l'utente o il componente che può mettere a disposizione la risorsa sulla propria macchina virtuale
la risorsa virtuale condivisa(oggetto)
l'utente o il componente che può richiedere l'accesso ad una risorsa disponibile su una macchina virtuale(soggetto)
l'entità che può autorizzarne l'accesso (gestore)
I soggetti sono quelle entità che invocano le operazioni definite dagli oggetti e la loro definizione esatta dipende dal livello di astrazione in cui vengono considerati. Di volta in volta il soggetto può essere l'utente, l'applicazione, il processo, il thread, l'istruzione o la microistruzione.
Analisi del rischio nei sistemi dedicati alla condivisione di file
Sono due i punti critici riguardanti i soggetti:
l'identificazione del soggetto, ovvero come controllare che chi afferma di essere A sia effettivamente A
scegliere la granularità dei diritti dei soggetti
In quest'ultimo caso, la scelta influenza il costo della commutazione del dominio di protezione di un soggetto ed i rischi associati.
Da un lato considerare soggetti a grana grossa rende computazionalmente leggera la concessione e la revoca di diritti, contemporaneamente crea vulnerabilità perché concede diritti inutili. Dall'altro scegliere soggetti a grana fine permette di avere domini di protezione piccoli ma allo stesso tempo aggrava il costo computazionale dovuto alla evoluzione nel tempo dei diritti di un soggetto. Sostanzialmente occorre stabilire un compromesso con il principio del privilegio minimo[75], che afferma che ogni soggetto deve avere tutti e soli i diritti necessari per le sue funzioni (o per il suo ruolo) e per il tempo necessario ad eseguirle. Al diminuire della dimensione del dominio di protezione di un soggetto diminuiscono i rischi associati ad esso.
Poiché ogni dominio può creare e cancellare soggetti durante la sua esecuzione, deve essere possibile rivalutare dinamicamente la politica di condivisione alla luce di queste modifiche.
La costruzione di un'architettura di sicurezza inizia dallo studio del contesto e del modello di utilizzo del sistema da proteggere per poi passare all'analisi del rischio che è composto da:
Analisi delle risorse da proteggere(asset) Analisi delle vulnerabilità
Analisi degli attacchi Analisi delle minaccie Analisi degli impatti
Individuazione del rischio accettabile e introduzione delle contromisure
L'analisi del rischio consente di individuare i requisiti di sicurezza dell'organizzazione; in particolare, essa prevede una valutazione sistematica dei danni e delle probabilità legate a un security incident al fine di concentrare gli investimenti dove essi risultano convenienti, individuando il giusto compromesso tra costi e benefici in termini di riduzione del rischio.
Questo capitolo sviluppa le analisi precedenti nel caso del sistema di interesse. Infine
Analisi del rischio nei sistemi dedicati alla condivisione di file
esamineremo i requisiti e giustificheremo le contromisure adottate e sviluppate nella tesi.
3.2 - Contesto e Assunzioni
Il contesto in cui si opera prevede un host sul quale è istallato un software di virtualizzazione delle risorse fisiche, il Virtual Machine monitor, Xen. Xen esegue:
una macchina virtuale privilegiata, chiamata MV_0
una macchina virtuale dedicata alla condivisione, che chiamerò MV_FS un numero arbitrario di macchine virtuali ospite, chiamate MV_GUEST
La MV_FS esegue il modulo server di un'applicazione, che chiameremo modulo per la condivisione. Compito di questo modulo è di permettere a ciascuna MV_GUEST, che esegue il corrispettivo modulo client, di condividere un numero arbitrario di file contenuti nel proprio file system.
Il modello di utilizzo consiste nel dedicare la MV_FS allo storage di dati, che quest'ultima mette a disposizione delle MV_GUEST, che eseguono operazioni per conto degli utenti
Inoltre si assume che:
il Virtual Machine Monitor sia robusto, cioè faccia parte del TCB la MV_0 e la MV_FS siano trusted
il modulo della MV_FS dedicato alla condivisione sia robusto, in quanto dedicato solo al servizio di condivisione dei dati
il canale di comunicazione tra la MV_FS e le MV_GUEST sia sicuro.
gli indirizzi di rete di tutte le macchine virtuali, sia la MV_FS che le MV_GUEST, presenti sull'host siano assegnati staticamente dall'amministratore della rete.
su ogni MV_GUEST sia presente una sola classe di utenti ed applicazioni con la stesso livello di fiducia
la provenienza ed il contenuto dei dati originati da una MV_GUEST non sia fidato
Analisi del rischio nei sistemi dedicati alla condivisione di file
Virtual Machine Monitor applicazioni
Sistema Operativo
MV_GUEST_1
applicazioni
Sistema Operativo
MV_GUEST_2
File System
Sistema Operativo
CPU, Memoria, Dispositivi I/O
Trusted Computing Base
Condivi sione
Sistema Operativo
MV_FS MV_0
Figura 16: il modello di utilizzo
3.3 Analisi degli asset
Una volta identificato il contesto ed il modello di utilizzo del sistema analizziamo gli asset, cioè le risorse, concrete o astratte, da proteggere da un possibile attacco e l'uso che se ne fa all'interno dell'organizzazione. Ciò richiede di individuare quali attività o processi utilizzano le risorse e quali possono essere i danni nel caso in cui un attacco abbia avuto successo,.Ad esempio, quando un processo è stato bloccato o una risorsa deve essere ricostruita ex novo.
La macchina virtuale MV_FS gestisce e mette a disposizione una parte del proprio File System e tutti i file in essa contenuti ed il modulo dedicato alla condivisione gestisce le richieste di accesso da parte di una o più macchine virtuali utente MV_GUEST e le successive risposte di servizio.
Le risorse da proteggere da un possibile attacco sono quindi:
la MV_FS, in particolare garantendo l'integrità e la disponibilità del modulo di condivisione. Se questo modulo fosse sovvertito, comprometterebbe l'integrità e la disponibilità dell'intero sistema
i dati contenuti nel file system condiviso ed i loro attributi o metadati le applicazioni contenute nel file system condiviso e i loro metadati la capacità di calcolo della MV_FS
Analisi del rischio nei sistemi dedicati alla condivisione di file
la capacità di comunicazione della MV_FS
E' ovvio che la MV_FS sia la macchina virtuale maggiormente esposta ad eventuali attacchi. Infatti essa fornisce accesso a dati condivisi tra un insieme potenzialmente alto di macchine virtuali, e quindi di intruder, e concentra a se una serie di meccanismi di autenticazione e autorizzazione.
Le macchine virtuali utente accedono in modo trasparente ai file condivisi, cioè il meccanismo di condivisione nasconde la struttura del file system remoto e la reale locazione del file sulla rete. Le modalità di accesso ammissibili al file system, da parte delle macchine virtuali utente, sono:
lettura di dati o metadati modifica di dati o metadati creazione di dati o metadati esecuzione di applicazioni
3.4 Analisi delle vulnerabilità
Le vulnerabilità di un sistema possono essere definite come un insieme di difetti di uno o più dei suoi componenti che, se sfruttati opportunamente, possono generare comportamenti inattesi del componente stesso. Tale comportamento inatteso permette di violare almeno una delle proprietà di sicurezza quali, ad esempio, la disponibilità, l'integrità e la confidenzialità. Le vulnerabilità possono essere di tipo organizzativo- procedurale o causate da difetti degli strumenti informatici, ad esempio errori con ripercussioni sulla sicurezza, o da collusioni con l'attaccante, come nel caso del social engineering.
Possiamo classificare le vulnerabilità del sistema considerato in:
vulnerabilità del sistema operativo in cui risiedono i file condivisi e del suo meccanismo per il controllo degli accessi
vulnerabilità del modulo per la condivisione e del protocollo di comunicazione da esso utilizzato
vulnerabilità procedurali dovute alla complessità di istallazione di un sistema di sicurezza per il controllo degli accessi alle risorse condivise
Nel primo caso, ogni sistema dovrebbe essere capace di forzare la separazione delle
Analisi del rischio nei sistemi dedicati alla condivisione di file
informazioni, basata su requisiti di confidenzialità e di integrità, al fine di fornire sicurezza.
Sfortunatamente i sistemi operativi più diffusi basano la propria sicurezza su meccanismi di tipo Discretionary Access Control, che permette al proprietario il controllo completo dei propri file. Ad esempio il proprietario può permettere a propria discrezione ad altri utenti l'accesso a file ed assegnare ai processi tutti i diritti che esso possiede.
Inoltre, tutte le decisioni per gli accessi si basano soltanto sull'identità dell'utente che esegue una certa applicazione e sulla proprietà del file, ignorando altre informazioni rilevanti per la sicurezza quali il ruolo dell'utente, la funzione ed il grado di fiducia dell'applicazione, l'integrità e la criticità del dato.
Di conseguenza non vengono definiti dei controlli contro del codice malevolo che, se istallato su una applicazione eseguita da un utente con privilegi di root, permette anche all'attaccante di ottenere tutti i diritti di root e così compromettere potenzialmente l'intero sistema. Ancora, questo meccanismo distingue soltanto tra il ruolo di amministratore, che possiede tutti i privilegi, e quello di utente, senza privilegi.
Il modulo di condivisione NFS rappresenta un componente standard, di cui sono ben note le vulnerabilità e di cui si conoscono alcuni exploit. Come descritto nel capitolo 2, i problemi di sicurezza di NFS sono legati in larga misura al meccanismo di comunicazione tra client e server che sfrutta le RPC ed il portmapping. Le vulnerabilità di NFS possono essere sfruttate dalle macchine virtuali utente al fine di sovvertire e violare le proprietà di sicurezza su cui si basa la macchina virtuale dedicata al file system.
Inoltre, l'adozione di misure di sicurezza spesso richiede la conoscenza, da parte di chi deve installarle e gestirle, di dettagli architetturali e implementativi che ne complicano notevolmente l'utilizzo. Le difficoltà dovute alla complessità della descrizione e della configurazione di una politica di sicurezza può causare quindi la mancata eliminazione o addirittura l'introduzione di nuove possibili vulnerabilità.
3.5 Analisi degli attacchi
Un attacco rappresenta una sequenza di azioni, che sfruttano una vulnerabilità, eseguite al fine di ottenere il controllo su un sistema. Questo paragrafo descrive e classifica gli attacchi rivolti ai sistemi di storage e di condivisione di file, secondo il modello CIAA[76], che considera gli aspetti più importanti legati alla computer security:
Analisi del rischio nei sistemi dedicati alla condivisione di file
confidenzialità, integrità, disponibilità e autenticazione.
Il primo problema da porsi è di capire chi sono i potenziali attaccanti del sistema.
Si è assunto che sia la macchina virtuale privilegiata, MV_0, che la macchina virtuale dedicata al file system, MV_FS, siano trusted, quindi esse non possono generare un attacco al sistema. Nessuna assunzione invece è stata fatta sull'affidabilità delle macchine virtuali utente, che potrebbero essere usate direttamente o indirettamente come strumento per eseguire attacchi, e sugli utenti che le utilizzano.
Un utente malevolo residente su una macchina virtuale ospite potrebbe sfruttare le vulnerabilità già discusse ed installare del codice malevolo o degli strumenti di controllo per guadagnare privilegi sul dominio dedicato al file system, quindi cancellare le proprie tracce e accedervi liberamente in un altro momento.
Per conoscere e prevedere quali sono gli attacchi permessi ad un attaccante è necessario capire quali sono le informazioni e le risorse che il sistema, nell'implementare il proprio servizio, gli mette a disposizione e le competenze di cui l'attaccante stesso dispone.
I punti che l'attaccante utilizza per guadagnare l'accesso agli asset della macchina virtuale dedicata al file system sono chiamati access entry point . In questo caso tali punti possono essere:
i socket, stabiliti con le macchine virtuali utente sia sulla rete interna dedicata alla condivisione dei file che sulla rete accessibile dall'esterno
l'interfaccia RPC Server, a cui i client, cioè le macchine virtuali utente, inviano le richieste di servizio
operazioni di lettura/scrittura sul file system condiviso
Sfruttando questi punti di accesso alla MV_FS, vediamo come le macchine virtuali utente possono condurre uno o più attacchi permessi dalle vulnerabilità descritte in precedenza.
3.5.1 Attacchi alla confidenzialità
Questi attacchi hanno come obiettivo la lettura di informazioni da un sistema di storage senza possederne l'autorizzazione.
Sniffing del traffico di storage: l'attività di sniffing sulla rete dedicata alla condivisione da parte di una macchina virtuale utente può rivelare dati, metadati e informazioni sul servizio utilizzato per la condivisione(protocollo, versione,
Analisi del rischio nei sistemi dedicati alla condivisione di file
numero di porta, tipo di autenticazione, etc...)
Snooping della cache del buffer: il file system NFS implementa sul server un meccanismo di caching per ottimizzare le operazioni di lettura e scrittura dei blocchi da e sul dispositivo di memoria. Se un attaccante, residente su una macchina virtuale utente, riesce ad infiltrarsi nella cache in memoria della MV_FS può accedere ai blocchi presenti in quel momento
Profiling: questi attacchi usano tipicamente degli scanner di rete e sfruttano le vulnerabilità dei servizi di rete per reperire informazioni su un host della rete, sui servizi attivi, sul sistema operativo. Questi dati vengono utilizzati per scoprire ulteriori vulnerabilità. Un attaccante su una macchina virtuale utente può sfruttare le informazioni restituite dal servizio portmap al fine di scoprire le vulnerabilità della MV_FS, come descritto nel paragrafo 2.1.4.
3.5.2 Attacchi all'integrità
Questi attacchi tentano di modificare l'informazione in un sistema di storage senza avere la necessaria autorizzazione. Modificare significa che utenti residenti sulle macchine virtuali utente possono creare, cambiare, appendere, scrivere o cancellare dati o metadati del file system remoto.
Subversion: questo attacco tenta di modificare i comandi del sistema operativo, le chiamate al kernel, i driver dei dispositivi di storage per cancellare o scrivere file, metadati o blocchi. Come descritto nel capitolo 2.1.4, un attaccante potrebbe sfruttare le vulnerabilità del protocollo RPC per modificare il modulo Server NFS sulla macchina virtuale MV_FS, e quindi sovvertire l'intero sistema di condivisione dei file;
Modifica degli eseguibili: se alcuni dei file esportati in lettura/scrittura dalla MV_FS sono eseguibili, un attaccante può facilmente determinare la versione dell'applicazione utilizzata dalla macchina virtuale dedicata al file system così da risalire alle sue vulnerabilità ed anche modificare il file binario inserendo codice malevolo;
Modifica dei metadati: poichè, in qualsiasi file system, la cancellazione di i-node o della tabella dei file comporta l'impossibilità di accedere ai file ad essi associati un attacco sui metadati è distruttivo per un sistema di storage;
Analisi del rischio nei sistemi dedicati alla condivisione di file
Modifica dei log: un tipico attacco a un sistema informatico prevede come ultima fase la cancellazione delle tracce dell'attaccante. Una macchina virtuale utente potrebbe quindi sfruttare una vulnerabilità della macchina virtuale MV_FS, eseguire un'azione illecita ed eliminare le entry nel file di log che ne avrebbero dovuto segnalare la presenza.
3.5.3 Attacchi alla disponibilità
È questo un attacco che cerca di rendere i dati o i servizi di condivisione delle risorse non disponibili per un certo periodo di tempo ai legittimi utenti. Uno degli attacchi alla disponibilità più difficili da prevenire è il Denial-of-Service(DoS), il cui obiettivo è di esaurire le risorse di calcolo e di memoria disponibili per il sistema di storage.
Esaurimento dello spazio di log: i sistemi di storage utilizzano varie forme di logging, che un attaccante può sfruttare generando un grande numero di piccole modifiche. In questo modo, una delle MV_GUEST può inviare alla MV_FS una lunga serie di richieste per saturare lo spazio di log in modo da bloccare il meccanismo di logging, o addirittura l'intero sistema;
Esaurimento dello spazio del disco: una macchina virtuale utente può generare una grande quantità di file con contenuto casuale così da esaurire lo spazio su disco disponibile per la MV_FS;
Esaurimento dello spazio dei metadati: un attaccante può creare numerosi file nascosti,vuoti o di piccola dimensione. Poiché ciascuno di essi usa un record nella tabella dei metadati, la presenza di una grande quantità di record ha l'effetto di degradare le prestazioni del sistema di storage;
Esaurimento dei filehandle: come discusso nel paragrafo 2.1, i filehandle, utilizzati dal server NFS per gestire le richieste effettuate dai client, sono bloccati finché il file a cui si riferiscono non è stato chiuso. Inoltre NFS prevede un numero massimo di filehandle da poter servire contemporaneamente. Un attaccante può quindi generare un attacco DoS aprendo numerosi file sulla MV_FS senza mai chiuderli, in modo tale da deteriorare le prestazioni della macchina virtuale;
Congestione della rete: un attacco in cui l'obiettivo è di congestionare la rete di comunicazione tra le macchine virtuali utente e la macchina virtuale dedicata al file system provoca la degradazione delle prestazioni o la disabilitazione del
Analisi del rischio nei sistemi dedicati alla condivisione di file
sistema di condivisione delle risorse.
3.5.4 Attacchi alla autenticazione
Questi attacchi avvengono quando un attaccante assume l'identità di un utente legittimo, utilizzando delle credenziali rubate o false, e come tale può lanciare attacchi alla confidenzialità(accesso a dati o metadati), alla integrità(modifica di dati o metadati) e alla disponibilità(blocco di dati o metadati).
IP Spoofing: un attacco di spoofing modica le credenziali della macchina sorgente di un messaggio per impersonare un'altra macchina autorizzata. Poiché il file system NFS è esportato ai client in base al loro indirizzo IP, un attaccante su una macchina virtuale utente può modificare l'indirizzo sorgente nei messaggi al server NFS e quindi effettuare richieste al file system impersonando altre macchine virtuali utente.
Sicurezza della classe DAC : poiché lo schema di autenticazione e di controllo degli accessi adottato dai sistemi Unix segue, di default, la classe di politiche DAC, ed il server NFS utilizza l'UID e il GID dell'utente che effettua la richiesta per autorizzare l'accesso ai file. Un attaccante residente su una macchina virtuale utente che riesca a guadagnare privilegi sulla MV_FS può eseguire azioni potenzialmente dannose, a causa dell'inadeguatezza della classe di politiche DAC di cui si è già discusso nel paragrafo 3.4.
3.6 Analisi delle minacce
Tutte le macchine virtuali utente che possono accedere al file system condiviso hanno la stessa configurazione, le stesse risorse a disposizione e gli stessi entry access point attraverso i quali lanciare un attacco . Inoltre, tutte potrebbero essere potenzialmente interessante ad attaccare la MV_FS allo scopo di accedere a file sensibili o a sovvertire l'intero sistema.
Poiché l'intersezione di questi due insiemi non è vuota, allora la probabilità di un attacco non è nulla.
Analisi del rischio nei sistemi dedicati alla condivisione di file
3.7 Requisiti
Specificare i requisiti delle contromisure significa identificare i meccanismi di sicurezza da introdurre e come il nuovo sistema mitighi i rischi legati alle minacce ed alle vulnerabilità esaminate.
I requisiti di confidenzialità, integrità, autenticazione e disponibilità rappresentano le caratteristiche di cui ogni sistema dovrebbe tener conto per garantire una adeguato livello di sicurezza ai dati in esso contenuti. Per questo motivo, si utilizza per i sistemi di storage lo stesso modello di sicurezza applicato in altri domini della computazione, ad esempio quelli delle applicazioni e delle reti informatiche, che si basano su un forte meccanismo di autenticazione e di analisi dell'integrità, la replicazione dei dati e la crittografia. Purtroppo però ciascuno di essi, singolarmente, non rappresenta una soluzione totale per la protezione dello storage e in fase di design di un sistema per la sicurezza non è possibile utilizzarli tutti perché ciò sarebbe troppo dispendioso ed i loro requisiti risultano spesso in conflitto.
Bisogna quindi valutare gli effetti di ogni contromisura rispetto alle minacce e alle vulnerabilità dell'ambiente specifico prima di disegnare o implementare qualsiasi soluzione per la protezione dello storage.
Il requisito fondamentale nel problema considerato è di proteggere in modo adeguato gli asset esaminati in precedenza. In particolare, l'architettura dei sistema di sicurezza deve:
permettere di descrivere le regole della politica di condivisione, in modo semplice e comprensibile, senza dover conoscere l'implementazione e la struttura dell'architettura
forzare tutte le macchine virtuali utente a rispettare la politica
permettere un controllo a grana fine e parametrizzabile su soggetti, le macchine virtuali utente, e gli oggetti, i file condivisi.
differenziare il livello di protezione di ciascun file memorizzato, in base alla criticità dei dati in esso contenuti.
essere parametrizzabile sulle politiche di sicurezza più diffuse(DAC, MAC, RBAC, MLS) ed in generale rappresentare un supporto flessibile per le politiche di sicurezza
sfruttare il più possibile le funzionalità di introspezione offerte dal Virtual
Analisi del rischio nei sistemi dedicati alla condivisione di file
Machine Monitor ed i controlli a livello di sistema operativo e di macchina virtuale
minimizzare l'overhead dovuto al controllo degli accessi non ridurre significativamente l'usabilità del sistema
Per soddisfare questi requisiti nel prossimo capitolo saranno descritte le contromisure adottate, alcune delle quali sono soluzioni standard, altre sono estensioni ed integrazioni di soluzioni standard
