ESX / ESXi - Hilfethread

Ja, wenns die HW net kann, gehts net. Ansonsten sind NICs das umkomplizierteste, was es gibt in dem Bereich.

@ASG (im Bereich Security durchaus, im Bereich Routing sicherlich nicht, das sind Router (wie eben der Ipfire) besser aufgestellt)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Gleiches gilt auch für Cable Anschlüsse.

Überall da, wo vorher kein Router sitzt, hast du eine öffentliche IP Adresse. Daher macht ja auch ein IPFire und Co auch erst Sinn, da das Teil direkt im Inet steht und so die volle Bandbreite an Diensten bereitstellen kann. (rot=Inet Interface)
 
Naja bei nem ESXi der direkt im WAN hängt (wie bei meinem alten Arbeitgeber) ist die Gefahr bei einem Zero Day Exploit nicht ohne... Mich wunderts, dass da noch nix passiert ist - oder es noch keinem aufgefallen ist...

Ich persönlich würde es nicht mehr machen - wenn ich überlege, dass aufgrund von 2 Verwundbarkeiten unter Suse damals 5 unser Linux Kisten von Chinesen (also auch China) hops genommen worden sind...
 
Da sehe ich auch das Problem. Es ist im Moment nur solange sicher, bis irgendwer mal ne Schwachstelle findet. Und dann geht es aber los.

Wenn aber die NIC durchgereicht ist, dann ist es ist es schon schwerer da was zu machen. Daher auch die Listen oben.
Letztendlich muß jeder für sich entscheiden, was ihm die Sicherheit wert ist. (an Aufwand und Gerätschaften)
 
Wenn die VM über das VM Net Interface ins WAN geht, dann hängt der ESX automatisch mit dran.

Dies wäre dann der Fall, wenn man das DSL Modem ins LAN hängt und eine VM eine PPPoE machen läßt. In dem Fall liegt unter der WAN Verbindung das LAN Interface und damit ist der ESX, mehr oder minder im WAN.

Anders sieht es aus, wenn man eine dedizierte NIC in die VM schiebt. Dort ist die PPPoE nicht mehr mit dem Interface des ESX verbunden. Problem ist nur, es besteht prinzipiell die Möglichkeit Speicherbereiche des passthrough zu attakieren, welche dann einen Zugriff auf den ESX bieten könnten.
 
Dann hängt die VM im WAN, aber nicht der ESXi mit seinen 23452345 Services.
 
Doch tut er, da unter der PPPoE die Verbindung des ESX läuft. (Abstraktionsschicht)

Die PPPoE kann ohne die ESX LAN Verbindung nicht existieren, oder?

Damit ist nicht gemeint, dass der ESX direkt auf dem WAN erreichbar ist. Dennoch sind hier Speicherbereich des ESX direkt beteiligt.
 
von einer vm auf den host und damit ins daran liegende netzwerk zu kommen ist schon eine große hürde.
ich dachte die asg v8 war nur eine testversion zwecks look&feel ??? oder bietet jetzt sophos die .vmx zum verkauf an :d

sicherlich lässt sich der host erreichen sobald man es ins lan geschafft hat. soweit ich weis wurde die maintenance-console von vmware abgeschafft gerade um diese lücke nochmehr zu schließen.

an einer baremetal firewall kommst nicht drum rum wenn du sicherheit haben möchtest. und sooo teuer sind die nicht, wenn du nicht gerade jeden scheiß darin lizenzieren willst :d
 
Zuletzt bearbeitet:
Für den gemeinen Anwender bringt Ipfire und Co keinen Vorteil gegenüber einem normalen Router.

Und ja, die machen grundsätzlich NAT, was anderes würde im Internet auch garnicht funktionieren. Es gibt grundsätzlich für jeden Anschluß nur eine IP Adresse, daher muß alles andere über NAT laufen.

Wieso macht ein Router grundsätzlich NAT? ;)
Es mag vllt sein, das per default IPFire, IPCop und Co. so eingestellt sind, das diese ihre internen Netze (Grün, Orange, Blau, weis der Teufel, wie es dort so schön heist) auf das Rote WAN Interface via NAT umsetzen.
Dennoch kann das Teil auch einfach nur routen, wie man es von einem Router verlangt.

Das man natürlich bei nur einer WAN IP am INet Anschluss grundsätzlich via NAT Arbeiten muss, ist aber richtig. Heist aber nicht, das es die Firewall Appliance sein muss, welche NAT macht. Eine Appliance davor/dahinter wäre dazu auch in der Lage. Wobei davor wenig Sinn macht :fresse:, dahinter schon mehr, sprich zwischen WAN und Firewall eben nen billigen Customer Router. Und dann den Router und die Firewall Appliance via Transitnetz koppeln. Das schließt so ziemlich alle Sicherheitslücken, die potentiell durch den Virtualisierungshost aufkommen können mit einem mal. Wichtig ist nur, das die Router Kiste dahinter eben genügend Bums liefert.

Naja, ASG ist eigentlich die EierlegendeWollmichsau und kann auch routen

Ich hoff bei Sophos versauen die nix :d

Was soll Sophos da kaputt machen?
Das Featurefucking, was man bis dato betreibt, bringt zwar in Mini Umgebungen nette Services ans Licht. Für größere Umgebungen funkt das aber so absolut gar nicht... Was wir auf der Arbeit schon für Probleme damit hatten, geht auf keine Kuhhaut.
Von fehlender Multicore Unterstützung der Software selbst (die größeren ASGs haben 2xQuadcore CPUs, welche zum Teil nicht auslastbar sind) über allgemeine Performanceprobleme, abschmierende Dienste, irgendwelche Workaround Patches, welche woanders wieder riesige Löcher aufreißen usw.

Bei uns geht das sogar soweit, das Astaro selbst bzw. jetzt Sophos ihre neuesten Firmware Releases für spezielle Kunden von uns dediziert freigeben. Einfach aus dem Grund, weil die selbst nicht wissen, ob in größeren Umgebungen der Spaß überhaupt tut. Im Moment fahren wir beispielsweise noch die 8.303 bzw. 8.305. Die V9 ist nichtmal im Ansatz freigegeben ;)

Gleiches gilt auch für Cable Anschlüsse.

Überall da, wo vorher kein Router sitzt, hast du eine öffentliche IP Adresse. Daher macht ja auch ein IPFire und Co auch erst Sinn, da das Teil direkt im Inet steht und so die volle Bandbreite an Diensten bereitstellen kann. (rot=Inet Interface)

Ja soweit schon klar. Nur warum sollte man sich das antun? Ich mein, die Sicherheitslücken, welche potentiell aufkommen kann niemand überschauen. Mit so nem Konstrukt erkauft man sich glatt mal 100% mehr Sicherheitsrisiko, weil doppelte Angriffsfläche (Firewall Appliance + Virtualisierer)
In meinen Augen gab es doch so viele Beispiele schon, wo die Nutzer dachten, sie wären sicher, und dann hats geknallt :fresse:
Jüngst war doch mal ein Virus für Apple MACs unterwegs. Wo niemand auf nem MAC auch nur nen Virenscanner in Betrieb hat ;) Weil man dachte, es wäre auch so sicher... -> Beispiel.

von einer vm auf den host und damit ins daran liegende netzwerk zu kommen ist schon eine große hürde.

Das ist die falsche Sichtweise...
Die Hürde ist nicht größer als bei anderen Angriffspunkten. Man könnte ganz einfach (als Beispiel) sich in den IP Stack einklingen und die Datenpakete verfälschen. Alles was im Klartext durchläuft, wäre somit mitlesbar.

Es ist ja nicht so, das der Angreifer zwingend und immer nur auf den jeweiligen Rechner drauf will. Oft gehts da doch um ganz andere Sachen.
Aber wie underclocker schon ansprach, jedem ist zum Glück selbst überlassen, wie stark er sich versucht gegen mögliche "Angriffe" abzusichern.

Im Grunde kann man auch die Firewall ganz weglassen, denn der potentielle Angreifer wird sich mit größter Warscheinlichkeit nicht in IP Adressbereichen von privaten INet Anschlüssen bewegen. Und unterm Strich ist die nächste Schwachstelle auch immer die Layer 8 Ebene des OSI Modells. Vor Dummheit des Users schützt die beste Firewalllösung nicht ;)
 
aber nicht der ESXi mit seinen 23452345 Services.

Doch tut er
Damit ist nicht gemeint, dass der ESX direkt auf dem WAN erreichbar ist.

Ja was denn jetzt?!

ESXi im WAN = Die API hängt im WAN, die Management-IP-Adresse hängt im WAN.

VM im WAN = Das Layer2-Segment des ESXi ist maximal vom DSL-Modem erreichbar. Auf Layer3 ist nichts erreichbar, was dem ESXi gehört. Da müsste man schon auf Layer3 einen Exploit finden, mit dem man der VM irgendwelche Pakete schickt, die dann irgendwie den vSwitch des ESXi beeinflussen.

Edit: Von so einem Exploit habe ich bis jetzt noch nie gehört. Maximal waren das spezielle Ethernet-Frames, mit denen der vSwitch aus dem Tritt kam.
 
Zuletzt bearbeitet:
Ja was denn jetzt?! Widersprichst du nur aus Prinzip, um dann von ganz anderen Voraussetzungen auszugehen? Langsam nervts.

Er meint nicht die Servicekonsole, sondern allgemein die Dienste.
Es geht schlicht und ergreifend darum, das der ESX(i) Dienste bereit stellt, welche via LAN erreichbar sind, und welche dazu noch potentielle Sicherheitslücken aufweisen können.
Es kann dir niemand garantieren, das das Konstrukt mit der logischen Trennung der physischen Netzwerkkarten so sicher ist, es ein Angreifer nicht die Möglichkeit hat, daran anzusetzen.

Es ist nunmal einfach ein ungeschriebenes Gesetz, das man eine Sicherheitslösung ala Firewall so aufbaut, das diese nichts weiter macht, als eben Firewall sein. Und das vom tiefsten Punkt der Hardware bis hin zur obersten Ebene der Software.
Als VM kann diese Lösung aber nicht bis auf die Hardware runter absichern, einfach weil der ESX bzw. allgemein, der Virtualisierungshost dort seine Finger drauf hat. Ist das ganze angreifbar (und ich gebe dir Brief und Siegel, es ist angreifbar!, da Software nie 100% fehlerfrei ist) nutzt dir die beste Firewall nix. Einfach weil der Angreifer an der Firewall vorbei agieren kann.

Beispiel: dieses virtuelle Interface, was der ESX bereit stellt, ist angreifbar, via Treiber oder weis der Teufel irgendwo. Schon kommt der Angreifer vor der Firewall ins System, und hast die Möglichkeit Schadcore auszuführen, welcher dann optimalerweise den ganzen Host untergräbt, bestenfalls sogar noch die Firewall VM gänzlich aushebelt und somit Tür und Tor Meterweit aufreißt.

Schützen kann man sich davor eben nicht. Außer eben, die Firewall als Single Appliance vor die eigentliche Hardware zu stellen.
Noch dazu kommt, das die meisten Leute nichtmal mitbekommen, das das System untergraben ist. Clevererweise verhält sich der Angreifer so, das er nicht erkannt wird ;) Für den User läuft alles schön weiter, der Angreifer hat aber alle Möglichkeiten.
 
Er meint nicht die Servicekonsole, sondern allgemein die Dienste.
Es geht schlicht und ergreifend darum, das der ESX(i) Dienste bereit stellt, welche via LAN erreichbar sind, und welche dazu noch potentielle Sicherheitslücken aufweisen können.
Definiere mal bitte "Dienste" im Kontext einer VM, die an einem vSwitch hängt, welcher an eine NIC geklemmt wird, an der z.B. ein DSL-Modem hängt. Auf diesem vSwitch gibt es keine Layer3-Dienste. Es gibt Ethernet-Frames (Layer2) vom Modem zur VM, die ein Angreifer aus dem Internet nicht beeinflussen _kann_. Er kann die öffentliche Adresse der VM ansprechen. Da laufen auch keine Dienste.

Er müsste also IP(!)-Pakete zur VM schicken, die von dieser zwar per ICMP Port unreachable oder TCP RST abgewiesen werden bzw. einfach blackholed werden, aber trozdem den unterliegenden vSwitch beeinflussen.

Das will ich sehen. Mit Passthrough ist dann sogar der vSwitch aus der Rechnung raus.

Edit: Ich verstehe natürlich den gedanklichen Ansatz, dass physikalische Trennung immer am besten ist. In Zeiten von 100Mbps-Leitungen - und was da noch alles kommt bis zu Gbps hin - bräuchte man aber immer stärkere separate Rechner als Router/Firewall, wenn man sich nicht auf Consumer-Blackboxen verlassen will. Ich weiß für mich, dass mir ein virtualisierter Router komplett reicht zu Hause.
 
Zuletzt bearbeitet:
aktuell ist mir nichts bekannt, sprich ich wüsste aus dem Hut nicht, das es mit aktuellem Wissen möglich ist, dort anzusetzen ;)
Aber darum gings ja auch nicht, es ging viel eher darum, das es ungewiss ist, das an der Schnittstelle nicht irgendwie mal eine Lücke aufgedeckt wird. Man schaue sich doch nurmal die Patchlisten und Securityfixes seitens VMware an. Da ist bei weitem nicht nur reines Bugfixing oder Featuresupport inbegriffen, da gibts genau so wie bei nahezu allen Betriebssystemen am Markt alle Nase lang ein paar Securityfixes.
Sicherheitslücken sind also wie schon angesprochen immernoch vorhanden. Nur müssen diese erst aufgedeckt werden, bevor man sie fixen kann.

Auch wäre zum Beispiel denkbar, das ein Angreifer sich über den Treiber der NICs oder über die VMware Tools Tür und Tor öffnet.

Eigentlich gibts an dem Thema nichts zu diskutieren. Jeder muss selbst seine Risikobereitschaft einschätzen und agiert danach. Fakt ist aber, der Virtualisierungshost auf dem die Firewall VM läuft, bringt ein um 100% erhöhtes Gesamtrisiko ins Haus, woran die Firewall absolut rein gar nichts beeinflussen kann.

PS: zum Thema "Auf diesem vSwitch gibt es keine Layer3-Dienste."
Wer garantiert dir die Funktion der logischen Trennung? Die Firewall kann dies definitiv nicht ;)
 
@TCM
Ich widerspreche nicht, ich sage nur, wie sich die Sachlage darstellt. Desweiteren ändere ich auch nicht die Vorraussetzungen. Ich beziehe mich, wie jeder andere auf die Umstände, die hier bezüglich der Möglichkeiten der Nutzung von Firewalls genannt wurden.

Aber es ist natürlich klar, nur weil DU noch nichts von einem Exploit gehört hast, so ist auch keiner existent und wird auch nicht existieren.

Früher hat man es auch nicht für möglich gehalten, dass man fliegen wird. Genausowenig wie man es für möglich gehalten hat, dass man mehr als 640kb RAM braucht. Und bei genau diesen Tatsachen ist es geblieben. Kein Mensch auf diesem Planeten fliegt und kein Rechner hat mehr als 640kb RAM. :rolleyes:

Evtl solltest du dich mal mit Sicherheitstechniken beschäftigen. Man geht dort immer vom Worstcase aus, bedenkt alle Möglichkeiten, so gut es nur geht.
 
Zuletzt bearbeitet:
Hallo,

ich entschuldige mich für den Start der Diskussion, wir sollten nicht den ESXi-Thread damit zerstören.
Nach den hier gelesenen Informationen ist nun geplant, der VM die Nic physisch durchzureichen, den Telekomrouter davor zu belassen. Es ist also noch ein Transfernetz dazwischen.
Laufen soll auf der virtuelle Firewall Squid etc, gesichert würde das Netz schon vom Telekomrouter. Augenblicklich kommt nach dem Telekomrouter garnichts weiter an Schutz. Ausser einigen Portweiterleitungen bietet das Teil leider keinerlei Komfort, daher soll ein zw. internem Netz und Router geschalteter ipFire für zusätzlichen Komfort sorgen.
Stimmt mein Gedankengang?

Gruß Millenniumpilot
 
passthrought ist schonmal sicher als VMNet und das wiederum (mit ner Firewall) ist sicher als ganz nakt.

Wichtig ist, dass du die Ports eben für die externen dienste des IPFire weiterleitest, sonst tut sich da nix.
 
@millenniumpilot
so kann man es machen. Ich würde, sofern du dir das so zutraust dann auch das NAT so umkonfigurieren, das der Speedport "dich" ins INet NATet. Und du eben die Firewall VM einzig als Firewall und ggf. noch Proxy nutzt.
Es kommt aber auf den Speedport an, ob der sich statische Routen auf der private Seite einkonfigurieren lässt. Wenn nicht, musst du wohl doppelt NATen.

@underclocker, was meinst du mit "auf die externen Dienste des IPFire weiterleitest"?
 
ich dachte die asg v8 war nur eine testversion zwecks look&feel ??? oder bietet jetzt sophos die .vmx zum verkauf an

Die VM ist voll funktionstüchtig und lässt sich auch mit den normalen Lizenzen betreiben. Kein unterschied zur HW Appliance. Bis auf die kleinen "Sorgen" mit der Sicherheit des Hypervisors...

Im Moment fahren wir beispielsweise noch die 8.303 bzw. 8.305. Die V9 ist nichtmal im Ansatz freigegeben

Nice 2 know :)

Wenn ihr mit den Gedanken spielt eure Firewall-Lösung zu virtualisieren, dann lest doch bitte noch folgenden Text:

www.ipcop-forum.de :: Der (Un)IPCop

Wenn man das so liest deckt sich das doch mit den Sorgen der Mods hier, d.h. wenn schon dann die WAN Verbindung direkt in die VM durchreichen. Wenn ich die weiterführenden Links sehe bedeutet das aber auch dass die VM erstmal kompromittiert werden muss damit da ausgebrochen werden kann. Wenn aber nun IPCop oder Astaro oder was auch immer die erste Lücke ist, dann hilft's auch kaum wenn dies auf eigener HW läuft. Oder etwa nicht?

Edit2:
Der Editor hier ist n Krampf mit Opera ;-)
 
Zuletzt bearbeitet:
ich weis dass die vm voll funktionstüchtig ist da ich die v8 testen musste bevor sie bei uns live ging ;) damals war es eine testversion fürs look and feel. wenn sich das jetzt geändert hat unter sophos dann sry...
aber es ist sicher nicht angedacht diese als "firewall" einzusetzen. man kann damit intern sicher schön routen und spielchen treiben.

wie gesagt, wegen der sicherheit hat vmware auch die console entfernt....

jetzt war noch was zwecks "sophos shice oder sowas^^" ehm das stimmt schon. ich denke auch nicht dass sophos astaro secure gateway für große firmen >500 user gedacht ist ;)

aber alles in allem die antwort: als firewall doch bitte baremetal...
 
Das war schon vorher so... man konnte die VM tatsache fürs testen nehmen, aber auch mit ner gültigen Lizenz betanken...
 
jetzt war noch was zwecks "sophos shice oder sowas^^" ehm das stimmt schon. ich denke auch nicht dass sophos astaro secure gateway für große firmen >500 user gedacht ist ;)

Neja, dennoch gibt es sizing Guides, welche eben genau dafür gedacht sind. Und da ist bei 500 Usern lange nicht schluss. Die Dicken Lokationen, welche wir betreuen haben 5000+ Connections gleichzeitig ;) Laut Astaro ja alles kein Problem, parktisch? Quasi mit selbst 2x625er AGSs gerade mal so im Active/Active Clusterbetrieb machbar. Und selbst das ist noch lahm...
Laut Astaro reicht da sogar ne Single 525er wenn mich nicht alles täuscht. Bzw. eben zwei im Active/Passiv Betrieb.

Wir haben sogar bei ganz paar Standorten der über 150 Weltweit in Summe von Astaro noch kostenfrei die Active/Active Lizenzen bekommen, weil sie eingesehen haben, das ihr sizing Guide nicht passt :fresse:
Und über die Versionen hinweg wird das halt immer schlimmer, da immer mehr Featurefucking betrieben wird... Es kommen mehr Ressourcenfressende Features hinzu.

Bei uns lokal im Office schafft es selbst ne dicke 625er ASG nicht, gleichzeitig Mailgateway + Proxy zu spielen. Sobald man diese beiden Sachen miteinander koppelt sprich einschaltet, lässt sich über den Proxy kein Download von großen Files durchführen. Weil der Downloadvorgang immer abbricht.
 
Zuletzt bearbeitet:
@ fdsonne
hmmm ja das klingt nach asg ;) widersprichst du dir in deinem eigenen post ?
und die ansage klingt mehr nach sophos, wie du schon sagtest, die 2 dicken brechen gerne schnell ein. das sind alles bekannte sachen, daher die aussage >500 und dabei bin ich von einem asg ausgegangen, noch kein load-balancing oder ha...
bei ner fw die was kann will ich ja auch die feature benutzen die ich auch lizenziert habe und nicht nur als fw benutzen oder ? ;)

@mueder joe
ok hab ich nicht gewusst aber trotzdem für mich eher unrelevant da, wie schon gesagt, fw immer bm ;)
bitte ein admin der sein wan-lan mit ner vfw schütz *hust*
 
Zuletzt bearbeitet:
Also ich werds wohl tun, zumindest für mich zu Hause ^^
Und damit es zum Thema passt, wenn dann kommts auf nen ESXi :d
 
@ fdsonne
hmmm ja das klingt nach asg ;) widersprichst du dir in deinem eigenen post ?
und die ansage klingt mehr nach sophos, wie du schon sagtest, die 2 dicken brechen gerne schnell ein. das sind alles bekannte sachen, daher die aussage >500 und dabei bin ich von einem asg ausgegangen, noch kein load-balancing oder ha...
bei ner fw die was kann will ich ja auch die feature benutzen die ich auch lizenziert habe und nicht nur als fw benutzen oder ? ;)

Das musst du mir erklären? Was widerspricht sich?

ASG ist die Abkürzung für Astaro Security Gateway. Das ist vor Sophos die Bezeichnung gewesen. Mittlerweile schimpfen sich die Teile UTM soweit mir bekannt. Ob es schon alle Leistungsklassen im neuen Standard gibt, weis ich aber nicht... Ich bin seit V7 in der Firma tätig, auch wenn ich primär damit weniger zu tun habe, bekommt man so einiges mit. Und das war weit vor Sophos ;) Das Sizing hat sich dahingehen nicht wirklich verändert. Passen tut es aber immernoch nicht.
Und der Activ/Passiv Betrieb ist vergleichbar mit ner Single Appliance, eben weil die zweite nur einspringt, wenn die erste ausfällt. Activ/Activ hingehen heist, zwei Geräte arbeiten... Das macht man genau dann, wenn die Leistung einer Appliance nicht ausreichend ist. Offenbar stimmt da also am Sizing was nicht... Der der Guide schreibt explizit was anderes.


Und zum letzten, ja genau das ist der Punkt. Das Problem ist eben die Eierlegende Wollmilchsau Metalität von Astaro... Das Teil kann im kleinen wirklich gut sein. Im großen und ganzen, sprich nutzt man wirklich mal die Funktionen aus, fährst du dich schneller an die Wand, als dir lieb ist.
 
Zuletzt bearbeitet:
Hi Leute,
Ich brauche eure Hilfe.

Ich habe hier meinen kleinen Server stehen auf dem ESXi 5 läuft.
Leider verliert der nach mehreren Tagen immer an Netzwerkperformance.
Wenn ich dann einen Neustart durchführe funktioniert alles wieder mit voller Geschwindigkeit.
Natürlich ist das lästig, besonders wenn ich immer von Hand neustarten muss.

Meine Frage:
Kann ich in ESXi eine Startroutine erstellen, so dass der Server alle paar Tage bzw. jeden Tag zu einer festgelegten Zeit neu startet?

Danke im Voraus.
MFG
Chrilly-X
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh