napp-it in sicheres vLAN verfrachten

[AliManali]

Hi

Ich habe im Moment napp-it in meinem "LAN" (vLAN). Nun möchte ich die NFS und SMB Freigaben mit den VMs in ein eigenes vLAN verfrachten. Ich habe jetzt einen neuen VMKernel, einen neuen vSwitch und eine neue Portgruppe im ESXi erstellt. Ausserdem habe ich den VMKernel Port bereits direkt mit der Firewall verkabelt und alle Ports an der Firewall dementsprechend konfiguriert. Omg, was für ne Zangengeburt, bis ich wieder überall in meinen zahlreichen vLANs war, aba egal.

Im Moment ist es so, dass DMZ auf nem physischem Gateway läuft, und ich noch zwei vLANs auf Zone LAN2 habe, welche über den Switch verkabelt sind. Nun stellt sich mir die Frage, bzw. so habe ich schon angefangen zu basteln, ob ich auf Zone 1 ein Management Network aufbaue, wo zu aller erst mal die napp-it Geschichte rein soll. Allerdings hat mir mal ein Zywall Guru gesagt, dass das gewünschte Management Network besser bzw. korrekt ein vLAN in der DMZ wäre. Das wollten wir auch so einrichten, allerdings ist das daran gescheitert, weil sich mein Switch Admininterface irgendwie nicht in ein vLAN packen lässt, so weit ich mich erinnern kann. Da muss ich auch immer mit dem Laptop ran beim Switch, aber den tangiert das ganze hier nicht, weil ich DMZ und den neuen VMKernel wo napp-it rauf soll direkt zwischen Firewall und den Servern verkabelt habe.

• Soll ich das vLAN für NFS und SMB jetzt in der DMZ oder in einer der LAN Zonen machen? Oder ist das wumpe?
• Und kann ich auch dort noch mehr rein schmeissen, z.B. Firewall-, vSphere, Filer, wass weiss ich- Zugang?
• Wie handhabt Ihr das so?
• Wenn netzwektechnisch alles steht, wie switche ich dann? Alle VMs entfernen, Adapter wechseln, NFS Freigaben hinzufügen, die VMs wieder einhängen, und weiter gehts?

Gruss, schönes Wochenende und danke!

 

[Digi-Quick]

Management Network (VLAN) in die DMZ, AHA .....
Damit Hacker das einfacher haben....

 

[AliManali]

Hab ich mir auch gedacht. Drum hab ich jetzt ja mal wie gesagt in der LAN Zone 1 angefangen. Das hat mir da mal der Typ gesagt, wohl weil wenn man dann von aussen darauf zugreifen soll und das daher in die DMZ beregelt. Das war glaub ich der Hintergrund. Ist ja eh ein eigenes vLAN. Er macht das wohl so.

Meiner Meinung nach macht da wohl beides Sinn, bei mir wohl mehr die LAN Variante.

Brauchst deswegen nicht Deinen roten Kopf gegen die Wand knallen. Ich bin kein Pro, möchte nur mein napp-it ausm LAN haben. Damit es die Hacker nicht so einfach haben, ja.

Hast Du irgendwie schlechte Laune?

 

[fdsonne]

Management Network (VLAN) in die DMZ, AHA .....
Damit Hacker das einfacher haben....

Hä? Was sollen die Hacker da einfach haben?

DMZ heist lediglich demilitarisierte Zone. Im Netzwerksprech ist das schlicht und ergreifend ein Bereich mit kontrollierten Zugriffen. Man verwendet DMZ(s) dort, wo es darauf ankommt, Zugriffe in/aus diesem Bereich vom Rest abzuschotten. Also exakt das, was der TE erreichen möchte.

Lass ich mal nicht vom Fritzbox-Sprech verwirren. Irgendwelche findigen Hersteller nutzen hochtrabende Begrifflichkeiten für etwas, was damit eigentlich nichts zu tun haben. Und die Leute denken dann, das wäre DIE Definition. So einiges davon bürgert sich in der Zeit auch ein - wie eben, dass eine DMZ irgendwas wäre, wo der "Hacker" hin kommt... Was schlicht und ergreifend quatsch ist. Im Grunde ist nach der reinen Definition sozusagen jeder Netzbereich mit Zugriffsregeln eine DMZ. Fängt man an, Zugriffe zu reglementieren, erfüllt das reglementierte Netz die Spezifikation einer DMZ. Selbst any, any, allow wäre theoretisch sogar noch als DMZ zutreffend, denn auch das wäre formal eine spezifizierte Zugriffsregel. Das stumpfe Routen absolut ohne jegliche ACL/Firewall Geschichte hingegen wäre keine DMZ



@AliManali
Wie du das am Ende machst, musst du natürlich selbst wissen - man muss sich dabei natürlich auch immer frage, welchen Sinn das hat und vor allem, ob sich der Aufwand lohnt. Im privaten Umfeld wird kein "Hacker" kommen und dir das Netz auseinander nehmen. Da gibts meist eh nix zu holen.

Um sich dennoch vor Zugriffen zu schützen legt man einfach alles an MGMT IPs in ein separates IP Netz. Dieses Netz trennt man sauber vom Rest der Umgebung. Mit physisch getrennten Komponenten (Switches) oder eben per VLAN Trennung. Der Firewall gibt man dann ein Bein in diesem MGMT Netz und lässt die Zugriffe da rein/raus ausschließlich in einer genau definierten Art und Weise zu. Also nur aus dieser und jenem Sourcebereich, nur zu diesem und jeder Destination und auf nur diesem und jenem Port.
Dein Hypervisor bekommt dann zudem einfach ein Kernel Port in diesem VLAN, nebst IP zur Anbindung der NFS Shares und fertig ist die (per Definition) DMZ.

Wie du das Konstrukt dann am Ende schimpfst, ist nebensächlich. Schimpf es DMZ, schimpf es Management Netz, schimpf es altes Stuhlbein - völlig egal.



Bedenke allerdings, wenn du von SMB sprichst, dass du dann wohl den Traffic, den du erzeugst bei Zugriff auf die SMB Freigaben eben entsprechend über die FW schickst. Sprich für höhere Durchsätze braucht das Ding auch entsprechend Bumms, sonst schläft dir der Zugriff ein.

Ich bin übrigens der Meinung, dass das wenig Sinn ergibt, was du da vor hast, weil der Aufwand für etwas, was dich im Fall der Fälle vor nichts schützt, irgendwie unnötig ist. Wer soweit rein kommt, dass er in deinem internen LAN Bereich "ist", der hat von dort aus auch alle Möglichkeiten weiter zu kommen. Ob du da jetzt ne VLAN Trennung vor nimmst oder nicht. Schafft er es von "außen" über die FW ins LAN Zu kommen - warum sollte er es nicht auch vom LAN über die selbe FW in das Management LAN schaffen? Irgendwelche Zugriffe von LAN in dieses Managment Netz wirst du ja aufmachen - und sei es nur SMB für die Shares. Das Abschotten bringt dir keinen Schutz, wenn der Spaß dann eh erlaubt wird per Regel. Der Sinn hinter dem Vorhaben rrschließt sich mir persönlich so leider absolut gar nicht...

Was viel eher Sinn ergibt, ist das Abtrennen der Netzbereiche, die perse als eher unsicher gelten von dem Rest, den man als sicher erachtet um dort eine Art Übersprechen zu verhindern. Des weiteren könnte man zur Erhöhung der "Sicherheit" an derartiger Stelle bspw. über das PVLAN Feature nachdenken. Richtig konfiguriert unterbindet es das Sprechen zwischen Clients im selben Netz. Gerade im MGMT Netz ist das selten bis gar nicht notwendig, selbst intern eher wenig häufig anzutreffen. Ich wüsste nicht an welche Stelle meine Clients untereinander direkt Daten austauschen müssten. Verhindert man das aktiv auf der Netzwerkseite, sinkt das Risiko, dass sich Schadcode netzintern weiter verbreitet - und anständig abgeschottete Netzbereiche werden das Übersprechen in andere Netzwerke verhindern (können). Ggf. lässt sich da sogar was mit einer Firewall User Authentication oder ähnlichem durchführen. Also dass Zugriffe IN den geschützten Netzbereich erstmal manuell frei geschaltet werden müssen.


Ach und bitte ließ dich nochmal in die Begrifflichkeiten ein - der mittlere Textabschnitt ist so derart verwirrend geschrieben - das ergibt so effektiv überhaupt gar keinen Sinn.
Bspw.:
- m Moment ist es so, dass DMZ auf nem physischem Gateway läuft
- ich noch zwei vLANs auf Zone LAN2 habe, welche über den Switch verkabelt sind
- ein vLAN in der DMZ wäre
- Switch Admininterface irgendwie nicht in ein vLAN packen lässt
- weil ich DMZ und den neuen VMKernel wo napp-it rauf soll direkt zwischen Firewall und den Servern verkabelt habe

-> was möchte das aussagen?
Du mischt hier leider phyikalische Themen wie die Verkablung von irgendwelchen Geräten mit logischen Themen und paarst das dann noch mit (scheinbar, so denke ich zumindest) Begrifflichkeits-Eigenarten, die dein Firewall Gerät da in den Raum stellt. Es scheint mir, dass deine FW da irgendwo "Zonen" hat - unter anderem eine DMZ Zone oder LAN Zonen. Unterm Strich sind das aber drei idR getrennte paar Schuhe.


PS:
für eine Hilfestellung derartiger Themen ist eine Schematische Darstellung in Form eines Netzwerklayouts oder Plans übrigens sehr begrüßenswert.

 

[gea]

Prinzipiell ist es so, dass der NFS, SMB und napp-it Webserver an allen Netzwerkkarten antworten. Ein Zugriff aus dem "bösen" Internet sollte tunlichst unterbleiben oder per VPN Tunnel erfolgen.

Hat man ein "böses LAN" bei dem man im lokalen Netz extra Sicherheit braucht, kann man

- Per Firewall den Service Zugriff per Netzwerkkarte einschränken
- Den Zugriff auf napp-it auf einzelne IP begrenzen

Insbesondere NFS3 bei dem man ohne Authentifizierung und Authorisierung arbeitet muss im LAN dann verboten sein. Will man keine Firewall konfigurieren, bleibt nur ein sicheres Management/SAN Netz, im Zweifel sogar eine eigene NFS Storage Session für VMs und eine weitere für SMB Filerdienste bei denen Netzwerkkarten nur im jeweiligen Zielnetz liegen.

Ein physikalisches Netz bei dem man unterschiedliche IP Bereiche nutzt, bietet begrenzte Sicherheit und gute Sicherheit jenseits des nächsten Routers sofern der nicht übernommen werden kann.

 

[konfetti]

Danke fdsonne!

Schade, das der Danke-Knopf weg ist...

--
aber ja, diese "Begrifflichkeiten für Netzsegmente"werden gerne verallgemeinert z.B: MGMT für Management... was genau? - nur ILO-Boards, OOB komplett...?


Man kann das Netz (VLAN) ja nennen, wie man will, bei mir gibts z.B. folgende VLANS mit unterschiedlichen Zugriffsregeln, z.T. auch von außen erreichbar:

WAN (klar, extern / öffentliche IP)
WEB (alles was von außen per HTTPS erreichbar sein soll) <- Regeln für Zugriff ins WAN + aus LAN, HOME, GUEST
LAN (für die Systeme, die ich für die LAN-Party auch mit pflege) <- Regel für Zugriff ins WAN, WEB + aus HOME
HOME (das interne "Hauptnetz") <- Regel für Zugriff ins WAN, WEB, LAN, ADMIN, LAB - kein Zugriff aus anderen Netzen erlaubt!
LAB (Testumgebung / Labor) <- Regel für Zugriff ins WAN nur nach notwendigkeit aktiviert + aus HOME
ADMIN (iLO, SSH Switch, IPCAM, ...) <- Regel für Zugriff aus HOME für 2 IPs (Mein Laptop + Mein PC)
GUEST (Gastnetz - WLAN als auch Kabel) <- Regel für Zugriff ins WAN. GUEST

+nur am Switch ohne Regel an der FW:
NFS (Netz für iSCSI und NFS-Share zwischen ESX und Storage - z.T. auch nur Hostinternes Netz)

 

[AliManali]

Hi

Ja, danke für die ganzen ausführlichen Antworten. Ich habe da stundenlang rum gebastelt, und bin nicht wirklich weiter gekommen. Zum Glück habe ich noch einen kleinen Ersatzserver wo die wichtigsten Dienst drauf weiter laufen. Weil der Mainserver steht nun seit dem Wochenende...

Mein Ansatz das direkt über die Firewall zu verkabeln geht wohl nicht mit einem vLAN. Zumindest schaffe ich es nicht, dass da mit konfigurierter vLAN ID am vmkernel Adressen per DHCP bezogen werden. Auch napp-it bezieht keine Adresse am zweiten Adapter, aber das Problem hatte ich schon am "normalen" (v)LAN. Ich werde das also über den Switch verkabeln müssen. Ausserdem bin ich wohl zu doof, da eine funktionierende Interzone Regel zu erstellen. Wenn ich die Security Policy aus mache und der vmkernel fixe IPs konfiguriert bekommt, dann kann ich da zugreifen. Aber beregeln lässt sich das irgendwie nicht, wohl weil das vLAN direkt verkabelt ist.

Ich glaube, ich lass das mal sacken so. Plan B wäre dann, dass ich ein neues vLAN auf den Switch tagge und es halt da drüber verkable. Wollte ich eigentlich vermeiden, dass ich da den Switch auch noch mit rein ziehen muss. Weil ich habe praktisch alle Ports belegt, und das umkonfigurieren wird bisschen mühsam in meinem Kabel Puff.

Ich mache mir im Übrigen auch weniger Sorgen, dass sich da wer von aussen einhackt. Ich mach mir da vor allem Gedanken um meinen Desktop, weil da ist Tod und Teufel drauf installiert. Unter anderem halt auch Gaming. Ich surfe auch den ganzen Tag dubiose Websiten an und so. Und der Desktop kann halt munter nach draussen kommunizieren wie er will. Wenn den mal ein Kryptotrojaner oder sonst was hässliches erwischen würde, dann könnte der halt grad auch noch auf dem Server viel Unheil anrichten.

Aber wie ich das einrichte, weiss ich ja jetzt. Falls noch Fragen auftreten, werde ich auch eine kleine Netzwerkübersicht machen.

 

[Luckysh0t]

Ich surfe auch den ganzen Tag dubiose Websiten an und so. Un

Wäre es nicht sinniger dies entweder zu lassen oder sich für diesen zweck eine VM zu installieren, diese in ein exklusives vlan mit dem Wan zu packen und ggf noch dazu eine Live distri bzw. diese nach jeder Nutzung/neustart auf einem Snap zu rück zu setzen ?

 

[AliManali]

So, ich habe jetzt das mal alles über den Switch verkabelt und konfiguriert. Bezieht mal jetzt in einem neuen Range auf dem selben Gateway die Adressen, ein paar der gewünschten Geräte. Ohje, hab da mal für einen Teil des Netzwerksalats in Unwissenheit CAT 7 Kabel bestellt. In Zukunft gibts nur noch Cat 5e, bzw Cat 6. Sind natürlich auch diverse Laschen abgebrochen beim umstöpseln.

Oh, je. Wie sieht das bei Euch aus? Arten so Umbauten bei Euch auch in tagelangen Downtimes aus, oder baut Ihr so Zeugs in halbwegs annehmbarer Zeit um? Also so Chefspielzeugnetzwerk soll es bei mir mal werden; zumindest theoretisch. Da darf sich dann meinetwegen alles im LAN tummeln, nur die NFS und SMB napp-it Geschichte, die ohne Passwort da voll überschreibbar ist, das geht gar nicht.

 

[Gen8 Runner]

Napp-it läuft auf ZFS oder? Ich habe auch eine VM für dubiose Seiten am laufen, sonst aber tägliches Backup von allen SmartphoneBackup und Laptops auf meinen ZFS Server mit regelmäßigen snapshots.

Da diese read only sind, kann ein Crypto Trojaner nichts anrichten... Nur so am Rande.

VLANs unter esxi (habe jetzt nicht alles gelesen, ob du das nutzt), können in der Tat leicht zickig sein. Aber wenn sie erstmal laufen, dann stabil.

 

[AliManali]

Oh je. Ich glaub ich weiss jetzt was ihr meint mit, "ob Dir das den Aufwand wert ist". Meine Güte, ist das scheiss kompliziert. Hab jetzt den Mainserver und Storage in einem eigenen vLAN, Adressen wie gehabt per DHCP. Ich werd mir beim nächsten mal am Switch oder Firewall basteln todsicher meinen Ast absägen. Aber egal, ist ja dokumentiert.

Napp-it läuft auf ZFS oder? Ich habe auch eine VM für dubiose Seiten am laufen, sonst aber tägliches Backup von allen SmartphoneBackup und Laptops auf meinen ZFS Server mit regelmäßigen snapshots.

Da diese read only sind, kann ein Crypto Trojaner nichts anrichten... Nur so am Rande.

VLANs unter esxi (habe jetzt nicht alles gelesen, ob du das nutzt), können in der Tat leicht zickig sein. Aber wenn sie erstmal laufen, dann stabil.

Ja. Mit Snapshots unter napp-it habe ich noch gar keine Erfahrung. Ich habe an napp-it zwei Platten, eine SSD für die VMs, eine HDDs für Backup und weitere VM's (2x NFS Freigabe für 2 Platten). Ich habe da auch jeweils kein Platz für Snapshots, da die Platten voll sind...

 

[Digi-Quick]

DMZ heist lediglich demilitarisierte Zone.

Eine DMZ wird i.d.R. da genutzt, wo Dienste im Internet angeboten werden und nicht durch Firewallregeln blockiert werden dürfen!
Webserver, SMTP-server/-Gateways. Mailserver

Zwichen DMS und Internet häng i.d.R. eine einfache Portbasierte Firewall oder ggf. auch gar keine
Das "schwere Geschütz" von Firewall sitzt zwischen DMZ und LAN - mind. SPI, besser DPI

exposed Host und virtual DMZ sind hier sowieso als Ausnahme anzusehen, da reine Softwarelösung über Firewallregeln/Portweiterleitungen auf ein und derselben Firwall, die dann meist auch kein Schwergewicht ist- (Wenn man Glück hat einfaches SPI)

 

[gea]

Ja. Mit Snapshots unter napp-it habe ich noch gar keine Erfahrung. Ich habe an napp-it zwei Platten, eine SSD für die VMs, eine HDDs für Backup und weitere VM's (2x NFS Freigabe für 2 Platten). Ich habe da auch jeweils kein Platz für Snapshots, da die Platten voll sind...

ZFS Snapshots sind der wichtigste Schutz gegen Ransomware oder versehentlich gelöschte oder geänderte Dateien. Das nicht zu nutzen ist wie Autofahren ohne Sicherheitsgurt anlegen und deaktiviertem ABS/ESP.

Da ZFS Snapshots keine Daten kopieren sondern lediglich den aktuellen Stand readonly einfrieren, benötigen sie im Moment der Erstellung keinen Platz. Lediglich danach geänderte Datenblöcke oder neue Daten benötigen Platz.

Also unbedingt einen Autosnap Job aktivieren. Wenn man einen Job stündlich (jede Stunde, keep 24) und taglich (23:00Uhr, keep 7) so kann man für die letzten 24 Stunden auf den Datenstand jede Stunde und für die letzte Woche auf den Stand 23:00 zurückgehen, entweder als rollback oder z.B. Windows und "vorherige Version"

PLatzbedarf ist wie gesagt, die Summer der geänderten/neuen Datenblöcke. Sollte auch mit wenig Platz gut gehen. Zur Not halt nicht eine Woche vorhalten sondern nur 3 Tage. Bei mir gehen Snaps idealerweise zusätzlich ein Jahr zurück (je Monatsanfang). Die Anzahl der Snaps ist unerheblich. 10000 Snaps ist kein Problem. Der Platzverbrauch (eigentlich nicht Verbrauch sondern geblockte Daten) insgesamt ist immer geänderte/geschriebene Datenblöcke seit dem ersten Snap.

Wobei ein nahezu voller Pool schlecht für die Performance ist. Wenn es ganz eng wird, kann man die napp-it Pool-Reservierung von 10% z.B. auf 3% verringern.

 

[AliManali]

Hi

Danke, Jungs und Mädels! Der ganze Christbaum läuft nun soweit. War richtig übel. Musste beim ESXi das Netzwerk zurücksetzen, und bis die ganzen Netzwerkadapter wieder ihre richtigen MAC Adressen hatten, naja, lassen wir das. So schlimm war es ja auch nicht. Waren ja nur ~100 vNICs an 13 vSwitches.

Nun habe ich noch ein Problem: Ich habe von napp-it ein altes Backup eingespielt. Auf der neueren Version hatte ich ein neues ZFS File System angelegt, darauf liegen 6 VMs. Nun habe ich vom napp-it die alte Version per WinSCP drüber gebügelt, und NFS an dem neuen Netzwerk wieder eingehängt. Das Dateisystem, bzw. die NFS Freigabe war mit dem alten napp-it zu meinem Erstaunen immer noch da. Die VMs laufen auch. Nur kann ich sie nicht konfigurieren, da kommt im Hostclient folgender Fehler:



Wie kriege ich den noch weg? Ansonsten bin ich da wieder guter Dinge, mittlerweile. Zumindest dümmer wurde ich nicht bei der Aktion.

PLatzbedarf ist wie gesagt, die Summer der geänderten/neuen Datenblöcke. Sollte auch mit wenig Platz gut gehen. Zur Not halt nicht eine Woche vorhalten sondern nur 3 Tage. Bei mir gehen Snaps idealerweise zusätzlich ein Jahr zurück (je Monatsanfang). Die Anzahl der Snaps ist unerheblich. 10000 Snaps ist kein Problem. Der Platzverbrauch (eigentlich nicht Verbrauch sondern geblockte Daten) insgesamt ist immer geänderte/geschriebene Datenblöcke seit dem ersten Snap.

Wobei ein nahezu voller Pool schlecht für die Performance ist. Wenn es ganz eng wird, kann man die napp-it Pool-Reservierung von 10% z.B. auf 3% verringern.

Ich habe auf einer 2TB Consumer SSD noch 194GiB Platz (20VMs). Auf der WD Gold 6TB liegen nur 6VMs die eh nie laufen sowie die Backups der SSD. Dort habe ich noch 3TB frei. Wobei wenn ich bei der SSD im Root Verzeichnis bin, dann werden 378GiB frei angezeigt, nur im NFS Verzeichnis weniger. Ausgelesen habe ich das mit Midnight Commander, unten rechts da jeweils.

 

[gea]

Ich vermute mal, dass ESXi keine Schreibrechte hat.
Das NFS Dateisystem rekursive auf everyone@=modify setzen

(CLI via chmod, Napp-it oder Windows via SMB)