Glaubt man den Versprechungen der Hersteller, lassen sich bewährte Sicherheitsprodukte wie Firewalls, Virenscanner und Intrusion-Prevention-Systeme (IPS) durch virtualisierte Versionen ersetzen. Diese "virtuellen Appliances" übernehmen die gleichen Funktionen wie ihre physikalischen Pendants, bestehen aber lediglich aus einem Stück Software, das auf einer virtuellen Linux- oder Windows-Maschine läuft. Der IT-Sicherheitsexperte Christopher Hoff, Chief Security Architect von Unisys, erläuterte vor einigen Wochen in einem Vortrag auf der US-Sicherheitskonferenz Black Hat, wie kompliziert es sein kann, wenn IT-Verantwortliche ihre vorhandenen IT-Sicherheitsprodukte durch solche virtualisierten Appliances ersetzen wollen.

Dabei erklärte er die angebotenen Module, mit denen virtuelle Umgebungen gesichert werden sollen, kurzerhand für untauglich. Sie seien zu langsam, nicht skalierbar und verursachten obendrein Kosten, anstatt Geld einzusparen. Laut Hoff ist keines der Produkte, die zur Absicherung von mittels VMware ESX virtualisierten Servern angeboten werden, auch nur annähernd so praxistauglich wie die vorhandenen Hardwareprodukte. Dazu Martin Niemer, Senior Product Manager bei VMware: "In manchen Szenarien sind dedizierte Hardwareprodukte den virtuellen Appliances nach wie vor weit überlegen, und es wäre Wahnsinn, sie ersetzen zu wollen." Aus seiner Sicht besteht dieses Problem allerdings nur in großen bis sehr großen Rechenzentren, in denen hoch spezialisierte Security-Hardware eingesetzt wird. "Herkömmliche Appliances auf Basis standardisierter x86-Systeme lassen sich dagegen sehr wohl virtualisieren", meint Niemer.

Hoff teilt die Sicherheitsthematik im Zusammenhang mit der Server-Virtualisierung in drei Kategorien ein: "Absicherung von virtualisierten Servern", "virtualisierte Sicherheitskomponenten" und "Absicherung durch Virtualisierung". Ihm zufolge gibt es an allen drei Fronten noch erheblichen Verbesserungsbedarf, Diskussionen über Malware wie Blue Pill, die den Hypervisor attackieren, seien daher verfrüht: "Erst einmal sollten die Anbieter von Sicherheitsprodukten die aktuellen Probleme lösen, dann mache ich mir Gedanken über Blue Pill und ähnliche Angriffe."

Hoffs Hauptkritikpunkt ist die mangelnde Flexibilität von Virtual-Machine-Appliances. Wer versuche, seine bestehende Sicherheitsinfrastruktur aus Firewalls und IPS/IDS (Intrusion Detection/Prevention System) samt ausgeklügeltem Regelwerk in eine virtualisierte Umgebung zu übertragen, dem drohe ein böses Erwachen. Nach Erfahrung des Security-Experten gibt es keine Appliance, die in Sachen Leistungsfähigkeit mit hardwarebasierenden Sicherheitsprodukten mithalten kann. Um die gewohnte Funktionalität beizubehalten, müssen die vorhandenen Sicherheitskomponenten also weiterbetrieben werden. Hierdurch steigen Kosten und Komplexität.

Und auch die Performance ist offenbar ein großes Problem: Laut Hoff ist mit den derzeitigen VM-Appliances weder Hochverfügbarkeit noch hohe Performance zu erzielen. Der Grund: Keines der ihm bekannten Produkte lässt sich parallel mit anderen VM-Appliances betreiben. Ihm zufolge kann jeweils nur eine Appliance pro Host laufen - Skalierbarkeit Fehlanzeige. Fällt die Appliance aus, kann kein Ersatz einspringen, so dass sämtliche VMs entweder vom Netz getrennt werden oder - noch schlimmer - schutzlos weiterlaufen.

Anders sieht dies VMware-Mitarbeiter Niemer: Gerade "VMware HA" sorge dafür, dass - wenn ein physikalischer Host ausfalle - die VMs auf einem anderen Host sofort gestartet werden könnten. Das gelte auch für Security-Appliances, die als VM laufen, und lasse sich in der physikalischen Welt nur um den Preis der Hardwareredundanz einer Appliance erzielen. "Wir sehen bei Kunden beispielsweise Mail-Virenscanner, die in der DMZ deswegen auf ESX laufen, weil die Administratoren dank VMotion unter anderem die Hardware ohne Ausfallzeiten warten können", fügt der Produkt-Manager hinzu.

In jeder Hinsicht überfordert

Hoff hingegen hat die Erfahrung gemacht, dass eine einzelne Appliance niemals den Datenströmen (Messungen von VMware zeigen Datenraten von bis zu 2,5 Gbit/s pro virtuelle Maschine) gewachsen ist, die die ihr zugeteilten VMs erzeugen. Sie wird also zum Flaschenhals und lähmt das Gesamtsystem gleich doppelt: Einerseits kann die Appliance die Datenmengen nicht bewältigen, andererseits läuft sie auf der gleichen physikalischen Hardware wie die VMs, denen sie auf diese Weise notwendige Ressourcen abknapst.

Laut Hoff ist der Ansatz, alle virtuellen Maschinen von einer einzelnen Appliance sichern zu lassen, mit dem aus seiner Sicht praxisfernen UTM-Konzept (Unified Threat Management) zu vergleichen. "Wie soll eine einzige Appliance gleichzeitig die Funktionen von Virenscanner, Firewall, IPS/IDS und anderen Systemen übernehmen? Das klappt schon mit dedizierter Hardware nicht, denn sobald der Virenscanner läuft, steht meist das ganze System. Dieses Konzept in die komplexe Welt der virtuellen Server übertragen zu wollen, ist in meinen Augen weltfremd", so der Unisys-Mann.

Hoffnungen setzt Hoff indes auf das VMSafe-Konzept von VMware, in dem er die einzige Chance sieht, bereits bewährte Security-Produkte in die Welt der virtualisierten Server zu überführen. Allerdings gibt er zu bedenken, dass die Hersteller ihre Produkte eigens an die Anforderungen der VMSafe-API anpassen müssten, was mit Komplikationen bei der Markteinführung der Plug-ins verbunden sei.

Doch gibt es auch Argumente, die gegen VMsafe sprechen: Die gesteigerte Komplexität von ESX und somit dessen potenziell höhere Verwundbarkeit. Simon Crosby von der Firma Xensource äußerte in einer Podiumsdiskussion auf der RSA Conference 2008 jedenfalls die Meinung, ein Hypervisor sollte aus Performance- und Sicherheitsgründen so schlank wie möglich sein. Ziel der Hypervisor-Entwickler müsse demnach sein, "täglich" Zeilen aus dem Quellcode zu entfernen, statt neue hinzuzufügen.

Hacker nehmen ESX ins Visier

VMware stellt für seine Server-Produkte eine eigene Programmierschnittstelle zur Verfügung. Mit Hilfe dieses API (Application Programming Interface) hat der britische IT-Sicherheitsexperte John Fitzpatrick ein Tool und Skripte entwickelt, mit denen ein Angreifer die Kontrolle sowohl über den VMware-Server als auch den Bare-Metal-Hypervisor ESX Server erlangen kann. Die Hacker-Gemeinde nimmt sich der Sicherheitsthematik also aus einem ganz anderen Blickwinkel an. Die von dem Experten in Ruby programmierten Skripte basieren ebenso auf dem von VMware angebotenen API wie das von einem seiner Kollegen geschriebene Tool "dradis". Letzteres fasst die von Fitzpatrick geschriebenen Skripte zusammen und macht sie über eine grafische Benutzeroberfläche zugänglich.

Für den Angriff nutzt Fitzpatrick, der seine Skripte vor einigen Wochen live auf der Hacker-Konferenz Defcon demonstrierte, zunächst die von dem API gebotene Funktion, sich remote über das Intranet (Port: 902, authd) am VMware-Server anzumelden. Sein Skript kann alle möglichen Passwörter per Brute-Force-Attacke durchprobieren, bis das richtige gefunden ist. Dem Sicherheitsforscher zufolge sperrt der VMware-Server diesen Angriff nicht automatisch nach einer bestimmten Anzahl von Fehlversuchen. Anschließend wird über eine weitere API-Funktion die Konfigurationsdatei des Servers ausgelesen. Diese gibt Aufschluss beispielsweise über weitere Administrator-Konten, IP- und MAC-Adresse des Servers sowie der virtuellen Switches (vSwitch) und sogar über die Firewall-Regeln der einzelnen, auf dem Server installierten VMs.

In einem nächsten Schritt kopiert Fitzpatrick beliebige Dateien auf die VM und führt diese dort aus - wiederum mit Hilfe einer API-Funktion. In seiner Präsentation wählte er Metasploit, ein Paket aus verschiedensten Angriffstechniken für diverse Produkte. Nach dem Start des Toolkits sucht sich der Angreifer mit dessen Hilfe eine Kopie der Windows-Passwort-Hashes und knackt diese dann mittels eines bekannten Passwortknackers. So macht der Sicherheitsexperte deutlich, warum die Disk Files einer VM - also quasi deren virtuelle Festplatten - dringend vor unerlaubten Zugriffen geschützt werden müssen: Mountet ein Angreifer ein solches Disk File mit einer VMware-eigenen Software, kann er auch sämtliche Passwort-Hashes der VM kopieren und sich später (nach dem Passwort-Knacken) ganz regulär an der VM anmelden. Ähnliche Angriffsmöglichkeiten ergeben sich im Zusammenspiel mit ESX Server. Obwohl ESX mit einem eigenen Web-Interface zur Konfiguration ausgestattet ist, steht auch beim Bare-Metal-Hypervisor der ursprüngliche Login über Port 902 offen.

Die wichtigste Maßnahme gegen einen solchen Angriff ist laut Fitzpatrick die Separation des VMware-Management-Netzes vom übrigen Netz. Das kann entweder mittels Firewall erfolgen, oder über durch eigene Switches physikalisch voneinander getrennte Netze. Zudem sind die Benutzer-Accounts der VMs durch komplexe Passworte abzusichern, damit eine Wörterbuch-basierende Brute-Force-Attacke ins Leere läuft. Schließlich empfiehlt der Security-Spezialist allen VMware-Nutzern die Lektüre der VMware-eigenen Sicherheitsratschläge, die aus seiner Sicht sämtliche relevanten Themen abdecken, um Angreifer auszusperren.

Mehr Softwaresicherheit durch verstärkten Hardwareeinsatz

Ein weiteres, schon seit geraumer Zeit diskutiertes Angriffsszenario ist der Austausch eines Hypervisors durch Malware. Die viel zitierte - und selbst vom Virtualisierungs-Skeptiker Hoff als unrealistisch erachtete - Attacke durch Malware wie BluePill basiert auf der Idee, dass der bösartige Hypervisor vor dem gutartigen Hypervisor geladen wird und Letzteren somit ins Aus manövriert. Oder: Blue Pill ist der einzige Hypervisor und kontrolliert somit alles, was im plötzlich virtualisierten Betriebssystem läuft. Unabhängig davon, dass bislang kein funktionierender Weg bekannt ist, wie Blue Pill das Rennen mit dem legitimen Hypervisor gewinnen könnte, haben manche Hersteller bereits eine Abwehrstrategie parat. Ganz unmöglich dürfte diese Angriffsmethode werden, wenn das Server-Bios die Integrität des Hypervisors mittels eines Hash-Wertes sicherstellt, wie ihn beispielsweise ein Trusted Platform Module (TPM) errechnen und speichern kann. Der Xenserver von Xensource greift bereits auf ein eventuell vorhandenes TPM zurück. VMwares ESX ist dazu noch nicht in der Lage, soll aber in Kürze ebenfalls so weit sein. Das diesbezügliche Bemühen auf Seiten VMwares lässt darauf schließen, dass die Firma Lücken in ESX nicht ausschließen kann. Trotz Härtung von ESX diskutieren Hacker schon seit langem darüber, wie sich ein erfolgreicher Angriff beispielsweise auf den Netzkartentreiber von ESX auf die Sicherheit des Gesamtsystems auswirken könnte.

Auch andere Firmen wie IBM arbeiten an der Absicherung von Hypervisoren. Unter dem Codenamen "Phantom" laufen bei Big Blue verschiedene Projekte, die neben hauseigenen eventuell auch Hypervisoren anderer Hersteller sicherer machen sollen. Besonderes Augenmerk legt IBM dabei auf Intrusion-Prevention-Mechanismen, die unerwünschte und potenziell schadhafte Datenströme zwischen den VMs unterbinden sollen. Darüber hinaus soll Phantom anhand des Verhaltens einer VM erkennen, ob diese kompromittiert wurde. Wann Phantom zu fertigen Produkten führen wird, steht noch nicht fest. (kf)