Seite 1 von 1

Firewalls und Virtualisierung

Verfasst: Do 25.03.2010, 14:42
von Andreas
Hallo,

ich habe hier mal einen Artikel mit ein paar interessanten Statements zum Thema virtuelle Firewalls gefunden, die sich jeder mal zu Gemüte führen sollte, der vorhat, eine solche produktiv einzusetzen:

http://www.ipcop-forum.de/unipcop.php

Das dort gesagte würde sicherlich nicht nur ich, sondern auch sonst jeder aus unserer Supportmannschaft sofort unterschreiben.

Andreas

Firewalls und Virtualisierung

Verfasst: Do 25.03.2010, 15:00
von CHoell
Wie steht den Securepoint generell dazu virtualisierte Firewalls in Produktivumgebungen einzusetzen.

Würde mich mal ein offizielles Statement interessieren.

Wobei ich da mehr an ESX / ESXi Umgebungen denke als an VMWare Server Installationen.


Chris

Firewalls und Virtualisierung

Verfasst: Mi 07.04.2010, 18:30
von merlin
Hallo,

mir stellt sich hier eigentlich nur eine Frage:
Welche kompromittierbaren Dienste stelle ich denn ich einer virtuellen Umgebung (auf einer virtuellen Netzwerkkarte, auf einem virtuellen Switch) "mehr" zur Verfügung, als in einer physikalischen Umgebung?
In einer ESX-Umgebung kann/soll man das externe Interface vom internen Interface trennen (physisch und/oder per VLAN). Sicherheitsupdates müssen im Rahmen eines Sicherheitskonzeptes immer installiert werden, aber aktualisiert wirklich jeder die Firmware seiner Switche sobald es ein Update gibt? Bei Switchen sehen viele nicht einmal die Notwendigkeit sie vor Inbetriebnahme zu aktualisieren. Hier sagen doch fast alle: "Funktioniert doch..."

Bin mir selbst noch nicht 100% klar wie ich darüber denken soll, mal sehen ob es hier noch mehrere Meinungen gibt.

Gruß,
Rolf Gerold

Firewalls und Virtualisierung

Verfasst: Fr 16.04.2010, 12:37
von hurikhan77
Wir setzen solch auf ESXi basierte virtualisierte Firewalls erfolgreich ein. Sicherheitsbedenken sehe ich da eher weniger. Allerdings würde ich ein solches Setup auch wirklich nur auf Bare-Metal-Hypervisorn ausführen, und nicht in einer Virtualisierung, unter der ein vollständiges, mit Diensten vollgestopftes Betriebssystem läuft (z.B. VMware Server).

Firewalls und Virtualisierung

Verfasst: Fr 16.04.2010, 12:44
von hurikhan77
Hinzuzufügen bleibt natürlich, daß das Hostbetriebssystem selbst keine IP hat, die von außen erreichbar ist und daß man nicht alle Subnetze auf einer Netzwerkkarte virtuell zusammenführt, sondern eben physikalische Netzwerkkarten für WAN, LAN und DMZ auf dem Host bereitstellt.

Firewalls und Virtualisierung

Verfasst: Do 19.08.2010, 17:11
von achim
Bei einer virtualisierten Firewall benötige ich mehr KnowHow, da ich den Hypervisor UND die Firewall(-software) absichern muss.

Und wie das mit KnowHow nun mal so ist... zumindest in "kleineren Unternehmen" oder insbesondere im Vertretungsfall steigt hier das Risiko.

In größeren Umgebungen wird die Aufgabentrennung eventuell zum Problem. Der eine pflegt die Firewall-VM und der andere den Hypervisor. (Und in manchen Umgebungen pflegen beide aneinander vorbei)

Daher sehe ich das Sicherheitsrisiko bei einer Virtualisierung etwas höher.


Aber prinzipiell erschließt sich mir kein Vorteil in der Firewall-Virtualisierung.
Das Stück Blech, dass ich mir spare, wäre mir nicht die (geringen) Resourcen in meiner VM-Umgebung wert.
Auch im Recovery-Fall (Firewall defekt) würde ich es vorziehen einen (auch einen halb-DAU) mit der Anweisung: "hier -> USB-Stick -> Hardware -> Manager -> konfig-> 15 Minuten" loszuschicken, wenn nicht eh ein Ersatzgerät vorhanden ist, als den VM-Spezi zu suchen und ihm einen mehr oder weniger kompliziten Recovery Auftrag zu erteilen.


Nicht zu vergessen:
User: "nix geht mehr/kein Internet" -> mhh, zieh (bzw. ich zieh) mal den Stecker raus und steck ihn wieder rein... -> oh, es geht wieder

Firewalls und Virtualisierung

Verfasst: Do 19.08.2010, 17:53
von hurikhan77
achim hat geschrieben: Bei einer virtualisierten Firewall benötige ich mehr KnowHow, da ich den Hypervisor UND die Firewall(-software) absichern muss.
Das gilt es schonmal durch passende Planung weitgehend zu minimieren. Ein Restrisiko bleibt natürlich immer.
achim hat geschrieben: In größeren Umgebungen wird die Aufgabentrennung eventuell zum Problem. Der eine pflegt die Firewall-VM und der andere den Hypervisor. (Und in manchen Umgebungen pflegen beide aneinander vorbei)
Das ist bei einer physikalischen Firewall nicht anders: Einer pflegt die Firewall, der andere die Clients, die darüber ins Netz gehen. Wird hier „aneinander vorbeigepflegt“ funktioniert auch nichts mehr oder wird unsicher. Eine Firewall ist schließlich auch kein Allheilmittel. („Wir brauchen keinen Virenscanner - wir haben doch 'ne Firewall!“ - „Tut mir leid, daß ich Sie da enttäuschen muß - aber leider: falsch.“)

Das Problem kenne ich aus eigener Hand: Zwei Standorte, zwei Administratoren, ein VPN-Tunnel. „Nein, das Problem ist bei Ihnen - ich hab doch gar nichts verstellt“ - das ist frustrierend, und der Kunde denkt irgendwann: „Sag mal, können die Jungs überhaupt etwas?“
achim hat geschrieben: Aber prinzipiell erschließt sich mir kein Vorteil in der Firewall-Virtualisierung.
Das Stück Blech, dass ich mir spare, wäre mir nicht die (geringen) Resourcen in meiner VM-Umgebung wert.
Die Performance der Firewall ist aus meiner Erfahrung deutlich höher, das Wirtssystem stört die zusätzliche Last dagegen kaum. Außerdem ist es ein Stromverbraucher und eine Wärmequelle weniger im Serverschrank. Ich gehe davon aus, daß man sich keine Desktop-Hardware als Virtualisierung hinstellt, sondern etwas vernünftiges mit redundantem Netzteil und redundanten Festplatten (RAID).
achim hat geschrieben: Auch im Recovery-Fall (Firewall defekt) würde ich es vorziehen einen (auch einen halb-DAU) mit der Anweisung: "hier -> USB-Stick -> Hardware -> Manager -> konfig-> 15 Minuten" loszuschicken, wenn nicht eh ein Ersatzgerät vorhanden ist, als den VM-Spezi zu suchen und ihm einen mehr oder weniger kompliziten Recovery Auftrag zu erteilen.
Firewall defekt = Hardware defekt (an der Software spielt man schließlich nicht dauernd rum, schon gar nicht der erwähnte DAU). Falls das der Fall ist und übertragen auf eine andere Hardware (z.B. der Server), hat man ganz andere Probleme als die Firewall. Wenn die Firewall trotzdem in dieser Anschauung das empfindliche Hardware-Glied bleibt (oder sein soll), läuft es einfach auf keiner vernünftigen Hardware und der Umzug in eine VM verbessert diesen Umstand erheblich. Falls die Software-Konfiguration das Problem ist, gibt es nichts besseres, als VM-Snapshots. Ganz vorsichtige halten für den Bedarfsfall sowieso eine Zusatzhardware bereit, die dann eingesetzt werden kann, wenn „hier → USB-Stick → Hardware → Manager → konfig→ 15 Minuten“ nicht mehr hilft.
achim hat geschrieben: Nicht zu vergessen:
User: "nix geht mehr/kein Internet" -> mhh, zieh (bzw. ich zieh) mal den Stecker raus und steck ihn wieder rein... -> oh, es geht wieder
Das sind immer die gammeligsten Lösungen überhaupt. Hinterher weiß immer noch keiner, was das Problem war, so daß es sich in Zukunft nicht vermeiden läßt. Solche Probleme treten also entweder nie auf, oder andauernd. Falls andauernd, nervt es irgendwann so, daß der Kunde eh eine andere Lösung will. Wobei es natürlich solche und solche gibt: „Och hier, starte mal neu, dann geht das wieder“ - „Einfach neu installieren, dann geht das wieder“ - von daher kann ich dir hier natürlich durchaus zustimmen. Befriedigend ist das allerdings nicht, weil's unnötig Zeit kostet - und zwar immer wieder, nicht nur 1-2x.

Re: Firewalls und Virtualisierung

Verfasst: Mo 28.08.2017, 00:10
von Crintel
Sehr gut geschrieben :))

Re: Firewalls und Virtualisierung

Verfasst: Mo 28.08.2017, 18:01
von David
hurikhan77 hat geschrieben:Firewall defekt = Hardware defekt (an der Software spielt man schließlich nicht dauernd rum, schon gar nicht der erwähnte DAU). 
Dem würde ich gern wagen zu widersprechen, grade der.