Ins Netz gegangen

Sobald eine virtuelle Maschine ins Intra- oder Internet gelangt, kann sie wie ein realer Rechner Opfer von DoS-Attacken, Portscans und Einbruchsversuchen werden. Folglich sind die gleichen Sicherungsmaßnahmen wie auch bei physischen Rechnern zu treffen: Die in der VM laufenden Webanwendungen oder Dienste sollten immer auf dem aktuellen Stand sein. Bei einem erfolgten Einbruch darf die Schadsoftware nicht über das Netzwerk auf den Wirtsrechner, andere reale Rechner im LAN oder weitere VMs übergreifen. Letzteres ist vor allem dann leicht möglich, wenn alle virtuellen Maschinen im gleichen (virtuellen) Netzwerk hängen (Bild 7). Firewalls müssen folglich den Datenfluss von, zu und vor allem auch zwischen den virtuellen Maschinen kontrollieren. Hierbei helfen auch die libvirt-Werkzeuge, insbesondere der Network Filter Driver nwfilter [6].

 Bei der normalen NAT-Betriebsart (User Mode, Default Network) gelangt nur das Gastsystem in der virtuellen Maschine ins Netz; Angreifer von außen sehen nur den Wirtsrechner, den sie unter Beschuss nehmen könnten. Umgekehrt erreicht jedoch das Gastsystem seinen Wirt standardmäßig immer unter der IP-Adresse 10.0.2.2. Unter dieser Adresse läuft auch der eingebaute DHCP-Server. Das ist zwar für den Datenaustausch nützlich, Schadprogramme in der virtuellen Maschine können jedoch in aller Ruhe den Wirt angreifen. Die Firewall auf dem Wirt greift hier normalerweise nicht, weil die Anfragen auf dem Wirtssystem selbst stattfinden. Wichtig ist deshalb, dass auf dem Wirtssystem keine weiteren (angreifbaren) Dienste laufen. Im Idealfall führt der Wirt nur die virtuellen Maschinen aus – und sonst nichts.

Bild 6: Über VNC lässt sich eine virtuelle Maschine auch von entfernten Rechnern steuern, ein beliebiger VNC-Client genügt

QEMU bietet zudem die Möglichkeit, virtuelle Maschinen über TCP- und UDP-Sockets zu verbinden. Diese Verbindungen sind jedoch unverschlüsselt. Zudem kann jeder, der Zugriff auf die Sockets hat, Daten an die verbundenen virtuellen Maschinen schicken. Wer Sockets nutzt, sollte deshalb wenigstens beim Aufbau der Verbindungen die von QEMU angebotene Zugriffsbeschränkung nutzen und darüber die Verbindungen nur von bestimmten IP-Adressen erlauben (Parameter “-net socket, connect=host­name,port”).

Schnittstellen unter Kontrolle

Haben Sie Port-Weiterleitungen in die virtuellen Maschinen eingerichtet, sollten Sie diese auf eine Netzwerkschnittstelle beschränken. Damit lassen sich die Verbindungen zur virtuellen Maschine und zum Wirt leichter trennen und filtern: Wartungsarbeiten am Wirtsrechner erfolgen dann etwa ausschließlich über die Schnittstelle eth0, Zugriffe auf die virtuelle Maschine nur noch über eth1. Dabei helfen die libvirt-Werkzeuge und der MacVtap-Treiber, die im Zusammenspiel virtuelle Maschinen direkt mit einer Netzwerkschnittstelle des Wirtssystems verbinden können. Interessant sind hierbei die Betriebsmodi Private und Bridge, bei denen die virtuellen Maschinen nicht mehr auf das Wirtssystem zugreifen können. Im Private-Modus dürfen sogar die virtuellen Maschinen nicht mehr untereinander kommunizieren [7]. Eine Firewall machen diese Maßnahmen jedoch nicht überflüssig.

 QEMU bietet einen eingebauten TFTP-Server an, über den sich schnell und unkompliziert Dateien zwischen Wirts- und Gastsystem austauschen lassen. Die Kommunikation erfolgt jedoch unverschlüsselt, zudem gibt es keine Benutzerauthentifizierung. Administratoren sollten daher möglichst den eingebauten TFTP-Server abschalten und stattdessen einen richtig gesicherten FTP-Server oder noch besser im Gast einen SSH-Zugang einrichten.

Bild 7: Insbesondere wenn die virtuellen Maschinen auch von außen erreichbar sein sollen, entstehen gleich mehrere Punkte im Wirt, die entsprechende Firewalls kontrollieren müssen