Sicherheitsfrage bzgl. 1x physikalischen NIC
-
Moin.
Mal ehrlich, was erwartest Du in einem Firewall-Forum für eine Antwort auf eine solche Frage!? ;)
Natürlich stellt eine solche Konfiguration ein potentielles Sicherheitsrisiko dar.
Einmal wegen möglicher Exploits im Hypervisor selbst, zum Anderen durch eine schlichtweg mögliche Fehlkonfiguration der vSwitche/vLAN's.
Die ideale FW-Philosophie sieht halt für jedes Netz ein physisches Interface vor.Bleibt die Frage der Risikoabschätzung. Eine Unternehmensfirewall würde ich so nicht betreiben wollen. Im privaten Umfeld ist das Risiko m.E. durchaus vertretbar, wenn man denn Alles sauber konfiguriert hat.
Gruß
Dirk -
Hi.
Ich habe mir eine neutrale Meinung erwartet, die du mir größtenteils gegeben hast. Danke. :)
Oft ist es eben bei gemieteten Root-Servern so, dass man nur 1x physikalische NIC hat.
Den Aufpreis für eine weitere Netzwerkkarte möchte man sich als Privater eben meist sparen.
Für Firmenumgebungen hast du natürlich recht.Was mir noch nicht ganz klar ist:
-
Was meinst du mit Exploits im Hypervisor?
Wenn das Management Interface in einem VLAN hängt welches nur von intern erreichbar ist, ist doch erstmal nichts angreifbar? -
Man könnte natürlich das WAN und LAN(VLANs) mit 2x vSwitchen trennen. (WAN = 1 Uplink, LAN = ohne Uplink)
Hier sehe ich aber den Nachteil, dass falls ein weiteres physikalisches Gerät im Netzwerk vorhanden ist, dieses nicht in das selbe Netz wie eine VM auf dem LAN vSwitch gehängt werden kann. -
Wo wäre das Problem alles an einem vSwitch zu betreiben (WAN + LAN ohne VLANs)?
Die VMs im LAN haben in der Regel eine private IP-Adresse und werden in der pfSense geNATet und sind dann ja nicht für Angriffe aus dem WAN erreichbar?
Ich sehe schon, ihr werdet mich wegen der Frage kreuzigen…aber was könnte den im schlimmsten Fall passieren? ;D
Dass das interne Netze nicht mehr getrennt ist, ist mir klar. Die Frage zielt auf Gefahren von extern ab. -
Selbst wenn ich bei einem Root-Server eine weitere phys. NIC einbauen lasse bringt es mir ja so erstmal nichts, da die zusätzlichen NICs im Prinzip auch erstmal im WAN hängen?
Das wäre ja nur sinnvoll, wenn ich auch einen physikalischen Switch zur Verfügung hätte.
Grüße
-
-
Wenn das Management Interface in einem VLAN hängt welches nur von intern erreichbar ist, ist doch erstmal nichts angreifbar?
Exploits im Hypervisor die einen VM Escape zulassen. Damit ist der Zugriff AUS der VM IN den Hypervisor möglich bzw. in dessen Netzwerkstack. Damit durchbricht man die Trennwand der Virtualisierung recht eindeutig. Und wenn ich aus meinem HV ausgebüchst bin ist es zu spät. Deshalb sind solche Angriffe gefährlich und deshalb zahlen VMware und Co da ein Heidengeld für gegen sowas ständig zu testen. Die Geschichte letztes bzw. Vorletztes Jahr war bspw. mit unklarem Ergebnis für ESXi, in der Workstation Version konnte erfolgreich auf den Host aus der VM zugegriffen werden. Weil man vermeiden wollte, dass es ggf. doch Impact auf ESXi hat, wurde alles gepatcht. Die Angriffe sind also nicht theoretisch, sondern es gab durchaus bereits praktische (wie Venom bspw.)
Hier sehe ich aber den Nachteil, dass falls ein weiteres physikalisches Gerät im Netzwerk vorhanden ist, dieses nicht in das selbe Netz wie eine VM auf dem LAN vSwitch gehängt werden kann.
Der Satz macht eigentlich keinen Sinn? Die Standardprozedur auf solchen Billig-Hosting-Kisten ist meistens den physical NIC als WAN an eine Routing VM zu hängen und deren LAN/interne Interfaces dann entsprechend auf diverse VLAN Switche zu hängen, an denen dann die VMs angedockt werden. Wenn außer der einen Hosting Kiste noch mehr Hardware eine Rolle spielt macht das ganze Setup eh keinen Sinn, denn dann reden wir im Normalfall von einem größeren Setup/Cluster und DA hängen bitte eh HW Kisten vornedran.
- Selbst wenn ich bei einem Root-Server eine weitere phys. NIC einbauen lasse bringt es mir ja so erstmal nichts, da die zusätzlichen NICs im Prinzip auch erstmal im WAN hängen?
Deshalb stand oben bei meiner ersten Antwort bereits: wenn die physikalischen Gegebenheiten es nicht anders zulassen. Wenn man eh auf ein Blech limitiert ist und keine andere Möglichkeit hat, dann bringt auch lamentieren über hätte wäre wenn nichts, man hat ja nichts anderes :)
-
Hallo,
wie Dirk schon angemerkt hat, du fragst das vielleicht im falschen Forum. Die Leute hier sind/müssen auf Sicherheit bedacht/sein und ziehen oft auch sicherheitstechnische Netzwerkstrukturen der alten Schule vor.
In einem Virtualisierungs- oder ESXi-Forum würdest du hierauf vielleicht brauchbare Antworten bekommen.Du hättest auch die Forumsuche nach den Begriffen Virtualisierung und Sicherheit oder Risiko bemühen können und hättest wohl zahlreiche ähnliche oder gleiche Argumente gefunden. Solche Threads laufen hier meisten darauf hinaus, dass der TO raus geprügelt wird und dass ihm jeglicher Spaß an der Virtualisierung verdorben wird.
Ich will die Bedenken aber auch gar nicht ganz von der Hand weisen, doch sehe ich die Sache nicht ganz so dramatisch, obwohl ich in meinem Umfeld auch immer der mit den größten Sicherheitsbedenken bin.
Von ESXi habe ich allerdings ebenso wenig Ahnung wie von dessen vSwitche. Ich virtualisiere mit KVM und für das virtuelle Netzwerk innerhalb des Hosts verwende ich nur die Linux-typischen Geräte. Doch nehme ich an, dass die Problematiken vergleichbar sind.
Doch kann ich deinem Argument gegen mehrere vSwitche nicht ganz folgen.Aufgefallen ist mir hier, dass auf deine eigentliche Frage nach einem dadurch bedingten Sicherheitsrisiko, dass alles auf einem vSwitch hängt, gar nicht wirklich eingegangen wurde.
Als Argument dagegen hat man lediglich mögliche "Exploits im Hypervisor" genannt. Das steht aber gegen Virtualisierung im Allgemeinen.
Ja, die Gefahr ist gewiss real, doch halte ich sie bei ordentlicher Konfiguration nicht für sehr groß.
Das was Jens mit "Die Geschichte letztes bzw. Vorletztes Jahr war bspw. mit unklarem Ergebnis für ESXi, in der Workstation Version konnte erfolgreich auf den Host aus der VM zugegriffen werden" meint, ist vermutlich die Sache (sieht für mich jedenfalls so aus) auf dem Hacker-Wettbewerb Pwn2Own (https://www.heise.de/newsticker/meldung/Hacker-brechen-aus-virtueller-Maschine-aus-3658416.html), das war allerdings erst heuer. Wie Jens selbst genannt hat, hat das die VMWare Workstation betroffen, nicht den ESXi, den du einsetzt. Zudem hatten diese Hacker ein großes Ziel (105.000 USD), eine Menge Aufwand betrieben, ihren Hack genau auf den vorliegenden Aufbau ausgelegt und einige Schwachstellen ausgenutzt, die vermutlich bereits geschlossen sind.Auch die ebenfalls hier genannte Venom Vulnerability hat mir bislang noch kein Kopfzerbrechen bereitet. Soweit ich das in Erfahrung bringen konnte, nutzt diese ausschließlich eine Schwachstelle im virtuellen Floppy Gerät, das ich wohl noch nie eingesetzt hatte und wenn, dann nur temporär.
Sollten die Sicherheitsrisiken tatsächlich so hoch sein, dürfte generell keine DMZ virtualisiert werden, schon gar nicht eine Firewall, egal ob mit virtuellem Switch oder mit physischem. Denn schließlich hat ja jeder Host auch einen Management-Zugang und ob dieser am selben physischen Interface liegt, spielt bei den hier genannten Gefahren keine Rolle.
Wie hoch das Sicherheitsrisiko letzten Endes ist, hängt davon ab, was du genau für Daten auf deinen Server hast. Die Gefahr ist eben doch real, aber eher klein. Doch sind es besonders heikle Daten, wirst du hoffentlich nicht die Sache über einen Rootserver realisieren.
Für eine professionellere Einschätzung empfehle ich aber einen Virtualisierung-Fachmann, und einen solchen findest du vermutlich eher in einem anderen Forum. ;)Grüße
-
Hallo virago,
In einem Virtualisierungs- oder ESXi-Forum würdest du hierauf vielleicht brauchbare Antworten bekommen.
Warum? Auch da geht es schlußendlich darum, dass ich eine Security Appliance / Firewall virtualisieren möchte. Und da bin ich persönlich auch nicht dagegen, was ich geschrieben habe, sondern weise auf die Umstände hin. Wenn ich keine andere Chance habe (siehe 1 Host etc.) - warum nicht. Wenn ich die Chance habe aber daran was zu ändern und Hardware einzusetzen muss ich abwägen, was sinnvoller und sicherer ist und wie groß die Sicherheitsbedenken sind.
Solche Threads laufen hier meisten darauf hinaus, dass der TO raus geprügelt wird und dass ihm jeglicher Spaß an der Virtualisierung verdorben wird.
Das halt ich für ein Gerücht. Hier wird niemand verprügelt oder wem der Spaß vergällt. Man muss aber offen diskutieren dürfen auch wenns mal rauer wird ;)
Ich will die Bedenken aber auch gar nicht ganz von der Hand weisen, doch sehe ich die Sache nicht ganz so dramatisch
Ebenso, allerdings kann ich aus meinem Hintergrund eben bereits mehrfache Verstöße anführen, wo es genau solche Bugs und Exploits gegeben hat. Venom für KVM/XEN und Co. waren bspw. ein großes Ausrufezeichen, das genau erlaubt hat, dass eine VM ausbricht aus der Virtualisierung. Wenn das passiert ist das komplette Gefüge kompromittiert und wenn ich dann meine Firewall ebenso virtualisiert habe, dann ist die potentiell eben auch betroffen und gefallen. Wenn aber meine Netze VLAN technisch getrennt sind (auch per Switche etc.) und die Firewall extern/Hardware/etc ist, kann ich dieses Szenario minimieren.
Ja, die Gefahr ist gewiss real, doch halte ich sie bei ordentlicher Konfiguration nicht für sehr groß.
Wie kann ich gegen einen Exploit auf der Ebene "gegenkonfigurieren"? Wenn die HV Schicht kompromittiert ist, ist es eigentlich recht egal was ich konfiguriert habe, da der Eindringling sich Zugriff auf die HV Schicht verschafft hat und damit alles umgehen kann.
Pwn2Own
Jap, das war eine Sache, da war unklar, ob es ESXi betrifft. Intern wurden VMware Partner aber SEHR Nahe gelegt, den Patch einzuspielen, da das Ergebnis auf ESXi "inkonklusiv" war. Soweit ich mich erinnern kann gab es davor oder danach aber nochmal einen ESXi Patch mit Critical/Severe Status, der die VM+Netz Isolation betroffen hat. Aber steinigt mich nicht drauf ;)
Soweit ich das in Erfahrung bringen konnte, nutzt diese ausschließlich eine Schwachstelle im virtuellen Floppy Gerät, das ich wohl noch nie eingesetzt hatte und wenn, dann nur temporär.
Soweit mir das damals bekannt war, war es recht egal ob eingesetzt oder nicht, das Device bzw. die Schnittstelle wurde Huckepack genutzt um Code in die HV Schicht zu bekommen. Zumindest konnte mir das damals jemand problemlos demonstrieren.
Die Beispiele habe ich aber auch nicht zur Panikmache angeführt, sondern lediglich zu dem Punkt, dass diese Angriffe, die beschrieben werden NICHT theoretisch sind, sondern bereits mehrfach praktisch vorgekommen sind. Also muss ich auch zukünftig bei immer komplexer werdenden HVs damit rechnen, dass ggf. solche Attacken auftaucht können. BTW: Venom existierte nach Aussage damals jahrelang ohne dass es jemand aufgefallen war. Zwar war die einhellige Übereinkunft, dass es wohl niemand ausgenutzt hatte, sicher sein kann man aber nicht. Und da das Geschäft mit 0-Days immer mehr angekurbelt wird und nun teils auch durch Staaten selbst genutzt und gefördert wird… nunja. Der Fokus und Blick wird wohl eher stärker und strenger werden und nicht weniger. Wiederum: Keine Panikmache, lediglich der typische Punkt, wenn immer mehr Leute aktiv suchen, steigt einfach die Wahrscheinlichkeit dass was gefunden wird.
Sollten die Sicherheitsrisiken tatsächlich so hoch sein, dürfte generell keine DMZ virtualisiert werden, schon gar nicht eine Firewall, egal ob mit virtuellem Switch oder mit physischem. Denn schließlich hat ja jeder Host auch einen Management-Zugang und ob dieser am selben physischen Interface liegt, spielt bei den hier genannten Gefahren keine Rolle.
Kannst du erläutern was du damit meinst? Ein oder mehrere ESXi haben physikalisch mehrere Netzwerkkarten. Reine Storage Netze, vMotion etc., Frontend, Mgmt, IPMI/Remote. Die sind meist getrennt aufgelegt auf extra Switchen. Lediglich Frontend Netze sind meist viele VLANs auf einem Switch, ggf. bei Storage ebenfalls noch. Aber sonst alles getrennt. Da sehe ich keinen hochgradigen Vektor?
Wie hoch das Sicherheitsrisiko letzten Endes ist, hängt davon ab, was du genau für Daten auf deinen Server hast. Die Gefahr ist eben doch real, aber eher klein. Doch sind es besonders heikle Daten, wirst du hoffentlich nicht die Sache über einen Rootserver realisieren.
Absolut d'accord :)
Für eine professionellere Einschätzung empfehle ich aber einen Virtualisierung-Fachmann, und einen solchen findest du vermutlich eher in einem anderen Forum. ;)
Maybe. Aber ich denke hier gibt es zumindest einige, die auch virtuelle Umgebungen betreuuen. Und da kann man zumindest seine Gedanken und Erfahrungen einwerfen.
Würde ich virtualisieren wenn ich eine andere Möglichkeit habe? Potentiell nein, aber nicht nur aus Sicherheitsdenken, sondern auch aus anderen Punkten (Verfügbarkeit, Komplexität, Auftrennen der Verfügbarkeit, Hardware SLAs etc.). Würde ichs nie machen? Doch, habe ich auch schon. Es hängt eben wie beschrieben immer von den Rahmenumständen ab.
Grüße Jens
-
Hi,
Wie kann ich gegen einen Exploit auf der Ebene "gegenkonfigurieren"?
Gegen einen Exploit, der den Hypervisor kompromittiert, hilft wohl die professionellste Konfiguration nichts.
Die Aussage war auf "normale" Angriffe auf bspw. eine Webapplikation bezogen. Wenn das virtuelle Netz so konfiguriert ist, dass die VM ausschließlich in die DMZ kommt und alles andere von der Firewall gefiltert wird, bleiben normalerweise andere Netzwerksegmente unberührt.
Dabei spielt natürlich auch die Firewall-Konfig eine wichtige Rolle.Pwn2Own
Jap, das war eine Sache, da war unklar, ob es ESXi betrifftBei dem Pwn2Own Hack bin ich mir ehrlich gesagt auch nicht sicher, ob das tatsächlich nur die Workstation betroffen hätte. Das mit den Patches kurz danach habe ich mitbekommen, nachdem ich aber beides nicht verwende, habe ich mich nicht weiter damit befasst.
Hat VMware Schweigegeld bezahlt? Vielleicht hat sich der Job für die Chinesen weit mehr gelohnt, als wir wissen. :oSollten die Sicherheitsrisiken tatsächlich so hoch sein, dürfte generell keine DMZ virtualisiert werden, schon gar nicht eine Firewall, egal ob mit virtuellem Switch oder mit physischem.
Kannst du erläutern was du damit meinst? Ein oder mehrere ESXi haben physikalisch mehrere Netzwerkkarten. Reine Storage Netze, vMotion etc., Frontend, Mgmt, IPMI/Remote. Die sind meist getrennt aufgelegt auf extra Switchen.
Wenn der Hypervisor befallen wird, hat der Angreifer womöglich auch Zugriff auf andere Bereiche wie Management, Storage…
Oder kann ESXi das dennoch derartig trennen?Würde ich virtualisieren wenn ich eine andere Möglichkeit habe?
An der Virtualisierung kommt heute kein Netzwerkbetreuer mehr vorbei. Ich hatte mich anfangs auch dagegen gewährt, aber dann auch die Vorteile der Technik erkannt. Doch habe ich weder eine gesamte virtualisierte Netzwerkumgebung noch eine virtualisierte Firewall im Produktiveinsatz.
Grüße
-
Solche Threads laufen hier meisten darauf hinaus, dass der TO raus geprügelt wird und dass ihm jeglicher Spaß an der Virtualisierung verdorben wird.
Das halt ich für ein Gerücht. Hier wird niemand verprügelt oder wem der Spaß vergällt. Man muss aber offen diskutieren dürfen auch wenns mal rauer wird
Auch wenn es kurz Offtopic ist, dass stimmt wirklich und ich fühle mich hier im Forum als nichtprofi wirklich sehr gut aufgehoben und wollte dies mal als Anlass nehmen danke zu sagen für die schnelle, geduldige und hervorragende Hilfe die ich hier immer bekomme!
-
An der Virtualisierung kommt heute kein Netzwerkbetreuer mehr vorbei. Ich hatte mich anfangs auch dagegen gewährt, aber dann auch die Vorteile der Technik erkannt. Doch habe ich weder eine gesamte virtualisierte Netzwerkumgebung noch eine virtualisierte Firewall im Produktiveinsatz.
Das würde ich in weiten Teilen sicher auch abnicken. Mein Problem bei Virtualisierung von Firewalls (oft! nicht immer!) ist, dass es sehr gern als billiges Geld-spar-Argument kommt. Hey wir haben doch schon VMs hier, dann packen wir das noch rauf. Gekoppelt meist noch mit Unwissen, was das für Probleme oder Nebenkriegsschauplätze aufmachen kann. Oder eben ohne sich anderer Risiken bewusst zu sein.
Wo hab ich das schon gut gesehen? Bei bspw. Setups, die für Firewalling/Security eigene Hardware oder eigenen Cluster nutzen, um Firewalls zu virtualisieren. Wenn dann quasi nix anderes da drauf läuft und die VM Schicht zur Vereinfachung von Setup/Parallelisierung/Automatisierung etc. eingesetzt wird, kann man da richtig coole Setups bauen. Und da bin ich dabei :D
-
Bin auch noch da und fühle mich jetzt nicht rausgeprügelt. ;D
Ich denke meine Frage wurde mehr oder weniger beantwortet. ::)Danke
-
Wo hab ich das schon gut gesehen? Bei bspw. Setups, die für Firewalling/Security eigene Hardware oder eigenen Cluster nutzen, um Firewalls zu virtualisieren. Wenn dann quasi nix anderes da drauf läuft und die VM Schicht zur Vereinfachung von Setup/Parallelisierung/Automatisierung etc. eingesetzt wird, kann man da richtig coole Setups bauen. Und da bin ich dabei :D
Haben wir genau so im Einsatz ;)
Zwei dedizierte Dell R320 1HE Server auf denen ausschließlich der UTM-Cluster werkelt. Hintergrund waren schlichtweg Support/Kostengründe. Die Dell Server waren günstiger, leistungsfähiger und boten einen besseren Supportvertrag als die Hardware, die uns der UTM-Anbieter anbieten konnte.
Das dann die UTM-Software auf einen Hypervisor (VMWare vSphere) installiert wurde hat einfach den Hintergrund, dass der UTM-Anbieter sich etwas kleinlich mit dem Support anstellt. Supportet wird ausschließlich die eigene Hardware oder eben die UTM als VM unter vSphere/Hyper-V.
Und wir legen hier im Unternehmen wirklich Wert auf eine supportete Systemumgebung!Eine FW als VM mit auf die Produktiv-Hosts zu legen würde mir in der Firma nicht mal im (Alb)Traum einfallen. :o
-
Ich denke meine Frage wurde mehr oder weniger beantwortet. ::)
Super :) Pros und Contras sind denke ich immer wichtig :D
Haben wir genau so im Einsatz ;)
Zwei dedizierte Server…Ich darf zwar noch nichts Offizielles verlauten lassen, aber ich habe läuten hören, dass es an so einer Front (also Hardware mit Mini/Mikro-HV-Schicht) und mit *Sense und anderen Lösungen ggf. im Laufe des Jahres noch ein paar spannende Lösungen und News gibt ;)
