LA VIRTUALIZZAZIONE E I SUOI ASPETTI DI SICUREZZA

Транскрипт

1 LA VIRTUALIZZAZIONE E I SUOI ASPETTI DI SICUREZZA

2 Il testo è stato redatto da: Sergio Sagliocco SECURELAB CSP Innovazione nelle ICT Diego Feruglio CSI-Piemonte Gianluca Ramunno Politecnico di Torino Si ringraziano per la revisione finale del testo e per i preziosi suggerimenti forniti: Roberto Moriondo Regione Piemonte Nicola Franzese Laboratorio ICT Regione Piemonte Mario Ancilli Consiglio Regionale del Piemonte Laura Gonella CSP Innovazione nelle ICT Francesco Meschia CSI-Piemonte Daniele Mazzocchi Istituto Boella Sergio Duretti CSP Innovazione nelle ICT Si ringraziano i rappresentanti del Consiglio Direttivo di Assosecurity per il contributo fornito nell ideazione della pubblicazione. I contenuti sono soggetti a licenza Creative Commons, Attribuzione Non Commerciale Non opere derivate 2.5 Italia, il cui contenuto integrale è riportato all indirizzo: BY: 2 La virtualizzazione e i suoi aspetti di sicurezza

3 SOMMARIO Prefazione 7 Introduzione 8 1 La virtualizzazione: concetti di base Che cosa si intende per virtualizzazione Cenni storici Vantaggi e svantaggi della virtualizzazione Tecniche di virtualizzazione dei server 13 2 Virtualizzazione mediante partizionamento Soluzioni tecnologiche Hardware Partitioning Hypervisor Virtual Machine Monitor OS virtualization Approcci implementativi Virtualizzazione completa Paravirtualizzazione Supporti hardware 20 3 Prodotti per la virtualizzazione Sun Solaris Containers/Zones VMware Hyper-V Xen KVM Libvirt 29 3

4 4 Aspetti per il dimensionamento di una struttura Networking Storage Server 32 5 La sicurezza negli ambienti virtualizzati Virus basati sulla virtualizzazione User Space e Kernel space rootkit HVM rootkits SubVirt Blue Pill Vitriol Xen Subvertion Virtual machine detection Ricerca di artefatti specifici dell hypervisor Analisi dei tempi di esecuzione Utilizzo di hardware embedded Analisi remota dello stack di rete Progetti Red Pill Scoopy Doo VMDetect Live Migration VM Escape & Denial Of Service VMware Xen/QEMU 46 4 La virtualizzazione e i suoi aspetti di sicurezza

5 5.5 VM Integrity Cifratura dei dischi virtuali gestita dal VMM Cifratura dei dischi in VMware ACE Cifratura dei dischi virtuali gestita dai sistemi guest Cifratura dei dischi virtuali gestita dal sistema host Network Isolation VirtualServer VMware ESX Xen Cisco Nexus 1000V Virtual Switch 53 6 Nuovi orizzonti per la virtualizzazione Cenni sulla tecnologia Trusted Computing Uso combinato di virtualizzazione e Trusted Computing 57 Acronimi 61 Bibliografia 63 5

6

7 Prefazione È con grande piacere che introduco il presente testo, frutto della collaborazione tra i soci di Assosecurity, collaborazione scientifica e redazionale ormai divenuta nel corso degli anni un appuntamento fisso ed un occasione di confronto e rinnovamento in cui le finalità di divulgazione scientifica e culturale dell Associazione trovano concreta attuazione. La pubblicazione di quest anno mira a diffondere conoscenze specifiche nel campo della sicurezza dei sistemi virtualizzati, un settore sempre più rilevante nel mondo delle ICT. Grazie al lavoro di analisi e approfondimento avviato dal CSP e sviluppato in collaborazione con il Laboratorio ICT della Regione Piemonte, il CSI Piemonte e il Politecnico di Torino, presentiamo con questo volume lo stato dell arte nel settore della Virtualization Security, ovviamente senza alcuna pretesa di esaustività ma con l obiettivo documentato dalla nutrita presenza di casi di studio di fornire a tutti i lettori un quadro di riferimento il più possibile ampio e documentato sul tema. Commenti ed osservazioni sono graditi e possono essere inviati a: [email protected] Buona lettura! Prof. Antonio Lioy Presidente Assosecurity 7

8 INTRODUZIONE Il concetto di virtualizzazione di un sistema di elaborazione non è recente: uno dei primi esempi, introdotto dalla IBM, risale agli anni 60. Tuttavia, negli ultimi dieci anni, si è assistito ad un forte incremento dell uso di questa tecnica, che permette di contenere i costi di gestione e di sfruttare al meglio le risorse dei centri di elaborazione dati. Si può stimare che in media la potenza di calcolo di ogni singolo elaboratore sia sfruttata solo in minima parte. Questo dato - unito a quelli relativi ai costi di manutenzione, energia elettrica ed impianti di condizionamento - rende particolarmente conveniente per i responsabili dei CED, adottare la virtualizzazione dei server, una tecnica che permette l esecuzione di più macchine virtuali su un solo server fisico. L uso e il numero dei server installati viene razionalizzato, mantenendo inalterate le capacità funzionali del sistema. Oggi la virtualizzazione è una tecnologia matura che sta diventando ampiamente utilizzata a livello enterprise: numerose e particolarmente delicate sono le problematiche di sicurezza legate all uso di questa soluzione. La presente pubblicazione ha quindi l obiettivo di apportare un contributo a quanti abbiano adottato o intendano adottare tecniche di virtualizzazione e si trovino ad affrontare le relative problematiche di sicurezza. La prima parte del volume, che va dal primo al quarto capitolo, si focalizza sulle tecniche implementative, le soluzioni e i prodotti per la virtualizzazione, mentre il quinto capitolo affronta gli aspetti legati alla sicurezza. Il primo capitolo si sofferma sull evoluzione storica della virtualizzazione ed esamina una classificazione delle diverse tecniche. Il secondo capitolo prende in considerazione le soluzioni tecnologiche e gli approcci implementativi più diffusi, mentre il terzo descrive alcuni dei prodotti commerciali e dei progetti open source più noti. Il quarto capitolo tratta i diversi aspetti che devono essere presi in considerazione quando si realizza un infrastruttura di virtualizzazione complessa facendo riferimento ai componenti di base: networking, storage e server. Il quinto capitolo, che rappresenta una parte molto consistente dell elaborato, affronta gli aspetti di sicurezza di una specifica tecnica di virtualizzazione dei server, la Partitionig Virtualization, e in particolar modo dei sistemi di Hypervisor e di VMM (Virtual Machine Monitor). Vengono affrontati gli aspetti di sicurezza più critici legati al mondo della virtualizzazione, in particolare: Virus basati sulla virtualizzazione Rilevamento di un sistema virtualizzato Riallocazione dinamica delle immagini virtuali Isolamento delle macchine virtuali e denial-of-service Integrità delle macchine virtuali Isolamento del traffico di rete Il sesto e ultimo capitolo, esamina un nuovo paradigma di sicurezza che sfrutta la virtualizzazione in modo sinergico con una tecnologia sempre più emergente chiamata Trusted Computing. 8 La virtualizzazione e i suoi aspetti di sicurezza

9 1 La virtualizzazione: concetti di base Il concetto di virtualizzazione è molto ampio e per questo motivo spesso genera confusione e imprecisioni. È necessario quindi, prima di analizzare le problematiche inerenti questa tecnologia, soffermarsi sull evoluzione storica della virtualizzazione ed effettuare una classificazione delle diverse tecniche. 1.1 Che cosa si intende per virtualizzazione In generale si può definire virtualizzazione qualunque processo in grado di astrarre i dettagli fisici di una risorsa reale al fine di permettere ai suoi utenti un accesso più semplice, efficiente o sicuro. Utente Risorsa Logica Livello di astrazione Risorsa Fisica Figura 1: Concetto generale di virtualizzazione Per spiegare questo concetto (di per sé molto astratto) possono essere utili degli esempi: Un comune disco rigido di un personal computer è composto da uno o più piatti i quali a loro volta sono suddivisi in cilindri e settori 1. L utente finale, ovviamente, non deve conoscerne la geometria fisica in quanto vi è il sistema operativo che, attraverso un opportuno modulo, denominato file system, mostra all utente un generico spazio 1 Si parla di geometria del disco. 9

10 di memorizzazione organizzato in cartelle (directory) e documenti (file) 2. Facendo riferimento alla Figura 1 questo esempio può essere così schematizzato: Utente Cartelle e documenti File System del S.O. Geometria Fisica del disco Figura 2: Esempio: astrazione di un disco Un altro esempio è quello della memoria virtuale, ovvero quella tecnica mediante la quale il sistema operativo mostra alle applicazioni una memoria (RAM) ben più ampia di quello che è, mediante l uso di ulteriori supporti di memorizzazione. Applicazione Memoria Virtuale Gestore della memoria del S.O. RAM DISCO Figura 3: Esempio: memoria virtuale 2 I file system più noti sono FAT, NTFS e EXT. 10 La virtualizzazione e i suoi aspetti di sicurezza

11 La virtualizzazione dei server è una tecnica che permette l esecuzione di più macchine virtuali su un solo server fisico ed è usata allo scopo di ottimizzare le risorse disponibili. Come verrà illustrato nei prossimi paragrafi, con la virtualizzazione vengono creati diversi livelli di astrazione che fanno sì che il sistema operativo non veda l hardware fisico ma l hardware virtuale. Utente Server Virtuale 1 Server Virtuale N Gestore dei server virtuali Server Fisico Figura 4: Virtualizzazione dei server 1.2 Cenni storici Come accennato nell introduzione, uno dei primi esempi di virtualizzazione di un sistema di elaborazione risale agli anni 60 ed è stato introdotto coi sistemi chiamati CP/CMS progettati ed implementati dall IBM; la componente CP (Control Program) di fatto rappresentava il livello di astrazione il cui compito era quello di fare vedere ai livelli superiori (il sistema operativo) diverse macchine logiche al posto dell hardware fisico; il CMS (Conversational Monitor System) era il sistema operativo (monoutente) che girava sopra ogni macchina virtuale; il vantaggio di questa architettura era enorme se si considera che in quel periodo storico non esistevano ancora sistemi operativi multitasking interattivi. In seguito, l avvento dei nuovi sistemi operativi ha fatto sì che questa architettura venisse abbandonata con la conseguente progressiva dismissione dei mainframe e l aumento spropositato del numero di PC/server presso i CED delle aziende. Negli ultimi anni ci si è resi conto che la potenza di calcolo di ogni singolo elaboratore è mediamente utilizzata solo al 20%; questa considerazione unita ai dati relativi ai costi in termini di manutenzione, energia elettrica ed impianti di condizionamento ha fatto sì che si intraprendesse nuovamente la strada della virtualizzazione. 11

12 1.3 Vantaggi e svantaggi della virtualizzazione Come si è detto la virtualizzazione dei server permette di ottimizzare le risorse fisiche disponibili e di facilitare la gestione e l uso dei server. Più nel dettaglio, i vantaggi di questa tecnica di virtualizzazione sono i seguenti: la riduzione dei server fisici: le soluzioni hardware/software per la virtualizzazione permettono l esecuzione di diverse macchine virtuali su un solo server fisico con il vantaggio di ridurre i consumi energetici, il calore generato (sono necessari impianti di condizionamento meno potenti), i guasti hardware, i tempi tecnici per il montaggio e il cablaggio, il numero di armadi rack, lo spazio dedicato in sala macchine e il relativo cablaggio; il consolidamento dei server: si stima che mediamente un moderno server venga sfruttato solo al 15-20%. È quindi ragionevole che possano essere eseguite 3 o 4 macchine virtuali sullo stesso hardware fisico; l indipendenza hardware: il software, ed in particolar modo il sistema operativo, è strettamente legato all hardware sottostante. Se quindi per qualche motivo un installazione di un server deve essere spostata o clonata su un altra macchina, si dovranno tenere in conto diversi problemi di incompatibilità hardware (ad esempio si dovranno installare tutti i driver mancanti del nuovo hardware). Come verrà illustrato nei prossimi capitoli, una delle caratteristiche della virtualizzazione è quella di creare livelli di astrazione tali per cui il sistema operativo non vede l hardware fisico bensì un hardware virtuale. In questo modo l amministratore può spostare o clonare un sistema su altre macchine che eseguono lo stesso ambiente di virtualizzazione senza preoccuparsi dei dettagli fisici (modello delle schede di rete, schede grafiche, chipset e così via); l adattabilità: spesso in un azienda cambiano le priorità e le esigenze, per cui un servizio può diventare più importante di un altro e necessitare di risorse maggiori. La virtualizzazione permette di allocare le risorse hardware virtuali in modo decisamente più veloce e flessibile. Se necessario, la macchina virtuale può, inoltre, essere spostata su un hardware più efficiente in modo totalmente trasparente; il supporto alle applicazioni legacy: non è raro trovare nelle sale macchine delle aziende vecchi server con vecchi sistemi operativi (ad esempio il DOS) che non possono essere spostati su macchine nuove in quanto non sarebbero supportati. Gli ambienti di virtualizzazione permettono l esecuzione anche di sistemi legacy permettendo ai responsabili IT di liberarsi del vecchio hardware non più supportato e più soggetto a guasti; la standardizzazione delle installazioni: grazie all astrazione dell hardware è possibile preparare una sola volta le immagini di ambienti omogenei (come ad esempio quello delle postazioni di lavoro o server di sviluppo) comprensivi di sistema operativo, applicazioni e configurazioni particolari (ad esempio dominio, posta elettronica, LDAP, policy di sicurezza, ecc.); la creazione di ambienti di test: capita frequentemente che su un sistema in produzione si debbano apportare delle modifiche senza sapere quali siano le conseguenze: ad esempio l installazione di un aggiornamento del sistema operativo o soprattutto di una service pack non è un operazione priva di rischi. La virtualizzazione permette la replica immediata di una macchina virtuale per poter effettuare tutti i test di stabilità richiesti. 12 La virtualizzazione e i suoi aspetti di sicurezza

13 Ovviamente, come ogni altra tecnologia, l uso della virtualizzazione porta inevitabilmente a degli inconvenienti che variano a seconda dello scenario applicativo e devono essere valutati prima di avviare la virtualizzazione. Gli aspetti che devono essere tenuti in considerazione sono i seguenti: l overhead: ogni soluzione di virtualizzazione fa decrescere le performance globali, come ad esempio i tempi di accesso ai dischi, accesso alla memoria e cosi via. Alcune applicazioni particolarmente critiche potrebbero risentire dell overhead introdotto dall ambiente di virtualizzazione; l hardware non virtualizzabile: a seconda dei prodotti utilizzati, alcune periferiche potrebbero non essere usate dalle macchine virtuali, come ad esempio porte seriali/parallele, dispositivi USB, interfacce bluetooth, accelerazioni grafiche hardware e così via. 1.4 Tecniche di virtualizzazione dei server La virtualizzazione dei server può essere divisa in diverse tipologie a seconda della tecnica utilizzata. La seguente figura mostra una possibile classificazione. Server Virtualization Aggregation Virtualization Partitioning Virtualization Instruction-Set Virtualization Hardware Partitioning Hypervision Virtual Machine Monitor OS Virtualizzato n Hypervisor Hosted VMM OS Hosted VMM Figura 5: Classificazione delle tecniche di virtualizzazione 3 3 La figura è tratta (e qui riadattata) da Phelp J.R., Dawson P. (luglio 2007). 13

14 Come si può notare si possono identificare tre macro tecniche di virtualizzazione: 1. Mediante partizionamento (Partitioning Virtualization): in questa categoria rientrano quei sistemi che permettono di configurare l hardware fisico in più macchine logiche in grado di ospitare ognuna un suo sistema operativo. Questi sistemi possono essere ancora classificati in: Hardware Partitioning Hypervisor Virtual Machine Monitor (VMM) OS Virtualization. 2. Mediante emulazione (Instruction-Set Virtualization): questi sistemi permettono di emulare un diverso sistema hardware/software allo scopo di eseguire applicazioni scritte per diverse piattaforme; per questa ragione sono comunemente chiamati emulatori. Esempi molto noti sono: gli ambienti di sviluppo per dispositivi mobili, in cui è possibile eseguire gli applicativi (ad esempio Symbian) su PC in modo tale da agevolare le fasi di debugging; MAME 4 (Multiple Arcade Machine Emulator), il quale permette l esecuzione su PC dei vecchi videogiochi da bar degli anni 80 (senza modificare il codice originale). Gli esempi precedenti fanno riferimento a emulatori software; esistono anche emulatori hardware come ad esempio il processore Crusoe della Transmeta 5 ; si tratta di CPU che, pur non essendo in modo nativo compatibili con l architettura x86 6, tramite il livello di astrazione Code Morphing Software (CMS), possono essere usate come normali CPU x86 grazie alla traduzione delle istruzioni x86 in istruzioni VLIW. In questa categoria si può far rientrare anche la nota JAVA Virtual Machine (JVM) 7 in quanto effettua una traduzione al volo del byte code java in istruzioni eseguibili sul sistema nativo. 3. Mediante aggregazione (Aggregation Virtualization): a differenza delle altre due tecniche, in questo caso più macchine virtuali vengono aggregate fra di loro per fare eseguire un unica applicazione. Un caso tipico è l uso del GRID Computing o più in generale delle tecniche di calcolo distribuito; esse sono basate sulla possibilità di poter suddividere il compito principale in task più semplici e indipendenti fra di loro: ogni task è assegnato ai diversi nodi dell infrastruttura di calcolo ed alla fine i risultati vengono assemblati da nodi dedicati. La presente pubblicazione è focalizzata sugli aspetti di sicurezza della virtualizzazione basata su partizionamento (ed in particolar modo sugli Hypervisor e il Virtual Machine Monitor) che costituisce il sistema più diffuso nelle aziende e tra gli utenti privati Queste CPU appartengono all architettura Very Long Instruction Word (VLIW) La virtualizzazione e i suoi aspetti di sicurezza

15 2 Virtualizzazione mediante partizionamento In questo capitolo verranno prese in considerazione le soluzioni tecnologiche e gli approcci implementativi della virtualizzazione basata su partizionamento (Figura 5). In particolare, nel primo paragrafo si descriveranno le soluzioni tecnologiche più utilizzate, mentre nel secondo verranno discussi i due approcci implementativi più diffusi, ovvero quello della virtualizzazione completa e quello della paravirtualizzazione. Si tenga presente che la classificazione adottata ha lo scopo di mettere in evidenza i diversi approcci implementativi che stanno alla base dei progetti e dei prodotti descritti, ma che non è perfettamente applicabile nel caso di soluzioni ibride. Per concludere (paragrafo 2.3), questo capitolo affronterà la discussione dei supporti hardware per la virtualizzazione delle due maggiori case costruttrici di processori (Intel e AMD). 2.1 Soluzioni tecnologiche Hardware Partitioning Questi sistemi permettono la suddivisione di un sistema di elaborazione in diverse macchine tramite una definizione delle risorse a livello hardware; si associano quindi ad ogni macchina una o più board del sistema ognuna con i propri processori e la propria memoria. Questa tecnica si utilizza per superare il limite dei processori (socket) presenti su una singola board. Queste tecniche non permettono la condivisione delle risorse e la riallocazione ottimale; d altra parte hanno il vantaggio di non avere overhead per la gestione della virtualizzazione in quanto i confini di ogni macchina sono definiti a livello hardware. Alcuni esempi di prodotti sono npartition 8 della HP e Dynamic System Domains 9 della SUN Hypervisor Col termine hypervisor si intende quello strato di software che permette solamente l astrazione dell hardware fisico. Generalmente viene caricato all avvio del sistema di elaborazione e non integra nessuna funzionalità di gestione di macchine virtuali

16 Figura 6: Sistema virtualizzato tramite hypervisor La Figura 6 mostra come l hypervisor permetta la condivisione dell hardware fisico tra diverse macchine virtuali 10. Ovviamente, l hardware rilevato da ogni macchina virtuale differisce sia dal punto di vista qualitativo che da quello quantitativo rispetto a quello fisico: ad esempio, se il server fisico possiede una scheda video ATI, l hypervisor potrebbe presentarla come una VGA standard. Come descritto meglio nel prossimo paragrafo, per avere una gestione completa delle macchine virtuali (gestione del ciclo di vita, gestione delle priorità, ) è necessario disporre di una componente aggiuntiva che a seconda delle architetture può essere o non essere incorporata all interno dell hypervisor Virtual Machine Monitor Il VMM è il software vero e proprio che gestisce la condivisone delle risorse hardware e il ciclo di vita di ogni macchina virtuale; in particolare i compiti di un moderno VMM sono: esporre alle macchine virtuali le opportune interfacce hardware; gestire l interazione tra le diverse macchine virtuali; garantire l isolamento tra le macchine virtuali; garantire la stabilità del sistema, impedendo alle macchine virtuali di poter eseguire istruzioni privilegiate in modo non controllato. A seconda che sia ospitato da un sistema operativo nativo o da un hypervisor, il VMM viene chiamato OS-hosted VMM oppure Hypervisor-Hosted VMM. 10 Queste macchine vengono chiamate anche macchine guest o VM (Virtual Machine). 16 La virtualizzazione e i suoi aspetti di sicurezza

17 Alcuni esempi della prima tipologia sono: Microsoft Virtual Server 11, Microsoft Hyper-V 12 (stand alone edition), VMware server 13, Virtual Box 14, Parallels Server 15. Alcuni esempi della seconda tipologia sono: Microsoft Hyper-V, Xen 16 e relativi prodotti derivati da esso (OracleVM 17, VirtualIron 18, SUN xvm 19 ), VMware ESX server 20, Parallels Server Bare Metal 21, Linux KVM 22. Come si può notare, alcune aziende sviluppatrici di prodotti per la virtualizzazione (per esempio VMware e Microsoft), rilasciano sia la versione Hypervisor-Hosted sia la versione OS-hosted. I sistemi VMM Hypervisor-Hosted solitamente sono più complessi in quanto devono essere dotati di tutti i driver necessari a supportare l hardware virtualizzato. Per tale ragione solitamente essi sono certificati solo per determinati sistemi di elaborazione. I VMM OS-hosted invece sono più semplici (in quanto sono a tutti gli effetti delle applicazioni) a scapito però di una minore efficienza rispetto ai VMM Hypervisor-Hosted. Figura 7: Differenza fra Hosted VMM e UnHosted VMM

18 2.1.4 OS virtualization Questa tecnica, a differenza delle altre, inserisce lo strato di virtualizzazione fra sistema operativo e applicazioni, come schematizzato nella figura seguente: Figura 8: OS Virtualization 23 La virtualizzazione in questo caso prevede la creazione di una zona o copia del sistema operativo di base e di uno specifico albero di processi isolato. I processi contenuti in esso non possono afferire a processi esterni ovvero ai processi di altre zone. Si ottiene un ambiente simile ad una macchina virtuale ma con minore overhead. Esempi di questo tipo sono SUN Solaris Containers/Zones 24, FreeBSD Jails 25, Virtuozzo 26 e OpenVZ Approcci implementativi Nell ambito dei diversi VMM, possono essere adottati diversi approcci implementativi che possono essere ricondotti a due grandi famiglie: la virtualizzazione completa e la paravirtualizzazione Virtualizzazione completa La tecnica della virtualizzazione completa prevede che il VMM mostri alla macchina virtuale tutto l hardware necessario all esecuzione di un sistema operativo tradizionale; il VMM, quindi, tramite un BIOS virtuale, espone la/le CPU, le memorie, i dispositivi di memorizzazione e così via. 23 La figura è tratta dal sito web della società Parallels, La virtualizzazione e i suoi aspetti di sicurezza

19 Il vantaggio principale di questo paradigma riguarda la possibilità di eseguire sulle macchine virtuali tutti i tradizionali sistemi operativi senza che questi debbano essere modificati in quanto l hardware emulato risulta completamente trasparente. D altra parte, le complicazioni derivanti dall utilizzo di un VMM di questo genere sono una maggiore complessità ed una maggiore dipendenza dal tipo di CPU: quest ultima, come si capirà meglio proseguendo la lettura, condiziona in modo decisivo sia la stabilità che la complessità del VMM. Per capire come funziona un VMM di questo tipo è necessario innanzitutto ricordare che una moderna CPU funziona su almeno due livelli di privilegio (ring): uno denominato supervisore (o anche ring 0) e l altro (o gli altri) denominato utente; normalmente all interno del primo anello viene eseguito il sistema operativo (kernel e moduli/driver), mentre nel secondo vengono eseguiti gli applicativi; all interno del livello supervisore è ammessa l esecuzione di tutte le istruzioni della CPU (privilegiate e non) mentre a livello utente è possibile la sola esecuzione delle istruzioni non privilegiate. Nel caso in cui un applicazione utente tenti di eseguire un istruzione privilegiata la CPU (a seconda dei tipi) può comportarsi in due modi: ignorare la richiesta di esecuzione; avvisare il sistema operativo tramite una trap: il sistema operativo valuta la richiesta e intraprende le opportune azioni. Nel caso in cui una CPU sia in grado di intercettare tutte le istruzioni privilegiate viene definita naturalmente virtualizzabile. Si intuisce facilmente che una CPU di questo tipo ha un duplice vantaggio sui VMM: maggiore efficienza: le macchine virtuali possono eseguire direttamente il codice sulla CPU fisica senza alcun overhead da parte del VMM; maggiore stabilità: nel caso in cui una macchina virtuale esegua un istruzione privilegiata e quindi potenzialmente dannosa per l intero sistema, la CPU la interrompe e ne dà notifica al VMM 28 che esegue le opportune azioni. Purtroppo esistono alcune CPU che non sono naturalmente virtualizzabili: in questi casi il VMM deve prevedere una fase di parsing delle istruzioni da eseguire in modo da poter intercettare quelle che la CPU nativamente non fa: ad esempio VMware implementa una tecnica chiamata fast binary translation che consente la traduzione al volo di un codice potenzialmente pericoloso permettendone la notifica al VMM (a scapito di un maggiore overhead). 28 In questa discussione, per semplicità, si è assunto che i livelli di protezione della CPU siano solo due e che quindi il VMM sia una componente del sistema operativo. Le CPU normalmente hanno più di due livelli di protezione ed è quindi pensabile che Sistema Operativo, VMM e Macchina virtuale siano eseguiti in tre livelli gerarchicamente differenti. 19

20 2.2.2 Paravirtualizzazione I VMM paravirtualizzati, a differenza di quelli descritti in precedenza, non emulano l hardware della macchina fisica, ma definiscono e implementano un interfaccia applicativa tra VMM e sistema operativo della macchina virtuale (anche nota come Virtual Hardware API). La conseguenza primaria di un approccio di questo tipo è che il sistema operativo guest deve essere consapevole di essere in esecuzione in un ambiente virtuale; ne consegue che un sistema operativo per essere eseguito in un ambiente paravirtualizzato deve essere opportunamente modificato rispetto alla sua versione originale. Questo paradigma ha quindi lo svantaggio di dover sviluppare il porting di ogni sistema operativo, ma ha tutta una serie di vantaggi: i VMM sono molto snelli e semplici da realizzare; i VMM sono svincolati da CPU che non siano naturalmente virtualizzabili; l ambiente paravirtualizzato permette una maggiore interattività tra VMM e sistema operativo guest consentendo una maggior efficienza nella gestione delle risorse condivise (ad esempio nel caso della gestione della paginazione, il VMM può chiedere ai sistemi operativi guest quali sono le pagine di memoria usate di meno). Attualmente uno dei progetti più noti orientati alla paravirtualizzazione è XEN 29, il prodotto sviluppato dall Università di Cambridge e rilasciato con licenza opensource: su di esso l unico sistema operativo di cui è stato fatto il porting completo è Linux (XenoLinux); altri porting (più che altro sperimentali) sono in corso (ad esempio XenoXP Windows e XenoBSD). 2.3 Supporti hardware Come descritto nei paragrafi precedenti l implementazione di un VMM risulta più semplice (e quindi di conseguenza meno costosa e meno soggetta a bachi) se la piattaforma hardware sottostante (ed in particolare le CPU) prevede in modo nativo una serie di funzioni in grado di agevolare l esecuzione del VMM e delle relative macchine virtuali. Nel corso degli ultimi anni, i due produttori di CPU più noti (Intel e AMD) hanno realizzato un supporto alla virtualizzazione in termini di estensione dell Instruction Set e di strutture dati dedicate. Intel ha sviluppato due supporti hardware chiamati VT-x e VT-i utilizzati rispettivamente nelle architetture a 32 bit (IA-32) e a 64-bit (IPF Itanium Processor Family). In particolare VT-x definisce due nuove modalità della CPU dedicate alla virtualizzazione 30 : VMX root operations, dedicata all esecuzione del VMM; VMX non-root operations, dedicata all esecuzione delle macchine virtuali Virtual Machine Extensions (VMX). 20 La virtualizzazione e i suoi aspetti di sicurezza

21 La transizione da una VMX privilegiata ad una non privilegiata è chiamata VM exit, mentre quella contraria VM entry. Figura 9: VMX: transizioni di stato 31 Tali modalità sono ortogonali alla suddivisione nei quattro livelli di protezione: ciò vuol dire che all interno degli stati VMX continuano a valere le stesse regole di protezione con l importante conseguenza che il sistema operativo della macchina virtuale può essere eseguito normalmente nel ring-0. La figura sottostante mostra come sono impiegate le modalità VMX e i livelli di protezione nel caso in cui il VMM sia integrato in un hypervisor (Hypervisor-Hosted). Figura 10: VMX e livelli di protezione La figura è tratta dalla presentazione della Digital Enterprise Group Intel Corporation, Understanding Intel Virtualization Technology, TWAR05015_WinHEC05.ppt 32 Idem. 21

22 Oltre alle due modalità VMX, l estensione VT-x prevede l uso di una struttura dati (una per ogni macchina virtuale attiva) chiamata VMCS (Virtual Machine Control Structure): le funzioni fondamentali di tale struttura sono la gestione delle transizioni di stato VMX (entry e exit) e la definizione delle azioni da intraprendere nel caso in cui la macchina virtuale esegua determinate istruzioni (privilegiate e non). Per quanto riguarda invece il mondo AMD, la tecnologia che implementa l ausilio hardware alla virtualizzazione è chiamata SVM 33. Essa consente di: ottimizzare il cambio di contesto tra VMM e macchina virtuale e viceversa (world switch); intercettare istruzioni ed eventi delle macchine virtuali passando il controllo al VMM; gestire gli interrupt relativi all esecuzione delle macchine virtuali; gestire indirizzamenti di memoria separati per le macchine virtuali. Analogamente alla tecnologia VT-x, SVM introduce la modalità guest dedicata all esecuzione delle macchine virtuali; in questa modalità si entra quando il VMM esegue l istruzione speciale VMRUN. Il sistema guest viene eseguito fino a che non si verifica uno di questi eventi: esegue l istruzione VMMCALL; esegue un istruzione o scatena un evento per cui il VMM aveva espressamente richiesto l interruzione. In SVM la struttura dati analoga al VMCS si chiama VMCB (Virtual Machine Control Block). Figura 11: Supporto hardware in AMD (SVM) 33 La tecnologia è anche nota con il nome in codice Pacifica. 22 La virtualizzazione e i suoi aspetti di sicurezza

23 3 Prodotti per la virtualizzazione In questo capitolo verranno descritti alcuni dei prodotti commerciali e dei progetti opensource più noti; in particolare verrà presa in considerazione la soluzione SUN Solaris Container/Zones che rappresenta un sistema basato sulla tecnica della OS Virtualization 34 ; si proseguirà con una descrizione generale delle caratteristiche salienti della linea di prodotti VMware per poi passare all ultima soluzione Microsoft denominata Hyper-V; il capitolo si concluderà con una esposizione di due progetti opensource (Xen e KVM) i quali sono diventati anche ottime basi per prodotti commerciali (come ad esempio i già citati OracleVM, VirtualIron, SUN xvm). A parte la soluzione SUN tutti gli altri prodotti sono hypervisor e/o VMM 35. Infine, pur non essendo un applicativo che implementa un sistema di virtualizzazione, verrà descritta brevemente la libreria opensource Libvirt, che permette ad applicazioni di più alto livello di gestire l esecuzione di macchine virtuali su sistemi Linux. 3.1 Sun Solaris Containers/Zones A partire da Solaris 10, nel sistema operativo della SUN è presente una ambiente di virtualizzazione che non prevede modifiche a livello hardware, ovvero ai processori, ma solo a livello software. Questo ambiente prevede un partizionamento mediante copia dei file del sistema operativo e di tutto l ambiente di esecuzione. In questo modo è possibile creare delle zone da dedicare a copie di sistemi operativi, ognuno di essi con i propri file personalizzati ove necessario e con i propri processi. L implementazione prevede che ogni zona sia completamente separata dalle altre. Lo schema di esempio dell implementazione di SUN Container/Zones è il seguente: 34 Si veda il paragrafo Si vedano i paragrafi e

24 Figura 12: SUN Container/Zones Come mostrato in figura, l ambiente di virtualizzazione (container) contiene al suo interno diverse zone 36 ognuna delle quali ospita una macchina virtuale. Il compito principale dello strato di basso livello (OS platform) è quello di garantire il corretto isolamento fra le zone. Il compito della Virtual Platform, invece, è quello di mettere a disposizione delle zone le risorse principali di sistema, ovvero un root file system 37 comune e l accesso ai dispositivi hardware (come ad esempio le interfacce di rete). Una caratteristica importante di questa soluzione è la capacità del sistema di effettuare il riavvio di una zona in pochi secondi. 36 È possibile avere fino a 8192 zone. 37 La partizione principale di sistema. 24 La virtualizzazione e i suoi aspetti di sicurezza

25 3.2 VMware VMware è una soluzione che utilizza il metodo della binary translation. Questa scelta è stata obbligata dall assenza iniziale di altre tecniche efficienti per virtualizzare (come la virtualizzazione hardware). Le ultime versioni utilizzano la virtualizzazione hardware offerta dalle CPU Intel-compatibili. La binary translation riduce la velocità d esecuzione al fine di porre in esecuzione i sistemi operativi senza la necessità di doverli modificare. Con l introduzione da parte di Intel e AMD delle estensioni per la virtualizzazione in hardware in grado di semplificare l attività dell hypervisor, VMware ha recepito il cambiamento tecnologico in atto per cui le ultime versioni del software sfruttano in modo nativo queste estensioni (se presenti nell hardware in uso). VMware è una soluzione consolidata e matura; con l acquisizione di una consistente quota di partecipazione azionaria di VMware da parte di Intel, il software può avvalersi del know-how del più grande produttore mondiale di microprocessori, nonché delle conoscenze specifiche di Intel in ambito di virtualizzazione in hardware. VMware detiene ad oggi la quota più consistente del mercato dei prodotti per la virtualizzazione dei sistemi operativi. Le principali funzionalità della soluzione VMware sono di seguito descritte High availability (HA) è un strumento per garantire l affidabilità dei servizi. Il suo compito è di monitorare il pool di ESX server ed intervenire in caso di guasti hardware assistendo le VM presenti sul server in oggetto per garantirne il riavvio sui server fisici rimanenti. La caratteristica più interessante è la possibilità di monitorare le singole VM per verificare lo stato del loro funzionamento, ad esempio proteggendole da eventuali malfunzionamenti del sistema operativo virtuale. Il monitoraggio ed il riavvio avvengono in modo automatico secondo policy personalizzabili. 2. Distributed Resources Scheduler (DRS) e Distributed Power Management (DPM) DRS è una tecnologia in grado di bilanciare il carico di lavoro tra diversi server fisici in funzione della priorità assegnata alle VM. Consente di ottimizzare le risorse fisiche riassegnando di volta in volta le varie VM sulla base di differenti policy (ad esempio: garantire prestazioni minime ad una certa VM). Il software permette di gestire la manutenzione programmata: se è previsto un tempo di fermo si riassegnano le diverse VM tra i server rimanenti. DPM è una tecnologia di monitoraggio (dichiarata sperimentale dallo stesso produttore al momento della scrittura del documento) che sfrutta il DRS per ottimizzare i consumi energetici dei server fisici. 38 La descrizione è basata sulle dichiarazioni del produttore della suite di prodotti VMware ( 25

26 3. Virtual Machine File System (VMFS) è una tecnologia per centralizzare la memorizzazione dei dati tramite un file system di tipo cluster a cui possono accedere i vari server ESX in modo trasparente. I sistemi guest vedono le immagini virtuali su VMFS come dei dispositivi SCSI. VMware dichiara di permettere l installazione su questi dispositivi anche di sistemi non certificati per l installazione su SAN (esempio: Windows 95). L accesso ai dati è di tipo concorrente quindi è possibile permettere a due macchine virtuali di leggere e scrivere sulla stessa unità di data storage. VMFS prevede la possibilità di assegnare al server di storage un proxy per il backup delle immagini delle VM. 4. Converter è un applicazione per la conversione di ambienti virtuali. Permette di convertire installazioni già attive su una macchina fisica in immagini utili per l uso nei software di VMware (Phisical to Virtual P2V) e di convertire immagini preesistenti in un formato compatibile VMware. La opzioni P2V sono limitate alla sola famiglia di sistemi operativi Microsoft e Linux. 5. Storage Vmotion è una funzionalità che permette di migrare le immagini dei dischi virtuali da uno storage server ad un altro via rete; il processo può avvenire mentre la macchina virtuale è in funzione e senza tempi di fermo significativi: il produttore dichiara tempi inferiori ai due secondi ma è desumibile che i tempi dipendano dalle prestazioni di rete e dalle prestazioni in lettura/scrittura del sottosistema di I/O. L operazione di Storage Vmotion avviene in cinque fasi. 1. Vengono spostati i metadati (file di swap, configurazioni della VM). 2. Nella nuova locazione di storage vengono creati dei dischi temporanei (nella documentazione child disk) logicamente associati alla VM oggetto della Storage Vmotion. Questi dischi si occuperanno di intercettare le operazioni di scrittura della VM. 3. Vengono spostate le immagini dei dischi virtuali associati alla VM. 4. I dati delle immagini virtuali vengono sincronizzati con i dischi temporanei. 5. Viene aggiornata l interfaccia di front end. 3.3 Hyper-V Hyper-V è l ultima soluzione Microsoft di VMM basata su Windows Server Essa viene distribuita sia nella versione Hypervisor-Hosted che nella versione OS-hosted 39 (anche chiamata standalone). Per essere installato ha bisogno di un hardware che supporti le estensioni dedicate alla virtualizzazione 40. Hyper-V implementa una tecnica chiamata Parent/Child partitioning la quale può essere 39 Si veda il paragrafo Intel o AMD. Si veda il paragrafo La virtualizzazione e i suoi aspetti di sicurezza

27 schematizzata come nella figura seguente: Figura 13: Architettura di Hyper-V 41 Come si può notare la partizione root è una macchina virtuale che esegue una copia di Windows Server bit, la quale ospita tutti quei componenti necessari alla gestione di tutte le macchine virtuali. Le partizioni child, invece, ospitano i sistemi operativi delle macchine guest vere e proprie che possono essere di tre tipi differenti: 1. Sistemi Windows Hyper-V Aware (chiamati anche enlightened): sono quei sistemi operativi in grado si rilevare la presenza di Hyper-V e quindi ottimizzare la loro esecuzione e comunicare direttamente con alcune componenti di Hyper-V 42. Ad esempio Windows Server 2008 e 2003 R2 sono S.O. appartenenti a questa categoria. 2. Sistemi non Windows Hyper-V Aware: sono sistemi operativi che non appartengono alla famiglia Microsoft ma che con l aggiunta di opportuni moduli/driver sviluppati da terze parti consentono di rilevare la presenza di Hyper-V e quindi di ottimizzare la loro esecuzione. Appartiene a questa categoria, ad esempio, il sistema Novell SUSE 10 Xen-enabled. 3. Sistemi Non Hyper-Aware: sono sistemi operativi che non sono in grado di rilevare la presenza di Hyper-V. Per questa ragione sono eseguiti senza particolari ottimizzazioni (come ad esempio Windows Server 2000 e le vecchie versioni di Windows). 41 La figura è tratta da Virtualtopia, An Overview of the Hyper-V Architecture - An_Overview_of_the_Hyper-V_Architecture 42 Hyper-V pur non essendo un sistema paravirtualizzato, eredita da questo approccio alcuni concetti: il sistema guest è in grado di rilevare il VMM e di colloquiare con esso. 27

28 3.4 Xen Xen è un software per la virtualizzazione di sistemi operativi sviluppato dall Università di Cambridge. L architettura di Xen è la principale antagonista di VMware ed è integrata dalle soluzioni di virtualizzazione di Sun Oracle. L approccio adottato da Xen si basa sui seguenti concetti: L hypervisor è rilasciato e sviluppato con licenza GPL, mentre alcune delle utilità di supporto sono vendute con il modello tradizionale. Il sistema è integrato con il kernel Linux e alcune componenti di Xen si trovano direttamente dentro il ramo di sviluppo ufficiale. Xen ha introdotto il concetto di paravirtualizzazione. Nel caso di sistemi operativi non paravirtualizzabili Xen può sfruttare la virtualizzazione in hardware messa a disposizione da Intel e AMD. L hypervisor Xen definisce con il termine Domain l unita di schedulazione: in pratica ad ogni domain corrisponde una macchina virtuale; il dominio numero 0 43 viene creato automaticamente all avvio del sistema ed è l unico ad avere privilegi amministrativi in grado di avviare, sospendere, terminare le altre macchine virtuali. Il processo che ha il compito di gestire queste operazione si chiama xend e, oltre a gestire il ciclo di vita delle macchine guest, fornisce all utente le relative console virtuali. Xend ha sia un interfaccia a linea di comando sia una basata su http. Figura 14: Architettura di XEN Gli altri domain vengono genericamente chiamati Domain U. 44 La figura è stata tratta da 28 La virtualizzazione e i suoi aspetti di sicurezza

29 Nell estate del 2007 XenSource è stata acquistata da Citrix la quale rivende prodotti di fascia enterprise basati sul codice di Xen. Le funzionalità dichiarate della Enterprise Edition sono: XenMotion Live Migration with Resource Pools: capacità di migrare una VM da un host fisico ad un altro appartenente allo stesso pool, senza necessità di fermo macchina. XenCenter Administrator Console with Multi-Server Multi-Pool Management: interfaccia grafica che permette di gestire contemporaneamente più server locali e remoti. CPU, Disk and Network Resource Controls for QoS: gestione granulare delle risorse dell host fisico. 3.5 KVM Il Kernel Virtualization Module è un modulo per il kernel Linux rilasciato sotto licenza GPL che permette la virtualizzazione dei sistemi operativi. La principale innovazione e differenza con i principali hypervisor disponibili risiede nella gestione dell I/O e nella sua estrema semplicità. Grazie a questo approccio è possibile ottenere maggiori prestazioni rispetto ad altri hypervisor. La gestione dell I/O è particolarmente gravosa in termini di prestazioni: KVM ovvia a questo inconveniente usando i driver disponibili per il kernel della macchina host. Il principale svantaggio è quello di rendere più difficile la virtualizzazione di sistemi di cui non sono disponibili i sorgenti (per esempio Windows). Per tutti gli altri (per esempio Solaris, *BSD) il supporto è stato garantito nel giro di pochi mesi dai primi rilasci stabili. KVM è solamente un modulo per il kernel GNU/Linux. Tutta la parte di controllo, gestione e manutenzione viene delegata a programmi ed utilità esterne. Il principale software per la gestione è Qemu-kvm, una versione modificata del programma Qemu per l emulazione delle CPU. 3.6 Libvirt Libvirt è una libreria scritta da programmatori di Red Hat per la gestione di hypervisor. Fornisce una serie di API standard che consentono agli sviluppatori e agli amministratori di sistema una maggiore astrazione rispetto all hypervisor in uso. La descrizione della macchina virtuale avviene con file XML. Supporta i seguenti ambienti di virtualizzazione/emulazione: Xen hypervisor (host Linux o Solaris) QEMU KVM LXC Linux container system 29

30 OpenVZ Linux container system User Mode Linux paravirtualized kernel VirtualBox hypervisor. Una delle applicazioni più note basate su Libvirt è Virt-manager, che ha le seguenti caratteristiche: è sponsorizzato da Red Hat che ha l obiettivo di facilitare la gestione e la creazione di macchine virtuali; è basata su Libvirt e ne eredita il principale pregio costituito da una gestione delle VM trasparente rispetto all hypervisor sottostante. 4 aspetti per il dimensionamento di una struttura L adozione di un ambiente di virtualizzazione deve essere studiata in funzione degli obiettivi che ci si propone di raggiungere. Per esempio, l installazione di un ambiente di virtualizzazione sul proprio posto di lavoro non prevede requisiti particolari se non la disponibilità di sufficiente spazio disco e di memoria, mentre un infrastruttura che eroghi servizi e con SLA elevati deve prevedere che tutte le componenti in uso (rete, storage, server) siano opportunamente dimensionate e configurate in funzione dell alta affidabilità richiesta. Con questo, si vuole sottolineare che la scelta di adottare un ambiente di virtualizzazione deve essere meditata ed accompagnata da un analisi delle conseguenze. Infatti, anche nel semplice caso di installazione di un prodotto di virtualizzazione sul proprio PC, si deve essere pienamente consapevoli che non si avrà a disposizione solo un nuovo strumento software ma un altro sistema completo: vi sono quindi una serie di aspetti che dovranno essere riconsiderati, tra i quali quelli relativi alla sicurezza, come la presenza di un altro antivirus, di un firewall personale, ecc. Inoltre è necessario ricordare che anche le semplici e banali fasi di accensione e di spegnimento devono adottare un processo e un ordine ben preciso. Infine, anche la componente di rete dovrà prevedere un specifico ragionamento in quanto il sistema operativo installato in modo nativo sul PC (l host nella terminologia Xen) dovrà seguire regole specifiche per permettere il passaggio di dati dal sistema operativo virtualizzato (guest sempre nella terminologia Xen) alla rete esterna e viceversa. Ci sono quindi un insieme di considerazioni che devono essere attentamente verificate prima dell installazione di un qualunque ambiente di virtualizzazione. In questo capitolo, viene illustrato un esempio di realizzazione di un infrastruttura di virtualizzazione complessa, relativo ad una farm (un insieme di server con la stessa funzione) dedicata al consolidamento di più server fisici (ognuno dei quali è dedicato ad un singolo servizio). In questo caso gli obiettivi sono: ridurre complessivamente il numero fisico di server senza cambiare il numero e la tipologia dei servizi erogati, ridurre i consumi elettrici e quelli accessori (condizionamento e spazio occupato) ed aumentare 30 La virtualizzazione e i suoi aspetti di sicurezza

31 l affidabilità e la flessibilità di gestione. Per raggiungere questi obiettivi, le componenti di base dovranno essere predisposte per presentare il minor numero di point of failure possibili. In questo esempio non viene indicato un ambiente di virtualizzazione specifico, in quanto il modello può essere applicato ad un qualsiasi prodotto di questa tipologia. L unico vincolo è quello di utilizzare sistemi con processori con l estensione del chipset per gestire la virtualizzazione in modo nativo. Nella definizione dell architettura sono considerate le seguenti componenti di base: Networking Storage Server. 4.1 Networking Gli spazi di indirizzamento dovranno prevedere una rete dedicata alla gestione dei sistemi fisici, una rete dedicata ai sistemi virtualizzati e una rete dedicata al backup. Il numero di switch sarà dimensionato in funzione del numero dei server fisici, delle porte di rete presenti in ciascuno di essi, con capacità di banda di almeno 1 Gbit per porta, e in una configurazione tale che il failure di uno di essi non abbia effetto sugli altri (il numero minimo di switch per gestire l infrastruttura è due). 4.2 Storage In un architettura dedicata all ambiente di virtualizzazione, lo storage deve essere esterno ai server fisici per rendere possibile la live migration. In questo modo, lo spostamento di un sistema virtualizzato da un server fisico ad un altro può avvenire spostando la copia della memoria RAM utilizzata, un file che ha dimensioni decisamente inferiori rispetto all intero sistema. Lo storage, quindi, deve essere accessibile da tutti i server fisici e, per una maggiore affidabilità, le connessioni verso lo stesso devono essere ridondate per ogni server fisico. Nel caso in cui si adotti una SAN (Storage Area Network), per ottenere un alta affidabilità, occorre prevedere un doppio switch per le connessioni e un unità di storage con elementi ridondati o con un sistema RAID che possa gestire la rottura di un disco. Sui server fisici, dovranno essere previste il doppio di schede per il collegamento alla SAN. Infine, lo spazio disco da prevedere dovrà essere almeno pari alla somma dello spazio occupato dai server fisici da virtualizzare. In aggiunta, se lo stesso storage dovrà contenere anche la prima copia del backup, dovrà essere prevista anche l occupazione di quello spazio disco. 31

32 4.3 Server I server dovranno prevedere processori che supportano in modo nativo la virtualizzazione completa. La loro configurazione dovrà essere effettuata in funzione dei sistemi virtualizzati che dovranno essere eseguiti, con un indicazione di almeno 1 GByte di RAM per ognuno dei sistemi virtualizzati ed un numero di core in funzione delle necessità applicative. Il criterio da adottare è quello di scegliere processori con architettura almeno quadricore, con almeno quattro socket e con un espandibilità alta per quanto riguarda le schede di espansione di tipo PCI. Secondo quanto indicato precedentemente, le schede di rete dovranno essere almeno sei e le schede per la connessione alla SAN almeno due. Per quanto possibile, sarebbe meglio acquistare i server della farm nello stesso momento in modo da avere tutti i processori completamente uguali ed evitare criticità nella live migration. Esternamente ai server da dedicare alla virtualizzazione, dovranno essere previsti sistemi dedicati alla gestione dell infrastruttura, alla gestione del backup e alla gestione del DNS per questa infrastruttura. Queste ultime configurazioni potranno essere diverse in funzione del prodotto di virtualizzazione adottato. Nel caso di utilizzo di VMware ESXi, lo schema da adottare potrebbe essere simile al seguente: Figura 15: Tipica architettura VMWare ESXi Nello schema si possono notare alcune caratteristiche come una rete specifica e separata dedicata alla gestione e alla live migration, una rete dedicata al traffico applicativo verso i server virtualizzati e i server dedicati alla virtualizzazione organizzati in cluster. 32 La virtualizzazione e i suoi aspetti di sicurezza

33 5 LA SICUREZZA NEGLI AMBIENTI VIRTUALIZZATI Dopo aver descritto, nei capitoli precedenti, cosa è la virtualizzazione e quali sono le diverse tecniche implementative, questo capitolo sarà totalmente dedicato ad affrontare gli aspetti di sicurezza che sono legati a questa tecnologia. Come spesso accade nello sviluppo di una tecnologia, le relative questioni di sicurezza sono state per parecchio tempo messe in secondo piano, favorendo l efficienza e il miglioramento della tecnologia stessa; ad un certo punto però, quando questa è sufficientemente matura da essere utilizzata in un ambiente di produzione a livello enterprise, la sicurezza non può più essere sottovalutata. La sicurezza di un sistema, come noto, va affrontata su tutti i livelli 45, da quello fisico a quello applicativo. Nell ambito della virtualizzazione ci si deve concentrare principalmente sul livello fisico, in quanto per sua stessa natura, la virtualizzazione trasforma oggetti reali in oggetti astratti: ad esempio, avremo una macchina virtuale che non gestisce dischi fisici e non è collegata alla rete tramite cavi e switch veri e propri, ma tramite switch virtuali 46. È necessario quindi che un ambiente di virtualizzazione si prenda in carico di compensare la perdita di sicurezza conseguente alla perdita di fisicità degli oggetti coinvolti. Per comprendere meglio questo concetto si pensi alle seguenti situazioni: 1. in assenza di virtualizzazione, due server privi di connessione di rete (quindi offline) non possono in alcun modo comunicare fra di loro e quindi, in buona o cattiva fede, accedere ai rispettivi dischi. Invece, in presenza di virtualizzazione, due macchine virtuali le cui schede di rete (anch esse virtuali) siano offline, in presenza di bachi o configurazioni sbagliate nel VMM, potrebbero accedere alle rispettive immagini virtuali dei dischi; 2. in assenza di virtualizzazione, il traffico di rete di due server non può essere reciprocamente intercettato, 47 in quanto a livello infrastrutturale vi sono apparati di rete che si occupano di isolare il traffico. Invece, in presenza di virtualizzazione è necessario che sia l hypervisor e/o il VMM ad occuparsi di isolare il traffico di rete. Nei prossimi paragrafi quindi verranno affrontati gli aspetti di sicurezza più critici legati al mondo della virtualizzazione; in particolare verranno analizzate le seguenti problematiche: 1. virus basati sulla virtualizzazione 2. rilevamento di un sistema virtualizzato 3. riallocazione dinamica delle immagini virtuali 4. isolamento delle macchine virtuali e denial-of-service 5. integrità delle macchine virtuali 6. isolamento del traffico di rete. 45 Parlando di livelli, ci si riferisce al modello ISO/OSI che prevede di suddividere i ruoli di un sistema di comunicazione su sette livelli: fisico, datalink, network, transport, session, presentation e application. 46 Si veda il paragrafo Si parla, ovviamente, di situazioni in cui gli apparati di rete (in particolare gli switch) adottano sistemi si sicurezza appositi per evitare, ad esempio, attacchi basati sulla tecnica dell arp-spoofing. 33

34 5.1 Virus basati sulla virtualizzazione L introduzione della virtualizzazione ha permesso agli autori di codici malevoli di introdurre una nuova classe di virus, chiamati HVM rootkits. In questo paragrafo verranno analizzati i principi di funzionamento dei rootkits e verranno descritti alcuni proof-of-concept disponibili in rete per uso dimostrativo. Inoltre per comprendere meglio l evoluzione dei rootkits, il prossimo paragrafo descrive le due grandi famiglie in cui i virus potevano essere classificati (rispetto alle tecniche implementative) prima dell introduzione della virtualizzazione User Space e Kernel space rootkit I rootkit negli anni si sono evoluti e risultano sempre più difficili da individuare. In linea generale, fino all avvento della virtualizzazione potevano essere identificate due generazioni di rootkit: 1. user space: sono eseguiti nello stesso spazio di indirizzamento dei normali applicativi; 2. kernel space: sono eseguiti nello stesso spazio di indirizzamento del kernel. I primi sono facili da scrivere ma sono anche molto facili da identificare (ad esempio tramite signature o controllo degli hash dei file non infetti): ad esempio se un malware in ambiente Linux vuole nascondere la sua esecuzione e le connessioni di rete da lui generate, può sostituire o modificare gli eseguibili ps e netstat; questa operazione però è facilmente individuabile nel caso in cui l amministratore di sistema abbia effettuato un hash dei comandi di sistema; inoltre altri comandi che non siano ps o netstat potrebbero visualizzare il reale output. Siccome le informazioni relative al sistema vengono recuperate tramite chiamate a funzioni del kernel (system calls), i malware di seconda generazione hanno cominciato a modificare le strutture dati del kernel in modo da intercettare e ridirigere le system call; questo sistema è completamente trasparente a tutti gli applicativi eseguiti in user space i quali a loro insaputa fanno uso delle chiamate di sistema ridirette (hooked). Il vantaggio (dal punto di vista di chi li scrive) di questa categoria di rootkit è che i classici metodi di individuazione basati su signature o hash non funzionano. Per individuare i rootkit in kernel space sono necessari sistemi più complessi quali ad esempio l analisi del dump della memoria HVM rootkits Al fine di renderne ancora più difficile la loro individuazione, i rootkit hanno cominciato a sfruttare le funzionalità dei processori dedicate alla virtualizzazione. Come si può notare dalla figura seguente, in questo caso il malware non ha infettato il sistema operativo, ma ha sfruttato il supporto alla virtualizzazione nativa delle CPU che permettono di virtualizzare in ogni momento qualunque processo (anche il sistema operativo). 34 La virtualizzazione e i suoi aspetti di sicurezza

35 Applicativi (user space) S.O. (kernel space) Applicativi (user space) S.O. (kernel space) HARDWARE Sistema pulito Hypervisor (hyperjacker) HARDWARE Sistema infetto Figura 16: Principio di funzionamento degli HVM rootkit Il ruolo dell hypervisor (in questo contesto anche chiamato hyperjacker) è quello di far vedere al sistema operativo tutto l hardware reale intercettando e nascondendo solo gli eventi che vuole nascondere: di conseguenza l hyperjacker solitamente è molto piccolo 48 e di difficile identificazione. Le tecniche per contaminare un sistema operativo con un rootkit di questo tipo sono essenzialmente due: 1. Modificare la sequenza di boot del sistema in modo tale che esso faccia partire l hypervisor maligno al posto del sistema operativo originale (target): sarà poi compito del malware farlo partire sotto forma di macchina virtuale. Questa tecnica ha lo svantaggio che il server deve essere riavviato. Un esempio di malware dimostrativo che usa questo metodo è SubVirt Sfruttare le estensioni hardware delle CPU dedicate alla virtualizzazione per far sì che il sistema operativo in esecuzione venga trasformato in una macchina virtuale; questa modalità non richiede il riavvio del server. Un esempio di malware dimostrativo che usa questo metodo è BluePill 50. Una volta installato e avviato l hypervisor, è possibile lanciare l esecuzione dei malware veri e propri; a seconda di come interagiscono con il sistema originale, possono essere classificati in tre modi diversi 51 : 1. Sistemi che non comunicano in alcuni modo con il sistema originale, come ad esempio malware che svolgono le funzioni di spam relay, ponti per attacchi di Denial Of Service distribuiti, server web con funzioni di phishing e così via. 2. Malware che intercettano alcuni eventi del sistema target, come ad esempio la pressione dei tasti della tastiera o l invio e la ricezione di pacchetti di rete (finalizzati allo sniffing di informazioni) Per questa ragione viene anche chiamato thin hypervisor. 49 Si veda il paragrafo Si veda il paragrafo P. M. Chen et al., SubVirt: Implementing malware with virtual machines, Proceedings of the 2006 IEEE Symposium on Security and Privacy, maggio

36 3. Malware che modificano l esecuzione del sistema target, per esempio cancellando documenti, bloccando connessioni di rete e così via. Le modalità con cui una HVM può interagire con il sistema target sono essenzialmente due: Esponendo al sistema originale device driver scritti in modo opportuno per intercettare determinati eventi: ad esempio l hypervisor può esporre al sistema guest un interfaccia di rete virtuale il cui driver ad ogni pacchetto inviato o ricevuto gli passa il controllo. Inserendo opportuni breakpoint all interno del flusso di esecuzione del codice del sistema guest al fine di generare delle trap e passare il controllo all hypervisor malevolo. I prossimi paragrafi illustrano alcuni progetti dimostrativi che permettono l installazione e l esecuzione di un hypervisor maligno all insaputa dell utente e del sistema target SubVirt SubVirt è un prototipo o, più in generale, una ricerca di HVM rootkits 53 portata avanti dalla Microsoft in collaborazione con l università del Michigan. La ricerca ha portato allo sviluppo di due proof-of-concept basati su due piattaforme diverse: sistema target Linux e VMBR basato su VMware + Gentoo Linux; sistema target Windows e VMBR basato su VirtualPC + Windows XP minimale. Come anticipato nel paragrafo precedente, SubVirt richiede la modifica della sequenza di boot e il riavvio del sistema. Nella versione per Windows la sequenza di boot viene modificata 54 intercettando la chiamata di sistema LastChanceShutdownNotification 55 e modificando il boot loader in modo tale da caricare il VMBR al successivo riavvio. Analogamente, nella versione per Linux, il boot loader viene modificato durante gli script di spegnimento del sistema. I servizi malevoli che sono stati sviluppati a scopo dimostrativo sono quattro: 1. un web server finalizzato al phishing: tutte le connessioni alla porta 8080 sono state redirette ad un web server in esecuzione all interno del VMBR; 2. un keystroke logger ottenuto modificando il modulo che gestisce l emulazione della tastiera di VirtualPC; 3. un servizio che ricerca dati sensibili sul disco: il VMBR accede al disco in modo completamente trasparente al sistema target alla ricerca del file /etc/shadow; 4. un servizio che impedisce la rilevazione del VMBR stesso; viene intercettata l istruzione assembler sidt per evitare che l hypervisor venga rilevato I ricercatori di questo progetto chiamano questo genere di rootkits anche VMBR (Virtual Machine Based Rootkits). 54 Si assume che il VMBR abbia avuto accesso ai privilegi dell utente administrator. 55 Questa funzione viene richiamata dal sistema alla fine della procedura di spegnimento del sistema; i ricercatori hanno deciso di intervenire in questo momento perché in questa fase non vi è attivo nessun antivirus. 56 Si veda il paragrafo La virtualizzazione e i suoi aspetti di sicurezza

37 Blue Pill Blue Pill 57 è il proof-of-concept più noto di HVM rootkit 58. La versione originale del codice è stata presentata nel 2006 al Black Hat Briefing. Nel 2007, il codice è stato riscritto per aggiungere nuove funzionalità ed essere compatibile sia per processori Intel (sfruttando le estensioni VT-x) che per processori AMD (sfruttando le estensioni SVM). Per riportare le caratteristiche fondamentali, si noti che Blue Pill: può virtualizzare un SO in ogni istante; non resiste ad un reboot del sistema in quanto viene eseguito completamente in memoria; non virtualizza alcun tipo di hardware in quanto il sistema guest vede completamente tutto l hardware originale; utilizza delle hypercalls per poter comunicare tra sistema guest e hypervisor. Il funzionamento di Blue Pill, schematizzato nella figura sottostante, è il seguente: 1. viene abilitata la virtualizzazione sul processore. Per effettuare questa operazione il processo deve eseguire in kernel mode (ring 0). Per questa ragione Blue Pill deve essere caricato come driver di sistema; 2. viene allocata e preparata la struttura VMCB; 3. viene eseguita l istruzione VMRUN che porta il sistema originale in modalità guest; 4. il sistema operativo continua l esecuzione normalmente, ma in modalità guest, il che vuol dire che deve sottostare all hyperjacker di Blue Pill il quale è in grado di intercettare alcuni tipi di eventi. 57 Il nome Blue Pill deriva dalla scena del film Matrix in cui il protagonista Neo deve scegliere se rimanere per sempre nel mondo virtuale di Matrix (ingoiando la pillola blu) o tornare alla realtà (ingoiando la pillola rossa). Analogamente, accanto al progetto Blue Pill, esiste il progetto Red Pill, che serve a identificare se un sistema è in esecuzione in un ambiente virtuale o reale

38 Figura 17: Funzionamento di Blue Pill Blue Pill utilizza il sistema delle hypercalls per poter far comunicare il sistema guest con l hypervisor. Le hypercalls sono implementate intercettando le chiamate dell istruzione CPUID che hanno come parametro un determinato magic number; tale istruzione non è considerata un istruzione privilegiata e quindi può essere eseguita in user space da qualunque applicativo. Blue Pill, per scopi dimostrativi, usa questo metodo per far terminare l hypervisor chiamando un eseguibile (bpknock) dal sistema guest Vitriol Vitriol 59 è un progetto dimostrativo della Matasano Security 60 analogo a Blue Pill che permette di virtualizzare un sistema Mac OS X al volo senza necessità di riavvio del sistema grazie all uso delle estensioni Intel VT-x (si veda il paragrafo 2.3). Vitriol viene visto dal sistema target come un modulo del kernel che una volta caricato in memoria è in grado di eseguire tre funzioni principali: Vmx_init(): verifica la presenza delle estensioni VT-x e inizializza le opportune strutture dati La virtualizzazione e i suoi aspetti di sicurezza

39 Vmx_fork(): migra il sistema operativo in una macchina virtuale e manda in esecuzione l hypervisor maligno. On_vm_exit(): gestisce gli eventi per cui la macchina virtuale deve cedere il controllo all hypervisor; implementa quindi le funzionalità maligne e nasconde il più possibile la presenza del VMM (intercettando ad esempio le chiamate all istruzione CPUID). OS VM V M X F O R K Unitialize VM VM Entry Hypervisor O N V M E X IT VM Exit VM Entry O S O S Figura 18: Sequenza di lancio di Vitriol Xen Subvertion Il progetto Xen Subvertion 62 (portato avanti da Invisible Things Lab) vuole dimostrare come è possibile sfruttare un VMM già esistente (installato in modo consapevole dall utente) per trasformarlo in un VMM malevolo come quelli visti precedentemente. I vantaggi di un approccio di questo tipo sono diversi: non ci si deve preoccupare di nascondere la presenza del VMM; molte funzionalità sono presenti nel VMM ufficiale e non devono quindi essere sviluppate all interno del malware. 61 La figura è tratta dal sito web della azienda Matasano Security,

40 Ovviamente vi sono anche aspetti non banali da affrontare come ad esempio: come iniettare il codice malevolo all interno del VMM ufficiale; il VMM potrebbe avere dei sistemi di protezione per cui non è possibile modificare il codice a run time. I prototipi legati a questa ricerca sono basati sull hypervisor Xen 3.x e sfruttano alcune vulnerabilità che permettono l esecuzione di codice arbitrario (si veda il paragrafo 5.4.2). 5.2 Virtual machine detection La virtual machine detection è l insieme delle tecniche impiegate per accertare se un sistema operativo è in esecuzione in un ambiente virtualizzato. Questo tipo di rilevazione può essere eseguita per due motivi tra di loro opposti. Il primo è strettamente legato a quanto discusso finora nel capitolo precedente: l utente potrebbe non essere al corrente che il sistema in quel momento è virtualizzato in quanto il controllo è stato preso da un HVM rootkit. Il secondo motivo riguarda uno degli usi più diffusi della virtualizzazione ossia l analisi e la ricerca di codici maligni (malware, virus, rootkits, ecc.); spesso, per testare se un codice è nocivo viene eseguito su una macchina virtuale, in quanto si limitano i danni e il ripristino dell immagine di sistema al momento antecedente all esecuzione è un operazione immediata. Un uso tipico in questo ambito è quello degli honeypot 63, ovvero server usati come trappole per catturare nuovi virus o simili. Già da qualche tempo si è osservato che alcuni malware per evitare di cadere in trappola si avviano solo dopo aver verificato di non essere eseguiti in un ambiente virtuale. In questo scenario, è quindi fondamentale che un VMM si nasconda il più possibile. In linea teorica, un applicazione e lo stesso sistema operativo non hanno la possibilità di capire se sono eseguiti in un ambiente virtuale, ma vi sono metodi non convenzionali che in alcuni casi possono risultare efficaci. Tali metodi sfruttano diverse tecniche di seguito elencate. Ricerca di artefatti specifici dell hypervisor; Analisi dei tempi di esecuzione di determinate istruzioni; Utilizzo di hardware embedded; Analisi remota dello stack di rete. Nei prossimi paragrafi vengono brevemente illustrati i principi su cui si basano queste tecniche di rilevamento e alcuni applicativi disponibili in rete che ne fanno uso. 63 Si veda a tal proposito il progetto Argos ( 40 La virtualizzazione e i suoi aspetti di sicurezza

41 5.2.1 Ricerca di artefatti specifici dell hypervisor Un hypervisor può lasciare delle tracce in modo volontario o involontario. Si tratta di artefatti che possono essere rintracciati con diverse procedure. Processi in esecuzione: ad esempio nel caso di VMware si può notare l esecuzione del servizio VMtools. File presenti su file system: nel caso di VMware si possono identificare diversi file che nel nome contengono le parole vmware o vmx. Chiavi di registro: nel caso di VMware si possono identificare diverse chiavi di registro con nome o valore contenenti stringhe vmware o vmx. Analisi della memoria: effettuando il dump della memoria è spesso possibile trovare riferimenti espliciti al nome dell hypervisor (come nel caso di VMware). Questo approccio è sicuramente gravoso, ma, sapendo in quali zone l hypervisor lascia le tracce, la ricerca diventa sicuramente più leggera. Altre tecniche che fanno uso dell analisi della memoria si basano sulle caratteristiche di alcune strutture dati importanti quali ad esempio l Interrupt Descriptor Table (IDT) ovvero la tabella in cui sono definiti gli indirizzi degli handler degli interrupt. È stato notato che in un sistema guest l IDT viene rilocata nella zona alta della memoria, mentre normalmente si trova nella parte bassa. Caratteristiche dell hardware emulato: questa tecnica prevede di effettuare una scansione dell hardware presente nel sistema emulato e verificare i manufacturer ID presenti in tutte le schede di rete, i dispositivi PCI e USB. Comportamenti particolari di alcune istruzioni della CPU: spesso gli hypervisor usano la definizione di nuove istruzioni assembler (come fa ad esempio VirtualPC) o parametri non convenzionali per consentire la comunicazione tra sistema guest e sistema host. In altri casi invece alcuni comportamenti vengono ridefiniti: ad esempio, in un sistema non emulato (windows o linux) l istruzione IN 64 (se eseguita in user space) genera un eccezione; se la stessa istruzione viene richiamata con particolari parametri l hypervisor VMware non scatena alcuna eccezione in quanto serve a ricavare alcune informazioni di servizio (come ad esempio la versione di VMware) Analisi dei tempi di esecuzione In linea di principio l esecuzione delle istruzioni su un sistema virtualizzato è più lenta. Questo vale sicuramente per tutte le istruzioni nel caso di hypervisor software. Nel caso di hypervisor hardware il rallentamento riguarda solo le istruzioni privilegiate che sono state intercettate. Ad esempio, se il sistema guest volesse andare a leggere il registro EFER (in cui è presente il flag se la virtualizzazione è attiva) l hypervisor potrebbe decidere di intercettare quella istruzione. Questo provocherebbe un rallentamento rispetto alla situazione in cui 64 L istruzione IN serve a leggere dati dalle porte di Input/Output. 41

42 l hypervisor non è attivo. I problemi di questo approccio sono fondamentalmente due: si deve avere una stima di riferimento dei tempi di esecuzione nel caso di macchine non virtualizzate; si deve avere un sistema di misurazione del tempo non controllabile dall hypervisor. La prima difficoltà può essere risolta con misurazioni svolte in certezza assoluta di sistema non contaminato oppure mediante valori statistici. Il secondo problema si riferisce al fatto che se la misurazione viene svolta basandosi sui timer della CPU, le istruzioni che permettono di accedere ai timer possono essere intercettate e quindi l hypervisor può correggere e falsare la lettura. È quindi necessario usare sistemi di misurazione del tempo non controllabili dall hypervisor, come i seguenti: fonti esterne (ad esempio NTP): lo svantaggio di queste fonti sta nella bassissima granularità; l unico modo di ovviare a questo problema è di eseguire un numero sufficientemente alto di istruzioni; in queste condizioni l hypervisor è in grado di rilevare un uso anomalo delle istruzioni e di bloccare temporaneamente l intercettazione o addirittura uscire e far tornare il sistema guest al mondo reale (e dopo un timer programmabile impostare la sua ri-esecuzione per far tornare il sistema in modalità guest). Questo approccio è usato sia da Blue Pill sia da BlueChicken. È importante notare che, nel momento in cui l hypervisor viene disattivato, diventa molto più facile intercettarlo (come i normali rootkits eseguiti in kernel space); timer presenti in periferiche esterne: anche se questo approccio in linea di principio sarebbe intercettabile dall hypervisor, è impensabile che questo possa prevedere ogni tipo di timer presente in ogni tipo di periferica esterna. Per lo stesso motivo questo metodo è anche difficile da implementare negli antivirus in quanto dovrebbero prendere in considerazione un numero elevato di hardware Utilizzo di hardware embedded Queste tecniche si basano sulla ricerca di determinate signature all interno della RAM. Per evitare possibili intercettazioni da parte dell hypervisor è necessario che la componente che effettua la scansione sia fuori dal suo controllo. Le soluzioni possibili sono due: Utilizzo di hardware dedicato: alternativa scelta da Intel; lo svantaggio è che il software di gestione che ne fa uso (tipicamente un antivirus dedicato) è strettamente legato al chipset. Utilizzo della modalità SMM (System Management Mode 65 ) delle CPU: ha il vantaggio 65 SMM è una modalità delle CPU Intel in cui tutti i processi vengono interrotti (compreso il sistema operativo) per poter eseguire codice ad alta priorità (solitamente presente nel firmware o in hardware dedicato). SMM viene usato tipicamente per la gestione di eventi critici (temperature elevate) o gestione del risparmio energetico. 42 La virtualizzazione e i suoi aspetti di sicurezza

43 che permette l accesso diretto alla memoria ed è completamente trasparente al sistema operativo. Purtroppo recentemente è stato presentato un proof-of-concept di come questa modalità possa essere usata per scrivere SMM based rootkits Analisi remota dello stack di rete Questo sistema si differenzia dagli altri in quanto il controllo non viene svolto localmente ma remotamente. Esso si basa sulla tecnica del fingerprint dello stack di rete, già largamente usata da diversi strumenti 66 per la rilevazione remota dei sistemi operativi. Esso si basa sull assunzione che ogni sistema operativo implementa in modo leggermente diverso casi particolari non previsti dagli standard (tipicamente TCP/IP). Come si può intuire questa tecnica funziona per rilevare un hypervisor benigno e non un HVM rootkit in quanto è difficile che quest ultimi re-implementino uno stack di rete completo Progetti Di seguito vengono citati e descritti un certo numero di tool che utilizzano alcune delle tecniche viste nei paragrafi precedenti Red Pill Red Pill 67 è un applicativo che cerca di rilevare la presenza di un hypervisor basandosi sul valore dell Interrupt Descriptor Table Register IDTR (come descritto in 5.2.1). Red Pill si basa sul fatto che: sugli host Linux l IDTR è 0xc0ffffff; sugli host Windows l IDTR è 0x80ffffff; sui guest VMware l IDTR è un valore del tipo 0xffXXXXXX; sui guest VirtualPC l IDTR è un valore del tipo 0xe8XXXXXX. Essendo l istruzione assembler SIDT 68 non privilegiata, essa può essere eseguita in user mode. 66 Un esempio è Nmap ( Store Interrupt Description Table. 43

44 Scoopy Scoopy e la sua evoluzione ScoopyNG 69 sono un miglioramento di Red Pill dedicato alla rilevazione di sistemi guest VMware; oltre a basarsi sull indirizzo della IDT, prendono in considerazione anche gli indirizzi della Global Description Table (GDT) e della Local Description Table (LDT). Inoltre la versione NG analizza il valore del Task Register e prova ad eseguire istruzioni con particolari parametri contenenti magic number (si veda 5.2.1) Doo DOO 70 è un applicativo scritto dagli stessi autori di Scoopy (e compreso nell unico pacchetto Scoopy Doo) che cerca di rilevare tracce della presenza di hardware emulato da VMware. Vi è sia la versione per Linux che per Windows. Linux Doo analizza: /proc/iomem /proc/ioports /proc/scsi/scsi Log del kernel. Windows Doo, invece, controlla determinate chiavi di registro VMDetect VMDetect 71 cerca di eseguire istruzioni assembler proprietarie di VirtualPC che non esistono nel normale instructions set x86. Se la CPU scatena un eccezione (illegal instruction) vuol dire che il sistema non è emulato altrimenti se non viene scatenata nessuna trap il sistema è controllato da VirtualPC. Per effettuare la rilevazione di VMware, invece, VMDetect usa il metodo già illustrato in (utilizzo della istruzione IN con parametri particolari) La virtualizzazione e i suoi aspetti di sicurezza

45 5.3 Live Migration Molti VMM moderni hanno come caratteristica quella di poter trasferire l esecuzione di una macchina virtuale da un server fisico ad un altro. Questa caratteristica è chiamata live migration o virtual motion in quanto l esecuzione del sistema guest non viene interrotta durante il trasferimento. Questa funzionalità, però, se non implementata correttamente, apre le porte a possibili attacchi del tipo man in the middle permettendo la lettura ed eventualmente la modifica delle pagine di memoria e compromettendo la normale esecuzione del sistema appena migrato. Tre ricercatori 72 dell Università del Michigan hanno dimostrato come sia possibile compromettere la sicurezza di un sistema mentre questo viene migrato da un VMM all altro. Tramite il tool che hanno sviluppato (xensploit) è stato possibile modificare il codice di un eseguibile per modificarne il suo output; inoltre è stato possibile modificare il codice del demone SSH (sshd) per consentire l accesso di root senza alcuna autorizzazione. I VMM testati con successo sono stati Xen e VMware. Per prevenire questo genere di attacchi è necessario autenticare e cifrare tutte le comunicazioni fra i diversi VMM, sia quelle di controllo (richieste di migrazione in ingresso e uscita, annuncio delle performance di sistema per consentire il load balancing, ) sia quelle dati (pagine dell immagine di memoria del sistema migrato). Le attuali versioni di Xen e VMware non gestiscono ancora nessuna forma di autenticazione e cifratura delle comunicazioni. 5.4 VM Escape & Denial Of Service Uno dei principi fondamentali dei sistemi virtualizzati è l isolamento (VM isolation): questo vuol dire che teoricamente non deve essere possibile far comunicare le macchine virtuali tra di loro oppure una macchina virtuale con l host. Nel mondo reale però questo non accade in quanto spesso per comodità applicativa è necessario che queste comunicazioni siano possibili, seppure in modo controllato. Ad esempio molti hypervisor consentono di: condividere gli appunti tra host e macchine virtuali; condividere cartelle del file system fisico in quello virtuale; interconnettere più macchine virtuali tramite una rete virtuale implementando un vitrual hub o virtual switch. Le comunicazioni tra host e macchine virtuali sono controllate dall hypervisor, ma aprono la porta a diversi possibili bug di implementazione per cui le comunicazioni possono scavalcare le protezioni e rendere incontrollato l accesso alle risorse. 72 Oberheide J., Cooke E., Jahanian F. (marzo, 2008). 45

46 Strettamente legati al non corretto isolamento sono gli attacchi di tipo denial of service: uno sconfinamento dei confini delle macchine virtuali può causare crash dell host. Di seguito vengono illustrate una serie di vulnerabilità che dimostrano come attacchi di questo genere siano possibili e molto pericolosi; in questo campo vale quindi più che mai la buona norma di tenere sempre i sistemi aggiornati alle ultime versioni, in quanto un baco in un hypervisor può compromettere contemporaneamente la sicurezza di diverse macchine virtuali VMware Nel corso degli anni in VMware sono stati identificate diverse vulnerabilità. Di seguito ne vengono citate e descritte solo alcune a titolo esemplificativo. Molte vulnerabilità si basano sul fatto che VMware dispone di un canale di comunicazione tra host e guest (e viceversa) non documentato in modo ufficiale. A questo canale ci si riferisce col nome di VMware backdoor 73. x nota tabella 74 Identificativo CVE CVE CVE CVE CVE Descrizione Costruendo opportuni pacchetti FTP (relativi ai comandi EPRT o PORT FTP) è possibile generare un buffer overflow nello heap del servizio che gestisce il NAT consentendo l esecuzione di codice arbitrario sull host a partire dalla macchina virtuale Un baco di implementazione nel sistema di gestione delle shared folders utility 74 permette di accedere in scrittura all intero file system dell host (directory traversal) Utenti autenticati sul sistema guest con i privilegi di amministratore possono corrompere o eseguire codice arbitrario sul sistema host Utenti autenticati sul sistema guest con i privilegi di amministratore sono in grado di determinare il crash del sistema host Xen/QEMU Dal momento che parte del codice di Xen è basato su quello di QEMU (relativamente alla gestione dei driver hardware), i bachi che si riferiscono a QEMU possono riflettersi anche su Xen. Identificativo CVE CVE CVE CVE Descrizione Un baco nel boot loader dei sistemi guest (pygrub) consente l esecuzione di codice arbitrario in fase di boot Un buffer overflow nello heap dell emulazione del dispositivo VGA consente l esecuzione di codice arbitrario sull host a partire dai guest Analogamente al caso precedente, un buffer overflow nello heap dell emulazione del dispositivo di rete NE2000 consente l esecuzione di codice arbitrario sull host a partire dai guest 73 Ken Kato - VMware backdoor È la funzionalità che consente al guest di accedere a determinate cartelle dell host in modo controllato. 46 La virtualizzazione e i suoi aspetti di sicurezza

47 5.5 VM Integrity Nei precedenti capitoli è già stato sottolineato come la sicurezza dell host sia fondamentale in quanto una sua falla di sicurezza può compromettere la sicurezza di tutte le macchine virtuali in esso ospitate. Ad esempio se un virus riesce a compromettere l host, esso ha libero accesso alle immagini dei dischi delle macchine virtuali e quindi è in grado di propagarsi 75 senza alcun problema oppure semplicemente accedere a dati riservati. Come è noto, i VMM memorizzano le immagini dei dischi sul file system dell host in quanto sono molto più facili da gestire rispetto all uso di partizioni dedicate sui dischi fisici dell host. Risulta quindi chiaro come sia importante gestire l integrità o, ancora meglio, la cifratura dei dischi virtuali da fattori esterni. Le soluzioni possono essere basate su diversi approcci discussi nei paragrafi successivi Cifratura dei dischi virtuali gestita dal VMM In genere, i VMM, per gestire i dischi virtuali, si basano su un proprio formato proprietario. Ultimamente i VMM hanno iniziato a supportare anche altri formati che si sono ampiamente diffusi. I formati principali sono citati nella tabella seguente: Formato VMDK QCOW2 VDI VHD HDD RAW VMM nativo VMware QEMU VirtualBox Microsoft VirtualPC / VirtualServer / Hyper-V Parallels Rappresenta l immagine grezza del disco senza alcun metadato aggiuntivo per ottimizzare la gestione e l accesso da parte dei VMM Tabella 1: Formato dischi virtuali Tra tutti questi formati, l unico che supporta la cifratura in modo nativo è QCOW2. Esso usa come algoritmo di cifratura AES con chiavi a 128 bit nella modalità Cipher Block Chaining cifrando ogni settore in modo indipendente e utilizzando l offset del settore come vettore di inizializzazione. qemu-img create -e -f qcow2 disk.qcow2 128M 75 Vi sono diversi strumenti che consentono di montare le immagini dei dischi virtuali e quindi accedere ad esse come normali partizioni di dischi fisici. Ad esempio vmware-mount.pl permette di montare i file VMDK di VMware. 47

48 La chiave a 128 bit viene derivata a partire da una password che l amministratore inserisce in fase di boot; è da notare che all atto della creazione non viene chiesta nessuna password in quanto non ci sono dati da cifrare. La versione di QEMU ha un baco per cui in fase di boot, pur rilevando la presenza di un disco cifrato e pur mostrando la richiesta di inserimento della password, non è in grado di leggere correttamente l input. Per poter utilizzare dischi cifrati è necessario scaricare e installare un apposita patch Cifratura dischi in VMware ACE VMware ACE 77 è una soluzione per la gestione di postazioni di lavoro standard tramite l uso di macchine virtuali. Tramite la console, l amministratore è in grado di creare diversi modelli di macchine virtuali e distribuirle ai client degli utenti (possono essere PC oppure dispositivi mobili come chiavette USB o dischi removibili). Soluzioni di questo genere permettono una facile gestione delle installazioni delle postazioni di lavoro e permettono la propagazione di policy a tutti i client che appartengono al dominio. Figura 19: VMware ACE ACE usa un formato di disco virtuale (VMDK) che non supporta la cifratura in modo nativo. La cifratura viene gestita a livello superiore dalla console di gestione e dal player ACE. Durante la creazione delle macchine virtuali, la console di amministrazione permette di decidere il livello di sicurezza 78 : cifratura della macchina virtuale (disco e file di configurazione); integrità della macchina virtuale (disco e file di configurazione): i dati non sono cifrati ma viene rilevata un eventuale modifica non autorizzata VMware - VMware ACE Virtual Machine Encryption Basic 48 La virtualizzazione e i suoi aspetti di sicurezza

49 5.5.2 Cifratura dei dischi virtuali gestita dai sistemi guest Se il VMM non è in grado di gestire in modo nativo la cifratura dei dischi, una soluzione potrebbe essere quella di gestire la cifratura sfruttando le caratteristiche o gli applicativi disponibili nel sistema operativo guest. Attualmente vi sono differenti strumenti che permettono di cifrare intere partizioni o interi dischi sia in ambiente Linux che in ambiente Windows. Per quanto riguarda Linux ricordiamo: Dm-crypt 79 : sistema integrato nel kernel Linux 2.6; TrueCrypt 80 : versione Linux che non può cifrare la partizione di boot. Per quanto riguarda Windows, sono disponibili: EFS 81 : sistema integrato in Windows in grado di cifrare solo singole cartelle che non siano di sistema; TrueCrypt: versione per Windows in grado di cifrare anche la partizione di sistema tramite un bootloader dedicato; Bitlocker 82 : versione disponibile nei sistemi Windows Vista Enterprise o Ultimate Edition. Il nuovo sistema per cifrare intere partizioni (compresa quella di sistema 83 ) è integrato col TPM (Trusted Platform Module) hardware Cifratura dei dischi virtuali gestita dal sistema host Nel paragrafo precedente si è mostrato come i guest possono gestire la cifratura delle loro immagini dei dischi quando il VMM non è in grado di gestirla in modo nativo. In maniera del tutto analoga è possibile che sia l host a occuparsi della cifratura delle immagini usando gli stessi strumenti (TrueCrypt, EFS, dm-crypt, BitLocker o analoghi). Ad esempio, Microsoft consiglia l uso di BitLocker come sistema per la cifratura delle immagini dei dischi delle macchine virtuali La partizione di boot non può essere cifrata quindi è necessario creare una piccola partizione in cui verranno installati solo i file necessari al boot. La partizione di sistema (c:) invece può essere cifrata senza alcun problema. 84 Windows Server 2008 Hyper-V and BitLocker Drive Encryption aspx?familyid=2c3c0615-baf4-4a9c-b613-3fda14e84545&displaylang=en 49

50 Figura 20: Integrazione Hyper-V e BitLocker È importante però notare che, in questo modo, la protezione è valida solo per attacchi esterni al sistema operativo dell host (ad esempio furto o dump dei dischi fisici) in quanto, una volta avviato il sistema, tutti questi strumenti permettono l accesso ai dischi in modo trasparente da parte delle applicazioni (compresi eventuali virus!). L amministratore di sistema, prima di scegliere se proteggere i dischi virtuali lato host o lato guest, deve quindi valutare quali sono i rischi specifici: ad esempio, se il rischio maggiore è l accesso non autorizzato alle macchine fisiche e le macchine virtuali sono numerose, conviene configurare la cifratura lato host (col vantaggio che sui sistemi guest non dovrà essere configurato nulla). Nel caso in cui, invece, il rischio maggiore è la contaminazione da codice malevolo, allora le soluzioni migliori sono quelle guest based. 5.6 Network Isolation Gli hypervisor gestiscono la virtualizzazione della rete mappando le schede di rete fisiche (NICs) con delle schede virtuali visibili dalle macchine guest. Tipicamente le schede di rete virtuali vengono configurate in due modalità: Bridged: il NIC virtuale condivide lo stesso livello 2 del NIC fisico; questo vuol dire che entrambe condividono la stessa rete IP. NAT: il NIC virtuale ha un indirizzo in classe privata (rilasciato tipicamente da un server virtuale gestito dall hypervisor) il quale viene tradotto (Network Address Translation) con l indirizzo del NIC fisico. 50 La virtualizzazione e i suoi aspetti di sicurezza

51 A seconda dell hypervisor il mapping tra schede virtuali e fisiche può avvenire in modi più o meno complessi. Ad esempio, alcuni consentono di creare più reti virtuali, ognuna delle quali è gestita da un virtual switch. In altri casi, questa operazione non è possibile oppure il virtual switch si comporta come se fosse un virtual hub (con conseguenti ricadute sulla sicurezza della virtual network). L amministratore deve essere consapevole delle modalità di virtualizzazione della rete in quanto queste hanno importanti ricadute sull isolamento reciproco delle macchine guest ospitate e dell host. Nei paragrafi successivi verrà descritto come alcuni dei prodotti più noti gestiscano la rete ed in particolare affrontino la problematica della network isolation VirtualServer 2005 Microsoft VirtualServer permette di definire una o più reti virtuali che possono essere mappate su un interfaccia fisica. Nel caso in cui non venga specificato nessun NIC fisico, la rete virtuale non sarà interconnessa con il mondo esterno. Nel momento in cui si crea una nuova macchina guest, per ogni NIC virtuale si deve impostare la relativa rete virtuale a cui è interconnessa. Microsoft VirtualServer non permette di configurare le schede virtuali in modalità NAT. Logicamente le reti virtuali sono gestite da virtual hub; questo vuol dire che vi è uno scarso livello di isolamento del traffico di rete. In particolare si considerino i seguenti casi 85. Se la rete virtuale è collegata a una scheda di rete fisica dedicata e se a questa scheda di rete fisica non è collegata nessun altra rete virtuale, le macchine virtuali collegate a questa rete non sono in grado di leggere, monitorare o acquisire il traffico di rete del sistema operativo host. Il sistema operativo host non è in grado di leggere, monitorare o acquisire il traffico di rete tra le macchine virtuali, tuttavia può tuttavia leggere, monitorare o acquisire il traffico di rete tra una macchina virtuale e un altra periferica sulla rete fisica. Se le macchine virtuali sono collegate alla stessa rete virtuale, le macchine virtuali possono leggere, monitorare e acquisire il traffico di rete di altre macchine virtuali collegate alla rete virtuale. Si tratta della stessa situazione che si verifica quando più computer fisici sono collegati allo stesso hub di rete: tali computer possono leggere, monitorare e acquisire il traffico di rete di altri computer collegati alla rete. Se due o più reti virtuali sono collegate alla stessa scheda di rete fisica, il traffico di rete è solo parzialmente isolato. Le macchine virtuali collegate a tali reti virtuali sono in grado di leggere, monitorare e acquisire il traffico di rete in ingresso delle diverse macchine, ma non il traffico di rete in uscita. Se la rete virtuale non è collegata a una scheda di rete fisica, allora è una rete privata autonoma con un proprio server DHCP virtuale facoltativo. Il traffico di rete delle 85 Microsoft Guida dell amministratore di VirtualServer

52 macchine virtuali collegate a questa rete e il sistema operativo host sono completamente isolati. Il sistema operativo host non è in grado di leggere, monitorare o acquisire il traffico di rete delle macchine virtuali e le macchine virtuali non sono in grado di leggere, monitorare o acquisire il traffico di rete del sistema operativo host. Il traffico di rete è inoltre limitato al computer fisico, ovvero è totalmente isolato dalla rete fisica VMware ESX 3 La versione EXS di VMware, a differenza delle altre, ha un sofisticato sottosistema per la virtualizzazione della rete che permette un elevato grado di isolamento fra le diverse macchine virtuali 86. La gestione della rete si basa sulla creazione di uno o più virtual switch su cui sono collegate logicamente una o più interfacce di rete. L uso dei virtual switch rispetto all uso dei virtual hub garantisce un buon livello di isolamento del traffico. Inoltre, in modo del tutto analogo agli switch fisici, supportano il protocollo IEEE 802.1q per il VLAN Tagging per separare in modo ulteriore i domini di broadcast. Per ogni switch è possibile impostare tre opzioni per impedire ai guest di poter compiere operazioni potenzialmente dannose per la rete (cambiamenti di MAC address, o uso della modalità promiscua): Promiscuous Mode: nel caso in cui il guest imposti la scheda di rete virtuale in modalità promiscua, la richiesta viene ignorata. MAC Address Changes: nel caso in cui il sistema operativo guest cambi il MAC address della scheda virtuale impostato nel file di configurazione, tutti i pacchetti in ingresso sono scartati. Forged Transmits: tutti i pacchetti in uscita che hanno un MAC differente rispetto a quello impostato nel file di configurazione sono scartati Xen Xen utilizza un sistema analogo a quello di VMware ESX per garantire un ottimo isolamento del traffico 87. La configurazione di default prevede la creazione di un virtual bridge cui appartengono una o più interfacce fisiche dell host e tutte le schede virtuali delle macchine guest; editando i file di configurazione è però possibile creare al loro posto dei virtual router, utili per esempio ad avere reti IP diverse nei singoli guest. 86 VMware Security Design of the VMware Infrastructure 3 Architecture 87 Xen Xen networking 52 La virtualizzazione e i suoi aspetti di sicurezza

53 Xen prevede che a ogni interfaccia virtuale nella macchina guest, chiamata ethx, corrisponda un interfaccia virtuale nell host visibile dal sistema operativo Linux 88. Figura 21: Interfacce fisiche e virtuali in XEN Per questa ragione l amministratore tramite le utilitiy (iptables, bridge utilities, ifconfig, ) di Linux può configurare qualunque struttura di rete virtuale che ritenga più idonea (bridge, router, uso di VLAN, ecc.) Cisco Nexus 1000V Virtual Switch Come visto nel paragrafo 7.6.2, VMware integra già al suo interno uno switch virtuale sofisticato. Al fine di aumentare la sicurezza e la flessibilità, la Cisco ha implementato un plugin per VMware 89 chiamato Cisco Nexus 1000V in grado di sostituire il virtual switch nativo con uno nuovo. Il Nexus 1000V 90 nasce per mettere a disposizione della macchina virtuale uno switch il più possibile simile ad uno fisico, permettendo dunque di gestire VLAN, QoS, monitoraggio del traffico (ad esempio tramite il protocollo NetFlow) e quindi dialogare in modo standard con gli altri switch dell infrastruttura di rete. Inoltre, essendo integrato con l hypervisor, il sistema riesce a riconfigurarsi in modo dinamico in caso di eventi di Live Migration (VMotion). 88 Viene chiamata vifu.x, dove U rappresenta l ID della macchina virtuale e X il numero della scheda ethx corrispondente. 89 Al momento della scrittura di questa pubblicazione il Nexus 1000v è disponibile per VMware ESX, ESXi e vsphere. 90 Cisco - Cisco Nexus 1000V Virtual Switch - data_sheet_c html 53

54 La figura seguente mostra in modo schematico l architettura del Nexus 1000V: Figura 22: Architettura del Cisco Nexus 1000V La figura è tratta dal sito web di Cisco, 54 La virtualizzazione e i suoi aspetti di sicurezza

55 6 nuovi orizzonti per la virtualizzazione In questo capitolo conclusivo verrà preso in considerazione un nuovo paradigma basato sulla virtualizzazione e su una tecnologia emergente chiamata Trusted Computing. Volto ad incrementare la sicurezza di esecuzione di applicazioni e servizi critici, tale approccio è ancora prevalentemente confinato nell ambito della ricerca e della sperimentazione e tende a modificare il rapporto tra virtualizzazione e sicurezza. Se da una parte occorre sempre garantire la correttezza di progetto e di implementazione dei VMM, dall altra parte questi ultimi si avviano a diventare essi stessi strumenti per incrementare la sicurezza dei sistemi. 6.1 Cenni sulla tecnologia Trusted Computing Trusted Computing (TC) è una tecnologia a basso costo, orientata a contrastare attacchi software e semplici attacchi hardware sulle piattaforme, promossa dal Trusted Computing Group (TCG) 92, un consorzio industriale che include i maggiori produttori di hardware e software. Il TCG ha prodotto e continua a sviluppare un insieme di specifiche tecniche relative a Trusted Platform e a Trusted Infrastructure architecture. Il primo costituisce il cuore del secondo. TCG definisce il concetto di trust come segue: trust è l aspettativa che un dispositivo si comporterà in un modo particolare per uno specifico scopo. Questa definizione è neutrale rispetto alla bontà del comportamento di una piattaforma e restringe le aspettative solo a scopi ben precisi. Al fine di potersi fidare del comportamento di un sistema, condizione necessaria (ma non sufficiente) da soddisfare è l identificazione esatta di tutti i componenti eseguiti. Il Trusted Computing secondo la visione del TCG fornisce gli elementi tecnologici necessari a tale scopo. L elemento centrale di tale visione è la Trusted Platform, piattaforma fidata che fornisce tre funzionalità di base: protected capabilities, integrity measurement e integrity reporting. Protected capabilities sono comandi che hanno accesso esclusivo a shielded locations, luoghi in cui dati sensibili possono essere memorizzati e manipolati in modo sicuro. Informazioni di integrità e chiavi crittografiche sono esempi di dati che possono essere memorizzati in shielded locations. Esempi di protected capabilities sono le funzioni che riportano le informazioni di integrità o che usano chiavi in algoritmi crittografici, per esempio per firme digitali o cifratura di dati. Integrity measurement è la procedura di raccolta di tutti gli aspetti di una piattaforma che ne determinano il comportamento e l affidabilità (informazioni di integrità) e di memorizzazione dei relativi digest, o riassunti crittografici, in shielded locations. Integrity reporting è la procedura di rendicontazione delle informazioni di integrità memorizzate in shielded locations ad un verificatore (remoto)

56 Una Trusted Platform include tre Root of Trust realizzate per mezzo delle suddette funzionalità di base: Root of Trust for Measurement (RTM), Root of Trust for Reporting (RTR) e Root of Trust for Storage (RTS). Tali radici di fiducia sono gli elementi di una Trusted Platform di cui ci si fida a priori, cioè che si assume si comportino in modo corretto ed affidabile: occorre che ciò avvenga effettivamente perché dai Root of Trust discende la fiducia in tutte le altre operazioni di un Trusted Platform; un comportamento scorretto dei Root of Trust non può essere rilevato. Una Trusted Platform è una piattaforma di elaborazione convenzionale che include due componenti aggiuntivi che realizzano in pratica le radici di fiducia : il Core Root of Trust for Measurement (CRTM), usualmente la porzione del BIOS, trusted, che viene eseguita per prima all avvio della piattaforma, ed il Trusted Platform Module (TPM) 93, un chip crittografico a basso costo. Il TPM permette di generare chiavi che possono essere usate per firmare o cifrare dati, chiavi a loro volta protette mediante cifratura quando memorizzate all esterno del chip. Il TPM include un certo numero (16 o 24 secondo la versione) di Platform Configuration Register (PCR), cioè shielded locations usate per memorizzare ed accumulare, sotto forma di catene di digest, le misure di integrità dei componenti, effettuate prima del loro caricamento ed esecuzione. In Figura 23, è rappresentato il processo di avvio autenticato (authenticated boot) di una Trusted Platform: subito dopo il reset della piattaforma, il processore esegue il codice del CRTM, che effettua la misurazione (cioè il calcolo del digest) della restante parte del BIOS; la misura d integrità (il digest) viene accumulata in un PCR all interno del TPM mediante operazione di estensione 94 e poi il BIOS convenzionale viene eseguito. Con la stessa procedura il BIOS, appena misurato, misura a sua volta il boot loader, la cui misura di integrità viene memorizzata nel TPM e che viene successivamente caricato ed eseguito. La procedura di avvio autenticato implementata dal Trusted Platform effettua i passi fino alla misurazione del boot loader; poi devono essere quest ultimo ed il sistema operativo a proseguire le operazioni di misura su tutti i componenti prima del loro caricamento ed esecuzione. È necessario che boot loader e sistema operativo siano TCG-aware, cioè che abbiano il supporto per il TPM e continuino il processo di authenticated boot. La procedura di avvio autenticato permette di costruire una catena di fiducia transitiva (chain of transitive trust) a partire dal CRTM attraverso tutti i componenti caricati ed eseguiti, le cui misure di integrità sono accumulate nei registri PCR. I digest memorizzati in tali registri rappresentano una fotografia (statica) dei componenti in esecuzione nel sistema e delle loro configurazioni all atto del loro caricamento. Tali digest, per mezzo di integrity log aggiuntivi, permettono di identificare in modo univoco tutti i componenti caricati all avvio e le loro configurazioni. Il TPM mette a disposizione primitive per remote attestation e sealing che si basano sul contenuto dei PCR, cioè delle misure di integrità del sistema. Nel primo caso, durante Che produce in uscita un digest calcolato sulla concatenazione del valore precedente del registro e della misura di integrità del componente o della sua configurazione. 56 La virtualizzazione e i suoi aspetti di sicurezza

57 l accesso ad un servizio, il fornitore dello stesso, mediante protocollo di accesso/autenticazione opportunamente modificato, può richiedere informazioni sullo stato di integrità del client (cioè i valori dei PCR firmati digitalmente dal TPM) l attestazione remota e decidere se concedere l accesso o meno al servizio sulla base di quali componenti sono in esecuzione sul client e con quale configurazione. Nel secondo caso il TPM permette di legare l accesso a dati e l uso di chiavi crittografiche ad un preciso stato della piattaforma, rappresentato da un insieme specifico di valori dei PCR. L accesso a dati e chiavi è negato se la piattaforma è in uno stato differente da quello voluto ed impostato. Figura 23: Authenticated boot Uso combinato di virtualizzazione e Trusted Computing Al fine di assicurare alti livelli di sicurezza ai sistemi di elaborazione dati, tradizionalmente si è fatto uso di security kernel specificatamente progettati con meccanismi di Mandatory Access Control per realizzare differenti modelli di protezione ed accesso ai dati, tra cui quelli appartenenti alla tipologia Multilevel Security come Bell-La Padula, Biba, Chinese Wall, ecc. Sebbene sistemi operativi che includano (almeno in parte) tali funzionalità siano disponibili anche per piattaforme x86 (per esempio SELinux 96 ), nella maggior parte dei casi la complessità di configurazione non li rende adatti per l utente finale o comunque li confina ad utilizzi molto particolari. Come visto nel paragrafo 2.3, con l introduzione del supporto hardware per la virtualizzazione nelle ultime generazioni dei processori e chipset Intel e AMD, si sono introdotte anche sulle piattaforme x86 tecniche di partizionamento delle risorse hardware, consolidate nel contesto dei mainframe: tale linea di sviluppo dei produttori hardware fornisce un 95 Figura tratta dal capitolo "Trusted Computing" nel libro Handbook of Information and Communication Security

58 ulteriore impulso all uso della virtualizzazione per scopi di sicurezza. In questo contesto la virtualizzazione dei sistemi operativi ha l obiettivo di ottenere un migliore isolamento dei componenti software: per isolamento si intende il partizionamento delle aree di memoria in cui i componenti sono eseguiti e l uso di politiche di controllo di flusso dell informazione tra i componenti attuate dal VMM. In particolare la virtualizzazione, non richiedendo un grado predefinito di granularità del partizionamento delle risorse, permette di suddividere un sistema di elaborazione in un certo numero di compartimenti (cioè ambienti di esecuzione protetti) in cui siano eseguiti contemporaneamente macchine virtuali complete e micro componenti che interagiscono direttamente con il VMM senza la mediazione di un sistema operativo. All interno di ciascun compartimento non vi è alcuna garanzia a priori sulla sicurezza dei dati elaborati: occorre che il componente software eseguito sia ben progettato e realizzato. A garanzia di ciò, soprattutto per componenti critici, è opportuno che la relativa correttezza di progetto e realizzazione siano formalmente verificati, o comunque valutati secondo uno schema di certificazione di sicurezza (come il Protection Profile per high-security kernels Common Criteria 97 ). Sviluppare componenti di piccola dimensione, implica la minimizzazione del numero di linee del loro codice sorgente, una buona pratica che tende a ridurre (o contenere) il numero dei bug e ad incrementarne l affidabilità. Un esempio di tale approccio, per esempio per un componente critico per la sicurezza come il VMM, è dato dall architettura micro-kernel della famiglia L4 98 che realizza un security kernel in modo non monolitico e di cui esiste una implementazione formalmente verificata chiamata sel4 99. In questa prospettiva, le architetture dei sistemi possono essere progettate realizzando un Trusted Computing Base (TCB) minimale e non monolitico, costituito da un VMM e da piccoli compartimenti che eseguano i servizi di sicurezza essenziali per il sistema (per esempio GUI e storage sicuri), che possa essere valutato al fine di certificare l affidabilità dell intero sistema. La tecnologia di Trusted Computing, se integrata in tali sistemi, permette di identificarne i componenti in esecuzione: è possibile in tal modo limitare l esecuzione solo di componenti valutati come affidabili (secure boot), oppure è possibile verificare in remoto (remote attestation) i componenti misurati durante l avvio del sistema (authenticated boot), per esempio durante l accesso ad un servizio o risorsa critici come una corporate LAN 100. Il primo sistema sperimentale per hardware x86 basato su questo approccio di cui si ha riscontro nella letteratura scientifica, è Terra, un Trusted VMM che ha lo scopo di isolare le applicazioni critiche in macchine virtuali differenti che possono essere crittograficamente autenticate da parti remote. Terra non fa uso di hardware di sicurezza. Next-Generation Secure Computing Base (NGSCB) 101, già Palladium, è l idea di Microsoft per un Trusted Operating System basato su virtualizzazione e hardware per Trusted La virtualizzazione e i suoi aspetti di sicurezza

59 Computing, cioè il TPM. Il sistema mette a disposizione una partizione per l esecuzione del software non fidato ed un altra, isolata dalla prima, per l esecuzione protetta di software critico. Delle tecnologie sviluppate in tale progetto sperimentale, solo una piccola frazione sembra essere stata trasferita nei prodotti come Microsoft Windows Vista e Windows 7: Bitlocker Drive Encryption 102 che realizza la cifratura di volumi interi. È assente invece il partizionamento sicuro degli ambienti di esecuzione mediante virtualizzazione. Altri esempi di evoluzione in questa direzione sono i framework opensource sviluppati nei progetti di Ricerca e Sviluppo European Multilateral Security Computing Base (EMSCB) 103 e Open Trusted Computing (OpenTC) 104, entrambi basati sull uso del micro-kernel L4 come VMM e di Linux come sistema operativo per macchine virtuali complete. OpenTC in aggiunta può usare anche l hypervisor Xen come VMM e attraverso questo anche Microsoft Windows XP come sistema operativo per le macchine virtuali complete. Il paradigma (virtualizzazione e Trusted Computing) fondamento di EMSCB e OpenTC, prevede un modello architetturale, rappresentato in Figura 24, orientato allo sviluppo di framework di sicurezza completi e multiuso - non già, semplicemente, sistemi operativi convenzionali in grado di riconoscere il chip TPM - adatti a molteplici scenari applicativi, idealmente per qualunque applicazione. I servizi del sistema sono realizzati come componenti software eseguiti in compartimenti differenti, minimali ed isolati tra loro e che possono essere misurati, cioè identificati, al fine di poter decidere se considerarli trusted oppure no. Tali servizi insieme al VMM costituiscono il TCB del sistema. La comunicazione tra compartimenti è soggetta a politiche di controllo di flusso dell informazione attuate dal VMM. Il TPM costituisce la Root of Trust hardware per l intero sistema. Non solo i servizi del sistema, ma anche applicazioni critiche per l utente possono essere isolate in differenti compartimenti e misurate: esse possono essere progettate come appliances costituite da una o più macchine virtuali. In questa direzione in OpenTC sono stati definiti tre scenari applicativi in cui sperimentare il framework realizzato: Private Electronic Transactions (PET) 105, Corporate Computing at Home (CC@H) 106 e Virtual Data Centers (VDC). Il primo scenario prevede che a fianco di una macchina virtuale in cui sono eseguite applicazioni per le normali operazioni (office automation, client di posta elettronica, ecc.) vi sia un compartimento dedicato in cui è eseguito un Trusted Browser, usato per esclusivamente per accedere a servizi critici per l utente (Home Banking, e-auctions, ecc.). Il compartimento dedicato è isolato dalla macchina virtuale principale in cui sono eseguite tutte le altre applicazioni e non può accedere a siti web generici. L accesso ai servizi critici è concesso solo dopo che il fornitore del servizio ha verificato, mediante remote attestation, che nel compartimento dedicato sia eseguito software, il Trusted Browser, considerato affidabile, per esempio mediante inserimento dell identificazione crittografica (digest)

60 del compartimento in una white list. Il secondo scenario prevede che su una piattaforma usata, per esempio a casa dell utente, un compartimento sia dedicato ad usi corporate e che sia eseguito in parallelo a compartimenti dedicati all uso privato. Lo scambio di dati tra i compartimenti corporate e privati dell utente non è ammesso. L accesso alle risorse corporate (cioè la rete aziendale remota ed i dati memorizzati localmente e protetti mediante cifratura) può avvenire solo dal compartimento corporate, previa verifica (locale o remota) della sua integrità. Il terzo scenario, più complesso e orientato ai data center, prevede che su ciascuna piattaforma fisica possano essere eseguite macchine virtuali di clienti differenti, che devono essere perciò completamente isolate l una dall altra. Inoltre macchine virtuali dello stesso cliente possono essere eseguite su piattaforme fisiche differenti e contemporaneamente comunicare liberamente tra loro all interno di un Trusted Virtual Domain isolato da quello di altri clienti. Questo scenario prefigura l evoluzione verso architetture adatte ad incrementare la sicurezza del Cloud Computing, un paradigma emergente per l elaborazione distribuita su Internet. L approccio realizzato nei framework Terra, NGSCB, EMBCB e OpenTC si fonda sulla tecnologia di Trusted Computing e sul partizionamento sicuro delle risorse garantito dalla virtualizzazione; la correttezza di progetto e realizzazione dei VMM impiegati è pertanto un requisito imprescindibile, che se non soddisfatto nella realtà, mina di fatto la sicurezza di tali framework. Figura 24: Framework basato su Trusted Computing e virtualizzazione Figura tratta dal capitolo "Trusted Computing" nel libro Handbook of Information and Communication Security. 60 La virtualizzazione e i suoi aspetti di sicurezza

61 Acronimi API Application Programming Interface CED Centro Elaborazione Dati CPU Central Processing Unit CRTM DHCP Core Root of Trust for Measurement Dynamic Host Configuration Protocol DNS Domain Name System EFS Encrypting File System GDT Global Descriptor Table GUI Graphical User Interface HA High Availability HVM Hardware Virtual Machine IDT Interrupt Descriptor Table IDTR Interrupt Descriptor Table Register IT Information Technology KVM Kernel Virtualization Module LDAP Lightweight Directory Access Protocol LDT Local Descriptor Table NAT Network Address Translation NIC Network Interface Controller NTP Network Time Protocol OS Operating System PC Personal Computer PCI Peripheral Component Interconnect PCR Platform Configuration Register RAID Redundant Array of Independent Disks RAM Random Access Memory RTM Root of Trust for Measurement RTR Root of Trust for Reporting 61

62 RTS Root of Trust for Storage SAN Storage Area Network SMM System Management Mode SO Sistema Operaivo TC Trusted Computing TCB Trusted Computing Base TCG Trusted Computing Group TP Trusted Platform TPM Trusted Platform Module VGA Video Graphics Array VM Virtual Machine VMBR VMCB VMCS Virtual Machine Based Rootkits Virtual Machine Control Block Virtual Machine Control Structure VMM Virtual Machine Monitor 62 La virtualizzazione e i suoi aspetti di sicurezza

63 BIbliografia Boari M., Balboni S. (marzo 2007) Tecniche di virtualizzazione: teoria e pratica Mondo Digitale n.1, BSI and Sirrix AG security technologies (2008) - Protection Profile for a High-Security Kernel (HASKPP), version 1.14 Cabuk S., Dalton C.I, Eriksson K., Kuhlmann D., Ramasamy H.V., Ramunno G., Sadeghi A.R., Schunter M., Stueble C. (2010) Towards automated security policy enforcement in multi-tenant virtual data centers, Journal Of Computer Security, Volume 18, n.1, b7467efaa &pi=5 Cooke E., Jahanian F., Oberheide J., Empirical Exploitation of Live Virtual Machine Migration, Dawson P., Bittman T.J. (2008) Virtualization Changes Virtually Everything Gartner Research, Gartner Research, Desai A. (2009), The Definitive Guide to Virtual Platform Management, Realtime Publishers, Dong Yaozu et al. (agosto 2006), Extending Xen with Intel Virtualization Technology, Intel Technology Journal, Volume 10, Issue 03, itj/2006/v10i3/v10-i3-art03.pdf Ferrie P. (2006), Attacks on Virtual Machine Emulators, Symantec Advanced Threat Research, Fritsch H. (agosto 2008), Analysis and detection of virtualization-based rootkits, Technische Universität München, Garfinkel T., Pfaff B., Chow J., Rosenblum M., Boneh D. (2003) Terra: A Virtual Machine-Based Platform for Trusted Computing, ACM SOSP 03, papers/sosp03-terra.pdf King S. T. et al. (2006), SubVirt: Implementing malware with virtual machines, Proceedings of the 2006 IEEE Symposium on Security and Privacy, IEEE Computer Society Washington, DC, USA, Kuhlmann D., Landfermann R., Ramasamy H.V., Schunter M., Ramunno G., Vernizzi D. (2006) An Open Trusted Computing Architecture Secure Virtual Machines Enabling User-Defined Policy Enforcement, IBM Research Report Vol. RZ3655, watson.ibm.com/library/cyberdig.nsf/398c93678b87a12d aca/7024 c307ea0dfaee852571d0003b10f3 Lioy A., Ramunno G. (febbraio 2010) Trusted Computing in "Handbook of Information and Communication Security" (Peter Stavroulakis and Mark Stamp, Springer), b6966&pi=31 63

64 Liston T., Skoudis E. (2006), On the Cutting Edge: Thwarting Virtual Machine Detection, McMillan R. (maggio 2008), Hackers find a new place to hide rootkits, PCWorld, to_hide_rootkits.html Oberheide J., Cooke E., Jahanian F. (marzo 2008), Empirical Exploitation of Live Virtual Ma-chine Migration, Ormandy T. (2007), Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments, CanSecWest, Phelps J.R., Dawson P. (luglio 2007), Demystifying Server Virtualization Taxonomy and Terminology, Gartner Research, search&id= Rutkowska J., (novembre 2004) Red Pill... or how to detect VMM using (almost) one CPU instruction, Trusted Computing Group (2007) TCG Architecture Overview, Version 1.4, Trusted Computing Group (2007) TPM Main Specification Level 2 Version 1.2, Revision 103, VMWare (2006), Virtualization Overview, WMWare White Paper, pdf/virtualization.pdf Wojtczuk R. (agosto 2008), Subverting the Xen hypervisor, com/bh08/papers/part1-subverting_xen.pdf 64 La virtualizzazione e i suoi aspetti di sicurezza