Hyper-V: Firewall virtuell betreiben?

Kürzlich erschien ein Gastartikel im TechNet-Blog Deutschland, der sich mit einer „exklusiven“ Netzwerkkarte für Firewalls in Hyper-V beschäftigt:

[QuickTip Hyper-V: Netzwerkkarte exklusiv nutzen – TechNet Blog Deutschland]
http://blogs.technet.com/b/germany/archive/2015/05/20/quicktip-hyper-v-netzwerkkarte-exklusiv-nutzen.aspx

So, wie es der Artikel darstellt, ist das Vorgehen zwar nicht richtig falsch, aber doch unvollständig und gefährlich.

Die Grundfrage, die der Artikel leider auslässt, lautet: Darf man eine Firewall virtuell betreiben? Und wenn ja, darf dies auf einem Host geschehen, der noch andere VMs hält?

Der in dem Artikel beschriebene Weg zeigt auf, wie man einen vSwitch so einrichtet, dass das Management OS keine eigene vNIC (virtuelle Netzwerkkarte) daran bindet. Das heißt aber noch lange nicht, dass „der Host … nichts damit zu tun hat“. In Hyper-V ist das Management OS (auch bekannt als “Parent Partition”) an jedem I/O-Vorgang beteiligt, schließlich muss der Traffic ja durch den Virtualisierungs- und Treiberstack, und der liegt bei Hyper-V nun mal in der Parent Partition. (In anderen Plattformen ist es nicht exakt genauso, aber das Prinzip trifft dort auch zu.)

Daneben ist auch nicht sichergestellt, dass außer der Firewall-VM kein Computer an die Netzwerkkarte könne (im Blogtext ganz unten). Dazu fehlt schon in der Darstellung in dem Artikel der Hinweis, dass man an den betreffenden vSwitch natürlich auch keine andere VM binden darf. Das ist technisch ja nicht ausgeschlossen, sondern man muss es organisatorisch sicherstellen.

Und schließlich ist der ganze Ansatz auch noch fragwürdig: Eine Firewall sollte immer von internen Ressourcen getrennt sein. Das bedeutet aber gerade, dass man sie nicht mit internen VMs auf demselben Host betreiben darf – und genau dieser Hinweis fehlt. Jedes Virtualisierungssystem, insbesondere Hyper-V, hat bei aller „Isolation“ der VMs immer eine Verbindung zum Hypervisor bzw. zum Management-OS. Bei Hyper-V ist das besonders deutlich durch den VMBus, der eine geteilte Ressource ist. Und natürlich stellt der ein Angriffsziel dar, mit dem man potenziell aus der VM ausbrechen kann. So ein Risiko will man bei einer Firewall ja gerade nicht haben.

Man mag nun einwenden, dass das ein theoretisches Risiko ist – ist es aber nicht, wie vor einigen Jahren ein bekannter Angriff auf VMware gezeigt hat, der über eine geteilte Ressource (damals war es der Grafikspeicher, der Hack ist als „Cloudburst“ bekannt) von einer VM auf jede andere oder auch auf den Host kam. Solche Fehler kann es natürlich auch in Hyper-V geben. Daher muss man VMs, die zu einem unsicheren Netzwerksegment gehören, physisch von internen VMs trennen.