Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

01.10.2008

Sicher virtualisiert oder nur virtuell sicher?

Uli Ries ist freier Journalist in München.
Security-Experten warnen davor, Virtualisierung als Allheilmittel zur Lösung von Sicherheitsproblemen zu sehen. Hacker suchen bereits gezielt nach Lücken in Produkten wie VMware ESX.

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 physischen 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 kürzlich auf einer Sicherheitskonferenz in den USA, wie kompliziert es sein kann, wenn IT-Verantwortliche ihre vorhandenen 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-MachineAppliances. 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.

Zweifel an der Leistungsfähigkeit

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 Komponenten 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 Leistung 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.

Argumente gegen Hardwareredundanz

Anders sieht dies VMware-Mitarbeiter Niemer: Gerade "VMware HA" sorge dafür, dass - wenn ein physischer 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 physischen 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 physischen 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. So mahnt Simon Crosby von Xensource einen aus Performance- und Sicherheitsgründen möglichst schlanken statt ausgebauten Hypervisor an.

Was ist VMsafe?

VMsafe ist eine Programmierschnittstelle (API) für den Hypervisor ESX, mit der Hersteller von Sicherheitssoftware wie Symantec, Trend Micro oder McAfee ihre Produkte als Plug-ins für ESX liefern können. Damit soll sichergestellt sein, dass Malware gar nicht erst bis zu den virtuellen Maschinen (VMs) durchdringt. Da VMsafe auf Hypervisor-Ebene läuft, ist es vom Betriebssystem der VMs unabhängig. Zudem genügt zum Beispiel ein Virenscanner oder eine Firewall, um sämtliche auf dem physischen Server laufenden VMs abzusichern, was sich positiv auf deren Leistung auswirkt.

(kf)

Hacker nehmen VMware ESX ins Visier

VMware stellt für seine Server-Produkte eine eigene Programmierschnittstelle zur Verfügung. Mit Hilfe dieses API 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 via den Bare-Metal-Hypervisor ESX Server erlangen kann.

Hacker-Skripte nutzen VMware-API

Die in Ruby programmierten Skripte basieren auf dem von VMware angebotenen API. Für den Angriff nutzt Fitzpatrick 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 Administratorkonten, IP- und MAC-Adresse des Servers sowie der virtuellen Switches (vSwitch) und sogar über die Firewall-Regeln der einzelnen, auf dem Server installierten VMs.

Einschleusen der Dateien

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 Passwort-Knackers.

Die Konsequenz

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-MetalHypervisor der ursprüngliche Login über Port 902 offen.

Die Schutzoptionen

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