Virtualisierung und ihre Grenzen – Teil 2
Animiert durch diverse Diskussionen zum Thema Virtualisierung in unserem securITy-dome.eu Forum ( http://www.security-dome.eu/forum/pA/ ), habe ich mich entschlossen einen weiterführenden Artikel zu dem bereits erschienen Teil 1 zu schreiben. Den ersten Teil finden Sie unter --> „Interne Links“.
Themen dieses Berichts (was Sie erwartet):
Allgemein
Vorteile
Risiken
Erklärungen zu den Risiken --> Software-Risiken / Netzwerk-Risiken
Irrglaube oder Falschinformation --> Honey-Pots / Sicheres Surfen mit virtuellen Systemen / Analyse von Malware und Rootkits
Virtuelle Produktivsysteme
Virtuelle Schutzlösungen
Zusammenfassung
Interne Links
Externe Links
Allgemein:
Die Virtualisierungstechnik ist mit Sicherheit ein Meilenstein in der Anwendungsentwicklung und hat im Laufe der letzten Jahre die IT mehr oder weniger beeinflusst! Dies geht sogar soweit, dass Staaten Belohnungen auszahlen, wenn Firmen Systeme virtualisieren und auf einer gemeinsamen Hardwareplattform zusammen führen.
Auch die Prozessorhersteller haben die Wichtigkeit der Virtualisierung erkannt und bauen eigene Techniken in ihre Prozessoren ein, um Virtualisierung ressourcenschonender umzusetzen.
Doch wie alle neuen Techniken gibt es auch in diesem Fall Risiken und physikalische Grenzen, welche man kennen, bedenken und einplanen muss!
Vorteile:
Die Virtualisierungstechnik bietet eine Vielzahl von Vorteilen. Hauptsächlich zu nennen sind:
Bessere Ausnutzung vorhandener Hardware – und damit Verringerung von Kosten
Senkung des Strom-, Platz- und Kühlbedarf durch Verringerung der Notwendigen Hardware – und damit Verringerung von Kosten
Einfachere Administration durch Snap-Shot-Techniken
Einfachere Administration durch spezielle Verwaltungs- und Überwachungslösungen
Einfachere Installation durch Verwendung der „Clone-Technik“
Kürzere Ausfallzeiten bei Hardwaredefekten durch einfaches Verschieben der virtuellen Maschine auf eine funktionierende Hardware
Einfacher Aufbau von Testumgebungen
Aufgrund dieser praktischen Vorteile findet die Virtualisierung auch immer häufiger ihren Weg zu privaten Anwendern! Dies insbesondere durch die Tatsache, dass alle Hersteller mittlerweile kostenlose Lösungen anbieten und viele weitere Anbieter unter Open Source arbeiten (siehe z.B. den Bericht zur Virtual Box Teil 1 und Teil 2 unter --> „Interne Links“).
Risiken:
Einen Teil der Risiken sind schon in dem Artikel „Virtualisierung und Risiken“ genannt worden. Diesen Artikel finden Sie unter --> „Interne Links“.
Ich möchte diese Risiken aber noch mal kurz der Vollständigkeit halber nennen:
Lokale Identifizierung des Vorhandenseins von virtuellen Umgebungen
Remote Identifizierung des Vorhandenseins von virtuellen Umgebungen über das Netzwerk
Mögliche Kommunikation zwischen virtuellen Systemen
Mögliche Kommunikation zwischen dem Host- und dem virtuellen System
Auch wenn eine bekannte Sicherheitslücke durch die Funktion „Shared Folder“ mittlerweile durch ein Update behoben worden ist, gehe ich für die Zukunft von weiteren Schwachstellenfunden aus!
Weitere dokumentierte Risiken sind:
mögliches Fehlverhalten von Desktop-Firewallsystemen auf dem Hostsystem, wenn eine Virtualisierungssoftware installiert ist
Erklärungen zu den Risiken:
Bei der Risikoanalyse entspricht das Gesamtrisiko immer der Summe der einzelnen Risiken!
Dabei ist die Frage nach dem „Wer“ und dem „Warum“ völlig unerheblich. Tatsache ist aber, dass sich das Risiko schon alleine deshalb erhöht, weil sich virtuelle Systeme auch über entfernte Orte identifizieren lassen. Aus diesem Grund ergeben sich folgende Risiken:
mögliche Schwachstellen im Host-Betriebssystem
mögliche Schwachstellen in den Host-Anwendungen und -Diensten
mögliche Schwachstellen in Treiberpaketen der Virtualisierungssoftware
mögliche Schwachstellen im Gast-Betriebssystem
mögliche Schwachstellen in den Gast-Anwendungen und –Diensten
mögliche Fehlverhalten in Schutzlösungen auf dem Host-System (Firewall)
Ich möchte hierbei sehr deutlich sagen, dass die genannten Risiken kein Fehler, Probleme oder konzeptionelle Schwachstellen der Virtualisierungstechnik sind!
Vielmehr sind das physikalische Grenzen oder Gegebenheiten. Durch die extreme Bündelung von mehreren Systemen auf einer Hardware addieren sich aber alle einzelnen Schwachstellen zu einem Gesamtrisiko!
Software-Risiken:
Wie jede Software-Lösung ist auch die Virtualisierungstechnik den Schwächen des Host-Systems ausgesetzt. D.h. ebenso wie Desktop-Firewalls, Virenscanner und andere Schutzlösungen ist die Schutzleistung nur so gut wie die Basis (Hardware, Betriebssystem, Treiber usw.).
Netzwerk-Risiken:
Desktop-Firewalls nutzen eigene Treiberpakete zur Analyse des Netzwerkverkehrs. Auch Virtualisierungslösungen installieren eigene Netzwerktreiber. Aus diesem Grund kann die Schutzfunktion von Desktop-Firewallsystemen beeinträchtigt werden. Hierzu existieren Dokumentationen, dass Pakete von der Desktop-Firewall nicht mehr erkannt werden. Dies betrifft übrigens jede Situation in welcher zusätzliche Netzwerktreiber installiert werden (wie z.B. durch Sniffer usw.).
Ähnliches gilt wohl auch bei Virenscannern, wenn zusätzliche Dateitreiber installiert werden.
Irrglaube und Falschinformationen:
Leider herrscht ein starker Irrglaube vor, virtuelle Systeme (Gastsysteme) wären vollständig isoliert. Dies ist nicht so, schliesslich muss das Gastsystem mit dem Host auf irgendeine Art und Weise kommunizieren um die nur einmal vorhandene Hardware gemeinsam nutzen zu können.
Wie weit diese Kommunikation kompromittierbar ist, wird uns die Zukunft noch zeigen!
Weil diese Gefahr momentan nicht absehbar ist, möchte ich deutlich davor warnen Virtualisierung in Gefahrenbereichen einzusetzen!
Leider finden Tips, konkrete Vorschläge und Bauanleitungen in Verbindung mit Virtualisierungstechniken zurzeit immer mehr Verbreitung!
So werden häufig folgende Situationen beworben:
Aufbau eines Honey-Pots für jeden
Völlige Sicherheit beim Surfen im Internet mit virtuellen Maschinen (evtl. sogar noch ohne Virenschutz)
Analyse von Malware und Rootkits für jeden
Honey-Pots:
Honey-Pots (Honigtopf) sind Systeme mit speziell eingerichteten Schwachstellen um Angreifer anzulocken. Diese Systeme dienen dann zur Analyse der Vorgehensweise und Absichten der Angreifer und um evtl. deren Identität herauszufinden.
Diese Systeme erfordern aber ein hohes Mass an Fachwissen um Angriffe zu bemerken und später zu analysieren.
Ohne dieses Fachwissen ist ein Honey-Pot schneller ein Zombie-Rechner und Teil eines Botnets, als dem Benutzer lieb ist!
Ich rate deshalb ganz entschieden von solchen Vorhaben ab, auch wenn diverse Magazine neben einer Anleitung auch die nötigen Werkzeuge bereitstellen.
Sicheres Surfen mit virtuellen Systemen:
Natürlich bieten virtuelle Systeme einen gewissen höheren Schutzlevel beim Surfen, als normale Systeme.
Allerdings sollte dieses Plus an Sicherheit effizient genutzt werden und nicht zum völlig unkritischen Umgang mit dem Medium Internet und E-Mail verleiten!
Ähnlich wie ein Airbag oder ein Sicherheitsgurt nicht zum Rasen mit erhöhtem Risiko führen soll!
Auch hier distanziere ich mich von möglichen Bauanleitungen, die zum unkritischen Surfen verleiten und als gefahrlos dargestellt werden. Sie sind es nicht!
Analyse von Malware und Rootkits:
Auch diese Arbeit gehört in die Hände von Fachleuten!
Ich rate auch hier davon ab, solche Analysen ohne das nötige Hintergrundwissen durchzuführen!
Mal abgesehen von integrierten Erkennungsfunktionen einer virtuellen Umgebung (wie bereits im Bericht „Virtualisierung und Risiken – Teil 1“ beschrieben) hat auch diese Nutzung von virtuellen Maschinen Risiken, die von Laien kaum eingeschätzt werden können. Des weiteren ist der Nutzen auf Grund der Erkennungsfunktionen eher fragwürdig.
Auch hier rate ich ganz entschieden davon ab, solche „Bauanleitungen“ umzusetzen!
Virtuelle Produktivsysteme:
Virtuelle Systeme sind hervorragende Umgebungen um Tests und Zukunftsszenarien durchzuspielen.
In produktiven Umgebungen muss der Einsatz genau überdacht werden! Da hier die zukünftigen Entwicklungen und Angriffsspezialisierung noch nicht genau absehbar ist, mahne ich zur Vorsicht. Insbesondere wenn es sich um Dienste oder Services handelt, die vom Internet erreichbar sein sollen (Webserver, Mailserver usw.).
In jedem Fall sollte das Hostsystem entsprechend gehärtet sein und keine Dienste anbieten, die evtl. angreifbar wären. Denn hat der Angreifer das Hostsystem unter seine Kontrolle gebracht, gehören ihm auch das/die darauf laufenden Gastsysteme!
Vor allem unter der Prämisse, dass virtuelle Systeme auch remote erkannt werden können. Somit ist auch der Schluss logisch, wo ein Gastsystem ist, ist auch ein Hostsystem!
Virtuelle Schutzlösungen:
In meinem Bericht zu UTM`s (Unified Threat Management) bin ich auch auf die Möglichkeit eingegangen, diese als virtuelle Systeme aufzubauen. Ich habe damals auch schon auf die Risiken dieser Lösung hingewiesen!
Aufgrund der aktuellen Ereignisse und Erkenntnisse müssen wir aber davon abraten, solange es sich nicht um reine Testsysteme handelt!
Dies gilt im Übrigen für alle Schutzlösungen wie z.B. Firewalls, IDS/IPS-Systeme, UTM`s und UM`s.
Eine sehr gute Erklärung finden Sie im IPCop-Forum – siehe dazu --> „Externe Links“.
Zusammenfassung:
Die Virtualisierungstechnik bietet ganz hervorragende Einsatzzwecke und richtig eingesetzt auch ein Plus an Sicherheit.
Aber auch die Virtualisierung ist kein Allheilmittel und auch kein absoluter Schutz. Leider wird sie aber gerne und häufig so angesehen und beworben.
Auch hier (wie bei allen Schutzlösungen) ist eine kritische Betrachtungsweise nötig.
Welche Gefahren dabei noch kommen werden, wird die Zukunft zeigen. Eine kritische Planung kann aber viele Gefahren im Vorfeld vereiteln.
Interne Links:
Virtualisierung und Risiken – Teil 1: http://www.security-dome.eu/Virtualisierung_und_Risiken_1.html
Virtualisierung mit VirtualBox – Teil 1: http://www.security-dome.eu/Virtual_Box_Teil_1.html
Virtualisierung mit VirtualBox – Teil 2: http://www.security-dome.eu/Virtual_Box_Teil_2.html
Externe Links:
IPCop und virtuelle Maschinen: http://www.ipcop-forum.de/unipcop.php
Weitere Informationen bzw. zur Diskussion dieses Beitrags besuchen Sie unser Forum unter --> http://www.security-dome.eu/forum/pA/
Autor: Frank Richter
Copyright: Frank Richter – securITy-dome.eu
Erstellungsdatum: 31.07.07
Letzte Aktualisierung: 31.07.07