Mit der zunehmenden Verbreitung von virtuellen Maschinen werden diese zum lohnenden Ziel für Angriffe. Wie bei jeder komplexen Software sind die Virtualisierungslösungen nicht fehlerfrei. Meldungen über neu entdeckte Sicherheitslücken in Virtualisierungssystemen und darüber mögliche Angriffe finden sich immer häufiger. Das schlimmste Szenario dabei ist eine Attacke, die über eine virtuelle Maschine eine andere VM auf dem gemeinsamen Host angreift. Dazu übernimmt ein Angreifer zunächst über eine Schwachstelle in einer virtualisierten Applikation eines der virtuellen Gastsysteme. Im nächsten Schritt muss er über eine Schwachstelle in der Virtualisierungssoftware selbst aus dieser virtuellen Maschine in die Verwaltungskomponente der virtuellen Maschinen vordringen. Ist diese unter seiner Kontrolle, kann er alle anderen Gäste desselben Host-Systems kompromittieren.
Schwachstellen in der Virtualisierungssoftware stellen somit ein Risiko dar, das bei voneinander getrennten, physischen Servern so nicht besteht. Dabei handelt es sich nicht nur um theoretische Gefahren: In fast allen bekannten Virtualisierungsprodukten wurden bereits Schwachstellen entdeckt, die den Ausbruch aus einer virtuellen Maschine ermöglicht haben. Auf fast jeder Hacker-Konferenz führen Experten weitere Beispiele für derartige Angriffe vor (siehe auch "Sicher virtualisiert oder nur virtuell sicher?").
Die Gefahr besteht jedoch nicht unmittelbar. Sie entsteht erst, wenn zuvor ein Hacker erfolgreich in eine virtuelle Maschine eingedrungen ist. Dieser erste Einbruch ist dabei völlig unabhängig von der Virtualisierung und beruht allein auf Schwachstellen in den Anwendungen oder im Betriebssystem des ersten Ziels. Ein Angreifer, der beispielsweise über eine Schwachstelle in einem Web-Server die Kontrolle über das darunterliegende Betriebssystem erlangt, wird im ersten Schritt keinen Unterschied spüren, ob sich der HTML-Server auf einer eigenständigen Hardware oder in einer virtuellen Maschine befindet. Erst nach einer erfolgreichen Attacke kann der Hacker feststellen, dass er in einer virtuellen Maschine gelandet ist. Erst dann kann er versuchen, Sicherheitslücken der Virtualisierungssoftware auszunutzen und sich des Host-Systems zu bemächtigen.
Anwendungsumgebungen abschotten
Virtuelle Maschinen sind nicht so stark voneinander getrennt wie physikalische Server. Gleiches gilt natürlich auch für die Applikationen, die auf den physischen beziehungsweise virtuellen Servern laufen. Und da es fehlerfreie Software praktisch nicht gibt, müssen Nutzer davon ausgehen, dass Virtualisierungsprodukte zahlreiche Schwachstellen in sich bergen, die noch keiner kennt.
Foto: Computerwoche
Deshalb ist Virtualisierung aber nicht grundsätzlich unsicher. Vielmehr kommt es auf den Anwendungsfall an sowie auf die möglichen Alternativen. Um ein Virtualisierungsvorhaben in puncto Sicherheit bewerten zu können, muss ein Unternehmen deshalb in Betracht ziehen, welche bisherige Struktur es durch virtuelle Maschinen ablösen will. Jede IT-Infrastruktur weist Sicherheitsrisiken und -schwachstellen auf. Die Verantwortlichen müssen die Risiken der jeweiligen Infrastruktur abwägen.
Eine grundsätzliche Überlegung bei der Konzeption von IT-Strukturen unter Sicherheitsaspekten war schon immer, Systeme zu trennen, die nicht zueinander passen. Dies beginnt bei der Konzeption der Netzsegmente. Welche Applikationen oder Systeme sollen im gleichen Segment stehen, und welche sind durch Firewalls voneinander zu trennen? Ebenso betrifft es die Kombination von Anwendungen auf gemeinsamen Servern sowie die Kombination virtueller Maschinen auf gemeinsamen Host-Systemen.
Trennung von Applikationen auf einem Host
Wenn beispielsweise eine Applikation auf einem ersten Server direkt aus dem Internet erreichbar und somit angreifbar ist, wird man bestrebt sein, diesen Dienst möglichst nicht mit einer zweiten Anwendung zu koppeln, die interne und vertrauliche Daten verwaltet. Beide Applikationen stehen typischerweise nicht in einem gemeinsamen Netzwerksegment, und die Systeme sollten auch nicht auf einem gemeinsamen Host-System ablaufen. Noch geringer wäre die Sicherheit, wenn die Anwendungen sich einen normalen Server teilen und nicht einmal in einer jeweils eigenen virtuellen Maschine ablaufen würden.
Alle Applikationen auf einem Rechner werden durch das schwächste Glied in der Kette - in diesem Fall eine angreifbare Anwendung - in Gefahr gebracht. In diesem Fall könnte das Unternehmen für jede Anwendung eine jeweils eigene virtuelle Maschine schaffen und so die Sicherheit erhöhen. Es bleibt indes das erwähnte Risiko einer verwundbaren Virtualisierungslösung.
Unverfälschte Systemüberwachung ohne Rootkit-Einfluss
Moderne Virtualisierungssysteme bieten Sicherheitslösungen, wie sie bisher undenkbar waren. Das Host-System oder die Management-Komponente der Virtualisierungslösung besitzen nahezu uneingeschränkten Zugriff auf die virtuellen Maschinen. Daher hat man beste Voraussetzungen, von außen die Vorgänge und Zustände innerhalb der virtuellen Maschine zu überwachen. Trojaner, Viren oder Rootkits haben dann keine Chance, sich zu verstecken.
Wenn ein Angreifer die Kontrolle über ein gehacktes System übernommen hat, wird er versuchen, sich und seine Aktivitäten auf dem System mit einem Rootkit unsichtbar zu machen. Herkömmliche Erkennungsverfahren für Rootkits, die innerhalb der infizierten Maschine laufen müssen, haben das Problem, dass sie auf Daten zurückgreifen, die das Schadprogramm möglicherweise schon gefälscht hat.
In einer virtualisierten Umgebung hat man nun die Möglichkeit, beispielsweise den Hauptspeicher der virtuellen Maschine ohne Einflussmöglichkeit eines Rootkits von außen zu lesen. Auf diese Weise lässt sich eine neue Klasse von Sicherheitsprodukten entwickeln, die vom Host-System beziehungsweise von der Verwaltungskomponente aus die virtuellen Maschinen überwachen und auf diese einwirken können. Dazu zählen Virenscanner, die nicht mehr auf dem zu schützenden Server selbst laufen, sondern vom Host aus gleich mehrere virtuelle Maschinen überwachen. Eine weitere Möglichkeit sind Live-Forensik-Werkzeuge, die zur Laufzeit vollen Zugriff auf virtuelle Maschinen haben, ohne diese jedoch zu beeinflussen.
Schnittstelle für Sicherheitsprodukte
Der Virtualisierungsspezialist VMware hat bereits Schnittstellen angekündigt, die von den Herstellern von Sicherheitsprodukten genutzt werden können. Doch leider hat auch dieser vielversprechende Überwachungsansatz seine Schattenseiten: Jede neue Sicherheitskomponente erhöht die Komplexität des Gesamtsystems und kann auch selbst zum Angriffspunkt werden.
Insbesondere bei Virenscannern ist dies in den letzten zwei Jahren mehrfach bewiesen worden. Verwundbare Stellen in den Scannern selbst wurden veröffentlicht, mit denen ein Angreifer die Kontrolle über das System erlangen kann, auf dem der Virenscanner installiert ist.
Wenn man dieses Szenario auf einen ESX-Server von VMware überträgt, auf dem ein zentraler Virenscanner läuft, ergibt sich eine prekäre Situation: Ausgerechnet der Virenscanner, der vom Host aus Zugriff auf alle virtuellen Maschinen hat, wird allen diesen Maschinen zum Verhängnis.
Virtuelle Maschinen für gefährdete Web-Browser
Eine recht interessante Anwendung der Virtualisierung, die die Sicherheit erhöht, ist eine virtuelle Maschine auf Desktop-PCs für das Surfen im Web. Der Browser bildet ein hohes Sicherheitsrisiko. Somit liegt es nahe, die Web-Software so weit wie möglich von anderen Anwendungen und Daten auf dem jeweiligen Rechner zu trennen. Der Vorteil: Ein Angriff auf den Browser beispielsweise über manipulierte Web-Inhalte kompromittiert nicht gleich den gesamten PC.
Die Idee, den Browser aus dem normalen Desktop herauszulösen, ist nicht neu und wurde in der Vergangenheit gelegentlich über Sandbox-Systeme sowie mit Terminal-Servern realisiert. Bei letzterem Verfahren können die Anwender nicht direkt im Internet surfen, sondern müssen den Web-Browser auf einem dafür vorgesehenen Terminal-Server starten. Malware, die in den Browser einbricht, hat damit keinen direkten Zugriff auf die anderen Applikationen und Daten des Anwenders. Virtuelle Maschinen auf den jeweiligen Arbeitsplatzrechnern haben gegenüber einer zentralen Lösung den Charme, dass die Anwender sich auch gegenseitig nicht gefährden können.
Die lokalen virtuellen Maschinen lassen sich jederzeit in einen definierten Startzustand zurückversetzen. Sogar die zentrale Steuerung oder Bereitstellung solcher virtuellen Maschinen in Form eines Images lässt sich mit verfügbaren Lösungen elegant umsetzen. Auch die Skalierung ist bei dezentralen virtuellen Maschinen oft einfacher, da Firmen keine zentralen Hochleistungs-Server bereitstellen müssen. In der Regel verfügen die Desktop-PCs über genügend Leistung, um eine virtuelle Maschine zu betreiben. Hewlett-Packard und Mozilla haben mit "Virtual Firefox" genau einen solchen Ansatz angekündigt.
Falls ein Anwender in einer solchen Umgebung auf eine bösartige oder von Hackern manipulierte Website kommt, so besteht nicht mehr die Gefahr, dass der Angreifer die Kontrolle über den PC des Anwenders oder sogar Zugriff auf das komplette interne Netzwerk der betroffenen Organisation bekommt. Lediglich die virtuelle Maschine für die Internet-Nutzung kann kompromittiert werden, sie lässt sich aber weitgehend vom internen Netz isolieren. Zu klären ist allerdings, wie Anwender beispielsweise aus dem Web heruntergeladene Dateien außerhalb der virtuellen Maschine am lokalen Rechner nutzen können.
Firewalls in virtuellen Umgebungen
Wer virtualisierte Umgebungen konzipiert, muss auch überlegen, wo er Sicherheitssysteme wie Firewalls, Intrusion-Detection- oder Intrusion-Prevention-Komponenten platzieren will. Normalerweise werden einzelne Rechner über Netzwerkkabel, Router und Switches verbunden. Sicherheits-Appliances lassen sich dort einfach zwischenschalten. Wenn jedoch viele Computer nur noch als virtuelle Maschinen existieren und somit nur über virtuelle Netze innerhalb der Virtualisierungskomponente verbunden sind, wo schließt man dann eine Intrusion-Prevention-Appliance an?
Solche Fragen müssen Firmen berücksichtigen, wenn sie virtuelle Infrastrukturen konzipieren. In manchen Fällen mag die Lösung trivial sein, doch unter Umständen sind Anwender gezwungen, die Struktur anzupassen, um die vorhandenen Sicherheitskomponenten integrieren zu können.
Virtualisierte Sicherheitskomponenten
Eine besondere Variante ist dabei die Virtualisierung der Sicherheitskomponenten selbst. An Stelle von physikalisch eigenständigen Firewall-, VPN-, IDS- oder Content-Security-Appliances versucht man dabei auch die Sicherheitskomponenten als virtuelle Appliances in Form von virtuellen Maschinen auf einem gemeinsamen Host zu vereinen.
Manchmal scheidet diese Variante aber aus, da sie nicht genügend Leistung bietet. Wer zum Beispiel Gbit-Durchsätze benötigt und dafür spezialisierte Appliances einsetzt, der wird kaum eine vergleichbare Performance in einer virtuellen Umgebung erreichen. Aber auch wenn die Übertragungsbandbreite nicht das entscheidende Argument ist, muss man hier gut überlegen, welche Funktionen sinnvoll zusammenpassen, ohne dass die Sicherheit darunter leidet.
Fazit
Offensichtlich unsinnig wird es, wenn ein ursprünglich mehrstufiges Firewall-Konzept nur noch virtuell mehrstufig auf einem gemeinsamen Host implementiert wird. Mehrstufige Sicherheitskonzepte sind ja gerade dazu da, auch dann noch Schutz zu bieten, wenn eine Sicherheitskomponente versagt.
Die mehrstufigen Ansätze kann man als Gegenpol zu "Unified-Threat-Management"- (UTM)-Produkten sehen, die mehrere Funktionen in einem System zusammenfassen. Wenn aber ein mehrstufiges Firewall-Konzept aus mehreren getrennten Filtern und Proxies auf einem gemeinsamen Host virtualisiert wird, geht die Mehrstufigkeit verloren. Was bleibt, ist eine virtuelle UTM-Lösung, jedoch mit höhere Komplexität sowie größeren Kosten gegenüber einer klassischen UTM-Appliance. (ala)
Diesen Artikel haben wir von unserer Schwesterpublikation Computerwoche übernommen.