In Wirklichkeit zählt Sicherheit
Von Uli Ries
Virtualisierung gilt als Wunderwaffe, die strapazierte Budgets entlasten und ausufernd komplexe IT-Infrastrukturen verschlanken soll. Die Lobgesänge sind lang, aber die Diskussion um mögliche neue Gefahrenpotenziale kommt oft zu kurz. Denn virtualisierte Infrastrukturen bringen ihre ganz eigenen Sicherheitsprobleme mit sich und erfordern besondere Disaster-Recovery-Strategien – ganz abgesehen davon, dass auch die Kalkulation der Software-Lizenzen ungleich schwieriger wird.
Die Idee klingt schon verlockend: Einfach alle vorhandenen Server ausmustern und deren Betriebssysteme samt aller Dienste auf wenige oder gar nur einen neuen Server zu übertragen. Dieses Vorgehen ist jedoch ein Risiko an sich. Denn damit geht die mühsam aufgebaute Redundanz sofort verloren: Fällt die Hardware des Servers aus, sind davon gleich zig Serverdienste betroffen. Was für Controller und Einkäufer so attraktiv ist, schreckt Sicherheitsexperten daher ab.
So warf der britische Security-Profi Michael Kemp in einem Vortrag auf einer IT-Fachkonferenz die Frage auf, wie es um die Sicherheit eines virtualisierten Serverparks bestellt sei, wenn dieser auf einer einzigen Maschine läuft und sich alle virtuellen Maschinen den gleichen Arbeitsspeicher teilen. Das Problem: Im Falle der HP-Superdome-Server kann offenbar jede der so genannten Zellen – eine Kombination aus CPU, lokalem Speicher und geteiltem Speicher – auf den geteilten Speicher der anderen Zellen zugreifen. Erlangt ein Angreifer die Kontrolle über eine einzige der bis zu 128 CPUs eines Superdome 9000, könnte er dann nicht den Arbeitsspeicher der anderen Zellen – und somit anderer virtueller Maschinen – kontrollieren? HP wollte sich nicht äußern, ob dem tatsächlich so sei.
Nand Mulchandani, Senior Director Security bei VMWare, hielt im Gespräch das Hypervisor-Kaperproblem für praktisch bedeutungslos: „In Rechenzentren wird eine solche Architektur aus Performancegründen nur höchst selten zu finden sein. In aller Regel werden hier VMMs des Typs 1 eingesetzt, wie unser ESX. Diese Art des Hypervisors läuft direkt auf der Hardware des Servers, ohne zwischengeschaltetes und potenziell unsicheres Betriebssystem.“ In diesem Fall müsste es der Malware also gelingen, dem legitimen HV beim Startvorgang zuvorzukommen und sich an seiner Stelle zu platzieren. Laut Mulchandani ist das in der Praxis noch nie vorgekommen.
Putschversuch in der Zentrale
Ein weiteres, immer wieder gezeichnetes Schreckensszenario geht davon aus, dass die Hypervisor (HV) oder auch Virtual Machine Monitor (VMM) genannte, zentrale Komponente aller Virtualisierungstechniken kompromittiert wird. Dann hätte ein Angreifer vollen Zugriff auf alle virtuellen Maschinen, die sich der Dienste des Hypervisors bedienen.
Darauf basiert auch die von großem medialem Getöse begleitete Proof-of-Concept-Malware Blue Pill der polnischen Programmiererin Joanna Rutkowska. Blue Pill ist ein Rootkit, das ein komplettes Betriebssystem binnen Bruchteilen von Sekunden in eine virtuelle Umgebung verfrachtet und dem Angreifer so uneingeschränkten Zugriff auf das System gewährt.
Schwarz auf Weiß
Dieser Beitrag erschien zuerst in unserer Magazinreihe. Einen Überblick mit freien Download-Links zu sämtlichen Einzelheften bekommen Sie online im Pressezentrum des MittelstandsWiki.
Damit eine solche Attacke auf den HV gelingt, muss der Angreifer eines der Gastsysteme unter Kontrolle bringen und dann den Hypervisor attackieren. Virtualisierungs-Anbieter wie zum Beispiel VMware haben ihre Produkte in der Vergangenheit deshalb optimiert, um den unerlaubten Zugriff auf den HV zu verhindern. In diesen Fällen handelte es sich stets um VMM des Typs 2, die auf einem vollwertigen Betriebssystem (Host OS) wie Windows oder Linux laufen. Bei einem solchen Setup bedrohen Sicherheitslücken im Host OS auch den VMM und sämtliche Gastbetriebssysteme – der Angreifer hat theoretisch also zahlreiche Möglichkeiten, das System unter Kontrolle zu kriegen.
Hardware sichert Software
Unwahrscheinlich dürfte diese Angriffsmethode werden, wenn das Server-BIOS die Integrität des Hypervisors mittels eines Hashwertes sicherstellt, wie ihn beispielsweise ein Trusted Platform Module (TPM) errechnen und speichern kann.
Der XenServer von XenSource greift z.B. auf ein eventuell vorhandenes TPM zurück. VMwares ESX tut dies im Moment noch nicht; Nand Mulchandani ließ im Gespräch jedoch durchblicken, dass auch VMware an einer solchen Funktion arbeitet. Diese Ankündigung lässt darauf schließen, dass VMware potenzielle Lücken im weniger als 32 MByte großen ESX nicht ausschließen kann. Trotz spezieller Optimierung und Härtung von ESX diskutieren Hacker schon seit langem darüber, welche Folgen etwa ein erfolgreicher Angriff auf den Netzwerkkartentreiber von ESX für die Sicherheit des Gesamtsystems haben könnte.
Auch IBM nimmt sich der Sicherheit des Hypervisors an. Unter dem Codenamen Phantom laufen bei Big Blue verschiedene Anstrengungen zusammen, um den eigenen und eventuell auch fremde Hypervisors sicherer zu machen. Besonderes Augenmerk legt IBM dabei auf Intrusion-Prevention-Mechanismen, die unerwünschte und potenziell schadhafte Datenströme zwischen den Virtuellen Maschinen (VM) unterbinden sollen. Außerdem soll Phantom anhand des Verhaltens einer VM erkennen, ob sie kompromittiert wurde. Wann Phantom zu fertigen Produkten führen wird, ist noch unklar.
Natürlich will auch VMWare die Sicherheit weiter erhöhen: Die Firma bietet unter den Namen VMSafe Programmierschnittstellen für ESX an. Mit Hilfe dieser APIs können Hersteller von Sicherheitssoftware ESX-Plugins schreiben, die von zentraler Stelle aus alle Gastbetriebssysteme mit Firewalls oder Antivirenschutz absichern. Dadurch könnten diese Funktionen aus den Betriebssysteminstallationen entfernt werden, so dass die Performance steigt und der Wartungsaufwand sinkt.
Die Frage, ob derartige Schnittstellen nicht die Komplexität von ESX und somit abermals die Verwundbarkeit erhöhen, beantwortete VMware-Manager Mulchandani ausführlich wie im Kasten beschrieben. Sein Kollege Simon Crosby von der Firma XenSource äußerte in einem Vortrag auf der RSA Conference 2008 jedenfalls die Ansicht, dass der Hypervisor aus Performance- und Sicherheitsgründen so schlank als möglich sein sollte. Es müsse das Ziel der Entwickler sein, jeden Tag Codezeilen zu entfernen, anstatt neue hinzuzufügen.
Fazit: Neues Spiel, bewährte Regeln
Auch wenn Virtualisierung ein brandaktuelles Thema ist, so gelten zentrale Sicherheitsstrategien, die längst bekannt sind, auch für virtuelle Umgebungen. Denn wenn diese nicht abgesichert sind, bringen sie am Ende die komplette Infrastruktur ins Wanken. So sind Administratoren der VMMs nicht zwangsläufig auch Administratoren der virtualisierten Server. Diese beiden Teile der Infrastruktur sind aus Sicht der Sicherheitsarchitektur komplett getrennt und sollten auch so behandelt werden.
Ebenso wichtig ist die Kontrolle darüber, welcher virtuelle Server gerade auf welcher physikalischen Hardware läuft. Dank Virtualisierung ist es ja denkbar leicht, einen funktionierenden Windows– oder Linux-Server von einer Serverhardware auf eine andere zu kopieren. Dazu muss lediglich das Server-Image kopiert und neu gestartet werden.
Geht der Server nun auf einer anderen Hardware online, muss sichergestellt sein, dass er auch im richtigen Netzwerksegment läuft. Es wäre beispielsweise fatal, wenn ein nur für Intranet-Dienste konzipierter Server plötzlich auf einer Maschine online geht, die physikalisch in die unsichere DMZ (Demilitarisierte Zone) gehört. Es empfiehlt sich ohnehin, eigene Netzwerkkarten für verschiedene Netzwerksegmente in den Server einzubauen und sich nicht auf die VLAN-Funktion des virtuellen Switches der Virtualisierungssoftware zu verlassen.
In Sachen Patch-Management erleichtert die Virtualisierung das Leben der Administratoren allerdings erheblich. Sie müssen lediglich ein Betriebssystem-Image patchen und dieses dann auf allen Servern neu starten – langwierige Updates auf vielen verschiedenen Maschinen gehören der Vergangenheit an. Falls also der Server angegriffen und mit Malware verseucht wird, ist es in einer virtualisierten Serverlandschaft ein Leichtes, die Maschine wieder auf den Stand vor dem Angriff zu bringen.
Uli Ries ist freier Journalist und Autor mit abgeschlossene journalistischer Ausbildung und langjähriger Erfahrung (u.a. bei CHIP, PC Professionell und www.notebookjournal.de). Seine Spezialgebiete sind Mobilität, IT-Sicherheit und Kommunikation – zu diesen Themen tritt er immer wieder auch als Moderator und Fachreferent auf.
Kontakt via Xing
