LA VIRTUALIZZAZIONE E I SUOI ASPETTI DI SICUREZZA

LA VIRTUALIZZAZIONE
E I SUOI ASPETTI
DI SICUREZZA
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:
http://creativecommons.org/licenses/by-nc-nd/2.5/it/
BY:
€
2
La virtualizzazione e i suoi aspetti di sicurezza
SOMMARIO
Prefazione 7
Introduzione 8
1La
virtualizzazione: concetti di base
9
1.1 Che cosa si intende per virtualizzazione
9
1.2 Cenni storici
11
1.3 Vantaggi e svantaggi della virtualizzazione
12
1.4 Tecniche di virtualizzazione dei server
13
2Virtualizzazione
15
mediante partizionamento
2.1 Soluzioni tecnologiche
2.1.1 Hardware Partitioning
15
2.1.2 Hypervisor
15
2.1.3 Virtual Machine Monitor
16
2.1.4 OS virtualization
18
2.2 Approcci implementativi
18
2.2.1 Virtualizzazione completa
18
2.2.2 Paravirtualizzazione
20
2.3 Supporti hardware
3Prodotti
per la virtualizzazione
15
20
23
3.1 Sun Solaris Containers/Zones
23
3.2 VMware
25
3.3 Hyper-V
26
3.4 Xen
28
3.5 KVM
29
3.6 Libvirt
29
3
4Aspetti
per il dimensionamento di una struttura
30
4.1 Networking
31
4.2 Storage
31
4.3 Server
32
5La
33
sicurezza negli ambienti virtualizzati
5.1 Virus basati sulla virtualizzazione
34
5.1.1 User Space e Kernel space rootkit
34
5.1.2 HVM rootkits
34
5.1.2.1SubVirt
36
5.1.2.2Blue Pill
37
5.1.2.3Vitriol
38
5.1.2.4Xen Subvertion
39
5.2 Virtual machine detection
40
5.2.1 Ricerca di artefatti specifici dell’hypervisor
41
5.2.2 Analisi dei tempi di esecuzione
41
5.2.3 Utilizzo di hardware embedded
42
5.2.4 Analisi remota dello stack di rete
43
5.2.5 Progetti
43
5.2.5.1Red Pill
43
5.2.5.2Scoopy
43
5.2.5.3Doo
44
5.2.5.4VMDetect
44
5.3 Live Migration
45
5.4 VM Escape & Denial Of Service
45
5.4.1 VMware
46
5.4.2 Xen/QEMU
46
4
La virtualizzazione e i suoi aspetti di sicurezza
5.5 VM Integrity
47
5.5.1 Cifratura dei dischi virtuali gestita dal VMM
47
5.5.1.1Cifratura dei dischi in VMware ACE
48
5.5.2 Cifratura dei dischi virtuali gestita dai sistemi guest
49
5.5.3 Cifratura dei dischi virtuali gestita dal sistema host
49
5.6 Network Isolation
50
5.6.1 VirtualServer 2005
51
5.6.2 VMware ESX 3
52
5.6.3 Xen
52
5.6.4 Cisco Nexus 1000V Virtual Switch
53
6Nuovi
55
orizzonti per la virtualizzazione
6.1 Cenni sulla tecnologia Trusted Computing
55
6.2 Uso combinato di virtualizzazione e Trusted Computing
57
Acronimi
61
Bibliografia
63
5
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
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
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.1Che 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 settori1. 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
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
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.2Cenni 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 10-15 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
1.3Vantaggi 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
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.4Tecniche 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
Hardware
Partitioning
Partitioning
Virtualization
Virtual
Machine
Monitor
Hypervision
Hypervisor
Hosted
VMM
Instruction-Set
Virtualization
OS
Virtualizzato
n
OS
Hosted
VMM
Figura 5: Classificazione delle tecniche di virtualizzazione3
3
La figura è tratta (e qui riadattata) da Phelp J.R., Dawson P. (luglio 2007).
13
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;
• MAME4 (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 Transmeta5; si tratta di CPU
che, pur non essendo in modo nativo compatibili con l’architettura x866, 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.
4
http://mamedev.org/
5
http://www.transmeta.com/tech/microip.html
6
Queste CPU appartengono all’architettura Very Long Instruction Word (VLIW).
7
http://java.sun.com/
14
La virtualizzazione e i suoi aspetti di sicurezza
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.1Soluzioni tecnologiche
2.1.1
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 nPartition8 della HP e Dynamic System Domains9 della
SUN.
2.1.2Hypervisor
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.
8
http://h20341.www2.hp.com/hpux11i/cache/323751-0-0-0-121.html
9
http://www.sun.com/servers/highend/dr_sunfire/
15
Figura 6: Sistema virtualizzato tramite hypervisor
La Figura 6 mostra come l’hypervisor permetta la condivisione dell’hardware fisico tra diverse macchine virtuali10. 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.
2.1.3 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
Alcuni esempi della prima tipologia sono: Microsoft Virtual Server11, Microsoft Hyper-V12
(stand alone edition), VMware server13, Virtual Box14, Parallels Server15.
Alcuni esempi della seconda tipologia sono: Microsoft Hyper-V, Xen16 e relativi prodotti derivati da esso (OracleVM17, VirtualIron18, SUN xVM19), VMware ESX server20, Parallels
Server Bare Metal21, Linux KVM22.
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
11
http://www.microsoft.com/italy/server/virtualserver/Default.mspx
12
http://www.microsoft.com/windowsserver2008/en/us/hyperv-main.aspx
13
http://www.vmware.com/products/server/
14
http://www.virtualbox.org/
15
http://www.parallels.com/it/virtualization/server/
16
http://www.xen.org
17
http://www.oracle.com/lang/it/technologies/virtualization/index.html
18
http://www.virtualiron.com/
19
http://www.sun.com/software/products/xvmserver/index.xml
20
http://www.vmware.com/products/vi/esx/
21
http://www.parallels.com/it/virtualization/server/
22
http://www.linux-kvm.org/page/Main_Page
17
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 Virtualization23
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/Zones24, FreeBSD Jails25, Virtuozzo26 e OpenVZ27.
2.2Approcci 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.
2.2.1 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, http://www.parallels.com/it/products/virtuozzo/os
24
http://www.sun.com/bigadmin/content/zones/index.jsp
25
http://wiki.freebsd.org/Jails
26
http://www.parallels.com/it/products/virtuozzo/
27
http://wiki.openvz.org/Main_Page
18
La virtualizzazione e i suoi aspetti di sicurezza
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 VMM28 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
2.2.2Paravirtualizzazione
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 è XEN29, 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.3Supporti 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 virtualizzazione30:
• VMX root operations, dedicata all’esecuzione del VMM;
• VMX non-root operations, dedicata all’esecuzione delle macchine virtuali.
29
http://www.xen.org/
30
Virtual Machine Extensions (VMX).
20
La virtualizzazione e i suoi aspetti di sicurezza
La transizione da una VMX privilegiata ad una non privilegiata è chiamata VM exit, mentre quella contraria VM entry.
Figura 9: VMX: transizioni di stato31
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 protezione32
31
La figura è tratta dalla presentazione della Digital Enterprise Group Intel Corporation, Understanding Intel® Vir-
tualization Technology, http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/
TWAR05015_WinHEC05.ppt
32
Idem.
21
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 SVM33. 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
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 Virtualization34; 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 VMM35.
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.1Sun
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 2.1.4.
35
Si vedano i paragrafi 2.1.2 e 2.1.3.
23
Figura 12: SUN Container/Zones
Come mostrato in figura, l’ambiente di virtualizzazione (container) contiene al suo interno
diverse zone36 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 system37 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
3.2VMware
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 descritte38.
1. 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 (http://www.vmware.com).
25
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.3Hyper-V
Hyper-V è l’ultima soluzione Microsoft di VMM basata su Windows Server 2008. Essa
viene distribuita sia nella versione Hypervisor-Hosted che nella versione OS-hosted39 (anche chiamata standalone). Per essere installato ha bisogno di un hardware che supporti
le estensioni dedicate alla virtualizzazione40.
Hyper-V implementa una tecnica chiamata Parent/Child partitioning la quale può essere
39
Si veda il paragrafo 2.1.3.
40
Intel o AMD. Si veda il paragrafo 2.3.
26
La virtualizzazione e i suoi aspetti di sicurezza
schematizzata come nella figura seguente:
Figura 13: Architettura di Hyper-V41
Come si può notare la partizione root è una macchina virtuale che esegue una copia di
Windows Server 2008 64 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-V42. 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 - http://www.virtuatopia.com/index.php/
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
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 043 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 XEN44
43
Gli altri domain vengono genericamente chiamati Domain U.
44
La figura è stata tratta da http://commons.wikimedia.org/wiki/File:XEN-schema.png
28
La virtualizzazione e i suoi aspetti di sicurezza
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
• 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
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.1Networking
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.2Storage
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
4.3Server
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
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 livelli45, 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 virtuali46.
È 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 5.6.
47
Si parla, ovviamente, di situazioni in cui gli apparati di rete (in particolare gli switch) adottano sistemi si sicurezza ap-
positi per evitare, ad esempio, attacchi basati sulla tecnica dell’arp-spoofing.
33
5.1Virus 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.
5.1.1
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.
5.1.2 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
Applicativi (user space)
Applicativi (user space)
S.O. (kernel space)
S.O. (kernel space)
Hypervisor (hyperjacker)
HARDWARE
HARDWARE
Sistema pulito
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 piccolo48
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 è SubVirt49.
2. 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 è BluePill50.
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 diversi51:
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)52.
48
Per questa ragione viene anche chiamato thin hypervisor.
49
Si veda il paragrafo 5.1.2.1.
50
Si veda il paragrafo 5.1.2.2.
51
P. M. Chen et al., SubVirt: Implementing malware with virtual machines, Proceedings of the 2006 IEEE Symposium
on Security and Privacy, maggio 2006.
52
http://www.eecs.umich.edu/virtual/papers/king06.pdf
35
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.
5.1.2.1SubVirt
SubVirt è un prototipo o, più in generale, una ricerca di HVM rootkits53 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 modificata54 intercettando la chiamata di sistema LastChanceShutdownNotification55 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 rilevato56.
53
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 5.2.5.1.
36
La virtualizzazione e i suoi aspetti di sicurezza
5.1.2.2 Blue Pill
Blue Pill57 è il proof-of-concept più noto di HVM rootkit58. 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.
58
http://bluepillproject.org
37
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.
5.1.2.3Vitriol
Vitriol59 è un progetto dimostrativo della Matasano Security60 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.
59
http://www.theta44.org/software/HVM_Rootkits_ddz_bh-usa-06.pdf
60
http://www.matasano.com
38
La virtualizzazione e i suoi aspetti di sicurezza
• 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
V
M
X
VM
Unitialize VM
F
O
R
K
VM Entry
Hypervisor
VM Exit
O
S
O
N
V
M
E
X
I
T
VM Entry
O
S
Figura 18: Sequenza di lancio di Vitriol61
5.1.2.4 Xen Subvertion
Il progetto Xen Subvertion62 (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, http://www.matasano.com
62
http://invisiblethingslab.com
39
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.2Virtual 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 honeypot63, 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 (http://www.few.vu.nl/argos).
40
La virtualizzazione e i suoi aspetti di sicurezza
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 IN64 (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).
5.2.2 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
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.
5.2.3 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 Mode65) delle CPU: ha il vantaggio
65
SMM è una modalità delle CPU Intel in cui tutti i processi vengono interrotti (compreso il sistema operativo) per po-
ter 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
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.
5.2.4 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 strumenti66 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.
5.2.5Progetti
Di seguito vengono citati e descritti un certo numero di tool che utilizzano alcune delle
tecniche viste nei paragrafi precedenti.
5.2.5.1Red Pill
Red Pill67 è 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 SIDT68 non privilegiata, essa può essere eseguita in
user mode.
66
Un esempio è Nmap (http://nmap.org).
67
http://invisiblethings.org/papers/redpill.html
68
Store Interrupt Description Table.
43
5.2.5.2Scoopy
Scoopy e la sua evoluzione ScoopyNG69 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).
5.2.5.3Doo
DOO70 è 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.
5.2.5.4VMDetect
VMDetect71 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
5.2.1 (utilizzo della istruzione IN con parametri particolari).
69
http://www.trapkit.de/research/vmm/scoopyng/index.html
70
http://www.trapkit.de/research/vmm/scoopydoo/index.html
71
http://www.codeproject.com/KB/system/VmDetect.aspx
44
La virtualizzazione e i suoi aspetti di sicurezza
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 ricercatori72 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.4VM
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
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.
5.4.1VMware
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 backdoor73.
x nota tabella74
Identificativo CVE Descrizione
CVE-2005-4459
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
CVE-2007-1744
Un baco di implementazione nel sistema di gestione delle shared folders
utility74 permette di accedere in scrittura all’intero file system dell’host
(directory traversal)
CVE-2007-4496
Utenti autenticati sul sistema guest con i privilegi di amministratore possono
corrompere o eseguire codice arbitrario sul sistema host
CVE-2007-4497
Utenti autenticati sul sistema guest con i privilegi di amministratore sono
in grado di determinare il crash del sistema host
5.4.2Xen/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-2007-4993
CVE-2007-1320
CVE-2007-1321
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 - http://chitchat.at.infoseek.co.jp/vmware/backdoor.html
74
È 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
5.5VM
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
propagarsi75 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.
5.5.1 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
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 0.9.1 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 patch76 .
5.5.1.1Cifratura dischi in VMware ACE
VMware ACE77 è 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 sicurezza78:
• 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.
76
http://lists.gnu.org/archive/html/qemu-devel/2008-06/msg00344.html
77
http://www.vmware.com/products/ace/
78
VMware - VMware ACE – Virtual Machine Encryption Basic – www.vmware.com/pdf/ace_encrypt_bg.pdf
48
La virtualizzazione e i suoi aspetti di sicurezza
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-crypt79: sistema integrato nel kernel Linux 2.6;
• TrueCrypt80: versione Linux che non può cifrare la partizione di boot.
Per quanto riguarda Windows , sono disponibili:
• EFS81: 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;
• Bitlocker82: versione disponibile nei sistemi Windows Vista Enterprise o Ultimate Edition. Il nuovo sistema per cifrare intere partizioni (compresa quella di sistema83) è integrato col TPM (Trusted Platform Module) hardware.
5.5.3 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 virtuali84.
79
http://www.kernel.org
80
http://www.truecrypt.org
81
http://www.microsoft.com
82
http://www.microsoft.com/windows/windows-vista/features/bitlocker.aspx
83
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 – http://www.microsoft.com/downloads/details.
aspx?FamilyID=2c3c0615-baf4-4a9c-b613-3fda14e84545&displaylang=en
49
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.6Network
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
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.
5.6.1 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 casi85.
• 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 2005
51
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.
5.6.2 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 virtuali86.
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.
5.6.3Xen
Xen utilizza un sistema analogo a quello di VMware ESX per garantire un ottimo isolamento del traffico87.
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 – www.vmware.com/pdf/vi3_security_archi-
tecture_wp.pdf
87
Xen – Xen networking – http://wiki.xensource.com/xenwiki/XenNetworking
52
La virtualizzazione e i suoi aspetti di sicurezza
Xen prevede che a ogni interfaccia virtuale nella macchina guest, chiamata ethX, corrisponda un’interfaccia virtuale nell’host visibile dal sistema operativo Linux88.
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.).
5.6.4 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 VMware89 chiamato Cisco Nexus 1000V in grado di sostituire il virtual switch nativo con uno nuovo.
Il Nexus 1000V90 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 corrispon-
dente.
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 - http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/
data_sheet_c78-492971.html
53
La figura seguente mostra in modo schematico l’architettura del Nexus 1000V:
Figura 22: Architettura del Cisco Nexus 1000V91
91
La figura è tratta dal sito web di Cisco, http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9902/da-
ta_sheet_c78-492971.html
54
La virtualizzazione e i suoi aspetti di sicurezza
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.1Cenni 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).
92
http://www.trustedcomputinggroup.org/
55
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
93
http://www.trustedcomputinggroup.org/developers/trusted_platform_module/specifications
94
Che produce in uscita un digest calcolato sulla concatenazione del valore precedente del registro e della misura di in-
tegrità del componente o della sua configurazione.
56
La virtualizzazione e i suoi aspetti di sicurezza
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 boot95
6.2
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 SELinux96), 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.
96
http://www.nsa.gov/research/selinux/index.shtml
57
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 Criteria97). 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 L498 che realizza un security kernel in modo non monolitico e di cui esiste una implementazione formalmente verificata chiamata seL499.
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 LAN100.
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
97
http://www.niap-ccevs.org/pp
98
http://www.l4hq.org
99
http://ertos.nicta.com.au/research/sel4
100
http://www.trustedcomputinggroup.org/developers/trusted_network_connect
101
http://www.microsoft.com/resources/ngscb/default.mspx
58
La virtualizzazione e i suoi aspetti di sicurezza
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 Encryption102 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)
102 http://www.microsoft.com/windows/windows-vista/features/bitlocker.aspx
http://www.microsoft.com/whdc/system/platform/hwsecurity/default.mspx
103 http://www.emscb.com
104 http://www.opentc.net
105 http://www.opentc.net/publications/OpenTC_Newsletter_03.html
106 http://www.opentc.net/publications/OpenTC_Newsletter_05.html
59
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 virtualizzazione107
107
Figura tratta dal capitolo "Trusted Computing" nel libro Handbook of Information and Communication Security.
60
La virtualizzazione e i suoi aspetti di sicurezza
Acronimi
API
–
Application Programming Interface
CED
–
Centro Elaborazione Dati
CPU
–
Central Processing Unit
CRTM – Core Root of Trust for Measurement
DHCP – 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
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 – Virtual Machine Based Rootkits
VMCB – Virtual Machine Control Block
VMCS – Virtual Machine Control Structure
VMM
–
Virtual Machine Monitor
62
La virtualizzazione e i suoi aspetti di sicurezza
BIbliografia
• Boari M., Balboni S. (marzo 2007) – Tecniche di virtualizzazione: teoria e pratica – Mondo
Digitale n.1, http://www.mondodigitale.net/Rivista/07_numero_1/Boari_p._38-49.pdf
• 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, http://iospress.metapress.com/content/m537866684577215/ ?p=af8e9b4572a
14945b7467efaa5509530&pi=5
• Cooke E., Jahanian F., Oberheide J., Empirical Exploitation of Live Virtual Machine Migration, http://www.net-security.org/dl/articles/migration.pdf
• Dawson P., Bittman T.J. (2008) – Virtualization Changes Virtually Everything – Gartner
Research, Gartner Research, http://www.gartner.com/resources/156400/156488/virtualization_changes_virtu_156488.pdf
• Desai A. (2009), The Definitive Guide to Virtual Platform Management, Realtime Publishers, http://nexus.realtimepublishers.com/dgvpm.php
• Dong Yaozu et al. (agosto 2006), Extending Xen with Intel Virtualization Technology, Intel Technology Journal, Volume 10, Issue 03, http://download.intel.com/technology/
itj/2006/v10i3/v10-i3-art03.pdf
• Ferrie P. (2006), Attacks on Virtual Machine Emulators, Symantec Advanced Threat Research, http://www.symantec.com/avcenter/reference/Virtual_Machine_Threats.pdf
• Fritsch H. (agosto 2008), Analysis and detection of virtualization-based rootkits, Technische Universität München, http://www.mnm-team.org/pub/Fopras/frit08/PDF-Version/frit08.pdf
• Garfinkel T., Pfaff B., Chow J., Rosenblum M., Boneh D. (2003) – Terra: A Virtual Machine-Based Platform for Trusted Computing, ACM SOSP’03, http://suif.stanford.edu/
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, http://www.eecs.umich.edu/virtual/papers/king06.pdf
• 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, http://domino.
watson.ibm.com/library/CyberDig.nsf/398c93678b87a12d8525656200797aca/7024
c307ea0dfaee852571d0003b10f3
• Lioy A., Ramunno G. (febbraio 2010) – Trusted Computing – in "Handbook of Information
and Communication Security" (Peter Stavroulakis and Mark Stamp, Springer), http://
www.springerlink.com/content/k33r27v012166072/?p=07b4f042f0e94289817084c9c
76b6966&pi=31
63
• Liston T., Skoudis E. (2006), On the Cutting Edge: Thwarting Virtual Machine Detection,
http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf
• McMillan R. (maggio 2008), Hackers find a new place to hide rootkits, PCWorld, http://www.pcworld.com/businesscenter/article/145703/hackers_find_a_new_place_
to_hide_rootkits.html
• Oberheide J., Cooke E., Jahanian F. (marzo 2008), Empirical Exploitation of Live Virtual
Ma-chine Migration, http://www.net-security.org/dl/articles/migration.pdf
• Ormandy T. (2007), Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environments, CanSecWest, http://taviso.decsystem.org/virtsec.pdf
• Phelps J.R., Dawson P. (luglio 2007), Demystifying Server Virtualization Taxonomy and
Terminology, Gartner Research, http://www.gartner.com/DisplayDocument?ref=g_
search&id=510007
• Rutkowska J., (novembre 2004) Red Pill ... or how to detect VMM using (almost) one
CPU instruction, http://www.invisiblethings.org/papers/redpill.html
• Trusted Computing Group (2007) – TCG Architecture Overview, Version 1.4, http://
www.trustedcomputinggroup.org/resources/tcg_architecture_overview_version_14
• Trusted Computing Group (2007) – TPM Main Specification Level 2 Version 1.2, Revision 103, http://www.trustedcomputinggroup.org/resources/tpm_main_specification
• VMWare (2006), Virtualization Overview, WMWare White Paper, www.vmware.com/
pdf/virtualization.pdf
• Wojtczuk R. (agosto 2008), Subverting the Xen hypervisor, http://invisiblethingslab.
com/bh08/papers/part1-subverting_xen.pdf
64
La virtualizzazione e i suoi aspetti di sicurezza