Grundlagen Hyper-V-Sicherheit
Virtuelles real schützen
In fast allen Rechenzentren kommt heute Server-Virtualisierung zum Einsatz. Immer häufiger findet man auch Microsofts Hyper-V als Plattform, auf der verschiedene virtuelle Server-Systeme auf einer Hardware aktiv sind - was durchaus zu Sicherheitsproblemen führen kann. Wir stellen die eingebauten Sicherheitsmechanismen des Hyper-V vor und zeigen, was der Administrator zum Schutz seiner virtuellen Systeme tun kann.
Microsoft bietet zwei Lösungen zur Server-Virtualisierung an: Die schon ältere trägt den Namen "
Virtual Server 2005 R2" und kann auf Windows Server 2003 (x32 und x64) und Windows-XP-Systemen (x32
und x64) zum Einsatz kommen. Der Hersteller rät jedoch davon ab, die Software in
Produktivumgebungen auf einem XP-System zu betreiben. Die Lösung steht bei Microsoft zum
kostenlosen Download bereit [1]. Microsofts aktuelle Plattform ist jedoch Hyper-V. Die Software
gibt es sowohl als Bestandteil des Windows Servers 2008 R2 (und Windows Server 2008) als auch als
Stand-alone-Version (ebenfalls zum kostenlosen Download [2]). Beiden Lösungen ist gemeinsam, dass
der Anwender auf ihnen sowohl Windows- als auch Nicht-Windows-Systeme als Gastbetriebssysteme in
den virtuellen Maschinen betreiben kann.
Grundlegende Schutzmaßnahmen
Wird die Hyper-V-Rolle auf Windows Server 2008 installiert, so laufen danach alle
Betriebssysteminstanzenen auf virtuellen Maschinen (VMs) – auch die Instanz des Windows Servers
2008, aus der heraus der Administrator die anderen VMs installiert und verwaltet. Hyper-V benutzt
den Ansatz eines Microkernels, einer speziellen Abstraktionsschicht, die kleiner als 1 MByte ist.
Als Hypervisor vermittelt er zwischen der Hardware und dem Host-Betriebssystem (Bild 1). Diese
Schicht besitzt direkte Schnittstellen zur Hardware und startet immer vor dem eigentlichen
Betriebssystem. Das Design der Hypervisor-Schicht ist so ausgelegt, dass dort kein Programmcode
eines Drittherstellers ausführbar ist.
Systemkritische Aufgaben wie die Verwaltung der Hauptspeicherbereiche führt der Hypervisor
direkt aus, was eine Abschottung des Host-Betriebssystems von den virtualisierten Systemen
gewährleistet. Unter Hyper-V wird der Bereich, in dem das Host-System oder eine VM läuft, als
Partition bezeichnet. Der Administrator kann eine dieser Partitionen als Basiseinheit für die
Isolation definieren. Die Partition, in der das Host-Betriebssystem läuft, nennt Microsoft
Parent-Partition, die übrigen VM-Bereiche Child-Partitions (Bild 1). Die Parent-Partition besitzt
besondere Privilegien: Nur sie kann Child-Partitionen anlegen und verwalten. Zudem organisiert und
besitzt dieser Bereich den Zugriff auf all die Ressourcen, die dem Hypervisor nicht unterstehen.
Die Parent-Partition hat beispielsweise die Aufgabe, die Energieoptionen (Power-Management) und die
Ereignisse, die bei Hardwarefehlern auftreten, zentral zu verwalten. Eine weitere
Sicherheitsmaßnahme besteht darin, dass weder die Child- noch die ansonsten privilegierte
Parent-Partition in den Bereich des Hypervisors schreiben können.
Um die Isolation der Partitionen zu garantieren und zugleich die Angriffsfläche des Hypervisors
zu verringern, haben die Entwickler den Programmcode und die Dienste beschränkt, die innerhalb
dieser Schicht laufen können. So beinhaltet dieser Teil der Virtualisierungslösung keine I/O-Stacks
oder auch nur Gerätetreiber. Die Child-Partitionen kommunizieren mit der darunterliegenden Hardware
über Gerätetreiber, die innerhalb der Parent-Partition aktiv sind. Diese Art, mit Gerätetreibern
umzugehen, ist typisch für eine Hypervisor-Architektur, die auf einen Microkernel aufbaut ist.
Allerdings besitzt dieses Vorgehen auch Nachteile: Die Parent-Partition ist durch den Aufbau
grundsätzlich größeren Risiken ausgesetzt. Beispielsweise könnten fehlerhafte oder bösartige
Treiber diesen Bereich gefährden. Wir stellen weiter unten Lösungsmöglichkeiten vor, die der
Administrator zum Schutz der Parent-Partition nutzen kann.
Hardwarevoraussetzungen, die Sicherheit schaffen
Microsoft hat die Hardwarevoraussetzungen für den Einsatz des Hyper-V auch aus
Sicherheitsgründen sehr eng umrissen: Neben der hardwarebasierten Virtualisierung, die von der CPU
unterstützt werden muss, darf in der Parent-Partiton nur Windows Server 2008 in der x64-Version
oder gleich das nur in einer 64-Bit-Version angebotene R2-Release des Servers laufen. Nach Aussagen
der Microsoft-Ingenieure werden ausschließlich 64-Bit-Systeme zugelassen, weil diese ein
erweitertes und besseres Management für den Hauptspeicher wie auch für die Prozesse aufweisen. Ein
zusätzlicher Sicherheitgewinn: Diese Versionen von Windows beinhalten keinen Legacy-Code mehr. Sie
wurden von Grund auf neu entwickelt, wobei dabei die so genannte SDL-Methode (Security Development
Lifecycle) zum Einsatz kam [3].
Zu den weiteren Voraussetzungen für den Einsatz des Hyper-V gehört eine Reihe von
Sicherheitsvorrichtungen, die bei modernen Prozessoren standardmäßig zur Verfügung stehen und die
Hyper-V direkt nutzt. Dazu zählen DEP (Data Execution Prevention) und ASLR (Adress Space Layout
Randomization). DEP ist eine Technik, um Buffer Overruns zu verhindern. Bei solchen "Überläufen von
Pufferbereichen" wird ausführbarer und in der Regel bösartiger Programmcode direkt in
Datenpufferbereiche des Hauptspeichers geschrieben. Die Technik zur Verhinderung dieser Angriffe
wird bei den AMD-Prozessoren als "No Execute" (NX) und bei den Intel-Pendants als "Execute Disable"
(XD) bezeichnet.
ASLR soll vor Malware schützen. Das Verfahren verändert zwischen den Neustarts des Systems per
Zufall die Speicheradressen, an denen systemkritische Dateien zur Laufzeit im Hauptspeicher
abgelegt werden. Dies kann zum Beispiel Trojaner und Würmer, die immer wieder versuchen, die
gleichen Speicheradressen auf verschiedenen Systemen anzusprechen, relativ wirkungsvoll am
Ausführen ihrer Schadroutinen hindern.
Es sind also insgesamt drei wichtige Voraussetzungen, die eine Server-Hardware erfüllen muss,
damit Hyper-V von den Sicherheitsvorteilen profitieren kann: hardwarebasierte Virtualisierung,
hardwarebasiertes DEP/ASLR sowie die 64-Bit-Unterstützung. Wer feststellen will, ob seine Hardware
diese Features zur Verfügung stellt, kann dazu das freie Tool Securable [4] verwenden. AMD stellt
zudem für seine CPUs eine eigene Software [5] zum Überprüfen der benötigten Eigenschaften bereit
(Bild 2).
Schutz der Parent-Partition
Wird die Angriffsfläche der Parent-Partition verkleinert, so bedeutet dies immer eine höhere
Sicherheit für den gesamten Hyper-V-Server und die VMs. Dem Systemverwalter stehen unterschiedliche
Wege offen, um dieses Ziel schnell und sinnvoll umzusetzen: Er kann gleich bei der Installation die
Server-Core-Option auswählen, den so genannten Authorization Manager (Azman) verwenden oder BDE
(Bitlocker Drive Encryption) als Server-Feature einsetzen.
Soll die Server-Core-Variante des Windows Servers 2008 als Grundlage des Virtualisierungssystems
zum Einsatz kommen, so muss sich der Administrator bereits bei der Installation des Windows-Servers
dafür entscheiden – eine spätere Umwandlung des kompletten Windows-Servers in den Core-Server ist
nicht möglich. Hat er sich dafür entschieden, so steht ihm ein Server ohne die übliche
Windows-Oberfläche zur Verfügung, auf dem er eine Untermenge der Server-Rollen wie etwa den
Domänen-Controller, Datei-Server und eben auch den Hyper-V-Server verwenden kann. Generell ist die
Angriffsfläche eines solchen minimalen Server-Systems, das nur per Kommandozeile oder
Terminal-Server-Verbindung verwaltbar ist, deutlich verkleinert, was wiederum die Sicherheit des
Hyper-V steigert.
Ein weiterer Ansatz besteht darin, die Standalone-Version der Hyper-V-Software einzusetzen.
Dabei wird kein Virtualisierungs-Server auf einem Windows Server 2008 Standard, Enterprise oder
Datacenter installiert, sondern hier steht von Anfang an eine sehr schlanke
Virtualisierungsplattform ohne GUI zur Verfügung. Allerdings bietet eine derartige Installation
keine Optionen zur Hochverfügbarkeit wie das Windows Failover Clustering (WFC), das viele
IT-Verantwortliche in ihren Systemumgebungen benötigen.
Jeder Administrator sollte grundsätzlich nur mit den Zugriffsrechten und -privilegien
ausgestattet sein, die er zur Erledigung seiner Aufgaben unbedingt benötigt. Dieses "Least
Privileges"-Prinzip sollte man aus Sicherheitsgründen unbedingt auch bei den virtualisierten
Servern stringent durchhalten. Die für VMs verantwortlichen Administratoren sollten ausschließlich
die ihnen zugeordneten VMs verwalten können und auf keinem Fall die Möglichkeit besitzen, in
irgendeiner Weise auf die Parent-Partition zuzugreifen. Das funktioniert aber nur, wenn die
Zugriffsrechte dieser Personen entsprechend eingeschränkt und kontrolliert werden. Auf dem Hyper-V
Server kann dazu der Authorisierungs-Manager (Authorization Manager, Azman) des Betriebssystems zum
Einsatz kommen, den Microsoft erstmals mit dem Windows Server 2003 zur Verfügung stellte. Mit
dieser Software lassen sich Rollen für die VM-Administratoren direkt aus der MMC (Microsoft
Management Console) heraus festlegen und durchsetzen.
Schließlich sind noch die Möglichkeiten der Laufwerksverschlüsselung (Bitlocker Drive
Encryption, BDE) zu erwähnen, die der Hersteller standardmäßig mit Windows Server 2008 sowie den
Version Ultimate und Enterprise von Windows 7 bereitstellt. Um eine Hyper-V-Installation
abzusichern, kann ein Administrator die physischen Festplatten, auf den sich beispielsweise die
Dateien für die virtuellen Festplatten (Virtual Hard Disks, VHDs) und die Konfigurationsdateien
befinden, mittels BDE wirkungsvoll und vor allen Dingen für das System transparent verschlüsseln.
Microsoft stellt unter [6] ein White Paper zu diesem Thema zur Verfügung.
Grundlagen nicht vergessen
Zudem darf ein Administrator auch bei virtualisierten Systemen die klassischen Best Practices
aus dem Sicherheitsbereich nicht außer Acht lassen: Er sollte nie Anwendungen in der Parent
Partition installieren, die er dort nicht benötigt. Außerdem sollte er unbedingt eine dedizierte
physische Netzwerkschnittstelle für die Verwaltung der Parent Partition definieren und diese
niemals ungesichertem Netzwerkverkehr aussetzen. Sinnvollerweise setzt er ein separates VLAN für
das Management-Netzwerk auf, das mit entsprechend starken Sicherungs- und
Authentifizierungsmaßnahmen wie Smartcards für den Administratorzugang gesichert wird. Keine
virtuelle Maschine darf dabei irgendeine Zugangsmöglichkeit zur Netzwerkschnittstelle besitzen, die
für die Verwaltung der Parent Partition zum Einsatz kommt. Und schließlich gilt es natürlich, dafür
Sorge zu tragen, dass die Betriebssysteme und Anwendungen innerhalb der virtuellen Maschinen immer
mit Antivirenlösungen sowie allen Sicherheits-Updates und -Patches ausgestattet sind.
Neue Technik – neue Gefahren
Da Virtualisierung zu den anerkannten und häufig genutzten Techniken gehört, tauchen immer
häufiger auch spezielle Angriffstechniken auf, die sich die hohe Komplexität solcher Lösungen
zunutze machen, um die Systeme zu kompromittieren. Im Fall eines so genannten "Guest-Hopping"
-Angriffs wird der Angreifer versuchen, zwei virtuelle Maschinen zu identifizieren, die auf dem
gleichen Host-System aktiv sind. Will er beispielsweise Daten in der ersten der beiden VMs
angreifen, kann aber nicht an diese gelangen, so steht ihm nun noch der Weg offen, die zweite VM zu
infiltrieren und dann mit einem entsprechenden "Sprung" – dem Guest-Hopping – direkt in die
gewünschte VM einzudringen. Ein derartiges Szenario wurde zwar bereits einige Male beschrieben, es
ist wenig darüber bekannt, ob entsprechende Angriffe schon erfolgreich durchgeführt werden konnten.
Die Anbieter von Virtualisierungslösungen bestreiten zumeist, dass ein solches unkontrolliertes "
Wandern" zwischen den VMs möglich sei.
In einer anderen Variante dieses Angriffs wird ein solches Szenario auf der Ebene der
Hypervisoren durchgespielt: Gelingt es einem Angreifer, dem Hypervisor einen kompromittierten
Server unterzuschieben und sind in einem Netzwerk bereits mehrere Host-Systeme betroffen, so kann
das Angriffsprogramm von einem Virtual-Server-Host zum nächsten wechseln, wobei es für
Administratoren extrem schwierig wäre, diese Angriffe zu entdecken und abzuwehren.
Eine weitere Angriffsmethode wird von einigen Experten als "Hyper-Jacking" (Entführung des
Hypervisors) bezeichnet: Ein Angreifer bedient sich unterschiedlicher Methoden, um die Kontrolle
über den Hypervisor und damit über die komplette Virtualisierungslösung zu übernehmen. So kann er
beispielsweise einen zusätzlichen "Rogue Hypervisor" so auf dem System installieren, dass jener
unterhalb des echten Hypervisors direkt auf der Hardware aktiv wird. Ein zweiter Weg besteht darin,
die direkte Kontrolle über den Hypervisor zu erlangen. Schließlich kann ein kompromittierter
Hypervisor auch auf dem richtigen Hypervisor installiert werden, alle alle Ein- und Ausgaben sowie
die Systemaufrufe abzufangen.
Der bisher bekannteste dieser Angriffe ist das so genannte "Subvirt Virtual Machine Based Root
Kit" (VMBR). Es wurde bereits im Jahr 2006 als Proof of Concept entwickelt und hat damals für
ziemliches Aufsehen gesorgt. Diese Software installierte sich als Schicht zwischen dem
Originalsbetriebssystem und der darunterliegenden Hardware. Das Originalsystem wurde dann unbemerkt
als Gastsystem betrieben.
Links rund um Microsoft Hyper-V
Lesen Sie mehr zum Thema
