Wie Virtualisierung die Sicherheit erhöht

12.12.2008
Von 
Stefan Strobel ist Geschäftsführer der cirosec GmbH in Heilbronn.
Mit Hilfe von virtuellen Maschinen lassen sich Anwendungen voneinander trennen und sichere Surf-Umgebungen einrichten. Ein Risiko bleibt, weil auch die Virtualisierungsplattform angreifbar ist.

Virtualisierung gehört für viele Firmen schon seit einiger Zeit zur gängigen Praxis. Sie virtualisieren Server und richten virtuelle lokale Netze (VLANs) ein. In beiden Fällen wird eine physisch vorhandene Hardwarekomponente logisch vervielfältigt. Mehrere virtuelle LANs werden auf nur einem tatsächlich vorhandenen Switch abgebildet. Nur virtuell existierende Server laufen mit eigenem Betriebssystem als Gäste auf einer gemeinsam genutzten Hardware, dem Host-System.

Doch wie steht es um die Sicherheit? Immer wieder kursieren Meldungen über neu entdeckte Sicherheitslücken in Virtualisierungssystemen und deren Verwundbarkeit. Der schlimmste Fall ist eine Attacke, die über eine virtuelle Maschine andere angreift. Dazu müsste ein Angreifer zunächst in das Gastsystem einbrechen. In einem zweiten Schritt ist es dann denkbar, dass er über eine Schwachstelle in der Virtualisierungssoftware aus dieser virtuellen Maschine in die Verwaltungskomponente der virtuellen Maschinen vordringen kann. Von dort aus kann er dann auch alle anderen Gäste desselben Host-Systems kompromittieren.

Keine unmittelbare Gefahr

Schwachstellen in der Virtualisierungssoftware stellen damit 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 vor.

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 könnte der Hacker feststellen, dass er in einer virtuellen Maschine gelandet ist. Er könnte daraufhin versuchen, Sicherheitslücken der Virtualisierungssoftware auszunutzen und sich des Host-Systems zu bemächtigen.

Virtuelle Maschinen sind nicht so stark voneinander getrennt wie physische Server. Gleiches gilt natürlich für Applikationen, die auf physischen beziehungsweise virtuellen Server-Umgebungen 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.

Vergleichbare Konzeption

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 der Applikationen

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 Programme 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.

Moderne Virtualisierungssysteme bieten Sicherheit, wo sie bisher undenkbar waren. Da das Host-System oder allgemeiner bezeichnet die Management-Komponente der Virtualisierungslösung nahezu uneingeschränkten Zugriff auf die virtuellen Maschinen besitzt, hat man hier beste Voraussetzungen, um von außen die Vorgänge und Zustände innerhalb der virtuellen Maschine zu überwachen, ohne dass ein Trojaner, Virus oder ein Rootkit sich davor verstecken kann.

Keine Chance für Rootkits

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 haben das Problem, dass sie Daten nutzen, die das Schadprogramm möglicherweise schon gefälscht hat.

In einer virtualisierten Umgebung hat man nun die Möglichkeit, diese Daten, beispielsweise den tatsächlich vorhandenen Hauptspeicher der virtuellen Maschine, ohne Einflussmöglichkeit eventueller Rootkits im virtuellen System 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 virtuelle 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.

Der Virtualisierungsspezialist VMware hat bereits Schnittstellen angekündigt, die von den Herstellern von Sicherheitsprodukten genutzt werden können. Doch leider hat auch dieser viel versprechende Ü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 sich dieses Szenario auf einem internen ESX-Server von VMware vorstellt, dann bedeutet dies, dass ausgerechnet der Virenscanner, der vom Host aus Zugriff auf alle virtuellen Maschinen hat, allen diesen Maschinen zum Verhängnis werden kann.

Eine recht interessante Anwendung der Virtualisierung, die die Sicherheit erhöht, ist eine virtuelle Maschine für das Surfen im Web vom Arbeitsplatz aus. 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 gelegentlichu uü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 auf den eigentlichen Arbeitsplätzen der Anwender.

Die Vorteile dezentraler VMs

Doch virtuelle Maschinen auf den jeweiligen Arbeitsplatzrechnern haben gegenüber einer zentral bereitgestellten Terminal-Server-Lösung den Charme, dass die Anwender sich auch gegenseitig nicht gefährden können. Zudem lassen sich die lokalen virtuellen Maschinen jederzeit in einen definierten Startzustand zurückversetzen. Sogar die zentrale Steuerung oder Bereitstellung solcher virtuellen Maschinen in Form eines Images lässt sich mit heute verfügbaren kommerziellen 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.

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, und die Sicherheitsprodukte lassen sich dort 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.

Virtuelle Sicherheit

Eine besondere Variante dieses Ansatzes ist 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 bisher Gigabit-Durchsätze benötigt und dafür spezialisierte Appliances einsetzt, der wird derzeit 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.

Ausnahme Mehrstufigkeit

Offensichtlich unsinnig wird es jedoch, wenn ein ursprünglich mehrstufiges Firewall-Konzept nur noch virtuell mehrstufig auf einem gemeinsamen Host implementiert wird, denn mehrstufige Sicherheitskonzepte sind ja gerade dazu da, auch dann noch Schutz zu bieten, wenn eine Sicherheitskomponente versagt. Solche mehrstufigen Ansätze können durchaus als Gegenpol zu Produkten für "Unified-Threat-Management" (UTM) gesehen werden, die mehrere Funktionen in einem System zusammenfassen.

Wenn beispielsweise ein mehrstufiges Firewall-Konzept aus mehreren getrennten Filtern und Proxies auf einem gemeinsamen Host virtualisiert wird, geht die Mehrstufigkeit und damit die Sicherheit verloren. Was bleibt, sind eine höhere Komplexität sowie größere Kosten im Vergleich zu einer UTM-Lösung. Die Argumente bei der Konzeption von virtualisierten Sicherheitsfunktionen sind übrigens nahezu die gleichen wie bei der Definition von Firewall-Zonen und der Verteilung von Filter- und Proxy-Komponenten. (fn)

Virtualisierungs-Rootkits

Seit die polnische Sicherheitsforscherin Joanna Rutkowska auf einer Konferenz ihr Virtualisierungs-Rootkit "Blue Pill" vorgestellt hat, gab es viele Diskussionen über die technische Machbarkeit, die Gefahren und Grenzen dieser Idee. Mit der Sicherheit von Virtualisierung in Unternehmen hat diese Diskussion recht wenig zu tun. Bei Virtualisierungs-Rootkits geht es nicht um Angriffe oder Hacker-Techniken, die sich gegen Virtualisierungssysteme wie VMware, Xen oder Virtual PC richten, sondern um eine neue Art von Hacker-Werkzeugen, die selbst Hypervisor-Techniken verwenden, wie sie auch in kommerziellen Produkten vorkommen. Damit stellen sie keine neue spezielle Gefahr für virtuelle Maschinen dar, sondern eine generelle Bedrohung, die in Zukunft jedes Unternehmen betreffen kann, egal ob man selbst virtuelle Maschinen betreibt oder nicht.

Die Idee eines Rootkits besteht darin, dass ein Angreifer nach einem erfolgreichen Einbruch in ein System sich selbst und seine Werkzeuge auf dem System unsichtbar macht. Bei einem Virtualisierungs-Rootkit bringt der Angreifer dazu selbst einen minimalen Hypervisor mit und manipuliert sein Opfersystem zur Laufzeit so, dass es selbst in einer virtuellen Umgebung läuft, während der Angreifer sich außerhalb der virtuellen Maschine befindet und damit mit klassischen Ansätzen nur noch sehr schwer zu erkennen ist.

Das Problem

- Unabhängig von der Virtualisierung dringt ein Hacker in die Anwendung oder das Betriebssystem einer virtuellen Maschine (VM) ein.

- Im zweiten Schritt nutzt er eine Schwachstelle der Virtualisierungssoftware und dringt darüber in die VM-Verwaltungskomponenten ein.

- Nun ist der Weg frei, auch die anderen Gäste desselben Host-Systems zu kompromittieren.

Was zu beachten ist

- Bei der Konzeption klassischer Infrastrukturen gilt es aus Sicherheitsgründen zu analysieren, welche Kombination von Anwendungen auf einem gemeinsamen Server laufen soll. Analog dazu muss man bei der Virtualisierung festlegen, welche virtuellen Maschinen auf einem gemeinsamen Host-System kombiniert werden sollen.

- Es sollte geklärt werden, welche Anwendung das schwächste Glied in der Kette ist, um diese gegebenenfalls in einer eigenen virtuellen Maschine zu schützen.

- Virtualisierung bietet in Kombination etwa mit Virenscannern die Möglichkeit, von der Verwaltungskomponente aus Gastsysteme zu überwachen, ohne dass sich ein Trojaner, Virus oder ein Rootkit davor verstecken kann. Aber Vorsicht: Ausgerechnet Virenscanner sind inzwischen vermehrt dem Hacker-Angriff ausgesetzt.

- Ein interessanter Sicherheitsaspekt ist, Web-Software wie Browser über virtuelle Maschinen von anderen Anwendungen zu isolieren.

- Es ist unsinnig, ursprünglich mehrstufige Firewall-Konzepte auch in einer virtuellen Umgebung mehrstufig auf einem gemeinsamen Host zu implementieren.