Wie man virtuelle Umgebungen mit einer DMZ-Netzwerk-Architektur verbindet

Wenn Sie virtualisierte Umgebungen mit einer DMZ-Netzwerk-Architektur verbinden wollen, müssen Sie dabei besondere Regeln beachten.

In einer physischen Umgebung stellen DMZ-Netzwerke einen Puffer zwischen dem internen Netzwerk und dem Internet dar. Es werden Server abgesichert, die mit beiden Seiten verbunden sind. Verbindet man allerdings virtuelle Umgebungen mit einer DMZ-Netzwerk-Architektur, gibt es neue Herausforderungen für die Sicherheit. Deshalb müssen Netzwerk-Manager mit neuen Design-Methoden experimentieren.

Wie DMZ-Netzwerke bei physischen Umgebungen funktionieren

DMZ-Netzwerke agieren als Puffer zwischen einem internen Netzwerk und dem Internet. Sie sind durch Firewalls geschützt, die Traffic unter anderem basierend auf IP-Adressen und TCP/IP-Port-Nummern blockieren.

In einer physischen Umgebung sind Server mit einem isolierten Netzwerk-Switch verbunden, der wiederum von einer physischen Firewall beschützt ist, die Schnittstellen zum DMZ-Switch, dem internen und dem externen Netzwerk unterhält. Der Server selbst hat nur Netzwerk-Verbindungen in der DMZ (Demilitarisierte Zone). Seine Netzwerk-Verbindungen zu den internen und externen Netzwerken sind durch die Firewall abgesichert. Sollte der Server kompromittiert werden, hat ein Angreifer nur Zugriff bis zum DMZ-Netzwerk. Auf das interne Netzwerk hätte er keinen Zugriff, ohne sich einen Weg durch die Firewall bahnen zu müssen.

Jeder sich in der DMZ befindliche Server sollte nur mit dem DMZ-Switch verbunden sein. Eine physische Verbindung zu sowohl DMZ-Netzwerk als auch internem Netzwerk sollte es niemals geben. Ist ein Server mit beiden Netzwerken verbunden, agiert er im Grunde genommen als Bridge. Sollte das Gerät kompromittiert sein, haben Angreifer einen direkten Weg in das interne Netzwerk und sie müssen nicht erst durch die Firewall. Das Separieren von internem Netzwerk, DMZ-Netzwerk und dem externen Internet funktioniert allerdings hervorragend.

Probleme beim Verbinden virtueller Maschinen zum DMZ-Netzwerk

Im Vergleich zur Isolation physischer Server mithilfe einer DMZ funktionieren die herkömmlichen Methoden bei Virtualisierung nicht sehr gut. Das hat mehrere Gründe:

  • Bei Virtualisierung geht es darum, viele virtuelle Server-Instanzen auf einen physischen Server zu konsolidieren. Aus diesem Grund wird ein einzelner Host eine sehr wichtige Komponente, weil sich darauf viele virtuelle Maschinen (VM) mit verschiedenen Funktionen und unterschiedlichen Anforderungen befinden. Ein typischer Host verbindet sich zu mehreren physischen Netzwerken, um den vLAN-Anforderungen der virtuellen Maschinen gerecht zu werden. Es ist gebräuchlich 802.1Q VLAN Tagging zu verwenden, damit man mit weniger NICs viele VLANs auf einer einzelnen physischen NIC unterstützen kann. Müssen Sie spezielle Hosts für eine DMZ-Umgebung reservieren, kann das die Wirtschaftlichkeit von Virtualisierung ruinieren, denn die Konsolidierungs-Verhältnisse sind in der Regel hoch, um die Nutzung der Ressourcen zu maximieren.
  • Das physische Netzwerk wird mit einem virtualisiertem Host erweitert, der sein eigenes Netzwerk an virtuellen NICs und Switches mit sich bringt. Diese werden separat vom physischen Netzwerk verwaltet. Physische Firewalls lassen sich nicht auf das virtuelle Netzwerk ausweiten. Traffic, der den Host niemals verlässt, ist ungeschützt.
  • Jeder Host bringt auch eine Management-Konsole mit, der dort läuft. Alternativ könnte das eine virtuelle Maschine sein, die alle VMs auf diesem Host kontrolliert. Wird diese Management-Komponente kompromittiert, wirkt sich das auf alle virtuellen Maschinen auf diesem Host aus. Deswegen sollte dieser niemals zu einem DMZ-Netzwerk verbunden sein.

Aus den oben genannten Gründen müssen Sie neue Methoden entwickeln, wenn Sie eine virtuelle Umgebung mit einer DMZ-Architektur verbinden. Es ist also notwendig, die Virtualisierungs-Architektur zu adaptieren.

Methoden, um virtuellen Maschinen mit einer DMZ-Netzwerk-Architektur zu verbinden

Es gibt diverse Möglichkeiten, um Hosts und VMs mit einer DMZ-Netzwerk-Architektur zu verbinden. All diese weisen eine Gemeinsamkeit auf: Die Management-Konsole des Hosts ist mit einem internen Netzwerk verbunden. Das scheint ein ziemlicher Gegensatz zum grundlegenden Prinzip zu sein, dass ein physischer Server niemals gleichzeitig mit einem öffentlichen und einem privaten Netzwerk verbunden sein sollte, da dieser Umstand als Bridge fungieren könnte. Läuft auf einem Server ein herkömmliches Betriebssystem, ist diese Situation auch auf gar keinen Fall wünschenswert. Verwenden Sie einen Bare-Metal-Hypervisor (Type 1) wie zum Beispiel vSphere, ist das allerdings in Ordnung.

Ein Typ-1-Hypervisor ist dafür ausgelegt, die virtuellen Maschinen und vSwitches zu isolieren und aufzuteilen. Wenn eine VM kompromittiert ist und Angreifer kompletten Zugriff auf das Betriebssystem der virtuellen Maschine haben, dann können sie die VM auf Betriebssystem-Ebene ausnutzen. Der Zugriff auf und ein Exploit des Hypervisors sind jedoch nicht möglich. Somit ist auch kein Zugang auf die anderen virtuellen Maschinen oder Host-Netzwerke realisierbar. Dieses Design hat sich bewährt und VMware hat noch keinen Vorfall gemeldet, dass ESX- oder ESXi-Hypervisoren auf diese Weise kompromittiert wurden.

Die Management-Konsole sollte sich jedoch unter allen Umständen in einem internen Netzwerk befinden und nicht in der DMZ. Da sie Zugriff auf jede virtuelle Maschine eines Hosts ermöglicht, wäre das ein begehrtes Ziel für jeden Angreifer.

Mit vSwitches virtuellen Maschinen im DMZ-Netzwerk managen

Den Rest der Netzwerk-Architektur eines Hosts, der mit einer DMZ verbunden ist, kann man auf unterschiedliche Weise adressieren. Ein virtueller Switch (vSwitch) kann verschiedene physische NICs und auch mehrere VLANs unterstützen, wenn Tagging im Einsatz ist. Ein Host kann mehrere vSwitches besitzen. Die physischen NICs müssen allerdings einem vSwitch zugeordnet sein und können eine Schnittstelle nicht gemeinsam nutzen. Oftmals gibt es mehrere vSwitches, die für bestimmte Host-Funktionen oder VM-Gruppen reserviert sind. Zusätzlich besitzen vSwitches normalerweise mehrere physische NICs für Failover oder Load Balancing.

Wenn Sie eine DMZ-Netzwerk-Architektur auf einem Host anlegen, gibt es dabei eine goldene Regel, die unbedingt zu beachten ist: Spendieren Sie der DMZ einen vSwitch und verwenden sie diesen niemals zusammen mit einem internen VLAN. So isolieren Sie den DMZ-Traffic. Er spielt sich nur auf der eigenen physischen NIC ab und Traffic von virtuellen Maschinen gelangt nicht in private Netzwerke. Ein vSwitch ist genau genommen ein Layer-2-Switch auf Software-Ebene im RAM eines Hosts. Der wiederum enthält physische NICs (Uplinks), die den virtuellen Maschinen zugewiesen sind. Jeder vSwitch ist von den anderen isoliert und es gibt keine Backend-Schaltungen, die vSwitches miteinander verbinden. Will eine virtuelle Maschine an einem vSwitch mit einer anderen VM an einem anderen vSwitch auf dem gleichen Host kommunizieren, muss der Traffic über das physische Netzwerk laufen. Somit lassen sich herkömmliche Sicherheits-Maßnahmen für physische Netzwerke einsetzen, um den Traffic zwischen vSwitches zu isolieren und zu schützen. Wenn Sie für die DMZ einen vSwitch reservieren, dann können Sie eine herkömmliche physische Firewall für den Schutz mobilisieren. Weiterhin ist das Konstrukt von anderen vSwitches auf dem Host isoliert, die möglicherweise mit internen Netzwerken verbunden sind.

Wie VLAN Tagging mehrere VLANs in einem DMZ-Netzwerk unterstützen kann

Sie können das DMZ-Netzwerk weiterhin separieren, indem Sie VLAN Tagging innerhalb des vSwitches einsetzen. Damit unterstützen Sie mehrere VLANs in der DMZ. Allerdings ist es möglicherweise wünschenswert, die virtuellen Maschinen physisch zu isolieren. In diesem Fall könnten Sie mehrere vSwitches anlegen, die jeweils eine eigene physische NIC besitzen, die wiederum mit dem DMZ-Netzwerk verbunden sind. Somit haben Sie die Möglichkeit, jeden vSwitch mit einer physischen Firewall abzusichern. Außerdem zwingen Sie damit den internen VM-Traffic durch eine physische Firewall.

Nehmen wir an, dass Sie einen oder mehrere vSwitches auf einem Host für ein DMZ-Netzwerk dediziert haben. Verwenden Sie nun auch einen kompletten Host für virtuelle Maschinen, die sich ausschließlich in der DMZ befinden? Das können Sie natürlich machen, wenn Sie die Security maximieren und die virtuellen Maschinen von denen im internen Netzwerk trennen wollen. Allerdings ist es gebräuchlich, vSwitches auf den gleichen Hosts zu betreiben, die mit internen oder externen Netzwerken verbunden sind. Wir haben bereits darüber gesprochen, dass der Hypervisor den Traffic der einzelnen vSwitches getrennt voneinander behandelt. Nachfolgend finden Sie eine Abbildung mit einer typischen Netzwerk-Konfiguration für einen Host, der mit einem DMZ-Netzwerk verbunden ist. Außerdem zeigt die Abbildung, wie separate vSwitches für DMZ-Netzwerk-VM-Traffic, interner Traffic der virtuellen Maschinen und Datenverkehr der Management-Konsole eingesetzt werden.

Typische Netzwerk-Konfiguration eines ESX-Hosts, der mit einem DMZ-Netzwerk verbunden ist.
Abbildung 1: Typische Netzwerk-Konfiguration eines ESX-Hosts, der mit einem DMZ-Netzwerk verbunden ist.

Mithilfe dieses Designs können Sie Ihre Host-Ressourcen maximal ausnutzen, da Sie vielleicht nur wenige virtuelle Maschinen betreiben, die man mit einer DMZ verbinden muss. Reserviert man in so einem Fall einen kompletten Host, wäre das pure Ressourcen-Verschwendung. Jeder vSwitch besitzt sein eigene physische NIC, die sich zu verschiedenen physischen Switches verbindet, die wiederum durch physische Firewalls von anderen Netzwerken abgesichert sind.

Fazit

Eine Verbindung zum Internet ist immer mit einem gewissen Risiko verbunden. Allerdings ist es mit cleverer Design-Entscheidungen möglich, einen Host mit einem DMZ-Netzwerk zu verbinden. Eine sichere DMZ-Netzwerk-Architektur sollte eine Kombination aus angemessenem Design und entsprechenden Sicherheits-Kontrollen sein. Das gilt sowohl auf virtueller als auch physischer Seite. Halten Sie sich daran, können Sie die Vorteile von Virtualisierung auch in einer DMZ-Umgebung genießen.

Folgen Sie SearchNetworking.de auch auf Twitter, Google+

Erfahren Sie mehr über LAN-Design und Netzwerkbetrieb

ComputerWeekly.de
Close