In den Köpfen der IT-Entscheider und Security-Spezialisten gibt es von einem virtuellen Computer ein ganz bestimmtes Bild: Er ist ein vollwertiger Rechner mit spezifischen Systemeigenschaften, der gleichzeitig unabhängig ist von dem System, auf dem er betrieben wird. Das System und die darin betriebene Software lassen sich ohne Beeinflussung überwachen und konfigurieren. Bei Problemen kann das Gastsystem jederzeit eingefroren, durchgestartet oder auf einen definierten Stand zurückgesetzt werden. Läuft etwas aus dem Ruder, kann durch eine unabhängige, übergeordnete und damit sichere Instanz der Zustand kontrolliert werden. Das Ganze erfolgt zudem schnell und intuitiv, was im Vergleich zu physischen Systemen zu völlig neuen Möglichkeiten führt.
Grob skizziert sind genau das die Vorzüge, welche die Virtualisierung zu einem wichtigen Instrument bei der Analyse von gefährlichem Code oder der Abwehr von Sicherheitsrisiken werden liessen. Voraussetzung hierfür ist die fehlerfreie Arbeit des sogenannten Hypervisors, jener Softwareschicht, die ein Host- vom Gastsystem trennt und nur indirekten und kontrollierten Zugriff erlaubt und somit die vollständige Isolation zwischen Gast und Host ermöglicht. Und so findet sich heute in vielen Geräten mit schützenswerten Inhalten ein Hypervisor: in BluRay- oder HDDVD-Playern ebenso wie in modernen Spielekonsolen wie beispielsweise der Xbox 360 und der PlayStation 3. Aber auch manche Appliances, Stand-alone-Systeme mit vorinstallierter Software (wie beispielsweise intelligente Router und Firewalls) sowie einige Content-Management-Systeme basieren auf virtuellen Maschinen. Hierdurch werden diese Anwendungen unabhängig von der eingesetzten Hardware, und der Inhalt kann verborgen werden.
Unternehmen wiederum vertrauen auf Virtualisierung, um kostengünstig ihre IT-Sicherheitskonzepte durchzusetzen, beispielsweise für das Auslegen von Honey Pots oder Honey Nets, die eingesetzt werden, um E-Mail-Spamfilter aktuell zu halten oder um gefährliche Trends im Internet zu beobachten und möglichst schnell reagieren zu können, um so rechtzeitig die eigene Infrastruktur zu schützen. IT-Sicherheitsexperten und Hersteller von Anti-Viren-Produkten benutzen bereits seit Jahren Virtualisierungstechniken, um das Verhalten von Viren, Trojanern und anderem Schadcode zu beobachten und zu analysieren.
Risse in der Brandschutzmauer
Doch mittlerweile bekommt das Vertrauen in die Vorzüge der Virtualisierung Risse. Denn Schadcode kann erkennen, dass er sich in einer virtuellen Maschine (VM) befindet – und verhält sich dann anders. Dieses «Erkennen», dass sich eine Anwendung auf einem virtuellen System befindet, ist zudem Voraussetzung für das Aushebeln des Schutzmantels.
Dass dies gelingen kann, wurde bereits gezeigt, indem Schwachstellen im Hypervisor einer Spielkonsole ausgenutzt wurden, um beliebige Software darauf auszuführen. Öffentlich publizierte Forschungen zu diesem Themenbereich gibt es allerdings kaum. Eine der wenigen Arbeiten zu dem Thema wurde auf der diesjährigen CanSecWest-Sicherheitskonferenz vorgetragen. Es wurde dabei über Löcher in der Abschottung virtueller Maschinen anhand weit verbreiteter Virtualisierungslösungen referiert. An verschiedenen Beispielen wurde erläutert, wie Schadcode der Isolation entfliehen oder VM respektive Hypervisor zum Absturz bringen kann. Die Konsequenz: Es muss akzeptiert werden, dass auch virtuelle Maschinen und deren Hosts trotz Virtualisierung Gefahren ausgesetzt und deshalb geeignete Massnahmen notwendig sind.
Sicherheitsmassnahmen bei Host und VM
Angriffsszenarien und Abwehrmassnahmen
In der Praxis gibt es zahlreiche Szenarien, wie Angreifer eine virtuelle Maschine oder deren Infrastruktur attackieren können – von aussen wie von innen!
- Angriffe von aussen: Das derzeit wahrscheinlichste und transparenteste Beispiel ist, dass eine VM über Verbindungen kommuniziert, die nicht vertrauenswürdig sind, zum Beispiel, wenn diese an das Internet angeschlossen sind. Diesem Gefährdungspotential lässt sich am einfachsten begegnen, indem auf Firewall- und Proxy-Lösungen zu deren Schutz zurückgegriffen wird – analog zu ihren physikalischen Pendants.
- Angriffe von innen: Im Gegensatz zu externen Bedrohungen lassen sich Intrahost-Threats – Bedrohungen, die zwischen virtuellen Maschinen auf einem Host existieren – nur sehr schlecht oder gar nicht mit herkömmlichen Security-Tools absichern oder erkennen. Zudem entsprechen sie nicht den üblichen Erfahrungen von Administratoren und IT-Managern. So werden beispielsweise für die Kommunikation zwischen VMs eines Host virtuelle LAN-Infrastrukturen als Teil der Virtualisierungslösung genutzt, die von aussen nicht einsehbar sind.
Hier werden, je nach Virtualisierungslösung, die Datenpakete nur im Speicher des Host zwischen den VMs ausgetauscht. Paket-Sniffer sehen davon nichts, weshalb herkömmliche Firewalls und Sicherheitswerkzeuge diesen Datenverkehr nicht überwachen oder steuern können. Daraus resultiert ein potentielles Sicherheitsrisiko, welches virtuelle Maschinen Angriffen anderer virtueller Maschinen aussetzen kann. Im Ergebnis ist beispielsweise eine Intrahost-Denial-of-Service-Attacke möglich – eine schadhafte oder infizierte virtuelle Maschine beeinflusst andere, benachbarte virtuelle Maschinen. So wird beispielsweise bei diesem Denial-of-Service-Angriff das virtuelle LAN mit Schadcode oder Traffic überflutet oder der Hypervisor zum Absturz gebracht, was sämtliche VMs gleichzeitig ausschaltet. Erst das hostseitige Monitoring dieser Maschinen würde enthüllen, dass sie nicht mehr erreichbar sind.
Durch Separation und Legitimation von Intrahost-Kommunikation ist es möglich, dass nur bestimmte virtuelle Maschinen untereinander kommunizieren oder Daten austauschen können. Für die Separation können virtuelle Netzwerk-Switches eingesetzt werden. Die Legitimation ist meist nur technisch aufwendig auf Basis von Betriebssystemfunktionen abzubilden, beispielsweise mittels IPSec. In diesem Fall muss sich ein Client zuerst ausweisen, bevor ein Datenaustausch beginnen kann. Auf Basis dieser Massnahmen lässt sich der Bereich, innerhalb dessen sich ein Ereignis ausbreitet, relativ einfach auf eine festgelegte Gruppe eingrenzen.
Obwohl Virtualisierungstechniken eine logische Partitionierung von virtuellen Maschinen erlauben, die mit der räumlichen Trennung zweier physischer Maschinen vergleichbar ist, können Eindringlinge diese softwaredefinierte Trennung überwinden und ins System gelangen. Solche Löcher können einerseits durch Fehler bei den emulierten Hardwarekomponenten oder des Hypervisors entstehen. Andererseits existieren virtualisierungstypische Funktionen wie VM-Tools und Memory-Sharing, die als Einstieg genutzt werden können. VM-Tools beispielsweise stellen neben Treibern auch Komponenten für das Drag&Drop zwischen VMs und VM oder Host bereit.
Weiterhin erlauben sie den Zugriff auf das Dateisystem des Host aus der VM heraus. Was als Arbeitserleichterung für Entwickler und Administratoren gedacht ist, kann im Angriffsfall ein offenes Scheunentor darstellen. Bei einer Analyse der VM-Tools von
Vmware konnte kürzlich gezeigt werden, dass sie sich auf vielfältige Art missbrauchen lassen. Gleiches wird für andere Virtualisierungslösungen gelten.
Beim Shared Memory nutzen virtuelle Maschinen einen Pool aus Speicherseiten des Host bei Bedarf. So kann den Gastsystemen in Summe mehr Speicher zugeordnet werden, als auf dem Host verfügbar ist. Eine virtuelle Maschine kann sich dann bei Bedarf mehr Speicher nehmen und gibt diesen zu einem späteren Zeitpunkt wieder frei. Bei dieser Technik besteht das Risiko darin, dass zum Beispiel aus Performance-Gründen die Speicherseiten nicht richtig gelöscht werden und so Speicherinhalte von einer VM zur anderen gelangen können. Da ein physischer Host normalerweise zahlreiche virtuelle Maschinen enthält, die wiederum über unterschiedliche Betriebssysteme, Patchlevel und Applikationen verfügen und oft verschiedenen Administratoren und Netzwerken gehören, ist dies problemlos möglich, speziell bei älteren Betriebssystemen, die über keine entsprechenden Schutzmassnahmen verfügen.
Die Art der Störfälle reicht von der Viren- und SPAM-Verbreitung über Datendiebstahl bis hin zu Denial-of-Service-Attacken und ist somit den Problemen gleichgestellt, die ein physisches System erleiden kann – nur der Zugangsweg ist ein anderer.
Risiken von Shared Memory
Definierte Prozesse geben Sicherheit
Virtuelle Maschinen müssen behandelt werden wie physische Systeme, die über zusätzliche Eigenschaften verfügen. Sie haben den gleichen Betriebsprozessen und Sicherheitsvorgaben zu unterliegen. Manche Systeme, etwa Altsysteme ohne weiteren Herstellersupport, erfüllen diese Prozessvorgaben allerdings nicht. Das kann zu dem Konflikt führen, einerseits Altsysteme hosten zu müssen, jedoch andererseits die Prozessvorgaben nicht erfüllen zu können.
Um diese Konflikte aufzulösen, hilft eine Risikoanalyse und
-bewertung. So liessen sich beispielsweise VMs, die an das Internet angeschlossen sind, auf einem gemeinsamen Host unterbringen. Weiterhin kann der isolierende Charakter der Virtualisierungslösungen unterstützt werden, indem virtuellen Maschinen jeweils eigene Hardware-Ressourcen (wie eine dedizierte Netzwerkkarte) zugewiesen werden. Zudem sollten diese risikobehafteten VMs sowohl untereinander als auch gegen den Rest des Netzwerks mit gängigen Mitteln wie Firewalls, Proxys und VLANs isoliert werden.
Ein durchdachtes Autorisierungskonzept ist ebenso notwendig wie hilfreich. Separation of Duties und Principle of Least Priviledge haben auch beim Zugriffs- und Verwaltungsmanagement von VM und Host ihren Sinn. Denn häufig stellt gerade der Administrator eines Virtualisierungs-Host eine potentielle Gefahrenquelle dar. Er ist in der Lage, weitreichende Konfigurationsänderungen innerhalb der virtuellen Maschine durchzuführen und dadurch ungewollt Intrahost-Angriffe zu ermöglichen. Mit einem geeigneten Berechtigungskonzept kann diese Möglichkeit entzerrt, erschwert und obendrein auditierbar gemacht werden.
Unautorisierte, nicht überwachte virtuelle Maschinen sollten nicht (mehr) vorkommen. Denn auch diese bergen ein Risikopotential. Zu jeder Zeit sollte eine Übersicht möglich sein über die vorhandenen virtuellen Maschinen, deren Zustand, Funktion und Zuordnung zu den verantwortlichen Personen. Dies setzt jedoch Management- und Monitoring-Lösungen voraus, die neben physischen Systemen auch virtuelle Systeme und deren Hosts integrieren können und auf deren Besonderheiten einzugehen verstehen. Zu diesen Besonderheiten gehören das schnelle Erscheinen und Verschwinden von Systemen ebenso wie das Springen von einem Host zum nächsten.
Gleichzeitig ist auch ein funktionierendes Patch-Management essentiell. Dieses muss nicht nur die virtuelle Maschine und die darin installierten Tools und Treiber des Virtualisierungsprodukts berücksichtigen, sondern ebenso den Host und die Virtualisierungslösung selbst.
Inter-Host- versus Intra-Host-Bedrohung
Fazit
Es ist unbestritten, dass sich Virtualisierung durch ihre diversen Vorzüge als Sicherheitswerkzeug eignet. Damit ergibt sich also kein Widerspruch. Genauso richtig ist aber auch, dass diese Technologie zusätzliche Herausforderungen sowohl für das operative als auch für das Sicherheitsmanagement bereithält. Zunächst ist zu differenzieren, wo und zu welchem Zweck Virtualisierung eingesetzt wird, und danach sind die notwendigen Massnahmen zu berücksichtigen. Beim Einsatz von Virtualisierung im produktiven Umfeld sind die oben beschriebenen Massnahmen angeraten. Die in der IT-Strategie verankerten Standards und Prozesse sind vorteilhaft und erleichtern auch den Umgang mit virtuellen Maschinen – zumal bei diesen die Lebensdauer kürzer sein kann. Diese hohe Agilität fordert alle IT-Bereiche ganz besonders.
Die Forderung, dass neben Stabilität, Performance und Kompatibilität vor allem Wert auf Sicherheit der virtualisierten Systeme in all ihren vielfältigen Aspekten gelegt werden muss, gilt in Fachkreisen als allgemein akzeptiert. Für die Nutzer gilt, dass beim Umgang mit riskantem Code oder geschäftskritischen Anwendungen das notwendige Augenmass vorhanden sein muss.
Die Autoren
Daniel Kern ist Senior Consultant, Jörg-Oliver Todamm ist CISSP und Associate Principal Consultant, beide bei Avanade. www.avanade.com
