Firewalls in virtuellen Umgebungen
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.
Virtualisierte Sicherheitskomponenten
Eine besondere Variante ist dabei 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.
Offensichtlich unsinnig wird es jedoch, wenn ein ursprünglich mehrstufiges Firewall-Konzept nur noch virtuell mehrstufig auf einem gemeinsamen Host implementiert wird, denn mehrstufige Sicherheitskonzepten 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 "Unified-Threat-Management"- (UTM)-Produkten 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.