Wieviel (v)LANs sind "normal"?
Umgebung ist eine Firma in NIS2-Nähe, ca. 100 PCs.
Ich dachte immer "keep it simple".
Ein Büro-Netz, ein PLS-Netz, je eine DMZ.
Dazu noch ein Backup-Netz, alles physisch getrennt.
So war die Welt in Ordnung.
Jetzt kommt eine E-Tankstelle ins LAN.
Eine Solaranlage.
Ein BHKW.
Hersteller wollen auf immer mehr Maschinen.
Darf nun der Toaster das BHKW steuern oder brauche ich eine separate DMZ für jede Anwendung?
Die Anomalieerkennung im PLS-Netz will unbedingt Internetzugang (bis jetzt ein No-Go).
Schon klar, Microsegmentierung und ZeroTrust.
Ein Netz für die Buchhaltung, für die Drucker, für jeden Frontend- zum Backend-Server.
Wie verwaltet man 20 vLANs? (Nicht technisch, sondern organisatorisch.)
Kabelfarben, bunte Aufkleber sind dann irgendwann nicht mehr möglich.
Switch-Bereiche physich beschriften?
Oder alles nur noch logisch im Switch und Software dokumentieren?
Ich wäre hier sehr dankbar für jede Idee oder praktische Erfahrung.
Uwe
Ich dachte immer "keep it simple".
Ein Büro-Netz, ein PLS-Netz, je eine DMZ.
Dazu noch ein Backup-Netz, alles physisch getrennt.
So war die Welt in Ordnung.
Jetzt kommt eine E-Tankstelle ins LAN.
Eine Solaranlage.
Ein BHKW.
Hersteller wollen auf immer mehr Maschinen.
Darf nun der Toaster das BHKW steuern oder brauche ich eine separate DMZ für jede Anwendung?
Die Anomalieerkennung im PLS-Netz will unbedingt Internetzugang (bis jetzt ein No-Go).
Schon klar, Microsegmentierung und ZeroTrust.
Ein Netz für die Buchhaltung, für die Drucker, für jeden Frontend- zum Backend-Server.
Wie verwaltet man 20 vLANs? (Nicht technisch, sondern organisatorisch.)
Kabelfarben, bunte Aufkleber sind dann irgendwann nicht mehr möglich.
Switch-Bereiche physich beschriften?
Oder alles nur noch logisch im Switch und Software dokumentieren?
Ich wäre hier sehr dankbar für jede Idee oder praktische Erfahrung.
Uwe
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671749
Url: https://administrator.de/forum/wieviel-vlans-sind-normal-671749.html
Ausgedruckt am: 26.04.2025 um 19:04 Uhr
52 Kommentare
Neuester Kommentar
nun - ich mache zB. Vendor-VLANs bei denen jeder Dienstleister "sein" Netzwerk hat und darin auch erstmal isoliert ist (bzw. nur die nötigen Dienste u. Seiten/Services freigegeben sind). Das hat für mich einige Vorteile:
- Es ist simpel mit der Firewall da ich einfach dem VLAN die Regeln verpassen kann
- Der DL kann mir (in grenzen) sagen was der in seinem VLAN braucht, ausser GW IP geb ich da erstmal nicht viel vor
- Sofern das VLAN gar keine Verbindung nach aussen braucht bleibts halt nen Flat-VLAN und da is es mir völlig egal (wenn zB. nur Maschinen kommunizieren müssen - die aber verteilt vor Ort stehen)
- Zugriffe per VPN sind recht einfach zu gestalten
Und am besten: selbst wenn der DL meint "ich häng mich einfach auf nen anderen Port" - ok, viel Spass... dort gibts dann ggf. Internet ABER dafür sind die eigenen Geräte dann nicht erreichbar. D.h. der hat nen eigenes Interesse daran das gleich richtig anzuschliessen...
- Es ist simpel mit der Firewall da ich einfach dem VLAN die Regeln verpassen kann
- Der DL kann mir (in grenzen) sagen was der in seinem VLAN braucht, ausser GW IP geb ich da erstmal nicht viel vor
- Sofern das VLAN gar keine Verbindung nach aussen braucht bleibts halt nen Flat-VLAN und da is es mir völlig egal (wenn zB. nur Maschinen kommunizieren müssen - die aber verteilt vor Ort stehen)
- Zugriffe per VPN sind recht einfach zu gestalten
Und am besten: selbst wenn der DL meint "ich häng mich einfach auf nen anderen Port" - ok, viel Spass... dort gibts dann ggf. Internet ABER dafür sind die eigenen Geräte dann nicht erreichbar. D.h. der hat nen eigenes Interesse daran das gleich richtig anzuschliessen...
kurz gesagt: "Soviel du brauchst" und "verwaltbar vertretbar"
Ich habe oben schon 6 gezählt .... manche teilen aber auch z.B. verschiedene Verwaltungen, Produktionsstätten, Drucker und Server auf.
Das kann eigentlich nur eure IT und das Management entscheiden ....
Ich habe oben schon 6 gezählt .... manche teilen aber auch z.B. verschiedene Verwaltungen, Produktionsstätten, Drucker und Server auf.
Das kann eigentlich nur eure IT und das Management entscheiden ....
1
Könntest evtl. mit Private VLAN arbeiten, für den ganzen sagen wir mal IoT Kram.
In Kurzform ist ein VLAN, aber die Geräte dürfen nicht untereinander sprechen, sondern nur mit der Firewall z. B.
In Kurzform ist ein VLAN, aber die Geräte dürfen nicht untereinander sprechen, sondern nur mit der Firewall z. B.
2
Moin,
Gruß
DivideByZero
Wie verwaltet man 20 vLANs? (Nicht technisch, sondern organisatorisch.)
ernst gemeint: wo ist das Problem? Sauber dokumentieren, und gut ist es.Kabelfarben, bunte Aufkleber sind dann irgendwann nicht mehr möglich.
Aber auch nicht notwendig. Wofür?Oder alles nur noch logisch im Switch und Software dokumentieren?
Ja, genau so. Warum nicht? Ist doch nur für die "Fachidioten" = IT erforderlich, alle anderen sollen ja die Finger weg lassen.Gruß
DivideByZero
Nachtrag:
Entscheidend ist wie beschrieben, die Doku.
Und ja: wenn man an verschiedenen Orten im Unternehmen 24/48-Port Switches einsetzt, müssen die natürlich VLANsund ggf Routing unterstützen...
... Aber NEIN: Das beschriften der Switch-Ports mit deren VLANs hilft....
beim Verlust der Übersicht 😉
Entscheidend ist wie beschrieben, die Doku.
Und ja: wenn man an verschiedenen Orten im Unternehmen 24/48-Port Switches einsetzt, müssen die natürlich VLANsund ggf Routing unterstützen...
... Aber NEIN: Das beschriften der Switch-Ports mit deren VLANs hilft....
beim Verlust der Übersicht 😉
Hi..
Ich würde das alles segmentieren (physikalisch) und über/oder eine FW trennen.. Ich habe solche Segmente (Aufzugssteuerung, Brandmeldeanlage, Einbruchserkennung..) komplett in anderen physikalisch getrennten Netzen sitzen.
Gruss Globe!
Ich würde das alles segmentieren (physikalisch) und über/oder eine FW trennen.. Ich habe solche Segmente (Aufzugssteuerung, Brandmeldeanlage, Einbruchserkennung..) komplett in anderen physikalisch getrennten Netzen sitzen.
Gruss Globe!
Moin,
wir sind gerade am segementieren und haben im Endausbau dann so 150-250 Vlans welche an jedem Standort identisch sind.
Eine vernünftige Planung ist unerlässlich. Bezüglich der Clients würde ich mir eh keine Gedanken machen. Das regelt das NAC von alleine.
Schwieriger sind die Server und die dafür nötigen Regeln auf der Segment Firewall da hier vorher schlicht keine Regeln notwendig waren. Somit muss jedes mal aufs neue eruiert werden, welchen Traffic wollen wir zulassen.
Mit der Kategorisierung nach Schutzkasse habe ich auch echt ein besseres Gefühl. Auch gerade dann wenn Dienstleister oder irgend welche Spezialfälle ins Spiel kommen.
Gruß
Spirit
wir sind gerade am segementieren und haben im Endausbau dann so 150-250 Vlans welche an jedem Standort identisch sind.
Eine vernünftige Planung ist unerlässlich. Bezüglich der Clients würde ich mir eh keine Gedanken machen. Das regelt das NAC von alleine.
Schwieriger sind die Server und die dafür nötigen Regeln auf der Segment Firewall da hier vorher schlicht keine Regeln notwendig waren. Somit muss jedes mal aufs neue eruiert werden, welchen Traffic wollen wir zulassen.
Mit der Kategorisierung nach Schutzkasse habe ich auch echt ein besseres Gefühl. Auch gerade dann wenn Dienstleister oder irgend welche Spezialfälle ins Spiel kommen.
Gruß
Spirit
1
Moin, VLAN sind auch simpel. Je nach Gateway kann man es auch mit Scripten konfigurieren. Einige haben API oder verfügen über Kommandozeilen Sprache.
Richtig gute Lösungen lassen auch "Modelle" zu. Man fast Dienste, Protokolle zusammen und verknüpft die mit einer Policy.
Bei meinen alten Arbeitgeber hat mein Vorgesetzter auch immer "keep it simple" oder besser "Wir haben gut zu tun" von sich gegeben. Da läuten die Alarmglocken.
https://netboxlabs.com/docs/netbox/en/stable/
OpenSource und on-premise. Damit sollte die Verwaltung schon mal in eine gute Richtung gehen. Man muss sich nur mal die Felder und Attribute des Programmes ansehen. Daraus ergibt sich dann schon eine grobe Richtung. Lokation-, Etage-, Raumverteiler. Könnte man als Kürzel nehme. L E R. Ggf. Mandanten, wenn es eine Firmengruppe ist. Firma A, B, C - entsprechend als Tag mit Anfangsbuchstaben.
So in der Form hat man eine gute Grundlage.
Die Netbox oben ist echt schon ein "Brett". Läuft aber auch unter Docker. Mit yaml Datei hast du einen ersten Eindruck auf deiner Büchse binnen Minuten.
https://netdisco.org/
Eine Config File und das Ding rennt los. Mitunter muss man noch von Hand die Uplinks nacharbeiten. Kommt auf die Switche und MIB's an. Manche haben TRUNK 1 - 8 schon vorgelegt, auch wenn nicht genutzt. Beim Auslesen schafft das Programm dann die Verbindung und man sieht die Topologie.
https://www.lantopolog.com/
Sehr günstig, tut eig. was es soll, stürzt bei mir nur oft ab. Für unter 30 Eur aber ansonsten eine schöne Methode. Über MAC Adressen kann man auch Devices "hinter" den Switchen sehen. VLANs einblenden. nur 1 VLAN auswählen und die beteiligten Switche anzeigen.
Wenn es etwas größer sein soll, wäre meine Antwort wohl Netbox.
https://github.com/netbox-community/netbox/blob/main/docs/media/screensh ...
https://demo.netbox.dev/
Klick auf Registrieren und wähle FREI einen Username und Passwort.
Es erschlägt dich! Aber sowas wie Standort, Geräterollen, Transportnetzgruppen kann man auch im kleinen Rahmen nutzen.
Du sollst nicht zum ISP werden oder eine Hochschule verwalten. Setz dich aber mal mit den Kategorien und Begriffen kurz auseinander. Wenn du den logischen Aufbau grob auf dein Szenario überträgst, möchte ich wetten dass eine Lösung nicht weit weg ist.
mfg Crusher
Richtig gute Lösungen lassen auch "Modelle" zu. Man fast Dienste, Protokolle zusammen und verknüpft die mit einer Policy.
Bei meinen alten Arbeitgeber hat mein Vorgesetzter auch immer "keep it simple" oder besser "Wir haben gut zu tun" von sich gegeben. Da läuten die Alarmglocken.
https://netboxlabs.com/docs/netbox/en/stable/
OpenSource und on-premise. Damit sollte die Verwaltung schon mal in eine gute Richtung gehen. Man muss sich nur mal die Felder und Attribute des Programmes ansehen. Daraus ergibt sich dann schon eine grobe Richtung. Lokation-, Etage-, Raumverteiler. Könnte man als Kürzel nehme. L E R. Ggf. Mandanten, wenn es eine Firmengruppe ist. Firma A, B, C - entsprechend als Tag mit Anfangsbuchstaben.
So in der Form hat man eine gute Grundlage.
Die Netbox oben ist echt schon ein "Brett". Läuft aber auch unter Docker. Mit yaml Datei hast du einen ersten Eindruck auf deiner Büchse binnen Minuten.
https://netdisco.org/
Eine Config File und das Ding rennt los. Mitunter muss man noch von Hand die Uplinks nacharbeiten. Kommt auf die Switche und MIB's an. Manche haben TRUNK 1 - 8 schon vorgelegt, auch wenn nicht genutzt. Beim Auslesen schafft das Programm dann die Verbindung und man sieht die Topologie.
https://www.lantopolog.com/
Sehr günstig, tut eig. was es soll, stürzt bei mir nur oft ab. Für unter 30 Eur aber ansonsten eine schöne Methode. Über MAC Adressen kann man auch Devices "hinter" den Switchen sehen. VLANs einblenden. nur 1 VLAN auswählen und die beteiligten Switche anzeigen.
Wenn es etwas größer sein soll, wäre meine Antwort wohl Netbox.
https://github.com/netbox-community/netbox/blob/main/docs/media/screensh ...
https://demo.netbox.dev/
Klick auf Registrieren und wähle FREI einen Username und Passwort.
Es erschlägt dich! Aber sowas wie Standort, Geräterollen, Transportnetzgruppen kann man auch im kleinen Rahmen nutzen.
Du sollst nicht zum ISP werden oder eine Hochschule verwalten. Setz dich aber mal mit den Kategorien und Begriffen kurz auseinander. Wenn du den logischen Aufbau grob auf dein Szenario überträgst, möchte ich wetten dass eine Lösung nicht weit weg ist.
mfg Crusher
2
Moin @UnbekannterNR1,
👍👍👍
Man benötigt dafür jedoch auch passende Switche, die PVLAN überhaupt unterstützen. Denn das kann bei weitem nicht mal jeder Enterprise-Swich.
Zudem muss man auch erwähnen, dass PVLAN's von der Logik her, auch etwas komplizierter sind wie normale VLAN's.
Gruss Alex
Könntest evtl. mit Private VLAN arbeiten, für den ganzen sagen wir mal IoT Kram.
In Kurzform ist ein VLAN, aber die Geräte dürfen nicht untereinander sprechen, sondern nur mit der Firewall z. B.
In Kurzform ist ein VLAN, aber die Geräte dürfen nicht untereinander sprechen, sondern nur mit der Firewall z. B.
👍👍👍
Man benötigt dafür jedoch auch passende Switche, die PVLAN überhaupt unterstützen. Denn das kann bei weitem nicht mal jeder Enterprise-Swich.
Zudem muss man auch erwähnen, dass PVLAN's von der Logik her, auch etwas komplizierter sind wie normale VLAN's.
Gruss Alex
Moin @Uwe-Kernchen,
solche Dinge würde ich wie schon von @UnbekannterNR1 angesprochen, wenn möglich eher in ein PVLAN reinpacken. 😉
Oh ja Dokus, die schaue ich mir zwar auch gerne an ... am liebsten schaue ich mir jedoch die echte Konfiguration auf den Switchen und oder der FW's/SGW's an, weil die Dokus sehr oft entweder veraltet, unvollständig oder fehlerhaft sind. 😔
Ich habe erst vor ein paar Monaten bei der Inbetriebnahme eines überschaubaren HV-Clusters eines grösseren Konzerns, in Summe locker über zwei Wochen extra verbraten müssen, nur um herauszufinden wie die neue Hardware in den externen RZ's dann tatsächlich angeschlossen wurde, denn die gerade mal einige Wochen zuvor erstellte Doku (Exel-Tabelle 🙃), war zum einen etwas unvollständig und an vielen Stellen auch schlichtweg falsch. 😭
Sprich, im Grunde ist es eigentlich so gut wie egal mit was und wo du Dokumentierst, solange es ordentlich und auch auf dem aktuellen Stand ist.
Du kannst die Doku einfach in Textfiles schreiben und diese z.B. mit Obsidian verwalten.
https://obsidian.md/
Wenn du das ganze etwas grafisch aufbauen möchtest, dann kann man das z.B. mit Visio ganz gut machen.
https://support.microsoft.com/de-de/topic/erstellen-eines-detaillierten- ...
Oder du hollst dir gleich ein richtiges Tool dafür, wie z.B. Docusnap ...
https://www.docusnap.com/
... oder ...
https://www.i-doit.com/
Gruss Alex
Jetzt kommt eine E-Tankstelle ins LAN.
Eine Solaranlage.
Ein BHKW.
Hersteller wollen auf immer mehr Maschinen.
Darf nun der Toaster das BHKW steuern oder brauche ich eine separate DMZ für jede Anwendung?
Eine Solaranlage.
Ein BHKW.
Hersteller wollen auf immer mehr Maschinen.
Darf nun der Toaster das BHKW steuern oder brauche ich eine separate DMZ für jede Anwendung?
solche Dinge würde ich wie schon von @UnbekannterNR1 angesprochen, wenn möglich eher in ein PVLAN reinpacken. 😉
Oder alles nur noch logisch im Switch und Software dokumentieren?
Oh ja Dokus, die schaue ich mir zwar auch gerne an ... am liebsten schaue ich mir jedoch die echte Konfiguration auf den Switchen und oder der FW's/SGW's an, weil die Dokus sehr oft entweder veraltet, unvollständig oder fehlerhaft sind. 😔
Ich habe erst vor ein paar Monaten bei der Inbetriebnahme eines überschaubaren HV-Clusters eines grösseren Konzerns, in Summe locker über zwei Wochen extra verbraten müssen, nur um herauszufinden wie die neue Hardware in den externen RZ's dann tatsächlich angeschlossen wurde, denn die gerade mal einige Wochen zuvor erstellte Doku (Exel-Tabelle 🙃), war zum einen etwas unvollständig und an vielen Stellen auch schlichtweg falsch. 😭
Sprich, im Grunde ist es eigentlich so gut wie egal mit was und wo du Dokumentierst, solange es ordentlich und auch auf dem aktuellen Stand ist.
Du kannst die Doku einfach in Textfiles schreiben und diese z.B. mit Obsidian verwalten.
https://obsidian.md/
Wenn du das ganze etwas grafisch aufbauen möchtest, dann kann man das z.B. mit Visio ganz gut machen.
https://support.microsoft.com/de-de/topic/erstellen-eines-detaillierten- ...
Oder du hollst dir gleich ein richtiges Tool dafür, wie z.B. Docusnap ...
https://www.docusnap.com/
... oder ...
https://www.i-doit.com/
Gruss Alex
Zitat von @Spirit-of-Eli:
Moin,
wir sind gerade am segementieren und haben im Endausbau dann so 150-250 Vlans welche an jedem Standort identisch sind.
Moin,
wir sind gerade am segementieren und haben im Endausbau dann so 150-250 Vlans welche an jedem Standort identisch sind.
Nur aus eigenem Interesse die Frage wozu 150-250? Wollt ihr jedes Büro in eigenes VLAN legen?
Zitat von @MysticFoxDE:
Moin @UnbekannterNR1,
👍👍👍
Man benötigt dafür jedoch auch passende Switche, die PVLAN überhaupt unterstützen. Denn das kann bei weitem nicht mal jeder Enterprise-Swich.
Zudem muss man auch erwähnen, dass PVLAN's von der Logik her, auch etwas komplizierter sind wie normale VLAN's.
Gruss Alex
Moin @UnbekannterNR1,
Könntest evtl. mit Private VLAN arbeiten, für den ganzen sagen wir mal IoT Kram.
In Kurzform ist ein VLAN, aber die Geräte dürfen nicht untereinander sprechen, sondern nur mit der Firewall z. B.
In Kurzform ist ein VLAN, aber die Geräte dürfen nicht untereinander sprechen, sondern nur mit der Firewall z. B.
👍👍👍
Man benötigt dafür jedoch auch passende Switche, die PVLAN überhaupt unterstützen. Denn das kann bei weitem nicht mal jeder Enterprise-Swich.
Zudem muss man auch erwähnen, dass PVLAN's von der Logik her, auch etwas komplizierter sind wie normale VLAN's.
Gruss Alex
Das hätte ich tatsächlich auch nicht gedacht bis wir das ganze hier eingeführt haben.
Alleine schon, dass die ganze Switch Kette für "das" PVlan implementiert werden muss war mir vorher nicht bewusst. Das heißt aus einer ID mach zwei 🤣
Zitat von @DerMaddin:
Nur aus eigenem Interesse die Frage wozu 150-250? Wollt ihr jedes Büro in eigenes VLAN legen?
Zitat von @Spirit-of-Eli:
Moin,
wir sind gerade am segementieren und haben im Endausbau dann so 150-250 Vlans welche an jedem Standort identisch sind.
Moin,
wir sind gerade am segementieren und haben im Endausbau dann so 150-250 Vlans welche an jedem Standort identisch sind.
Nur aus eigenem Interesse die Frage wozu 150-250? Wollt ihr jedes Büro in eigenes VLAN legen?
Es ist aufgeteilt in Perimeter, Campus und Datacenter.
Für die Infra kommen einige Vlans zusammen. Alleine für das Backup sind drei Netze nötig um den Zugriff nur von den entsprechenden Jumphosts zu regeln.
Ansonsten nimmt die Trennung der Server sehr viele IDs in Anspruch. Die kommen nicht mehr alle in ein Netz.
Bei 100-1000 VMs kommt da ein bisschen was zusammen. Und vor allem frisst das sehr viel Zeit.
Vielen Dank für die vielen guten Anregungen und Links!
Ich sehe mir gerade Netbox an, das erschlägt natürlich erst mal.
Mal testen ob ich das praxistauglich als Mehrwert empfinde.
Etwas mehr Grafik hätte ich mir auch gewünscht, oder habe ich das noch nicht gefunden?
Ich lasse das Thema noch bis abends laufen.
Gruß Uwe
Ich sehe mir gerade Netbox an, das erschlägt natürlich erst mal.
Mal testen ob ich das praxistauglich als Mehrwert empfinde.
Etwas mehr Grafik hätte ich mir auch gewünscht, oder habe ich das noch nicht gefunden?
Ich lasse das Thema noch bis abends laufen.
Gruß Uwe
also wir haben ca. 300 User und ca. 60-70 VLANs
Server VLANs:
- SAP (ERP) Systeme
- Domain Conroller Seperat
- Server Normal
- Backup
Drucker
Clients 2 verschiedene VLANs
Engineering eigenes VLAN
Produktionsmaschinen mit und ohne Internet 2 VLANs
Spezielle Maschinen Produktion 2 VLANs ebenfalls mit und ohne Internet
WLAN 4 VLANs
VMware auch nochmal 2 VLANs (Storage etc...)
Facitlity Management, SPS Steuerung usw., Diverse VLANs
Da läppert sich was zusammen...
Wie oben schon jemand geschrieben hat, so viel wie nötig.
Auch Optimal gleich mal 5 VLANs auf halde vorkonfigurieren, man weiss ja nie wann man mal wieder ein neues braucht...
Immer schön alles Dokumentieren in nem IP Plan, Excel wo alle VLANs drin sind.
Und beim Switch Ports Description auch mal gerne nutzen um am switch zu sehen was da dran ist.
bzw. auch ausführliche Excel Listen gerade im noch Client/Server Bereich wo wirklich alles Dokumentiert ist:
Maschine, Seriennummer, MAC Adresse, Port am Switch, VLAN usw....
Damit man nicht immer Vor Ort rumsuchen muss wenn man mal was braucht...
Ja ist Mords aufwand einmal die Doku zu erstellen, aber dann haste wenigstens vollen durchblick.
Server VLANs:
- SAP (ERP) Systeme
- Domain Conroller Seperat
- Server Normal
- Backup
Drucker
Clients 2 verschiedene VLANs
Engineering eigenes VLAN
Produktionsmaschinen mit und ohne Internet 2 VLANs
Spezielle Maschinen Produktion 2 VLANs ebenfalls mit und ohne Internet
WLAN 4 VLANs
VMware auch nochmal 2 VLANs (Storage etc...)
Facitlity Management, SPS Steuerung usw., Diverse VLANs
Da läppert sich was zusammen...
Wie oben schon jemand geschrieben hat, so viel wie nötig.
Auch Optimal gleich mal 5 VLANs auf halde vorkonfigurieren, man weiss ja nie wann man mal wieder ein neues braucht...
Immer schön alles Dokumentieren in nem IP Plan, Excel wo alle VLANs drin sind.
Und beim Switch Ports Description auch mal gerne nutzen um am switch zu sehen was da dran ist.
bzw. auch ausführliche Excel Listen gerade im noch Client/Server Bereich wo wirklich alles Dokumentiert ist:
Maschine, Seriennummer, MAC Adresse, Port am Switch, VLAN usw....
Damit man nicht immer Vor Ort rumsuchen muss wenn man mal was braucht...
Ja ist Mords aufwand einmal die Doku zu erstellen, aber dann haste wenigstens vollen durchblick.
Zitat von @Spirit-of-Eli:
Es ist aufgeteilt in Perimeter, Campus und Datacenter.
Für die Infra kommen einige Vlans zusammen. Alleine für das Backup sind drei Netze nötig um den Zugriff nur von den entsprechenden Jumphosts zu regeln.
Ansonsten nimmt die Trennung der Server sehr viele IDs in Anspruch. Die kommen nicht mehr alle in ein Netz.
Bei 100-1000 VMs kommt da ein bisschen was zusammen. Und vor allem frisst das sehr viel Zeit.
Zitat von @DerMaddin:
Nur aus eigenem Interesse die Frage wozu 150-250? Wollt ihr jedes Büro in eigenes VLAN legen?
Zitat von @Spirit-of-Eli:
Moin,
wir sind gerade am segementieren und haben im Endausbau dann so 150-250 Vlans welche an jedem Standort identisch sind.
Moin,
wir sind gerade am segementieren und haben im Endausbau dann so 150-250 Vlans welche an jedem Standort identisch sind.
Nur aus eigenem Interesse die Frage wozu 150-250? Wollt ihr jedes Büro in eigenes VLAN legen?
Es ist aufgeteilt in Perimeter, Campus und Datacenter.
Für die Infra kommen einige Vlans zusammen. Alleine für das Backup sind drei Netze nötig um den Zugriff nur von den entsprechenden Jumphosts zu regeln.
Ansonsten nimmt die Trennung der Server sehr viele IDs in Anspruch. Die kommen nicht mehr alle in ein Netz.
Bei 100-1000 VMs kommt da ein bisschen was zusammen. Und vor allem frisst das sehr viel Zeit.
Ich kann das schon verstehen, dass man verschiedene Server-Rollen abgrenzen möchte aber Hunderte VLANs?
Moin @Spirit-of-Eli,
na ja, bis 2017 kannte ich PVLAN auch nicht wirklich.
Dann kam ein Kunde auf die Idee seine ganzen Switche zu erneuern, wofür wir dann auch ein entsprechendes Angebot gemacht haben.
Dann hat der Kunde nach einiger Zeit angerufen und gebeten das Angebot zu überarbeiten, weil das Systemhaus welches seine SGW's betreut gemeint hat, dass die neuen Switche für die anstehende Netz-Segmentierung, auf jeden Fall PVLAN können müssen.
Also habe ich mich grob in das Thema eingearbeitet, das Angebot überarbeitet und habe dem Kunden daraufhin mehr als doppelt so teure Switche wie zuvor anbieten müssen, die er dann auch bestellt hat.
Nach einigen Monaten hat sich der Kunde wieder gemeldet und gefragt ob ich diesem bei der Konfiguration der PVLAN's helfen könne. Ich habe daraufhin dem Kunden gesagt, dass ich zwar theoretisch verstehe wie PVLAN’s funktionieren, von der Konfiguration dieser jedoch nicht wirklich eine Ahnung habe und dass er sich diesbezüglich doch bitte an das Systemhaus wenden soll, welches für die damalige Empfehlung/Anforderung auch verantwortlich war.
Daraufhin antwortete mir der entsprechende Admin, dass er das schon gemacht habe und dass, das entsprechende Systemhaus, ebenfalls überhaupt keinen Plan davon hat wie man PVLAN konfiguriert. 😬🙃
Ich habe dem Kunden dann gesagt, dass er sich keine Sorgen machen soll und ihm versprochen, dass ich das schon noch rausfuchsen werden. Zu der Zeit wusste ich jedoch nicht wirklich, was das wirklich bedeutet. 🤪
Na ja, nach dem Gespräch habe sofort bei HPE/Aruba angerufen und habe dort nach einer anständigen Doku für die Konfiguration der PVLAN’s gefragt, weil zu diesem Thema damals online so gut wie nichts verfügbar war. Daraufhin habe ich von dem Techniker des Herstellers die Antwort bekommen, dass er zwar theoretisch auch weiss wie PVLAN’s funktionieren, jedoch auch keinen Plan davon hat, wie man diese nun auf den Switchen konfigurieren könnte. 😭
Dann hat der HPE/Aruba-Techniker noch hinzugefügt, dass wenn wir das Projekt schaffen, wir wahrscheinlich die ersten wären die er kennt, die PVLAN’s im LAN ungesetzt hätten und ich soll mich wenn es dann so weit ist, wegen einer möglichen Referenz mal melden. 🙃
Zum Glück habe ich bei der damaligen Bestellung auch für uns selbst drei PVLAN fähige Switche mitgekauft. 😁
Sprich, nach ein paar Tagen „learning by doing“/“ try and error“, hatte ich dann endlich geschnallt wie man PVLAN’s korrekt konfiguriert. Vor allem die Geschichte mit den Promiscuous-Port’s hat mich damals ordentlich Hirnschmalz gekosten.
Gruss Alex
Das hätte ich tatsächlich auch nicht gedacht bis wir das ganze hier eingeführt haben.
Alleine schon, dass die ganze Switch Kette für "das" PVlan implementiert werden muss war mir vorher nicht bewusst. Das heißt aus einer ID mach zwei 🤣
Alleine schon, dass die ganze Switch Kette für "das" PVlan implementiert werden muss war mir vorher nicht bewusst. Das heißt aus einer ID mach zwei 🤣
na ja, bis 2017 kannte ich PVLAN auch nicht wirklich.
Dann kam ein Kunde auf die Idee seine ganzen Switche zu erneuern, wofür wir dann auch ein entsprechendes Angebot gemacht haben.
Dann hat der Kunde nach einiger Zeit angerufen und gebeten das Angebot zu überarbeiten, weil das Systemhaus welches seine SGW's betreut gemeint hat, dass die neuen Switche für die anstehende Netz-Segmentierung, auf jeden Fall PVLAN können müssen.
Also habe ich mich grob in das Thema eingearbeitet, das Angebot überarbeitet und habe dem Kunden daraufhin mehr als doppelt so teure Switche wie zuvor anbieten müssen, die er dann auch bestellt hat.
Nach einigen Monaten hat sich der Kunde wieder gemeldet und gefragt ob ich diesem bei der Konfiguration der PVLAN's helfen könne. Ich habe daraufhin dem Kunden gesagt, dass ich zwar theoretisch verstehe wie PVLAN’s funktionieren, von der Konfiguration dieser jedoch nicht wirklich eine Ahnung habe und dass er sich diesbezüglich doch bitte an das Systemhaus wenden soll, welches für die damalige Empfehlung/Anforderung auch verantwortlich war.
Daraufhin antwortete mir der entsprechende Admin, dass er das schon gemacht habe und dass, das entsprechende Systemhaus, ebenfalls überhaupt keinen Plan davon hat wie man PVLAN konfiguriert. 😬🙃
Ich habe dem Kunden dann gesagt, dass er sich keine Sorgen machen soll und ihm versprochen, dass ich das schon noch rausfuchsen werden. Zu der Zeit wusste ich jedoch nicht wirklich, was das wirklich bedeutet. 🤪
Na ja, nach dem Gespräch habe sofort bei HPE/Aruba angerufen und habe dort nach einer anständigen Doku für die Konfiguration der PVLAN’s gefragt, weil zu diesem Thema damals online so gut wie nichts verfügbar war. Daraufhin habe ich von dem Techniker des Herstellers die Antwort bekommen, dass er zwar theoretisch auch weiss wie PVLAN’s funktionieren, jedoch auch keinen Plan davon hat, wie man diese nun auf den Switchen konfigurieren könnte. 😭
Dann hat der HPE/Aruba-Techniker noch hinzugefügt, dass wenn wir das Projekt schaffen, wir wahrscheinlich die ersten wären die er kennt, die PVLAN’s im LAN ungesetzt hätten und ich soll mich wenn es dann so weit ist, wegen einer möglichen Referenz mal melden. 🙃
Zum Glück habe ich bei der damaligen Bestellung auch für uns selbst drei PVLAN fähige Switche mitgekauft. 😁
Sprich, nach ein paar Tagen „learning by doing“/“ try and error“, hatte ich dann endlich geschnallt wie man PVLAN’s korrekt konfiguriert. Vor allem die Geschichte mit den Promiscuous-Port’s hat mich damals ordentlich Hirnschmalz gekosten.
Gruss Alex
Zitat von @ThePinky777:
also wir haben ca. 300 User und ca. 60-70 VLANs
Server VLANs:
- SAP (ERP) Systeme
- Domain Conroller Seperat
- Server Normal
- Backup
Drucker
Clients 2 verschiedene VLANs
Engineering eigenes VLAN
Produktionsmaschinen mit und ohne Internet 2 VLANs
Spezielle Maschinen Produktion 2 VLANs ebenfalls mit und ohne Internet
WLAN 4 VLANs
VMware auch nochmal 2 VLANs (Storage etc...)
also wir haben ca. 300 User und ca. 60-70 VLANs
Server VLANs:
- SAP (ERP) Systeme
- Domain Conroller Seperat
- Server Normal
- Backup
Drucker
Clients 2 verschiedene VLANs
Engineering eigenes VLAN
Produktionsmaschinen mit und ohne Internet 2 VLANs
Spezielle Maschinen Produktion 2 VLANs ebenfalls mit und ohne Internet
WLAN 4 VLANs
VMware auch nochmal 2 VLANs (Storage etc...)
Man kann sich auch zu Tode mit VLANs konfigurieren. Vor allem die DCs in ein eigenes VLAN womöglich hinter einer FW, das ist doch krank. Da muss man so viele Standard-Ports und etliche dynamische öffnen, damit die Domain überhaupt funktioniert.
1
Moin,
zu der Ursprungsfrage. Im Prinzip sollte jedes Endgerät sein eigenes VLAN mit Firewall und Regeln bekommen. Nur so lässt sich definieren wer mit wem wie kommunizieren darf. In den meisten Fällen ist das aber wenig praktikabel
ich habe mir mal diesen Punkt rausgepickt. Ich bin der Meinung er zeigt prima verschiedene Probleme unserer IT-Zeit.
Viele Hersteller von Hard- und Software können einem gar nicht die Informationen geben welche Verbindungen nach Hause und innerhalb des Netzwerkes benötigt werden, weil sie das gar nicht wissen. Besonder schlimm im medizinschen Bereich wo scheinbar mit Sonnenbrille Server- und Softwarekomponenten eingekauft und verbaut werden.
Der Weg zu einem sicheren Netzwerk ist aufwendig und häufig möchte ihn Niemand bezahlen, nicht darauf warten und es ist "ja eh nur nervig diese IT-Sicherheit".
Zitat Kunde: Wo ist den das Problem, dass die Anmeldung an mein HO-PC ohne Zugriffsschutz erfolgt und ich mit 3 Klicks ohne Eingabe von nervigen Kennwort und/oder 2FA auf die Berichte der Buchhalter zugreifen kann? (Im Hintergrund ging gerade die Reinigungsdame vorbei
Also: Mach wie Du es für gut und sillvoll für Deine Firma findest. Tips gab es hier ja genug.
Gtw. Ist das Limit für VLANs nicht eh 4095?
Stefan
zu der Ursprungsfrage. Im Prinzip sollte jedes Endgerät sein eigenes VLAN mit Firewall und Regeln bekommen. Nur so lässt sich definieren wer mit wem wie kommunizieren darf. In den meisten Fällen ist das aber wenig praktikabel
Zitat von @Spirit-of-Eli:
Schwieriger sind die Server und die dafür nötigen Regeln auf der Segment Firewall da hier vorher schlicht keine Regeln notwendig waren. Somit muss jedes mal aufs neue eruiert werden, welchen Traffic wollen wir zulassen.
Schwieriger sind die Server und die dafür nötigen Regeln auf der Segment Firewall da hier vorher schlicht keine Regeln notwendig waren. Somit muss jedes mal aufs neue eruiert werden, welchen Traffic wollen wir zulassen.
ich habe mir mal diesen Punkt rausgepickt. Ich bin der Meinung er zeigt prima verschiedene Probleme unserer IT-Zeit.
Viele Hersteller von Hard- und Software können einem gar nicht die Informationen geben welche Verbindungen nach Hause und innerhalb des Netzwerkes benötigt werden, weil sie das gar nicht wissen. Besonder schlimm im medizinschen Bereich wo scheinbar mit Sonnenbrille Server- und Softwarekomponenten eingekauft und verbaut werden.
Der Weg zu einem sicheren Netzwerk ist aufwendig und häufig möchte ihn Niemand bezahlen, nicht darauf warten und es ist "ja eh nur nervig diese IT-Sicherheit".
Zitat Kunde: Wo ist den das Problem, dass die Anmeldung an mein HO-PC ohne Zugriffsschutz erfolgt und ich mit 3 Klicks ohne Eingabe von nervigen Kennwort und/oder 2FA auf die Berichte der Buchhalter zugreifen kann? (Im Hintergrund ging gerade die Reinigungsdame vorbei
Also: Mach wie Du es für gut und sillvoll für Deine Firma findest. Tips gab es hier ja genug.
Gtw. Ist das Limit für VLANs nicht eh 4095?
Stefan
Zitat von @DerMaddin:
Man kann sich auch zu Tode mit VLANs konfigurieren. Vor allem die DCs in ein eigenes VLAN womöglich hinter einer FW, das ist doch krank. Da muss man so viele Standard-Ports und etliche dynamische öffnen, damit die Domain überhaupt funktioniert.
Man kann sich auch zu Tode mit VLANs konfigurieren. Vor allem die DCs in ein eigenes VLAN womöglich hinter einer FW, das ist doch krank. Da muss man so viele Standard-Ports und etliche dynamische öffnen, damit die Domain überhaupt funktioniert.
naja kommt halt immer auf die NEEDS an, bedeutet wir haben auch Riesen Domain Trust Netzwerk mit ca. 15 Domains in verschiedenen Ländern. Da ist es am saubersten wenn man das Domain Controller VLAN trennt.
Und auch Geräte die halt nix am DC verloren hat aussperren kann. z.B. unsichere Stand Alone Produktions Maschinen auf Windows 7 Basis oder so gesox (Und nein Hersteller bietet keine Updates an)...
Ist halt einmal ein Konfig Aufwand... daran stirbt man nicht
Dafür hast du dann nene VLAN Plan komplett der mit Prozessen verknüpft ist wie z.B.
- Hier darf der Admin entscheiden falls neue Firewall Rules gemacht werden
- Bei anderen darf nur mit Genehmigung von XYZ neue Firewall Rules angesetzt werden
Und jeder ISO 27001 Auditor ist Glücklich und stellt keine dumme Fragen wenn er das ganze sieht...
1
von der Konfiguration dieser jedoch nicht wirklich eine Ahnung habe
Na ja, so ein Hexenwerk ist das ja nun auch wieder nicht. PVLAN generieren, Access Ports zuweisen, Uplink Port definieren, fertisch.https://www.fs.com/de/blog/was-ist-ein-privates-vlan-und-wie-funktionier ...
Moin @DerMaddin,
ja, vor allem die DC's gehören bei einer anständigen Netzsegmentierung in ein eigenes VLAN, weil diese neben dem Exchange in einer MS-AD-Umgebung, meistens als erste Angegriffen werden. 😉
Na hinter was den sonst?
Und komm mir jetzt bitte nicht mit solchen Scherzen wie Routung über einer Core-Switch.
Na ja, so viele sind das nun auch wieder nicht ...
TCP & UDP 53
TCP & UDP 88
TCP & UDP 123
TCP 135
TCP & UDP 137
UDP 138
TCP 139
TCP & UDP 464
TCP & UDP 389
TCP 445
TCP & UDP 636
TCP & UDP 1512
TCP & UDP 3268
TCP & UDP 3269
... 🙃
Und das mit den Dynamischen RPC Ports, kann man damit ...
https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-dir ...
... sehr einfach in den Griff bekommen. 😉
Sprich, alles nur halb so wild. 😁
Gruss Alex
Vor allem die DCs in ein eigenes VLAN
ja, vor allem die DC's gehören bei einer anständigen Netzsegmentierung in ein eigenes VLAN, weil diese neben dem Exchange in einer MS-AD-Umgebung, meistens als erste Angegriffen werden. 😉
womöglich hinter einer FW, das ist doch krank.
Na hinter was den sonst?
Und komm mir jetzt bitte nicht mit solchen Scherzen wie Routung über einer Core-Switch.
Da muss man so viele Standard-Ports
Na ja, so viele sind das nun auch wieder nicht ...
TCP & UDP 53
TCP & UDP 88
TCP & UDP 123
TCP 135
TCP & UDP 137
UDP 138
TCP 139
TCP & UDP 464
TCP & UDP 389
TCP 445
TCP & UDP 636
TCP & UDP 1512
TCP & UDP 3268
TCP & UDP 3269
... 🙃
und etliche dynamische öffnen, damit die Domain überhaupt funktioniert.
Und das mit den Dynamischen RPC Ports, kann man damit ...
https://learn.microsoft.com/de-de/troubleshoot/windows-server/active-dir ...
... sehr einfach in den Griff bekommen. 😉
Sprich, alles nur halb so wild. 😁
Gruss Alex
1
Demnach gibt es dann gar keine Visualisierung der Netze mehr, sondern "technische" Tabellen?
Ich wüßte nicht, wie ich das noch zeichnen sollte?
Leitet ihr alle VLANs an alle Switche oder ist der Trunk jeweils nur die notwendige Teilmenge?
Falls Letzteres, wie behaltet ihr den Überblick über den Kommunikationsweg?
Ich wüßte nicht, wie ich das noch zeichnen sollte?
Leitet ihr alle VLANs an alle Switche oder ist der Trunk jeweils nur die notwendige Teilmenge?
Falls Letzteres, wie behaltet ihr den Überblick über den Kommunikationsweg?
Moin @aqui,
das ist Fahrradfahren, sobald man es einmal beherrscht, auch nicht wirklich.
Na ja, dann pack mal interne Clients auf denen auch ein SIP Client läuft mal so einfach in eine Isolated PVLAN.
Sprich, nein, ein PVLAN Projekt sollte man nur nach einer sehr sorgfältigen Planung angehen!
Wenn man natürlich extrem auf Masochismus steht, dann kann man ein solches Projekt natürlich auch ungeplant angehen. 🤪
By the way, viele Admins unserer Kunden möchten sich stand heute noch nicht mal das normale VLAN noch antun, weil die nebenher auch noch duzende andere Dinge zu erledigen haben, die von Tag zu Tag zudem immer zahlreicher werden. 😔
Gruss Alex
Na ja, so ein Hexenwerk ist das ja nun auch wieder nicht.
das ist Fahrradfahren, sobald man es einmal beherrscht, auch nicht wirklich.
PVLAN generieren, Access Ports zuweisen, Uplink Port definieren, fertisch.
Na ja, dann pack mal interne Clients auf denen auch ein SIP Client läuft mal so einfach in eine Isolated PVLAN.
Sprich, nein, ein PVLAN Projekt sollte man nur nach einer sehr sorgfältigen Planung angehen!
Wenn man natürlich extrem auf Masochismus steht, dann kann man ein solches Projekt natürlich auch ungeplant angehen. 🤪
By the way, viele Admins unserer Kunden möchten sich stand heute noch nicht mal das normale VLAN noch antun, weil die nebenher auch noch duzende andere Dinge zu erledigen haben, die von Tag zu Tag zudem immer zahlreicher werden. 😔
Gruss Alex
@MysticFoxDE
Moment, man schiebt die DCs in ein VLAN, sichert den Zugriff mit Regeln, öffnet alle benötigten TCP/UDP Ports für quasi alle anderen VLANs. Wie verhindere ich damit einen potenziellen Angriff aus dem LAN? Hat man kein zu 100% umgesetztes 802.1x oder NAC, dann ist es ziemlich einfach. Aber selbst damit kann ich immer noch mit einem kompromittierten Client alles mögliche angreifen.
Übrigens, ich würde mich nicht auf die DCs oder andere Server konzentrieren sondern auf die Virtualisierung. Bin ich da drin habe ich Zugriff auf alle VMs.
Moment, man schiebt die DCs in ein VLAN, sichert den Zugriff mit Regeln, öffnet alle benötigten TCP/UDP Ports für quasi alle anderen VLANs. Wie verhindere ich damit einen potenziellen Angriff aus dem LAN? Hat man kein zu 100% umgesetztes 802.1x oder NAC, dann ist es ziemlich einfach. Aber selbst damit kann ich immer noch mit einem kompromittierten Client alles mögliche angreifen.
Übrigens, ich würde mich nicht auf die DCs oder andere Server konzentrieren sondern auf die Virtualisierung. Bin ich da drin habe ich Zugriff auf alle VMs.
Zitat von @MysticFoxDE:
Moin @Spirit-of-Eli,
na ja, bis 2017 kannte ich PVLAN auch nicht wirklich.
Dann kam ein Kunde auf die Idee seine ganzen Switche zu erneuern, wofür wir dann auch ein entsprechendes Angebot gemacht haben.
Dann hat der Kunde nach einiger Zeit angerufen und gebeten das Angebot zu überarbeiten, weil das Systemhaus welches seine SGW's betreut gemeint hat, dass die neuen Switche für die anstehende Netz-Segmentierung, auf jeden Fall PVLAN können müssen.
Also habe ich mich grob in das Thema eingearbeitet, das Angebot überarbeitet und habe dem Kunden daraufhin mehr als doppelt so teure Switche wie zuvor anbieten müssen, die er dann auch bestellt hat.
Nach einigen Monaten hat sich der Kunde wieder gemeldet und gefragt ob ich diesem bei der Konfiguration der PVLAN's helfen könne. Ich habe daraufhin dem Kunden gesagt, dass ich zwar theoretisch verstehe wie PVLAN’s funktionieren, von der Konfiguration dieser jedoch nicht wirklich eine Ahnung habe und dass er sich diesbezüglich doch bitte an das Systemhaus wenden soll, welches für die damalige Empfehlung/Anforderung auch verantwortlich war.
Daraufhin antwortete mir der entsprechende Admin, dass er das schon gemacht habe und dass, das entsprechende Systemhaus, ebenfalls überhaupt keinen Plan davon hat wie man PVLAN konfiguriert. 😬🙃
Ich habe dem Kunden dann gesagt, dass er sich keine Sorgen machen soll und ihm versprochen, dass ich das schon noch rausfuchsen werden. Zu der Zeit wusste ich jedoch nicht wirklich, was das wirklich bedeutet. 🤪
Na ja, nach dem Gespräch habe sofort bei HPE/Aruba angerufen und habe dort nach einer anständigen Doku für die Konfiguration der PVLAN’s gefragt, weil zu diesem Thema damals online so gut wie nichts verfügbar war. Daraufhin habe ich von dem Techniker des Herstellers die Antwort bekommen, dass er zwar theoretisch auch weiss wie PVLAN’s funktionieren, jedoch auch keinen Plan davon hat, wie man diese nun auf den Switchen konfigurieren könnte. 😭
Dann hat der HPE/Aruba-Techniker noch hinzugefügt, dass wenn wir das Projekt schaffen, wir wahrscheinlich die ersten wären die er kennt, die PVLAN’s im LAN ungesetzt hätten und ich soll mich wenn es dann so weit ist, wegen einer möglichen Referenz mal melden. 🙃
Zum Glück habe ich bei der damaligen Bestellung auch für uns selbst drei PVLAN fähige Switche mitgekauft. 😁
Sprich, nach ein paar Tagen „learning by doing“/“ try and error“, hatte ich dann endlich geschnallt wie man PVLAN’s korrekt konfiguriert. Vor allem die Geschichte mit den Promiscuous-Port’s hat mich damals ordentlich Hirnschmalz gekosten.
Gruss Alex
Moin @Spirit-of-Eli,
Das hätte ich tatsächlich auch nicht gedacht bis wir das ganze hier eingeführt haben.
Alleine schon, dass die ganze Switch Kette für "das" PVlan implementiert werden muss war mir vorher nicht bewusst. Das heißt aus einer ID mach zwei 🤣
Alleine schon, dass die ganze Switch Kette für "das" PVlan implementiert werden muss war mir vorher nicht bewusst. Das heißt aus einer ID mach zwei 🤣
na ja, bis 2017 kannte ich PVLAN auch nicht wirklich.
Dann kam ein Kunde auf die Idee seine ganzen Switche zu erneuern, wofür wir dann auch ein entsprechendes Angebot gemacht haben.
Dann hat der Kunde nach einiger Zeit angerufen und gebeten das Angebot zu überarbeiten, weil das Systemhaus welches seine SGW's betreut gemeint hat, dass die neuen Switche für die anstehende Netz-Segmentierung, auf jeden Fall PVLAN können müssen.
Also habe ich mich grob in das Thema eingearbeitet, das Angebot überarbeitet und habe dem Kunden daraufhin mehr als doppelt so teure Switche wie zuvor anbieten müssen, die er dann auch bestellt hat.
Nach einigen Monaten hat sich der Kunde wieder gemeldet und gefragt ob ich diesem bei der Konfiguration der PVLAN's helfen könne. Ich habe daraufhin dem Kunden gesagt, dass ich zwar theoretisch verstehe wie PVLAN’s funktionieren, von der Konfiguration dieser jedoch nicht wirklich eine Ahnung habe und dass er sich diesbezüglich doch bitte an das Systemhaus wenden soll, welches für die damalige Empfehlung/Anforderung auch verantwortlich war.
Daraufhin antwortete mir der entsprechende Admin, dass er das schon gemacht habe und dass, das entsprechende Systemhaus, ebenfalls überhaupt keinen Plan davon hat wie man PVLAN konfiguriert. 😬🙃
Ich habe dem Kunden dann gesagt, dass er sich keine Sorgen machen soll und ihm versprochen, dass ich das schon noch rausfuchsen werden. Zu der Zeit wusste ich jedoch nicht wirklich, was das wirklich bedeutet. 🤪
Na ja, nach dem Gespräch habe sofort bei HPE/Aruba angerufen und habe dort nach einer anständigen Doku für die Konfiguration der PVLAN’s gefragt, weil zu diesem Thema damals online so gut wie nichts verfügbar war. Daraufhin habe ich von dem Techniker des Herstellers die Antwort bekommen, dass er zwar theoretisch auch weiss wie PVLAN’s funktionieren, jedoch auch keinen Plan davon hat, wie man diese nun auf den Switchen konfigurieren könnte. 😭
Dann hat der HPE/Aruba-Techniker noch hinzugefügt, dass wenn wir das Projekt schaffen, wir wahrscheinlich die ersten wären die er kennt, die PVLAN’s im LAN ungesetzt hätten und ich soll mich wenn es dann so weit ist, wegen einer möglichen Referenz mal melden. 🙃
Zum Glück habe ich bei der damaligen Bestellung auch für uns selbst drei PVLAN fähige Switche mitgekauft. 😁
Sprich, nach ein paar Tagen „learning by doing“/“ try and error“, hatte ich dann endlich geschnallt wie man PVLAN’s korrekt konfiguriert. Vor allem die Geschichte mit den Promiscuous-Port’s hat mich damals ordentlich Hirnschmalz gekosten.
Gruss Alex
Ja ging uns genau so. Wir haben uns drei mal Ruckversichert.
Das ist schon spannend hin und Rückweg komplett zu trennen.
1Zitat von @DerMaddin:
Man kann sich auch zu Tode mit VLANs konfigurieren. Vor allem die DCs in ein eigenes VLAN womöglich hinter einer FW, das ist doch krank. Da muss man so viele Standard-Ports und etliche dynamische öffnen, damit die Domain überhaupt funktioniert.
Zitat von @ThePinky777:
also wir haben ca. 300 User und ca. 60-70 VLANs
Server VLANs:
- SAP (ERP) Systeme
- Domain Conroller Seperat
- Server Normal
- Backup
Drucker
Clients 2 verschiedene VLANs
Engineering eigenes VLAN
Produktionsmaschinen mit und ohne Internet 2 VLANs
Spezielle Maschinen Produktion 2 VLANs ebenfalls mit und ohne Internet
WLAN 4 VLANs
VMware auch nochmal 2 VLANs (Storage etc...)
also wir haben ca. 300 User und ca. 60-70 VLANs
Server VLANs:
- SAP (ERP) Systeme
- Domain Conroller Seperat
- Server Normal
- Backup
Drucker
Clients 2 verschiedene VLANs
Engineering eigenes VLAN
Produktionsmaschinen mit und ohne Internet 2 VLANs
Spezielle Maschinen Produktion 2 VLANs ebenfalls mit und ohne Internet
WLAN 4 VLANs
VMware auch nochmal 2 VLANs (Storage etc...)
Man kann sich auch zu Tode mit VLANs konfigurieren. Vor allem die DCs in ein eigenes VLAN womöglich hinter einer FW, das ist doch krank. Da muss man so viele Standard-Ports und etliche dynamische öffnen, damit die Domain überhaupt funktioniert.
Genau das ist zur Zertifizierung gefordert.
Aber du baust das ganze eh nur einmal und hast dann ja quasi ein Template. Auf die Masse und alle Standorte gesehen ist das nicht so wild.
i-doit wurde in den Raum geworfen.
https://glpi-project.org/
Noch gibt es glpi unter OpenSource und On-Premise. Furch Fields Plugin kann man auch eigene Felder erstellen und Assets zuweisen.
Wenn es um die Kombination und ggf. Einführung von Asset-Management geht, würde ich klar empfehlen GLPI mal anzusehen. Erschlägt einen auch, aber alles lässt sich via GUI eirnichten.
Neue Felder im neuen Tab stehen auch z.B. Data Injection sofort zur Verfügung. Man kann rasch mit CSV fehlende Daten nachtragen.
Selbst wenn man keine API hat und nur Excel Tabellen in der anderen "Anwendung" ist es mit GLPI kein Problem.
Auch denkbar aus Netbox oder anderen Tools Daten zu importierne. Oft macht man es ja nur einmal und es bleibt erstmal so die nächsten Monate / Jahre.
i-doit war mal gut. Nun nur noch in der Paid-Variante. Seblst QR-Code und deutsche Sprache gehen nicht mehr in der letzten OpenSource Version.
Nach derzeitigen Stand würde ich klar GLPI empfehlen. Durch die neuen selbstgebauten Felder kann man es einfach für den Import aus versch Quellen nutzen.
Tages, Seriennummern, etc. etc. blieben dann weiterhin erhalten und stehen in der Datenbank.
Ein gewaltiges Werkzeug.
https://www.youtube.com/watch?v=5wrv6ZertaA
Importiert auch andere Assets und verlinkt wie gesagt auch "Custom-Fields". Selbst wenn du Excel und CSV als "Middleware" einsetzt, ist es immer noch schnellerer und sicherer beim Import als andere Lösungen.
"Irgendwas" für Doku und Asset Management:
- GLPI
- Netbox
Tangiert zwar deine Frage teils nur, aber wenn ihr noch nix habt würde das durchaus einen Mehrwert schaffen.
https://glpi-project.org/
Noch gibt es glpi unter OpenSource und On-Premise. Furch Fields Plugin kann man auch eigene Felder erstellen und Assets zuweisen.
Wenn es um die Kombination und ggf. Einführung von Asset-Management geht, würde ich klar empfehlen GLPI mal anzusehen. Erschlägt einen auch, aber alles lässt sich via GUI eirnichten.
Neue Felder im neuen Tab stehen auch z.B. Data Injection sofort zur Verfügung. Man kann rasch mit CSV fehlende Daten nachtragen.
Selbst wenn man keine API hat und nur Excel Tabellen in der anderen "Anwendung" ist es mit GLPI kein Problem.
Auch denkbar aus Netbox oder anderen Tools Daten zu importierne. Oft macht man es ja nur einmal und es bleibt erstmal so die nächsten Monate / Jahre.
i-doit war mal gut. Nun nur noch in der Paid-Variante. Seblst QR-Code und deutsche Sprache gehen nicht mehr in der letzten OpenSource Version.
Nach derzeitigen Stand würde ich klar GLPI empfehlen. Durch die neuen selbstgebauten Felder kann man es einfach für den Import aus versch Quellen nutzen.
Tages, Seriennummern, etc. etc. blieben dann weiterhin erhalten und stehen in der Datenbank.
Ein gewaltiges Werkzeug.
https://www.youtube.com/watch?v=5wrv6ZertaA
Importiert auch andere Assets und verlinkt wie gesagt auch "Custom-Fields". Selbst wenn du Excel und CSV als "Middleware" einsetzt, ist es immer noch schnellerer und sicherer beim Import als andere Lösungen.
"Irgendwas" für Doku und Asset Management:
- GLPI
- Netbox
Tangiert zwar deine Frage teils nur, aber wenn ihr noch nix habt würde das durchaus einen Mehrwert schaffen.
Zitat von @aqui:
https://www.fs.com/de/blog/was-ist-ein-privates-vlan-und-wie-funktionier ...
von der Konfiguration dieser jedoch nicht wirklich eine Ahnung habe
Na ja, so ein Hexenwerk ist das ja nun auch wieder nicht. PVLAN generieren, Access Ports zuweisen, Uplink Port definieren, fertisch.https://www.fs.com/de/blog/was-ist-ein-privates-vlan-und-wie-funktionier ...
Nope. Du musst zwei VLans auf der ganzen Switch Kette betreiben. Vom Datacenter bis zum Gateway. Ansonsten funktioniert das leider nicht.
Das ist bei Cisco sowie Aruba identisch.
Moin @DerMaddin,
in dem man auf dem SGW nicht nur Layer 3-4 Security aktiviert, sondern auch die die Layer 7,
sprich, IPS & Co KG.
Zudem kann man in einer Gefahrenlage die AD's so auch ganz schnell von bestimmten Teilnetzen isolieren. 😉
Ja, NAC oben drauf wäre natürlich sehr wünschenswert, jedoch fehlt dafür den meisten (deutschen) Unternehmen schlichtweg sowohl die Kompetenz als auch die dafür notwendigen Ressourcen und damit meine ich in erster Linie die Mannpower, um das mal umzusetzen, aber auch danach noch ordentlich zu betreiben, monitoren und auch upzudaten. 😔
Eine 100% Sicherheit gibt es nicht wirklich. Mann kann und sollte jedoch dennoch dem Angreifer das Leben so schwer wie möglich gestallten. 😉
Da beisst du bei den meisten unserer Kunden im wahrsten Sinnen des Wortes auf Granit. 😎
Denn ALLE HV Umgebungen die wir mitverantworten laufen in eigenständigen Managementdomänen die Vollständig von der produktiven Umgebung getrennt sind. Sprich um an die HV's zu kommen, musst du dich bei diesen Kunden schon an einen der isolierten Jump-Hosts, physikalisch irgendwie hinsetzen können. 😉
Ich bezweifle jedoch, dass einer der entsprechenden Admins einen Fremden auch nur in die Nähe der entsprechenden Jump-Hosts oder gar in die Serverräume lässt.
Gruss Alex
Moment, man schiebt die DCs in ein VLAN, sichert den Zugriff mit Regeln, öffnet alle benötigten TCP/UDP Ports für quasi alle anderen VLANs. Wie verhindere ich damit einen potenziellen Angriff aus dem LAN?
in dem man auf dem SGW nicht nur Layer 3-4 Security aktiviert, sondern auch die die Layer 7,
sprich, IPS & Co KG.
Zudem kann man in einer Gefahrenlage die AD's so auch ganz schnell von bestimmten Teilnetzen isolieren. 😉
Hat man kein zu 100% umgesetztes 802.1x oder NAC, dann ist es ziemlich einfach.
Ja, NAC oben drauf wäre natürlich sehr wünschenswert, jedoch fehlt dafür den meisten (deutschen) Unternehmen schlichtweg sowohl die Kompetenz als auch die dafür notwendigen Ressourcen und damit meine ich in erster Linie die Mannpower, um das mal umzusetzen, aber auch danach noch ordentlich zu betreiben, monitoren und auch upzudaten. 😔
Aber selbst damit kann ich immer noch mit einem kompromittierten Client alles mögliche angreifen.
Eine 100% Sicherheit gibt es nicht wirklich. Mann kann und sollte jedoch dennoch dem Angreifer das Leben so schwer wie möglich gestallten. 😉
Übrigens, ich würde mich nicht auf die DCs oder andere Server konzentrieren sondern auf die Virtualisierung. Bin ich da drin habe ich Zugriff auf alle VMs.
Da beisst du bei den meisten unserer Kunden im wahrsten Sinnen des Wortes auf Granit. 😎
Denn ALLE HV Umgebungen die wir mitverantworten laufen in eigenständigen Managementdomänen die Vollständig von der produktiven Umgebung getrennt sind. Sprich um an die HV's zu kommen, musst du dich bei diesen Kunden schon an einen der isolierten Jump-Hosts, physikalisch irgendwie hinsetzen können. 😉
Ich bezweifle jedoch, dass einer der entsprechenden Admins einen Fremden auch nur in die Nähe der entsprechenden Jump-Hosts oder gar in die Serverräume lässt.
Gruss Alex
Zitat von @MysticFoxDE:
Ich bezweifle jedoch, dass einer der entsprechenden Admins einen Fremden auch nur in die Nähe der entsprechenden Jump-Hosts oder gar in die Serverräume lässt.
Ich bezweifle jedoch, dass einer der entsprechenden Admins einen Fremden auch nur in die Nähe der entsprechenden Jump-Hosts oder gar in die Serverräume lässt.
Sage niemals "nie" und vor allem kann man die eigene Infrastruktur nicht auf andere projizieren. Ich habe da schon wirklich verrückte Sachen gesehen und das nicht in einer 5-Mann-Bude oder Hinterhofwerkstatt. Ich spreche von Konzern-Größen so 30.000+ Mitarbeiter weltweit
In der Theorie kann man vieles sehr gut absichern aber oft fehlt es an €€€ und/oder Know-How und man muss Kompromisse eingehen.
1
Zitat von @Uwe-Kernchen:
Leitet ihr alle VLANs an alle Switche oder ist der Trunk jeweils nur die notwendige Teilmenge?
Falls Letzteres, wie behaltet ihr den Überblick über den Kommunikationsweg?
Leitet ihr alle VLANs an alle Switche oder ist der Trunk jeweils nur die notwendige Teilmenge?
Falls Letzteres, wie behaltet ihr den Überblick über den Kommunikationsweg?
Die jeweils nur benötigten VLANs zu den Switch zu bringen, wäre natürlich der Königsweg. Aber vermutlich möchte sich keiner eine händische Verwaltung antun. Da bieten sich dynamische VLANs an.
Alle VLANs auf jedem Switch zu verteilen, finde ich auch ungünstig - warum sollte ein User/Client netzwerktechnisch in die Nähe von Server oder Speicher, Backup etc. kommen (dürfen)?
Wir praktizieren den Mittelweg zwischen "alle VLANS" und "nur minimal benötigte VLANs" auf den Switches, indem wir die Switches nach Funktion einteilen: auf Core-Switches sind "alle VLAN", auf "Server-Switches" oder "Speicher-Switches" nur die entsprechende VLANs. Die User haben ihre eigenen Switches wo dann nur das/die Client-VLANs anliegen.
Gruß
TA
Moin @DerMaddin,
ja, das ist wiederum auch richtig. 🙃
Ich glaube ich weiss genau wovon du sprichst ... wir sollten mal gemeinsam ein 🍺 trinken gehen.
Das Leben ist und war, für Normalsterbliche zumindest, eben noch nie wirklich ein Wunschkonzert.
Gruss Alex
Sage niemals "nie" und vor allem kann man die eigene Infrastruktur nicht auf andere projizieren.
ja, das ist wiederum auch richtig. 🙃
Ich habe da schon wirklich verrückte Sachen gesehen und das nicht in einer 5-Mann-Bude oder Hinterhofwerkstatt. Ich spreche von Konzern-Größen so 30.000+ Mitarbeiter weltweit
Ich glaube ich weiss genau wovon du sprichst ... wir sollten mal gemeinsam ein 🍺 trinken gehen.
In der Theorie kann man vieles sehr gut absichern aber oft fehlt es an €€€ und/oder Know-How und man muss Kompromisse eingehen.
Das Leben ist und war, für Normalsterbliche zumindest, eben noch nie wirklich ein Wunschkonzert.
Gruss Alex
Zitat von @DerMaddin:
@MysticFoxDE
Moment, man schiebt die DCs in ein VLAN, sichert den Zugriff mit Regeln, öffnet alle benötigten TCP/UDP Ports für quasi alle anderen VLANs. Wie verhindere ich damit einen potenziellen Angriff aus dem LAN? Hat man kein zu 100% umgesetztes 802.1x oder NAC, dann ist es ziemlich einfach. Aber selbst damit kann ich immer noch mit einem kompromittierten Client alles mögliche angreifen.
Übrigens, ich würde mich nicht auf die DCs oder andere Server konzentrieren sondern auf die Virtualisierung. Bin ich da drin habe ich Zugriff auf alle VMs.
@MysticFoxDE
Moment, man schiebt die DCs in ein VLAN, sichert den Zugriff mit Regeln, öffnet alle benötigten TCP/UDP Ports für quasi alle anderen VLANs. Wie verhindere ich damit einen potenziellen Angriff aus dem LAN? Hat man kein zu 100% umgesetztes 802.1x oder NAC, dann ist es ziemlich einfach. Aber selbst damit kann ich immer noch mit einem kompromittierten Client alles mögliche angreifen.
Übrigens, ich würde mich nicht auf die DCs oder andere Server konzentrieren sondern auf die Virtualisierung. Bin ich da drin habe ich Zugriff auf alle VMs.
Ist wie mit der Henne und dem Ei...
Also wenn du ne halbwegs grosse umgebung hast, hast du VMware auch AD Anmeldungsbasierend angebunden oder? Somit wer das AD Knackt, knackt dir auch dein VMware. Und wer die das AD Knackt, hat eh auf alle VMs zugriff dann als domain admin.... und auf alle hardware server etc...
Somit musst du alle aspekte beachten.
Optimal auch ein VLAN für die IT, nur von dort ist Management Zugriff erlaubt. Normale Clients dürfen aber nie ins IT VLAN oder Management VLAN wo z.B. VMware drin ist vCenter und so...
Und klar leider müssen viele VLANs mit DCs arbeiten, aber Managementzugriff RDP braucht keiner von aussen
und auch andere Zugriffe sind entsprechend zu checken.
Und dann kommen wir auch schon gleich zum Admin Konzept. bedeutet man meldet sich nie mit dem Domain Admin an irgend nem Client an... sondern hat gesonderte Client Admin Accounts usw..
Dann kann auch keiner die Credentials abgreifen an nem kompromitierten Client. Und wenn dann die Kennwort Richtline entsprechend ist und man 28 stelligee Domain Admin Account Passwörter hat, wirds für den hacker auch nicht so einfach nen domain admin zu knacken...
greift halt vieles ineinander, und natürlich 802.1x setzt dem dann noch die krone auf was fremdgeräte angeht, aber man kann auch sagen hat man ne ordentliche physische zugangssperre, dann ist auch schon viel gesichert in der regel... sprich besprechungszimmer im normalen client VLAN ohne hürden und ohne aufsicht was externen besuch angeht in kombo mit admin clients im selben VLAN und .... naja man kann sichs denken ... ist halt auch nicht das was man secure nennen könnte
Zitat von @ThePinky777:
Ist wie mit der Henne und dem Ei...
Also wenn du ne halbwegs grosse umgebung hast, hast du VMware auch AD Anmeldungsbasierend angebunden oder? Somit wer das AD Knackt, knackt dir auch dein VMware. Und wer die das AD Knackt, hat eh auf alle VMs zugriff dann als domain admin.... und auf alle hardware server etc...
Somit musst du alle aspekte beachten.
Optimal auch ein VLAN für die IT, nur von dort ist Management Zugriff erlaubt. Normale Clients dürfen aber nie ins IT VLAN oder Management VLAN wo z.B. VMware drin ist vCenter und so...
Und klar leider müssen viele VLANs mit DCs arbeiten, aber Managementzugriff RDP braucht keiner von aussen
und auch andere Zugriffe sind entsprechend zu checken.
Und dann kommen wir auch schon gleich zum Admin Konzept. bedeutet man meldet sich nie mit dem Domain Admin an irgend nem Client an... sondern hat gesonderte Client Admin Accounts usw..
Dann kann auch keiner die Credentials abgreifen an nem kompromitierten Client. Und wenn dann die Kennwort Richtline entsprechend ist und man 28 stelligee Domain Admin Account Passwörter hat, wirds für den hacker auch nicht so einfach nen domain admin zu knacken...
greift halt vieles ineinander, und natürlich 802.1x setzt dem dann noch die krone auf was fremdgeräte angeht, aber man kann auch sagen hat man ne ordentliche physische zugangssperre, dann ist auch schon viel gesichert in der regel... sprich besprechungszimmer im normalen client VLAN ohne hürden und ohne aufsicht was externen besuch angeht in kombo mit admin clients im selben VLAN und .... naja man kann sichs denken ... ist halt auch nicht das was man secure nennen könnte
Ist wie mit der Henne und dem Ei...
Also wenn du ne halbwegs grosse umgebung hast, hast du VMware auch AD Anmeldungsbasierend angebunden oder? Somit wer das AD Knackt, knackt dir auch dein VMware. Und wer die das AD Knackt, hat eh auf alle VMs zugriff dann als domain admin.... und auf alle hardware server etc...
Somit musst du alle aspekte beachten.
Optimal auch ein VLAN für die IT, nur von dort ist Management Zugriff erlaubt. Normale Clients dürfen aber nie ins IT VLAN oder Management VLAN wo z.B. VMware drin ist vCenter und so...
Und klar leider müssen viele VLANs mit DCs arbeiten, aber Managementzugriff RDP braucht keiner von aussen
und auch andere Zugriffe sind entsprechend zu checken.
Und dann kommen wir auch schon gleich zum Admin Konzept. bedeutet man meldet sich nie mit dem Domain Admin an irgend nem Client an... sondern hat gesonderte Client Admin Accounts usw..
Dann kann auch keiner die Credentials abgreifen an nem kompromitierten Client. Und wenn dann die Kennwort Richtline entsprechend ist und man 28 stelligee Domain Admin Account Passwörter hat, wirds für den hacker auch nicht so einfach nen domain admin zu knacken...
greift halt vieles ineinander, und natürlich 802.1x setzt dem dann noch die krone auf was fremdgeräte angeht, aber man kann auch sagen hat man ne ordentliche physische zugangssperre, dann ist auch schon viel gesichert in der regel... sprich besprechungszimmer im normalen client VLAN ohne hürden und ohne aufsicht was externen besuch angeht in kombo mit admin clients im selben VLAN und .... naja man kann sichs denken ... ist halt auch nicht das was man secure nennen könnte
Klar, ich gebe dir im Großen und Ganzen Recht, vieles baut irgendwie auf dem Anderen auf. Wir sind kein 10.000+ MA Konzern und haben keine Vorgaben umzusetzen. Trotzdem...
- AD-Login für alles: nope - vCenter, Backup, SAN etc. alles nicht mit der Domäne verbunden, sprich lokale Konten, teils mit 2FA
- Management-Zugriff: Netzwerk und Server je ein VLAN. Zugriff RDP bzw. SSH nur für bestimmte Konten bzw. Gruppen oder IP-basiert. Einige Server VMs komplett ohne RDP und SSH
- Admin Konzept: ich kann die Admin-Zugriffe an zwei Händen abzählen, Anmeldung an Clients oder gar Arbeiten mit Dom-/AD-Admin ist nicht erlaubt und jeder hält sich dran
802.1x und CA ist kein Hexenwerk. Ich hatte damit bis vor 2022 keinerlei Berührung und konnte mit den verfügbaren MS-Learn Inhalten und anderen Blogs eine interne CA und NPS aufbauen. Noch haben wir keine entsprechende Policy aber es ist fast alles vorbereitet und könnte schnell umgesetzt werden, wenn die Anforderung irgendwann da ist.
1
Moin @DerMaddin,
kleiner aber wichtiger Tipp ... mach bitte auf keinen Fall 802.1x auf den Ports, an denen auch die NAC-Steuerung selbst dran hängt. 😉🙃
Gruss Alex
Noch haben wir keine entsprechende Policy aber es ist fast alles vorbereitet und könnte schnell umgesetzt werden, wenn die Anforderung irgendwann da ist.
kleiner aber wichtiger Tipp ... mach bitte auf keinen Fall 802.1x auf den Ports, an denen auch die NAC-Steuerung selbst dran hängt. 😉🙃
Gruss Alex
2Zitat von @DerMaddin:
802.1x und CA ist kein Hexenwerk. Ich hatte damit bis vor 2022 keinerlei Berührung und konnte mit den verfügbaren MS-Learn Inhalten und anderen Blogs eine interne CA und NPS aufbauen. Noch haben wir keine entsprechende Policy aber es ist fast alles vorbereitet und könnte schnell umgesetzt werden, wenn die Anforderung irgendwann da ist.
802.1x und CA ist kein Hexenwerk. Ich hatte damit bis vor 2022 keinerlei Berührung und konnte mit den verfügbaren MS-Learn Inhalten und anderen Blogs eine interne CA und NPS aufbauen. Noch haben wir keine entsprechende Policy aber es ist fast alles vorbereitet und könnte schnell umgesetzt werden, wenn die Anforderung irgendwann da ist.
Ja andem Projekt bin ich auch dran, seit 1 Jahr
Weil Standard Clients und so kein Thema.
Aber bei ca. 250 Produktionssystemen die nicht an der Domain hängen....
ja da macht 802.1x spass, vor allem soll man die Produktion ja nicht unterbrechen...
aber hab ja nur noch 1-2 Duzend Systeme übrig...
Sehr viel spass haben auch VoiP Telefone gemacht... ultra...
da kommste dann auch bei Druckern etc zum thema 802.1x per MAC Auth...
Und dann musste alle Ports einzeln anschauen was wirklich dran hängt etc...
Kurz mal ausm Ärmel schütteln is nicht.
1
Klar, einige Endgeräte sind eine Herausforderung mit 802.1x. MAB ist hier eine Möglichkeit. Bei IP-Telefonen sehe ich da keine Probleme, das VLAN kann nur Telefonie und nichts mehr. Drucker bzw. Tischgeräte ohne aufwendige Webserver/Verwaltung sind schon knackig, bei den "großen" kann man Credentials und Zertifikate hinterlegen. Irgendwelche "Anlagen" haben wir nicht.
Wir machen NAC mit ARP-Guard. Per SNMP ist das 1000x einfacher als 802.1x.
Hier für muss das Gerät nur einmal bekannt sein. Der ganze 802.1x Krams ist nicht nötig.
Hier für muss das Gerät nur einmal bekannt sein. Der ganze 802.1x Krams ist nicht nötig.
Falls Letzteres, wie behaltet ihr den Überblick über den Kommunikationsweg?
Immer Letzteres andernfalls würdest du alle Trunk Links mit überflüssigem Broad- und Multicast Traffic aus Netzen belasten die man dort gar nicht haben will. Sowas wäre immer ein Zeichen schlechten VLAN Designs. Das Stichwort dyn. VLANs bzw. VLAN Distribution mit GVRP usw. ist oben ja schon genannt worden.
🤪🤩😛
Hab sowas erwartet 🤪
Ist ja auch alles gar nicht verkehrt, was hier alles genannt wird 😉
Aber Überregulierung kann auch nach hinten los gehen 🤪
Also:Wie geschrieben: so viele VLANs wie ihr braucht und verwaltungstechnisch vertretbar 😉
Hab sowas erwartet 🤪
Ist ja auch alles gar nicht verkehrt, was hier alles genannt wird 😉
Aber Überregulierung kann auch nach hinten los gehen 🤪
Also:Wie geschrieben: so viele VLANs wie ihr braucht und verwaltungstechnisch vertretbar 😉
und verwaltungstechnisch vertretbar 😉
m.E. ist das nicht empfehlenswert, denn vertretbar ist dann, spätestens in Anbetracht von Aufwand, Zeit und Kosten für die Pflege, eher nur ein Minimalset. VLANs können aber, gut designt, erheblich zur Sicherheit im Netz beitragen, so dass es m.E. richtig ist, über Sicherheit zu diskutieren und was das einem wert ist. Und davon ableitend dann umsetzen.Aber es ist ja wie immer in der IT: wenn die Befehlskette aus welchen Erwägungen auch immer "nein" sagt oder das Budget es einfach nicht her gibt, dann muss es eben ein Schmalspurprogramm sein.
Danke für die rege Diskussion!
Ich fasse mal zusammen.
Ich fasse mal zusammen.
- eine "Handvoll" Netze sind bei o.g. Größe nicht "Stand der Technik"
- "so viel wie nötig" Netze (je nach Anwendungsfall) wird zumindest zweistellig
- klein anfangen, gut planen
- Private VLAN (kein Zugriff der Geräte untereinander) lassen ähnliche Geräte zusammen fassen, erfordern allerdings spezielle Switche und Kenntnisse
- die zentrale Firewall verwaltet die VLAN-Berechtigungen
- die Core-Switche bekommen alle VLANs im Trunk
- die Side-Switche haben nur die jeweils notwendigen VLANs (dyn. VLANs bzw. VLAN Distribution mit GVRP)
- gut dokumentieren (Excel?): Maschine, Seriennummer, MAC Adresse, Port am Switch, VLAN...
Moin @Uwe-Kernchen,
na ja, bei gerade mal 100 Clients, solltest du es mit den VLAN's aber auch nicht zu sehr übertreiben.
Denn irgenjemand muss all diese VLANs ja auch verwalten und auch dokumentieren und je mehr du davon hast umso komplizierter wird das Ganze auch. Sprich, konzentriere dich eher darauf was wirklich nötig ist und nicht auf das was theoretisch machbar ist, sonst wirst du nie fertig. 🙃
Wenn du bisher noch nie Segmentiert hast, dann trenn doch bitte zuerst mal grob Server, Clients, Drucker, IP-Telefone u.s.w. voneinander und schau ob du das so überhaupt gehändelt bekommst.
Bist du eigentlich der einzige Admin in diesem Unternehmen?
Also ich sehe hier mom. max 10 VLAN's, vor allem bei gerade mal 100 Clients.
Das mit Private VLAN und kein Zugriff der Geräte untereinander, stimmt so pauschal nun auch nicht wirklich.
Denn es gibt bei Private VLAN's noch zwei unterschiedliche Unterkategorien und zwar einmal Isolated und einmal Community. Bei allen Geräten die in einem Isolated Unter-V-LAN eines Kopf-PVLAN's stecken, trifft deine Aussage zu, alle Geräte die jedoch Teil desselben Community Unter-V-LAN sind, können sehr wohl miteinander schnacken.
Beispiel PVLAN:
Für das Netzsegment 172.16.0.0/24 wird das Kopf-PVLAN 500 angelegt.
In diesem Kopf-VLAN 500 werden als nächstes die folgenden "Unter-PVLAN's" angelegt.
501 - Isolated
502 - Community - Gruppe A
502 - Community - Gruppe B
Bei einer solchen PVLAN Konfiguration sieht die Zugrifsmöglichkeit der Clients untereinander dann folgend aus.
Alle Clients die in das Isolated Unter-PVLAN 501 reinkommen, können weder untereinander kommunizieren noch zu den Clients aus den Community Unter-PVLAN's 501 oder 502 reibersprechen.
Alle Clients die in das Isolated Unter-PVLAN 502 reinkommen, können hingegen sehr wohl untereinander, aber nicht mit den Clients aus dem Isolated Unter-PVLAN 501 und auch nicht mit den Clients aus dem Community Unter-PVLAN's 502 kommunizieren.
Und alle Clients die in das Isolated Unter-PVLAN 503 reinkommen, können ebenfalls untereinander, aber nicht mit den Clients aus dem Isolated Unter-PVLAN 501 und auch nicht mit den Clients aus dem Community Unter-PVLAN's 501 kommunizieren.
Jetzt noch was ganz wichtiges, alle Clients die ich oben genannt habe (Unter-PVLAN 501 & 502 & 503), stecken trotz der ganzen genannten restrektionen untereinander, IP technisch dennoch weiterhin im selben Netzsegment, sprich, dem 172.16.0.0/24. 😉
Zudem muss man berücksichtigen, dass die oben genannten Kommunikationsrestrektionen zwischen den Clients/Communities innerhalb eines Kopf-PVLAN's absolut fix sind, sprich, durch ein nachfolgendes Gateway/FW nicht verändert werden können.
👍
👍 und vor allem auch so, dass diese Doku wenigstens ein anderer ITler in einer brauchbaren Zeit auch noch irgendwie entziffern kann.
Gruss Alex
Ich fasse mal zusammen.
- eine "Handvoll" Netze sind bei o.g. Größe nicht "Stand der Technik"
na ja, bei gerade mal 100 Clients, solltest du es mit den VLAN's aber auch nicht zu sehr übertreiben.
Denn irgenjemand muss all diese VLANs ja auch verwalten und auch dokumentieren und je mehr du davon hast umso komplizierter wird das Ganze auch. Sprich, konzentriere dich eher darauf was wirklich nötig ist und nicht auf das was theoretisch machbar ist, sonst wirst du nie fertig. 🙃
Wenn du bisher noch nie Segmentiert hast, dann trenn doch bitte zuerst mal grob Server, Clients, Drucker, IP-Telefone u.s.w. voneinander und schau ob du das so überhaupt gehändelt bekommst.
Bist du eigentlich der einzige Admin in diesem Unternehmen?
* "so viel wie nötig" Netze wird zumindest deutlich zweistellig
Also ich sehe hier mom. max 10 VLAN's, vor allem bei gerade mal 100 Clients.
* Private VLAN (kein Zugriff der Geräte untereinander) lassen ähnliche Geräte zusammen fassen, erfordern allerdings spezielle Switche und Kenntnisse
Das mit Private VLAN und kein Zugriff der Geräte untereinander, stimmt so pauschal nun auch nicht wirklich.
Denn es gibt bei Private VLAN's noch zwei unterschiedliche Unterkategorien und zwar einmal Isolated und einmal Community. Bei allen Geräten die in einem Isolated Unter-V-LAN eines Kopf-PVLAN's stecken, trifft deine Aussage zu, alle Geräte die jedoch Teil desselben Community Unter-V-LAN sind, können sehr wohl miteinander schnacken.
Beispiel PVLAN:
Für das Netzsegment 172.16.0.0/24 wird das Kopf-PVLAN 500 angelegt.
In diesem Kopf-VLAN 500 werden als nächstes die folgenden "Unter-PVLAN's" angelegt.
501 - Isolated
502 - Community - Gruppe A
502 - Community - Gruppe B
Bei einer solchen PVLAN Konfiguration sieht die Zugrifsmöglichkeit der Clients untereinander dann folgend aus.
Alle Clients die in das Isolated Unter-PVLAN 501 reinkommen, können weder untereinander kommunizieren noch zu den Clients aus den Community Unter-PVLAN's 501 oder 502 reibersprechen.
Alle Clients die in das Isolated Unter-PVLAN 502 reinkommen, können hingegen sehr wohl untereinander, aber nicht mit den Clients aus dem Isolated Unter-PVLAN 501 und auch nicht mit den Clients aus dem Community Unter-PVLAN's 502 kommunizieren.
Und alle Clients die in das Isolated Unter-PVLAN 503 reinkommen, können ebenfalls untereinander, aber nicht mit den Clients aus dem Isolated Unter-PVLAN 501 und auch nicht mit den Clients aus dem Community Unter-PVLAN's 501 kommunizieren.
Jetzt noch was ganz wichtiges, alle Clients die ich oben genannt habe (Unter-PVLAN 501 & 502 & 503), stecken trotz der ganzen genannten restrektionen untereinander, IP technisch dennoch weiterhin im selben Netzsegment, sprich, dem 172.16.0.0/24. 😉
Zudem muss man berücksichtigen, dass die oben genannten Kommunikationsrestrektionen zwischen den Clients/Communities innerhalb eines Kopf-PVLAN's absolut fix sind, sprich, durch ein nachfolgendes Gateway/FW nicht verändert werden können.
* die zentrale Firewall verwaltet die VLAN-Berechtigungen
👍
* gut dokumentieren (Excel?): Maschine, Seriennummer, MAC Adresse, Port am Switch, VLAN...
👍 und vor allem auch so, dass diese Doku wenigstens ein anderer ITler in einer brauchbaren Zeit auch noch irgendwie entziffern kann.
Gruss Alex
Ja, das ist gut zusammen gefasst wie ich finde.
Ich würde als Gateway auch nichts anderes als eine Firewall nutzen, es sei denn die Performance und das Budget lassen es nicht anders zu.
Ich würde als Gateway auch nichts anderes als eine Firewall nutzen, es sei denn die Performance und das Budget lassen es nicht anders zu.
Wenn du bisher noch nie Segmentiert hast
Damit stoße ich an Grenzen.
Bist du eigentlich der einzige Admin ...
ich sehe hier mom. max 10 VLAN's, vor allem bei gerade mal 100 Clients.
Wir haben min. 40 Außenstandorte mit Anlagen, nur selten mit PCs.
4 VM-Hosts, ca. 25 Server.
In der DMZ tummelt sich jetzt die E-Tankstelle mit der Alarmanlage, das Gäste-WLAN mit dem MDM-Gateway.
Das ist mein Problem.
Auf einer Kläranlage (bis jetzt 100% vom Internet getrennt) soll jetzt IRMA Anomalieerkennung installiert werden. Natürlich mit Internetzugang. Das ist mein Problem.
Aber "keep it simple" sollte immer noch gelten, also nicht übertreiben ist schon klar.
Danke für die vielen Hinweise.
Ich würde den Sack jetzt zu machen?
Gruß Uwe
Moin Uwe,
na ja, wenn ich das richtige sehe ...
Ja, ein halber interner Thirst-Level und ich als halber Externer.
... dann habt ihr für ein sehr umfangreiches Segmentierungsprojekt auch nicht wirklich die nötige Kapazität.
Denn ausser diesem Thema, habt ihr beide ja sicherlich noch andere Dinge täglich zu tun, die wahrscheinlich auch nicht weniger werden.
Und so gut wie alles was hier bisher besprochen/empfohlen wurde, würde eben genau diese anderen Dinge auch
etwas komplizierter machen, sprich, primär euch beiden noch mehr Haare vom Kopf fressen.
Ich kann euch nur dringendst empfehlen für dieses Projekt einen fähigen Dienstleister zu suchen,
der euch zumindest bei der Plannung etwas unter die Arme greift.
Und was haben die 40 Aussenstandorte nun mit der Segmentierung der so wie es aussieht Hauptstelle zu tun?
Die sind doch wahrscheinlich eh per S2S VPN angebunden.
Oder?
Stehen die alle an einem Standort?
OK, dann pack doch als Nächstes mal die E-Tankstelle, die Alarmanlage, das Gäste-WLAN und das MDM-Gateway, in jeweils eigene VLAN's.
Dann hast du diese Kuh schon mal vom Eis und so kompliziert und aufwendig, sollte diese Aktion auch nicht sein.
Das bleibt dir überlassen, man kann auch bei gelösten Beiträgen ja trotzdem noch was Nachposten.
Und wenn nicht, auch nicht schlimm.
Dann bekommst du höchstens nach einer Zeit von unserem Putzteufelchen eine kleine Aufräum-Aufforderung. 🙃
Gruss Alex
Doch, aber eben Minimal. Prozessnetz, Büronetz, DMZ.
Damit stoße ich an Grenzen.
Damit stoße ich an Grenzen.
na ja, wenn ich das richtige sehe ...
Bist du eigentlich der einzige Admin ...
... dann habt ihr für ein sehr umfangreiches Segmentierungsprojekt auch nicht wirklich die nötige Kapazität.
Denn ausser diesem Thema, habt ihr beide ja sicherlich noch andere Dinge täglich zu tun, die wahrscheinlich auch nicht weniger werden.
Und so gut wie alles was hier bisher besprochen/empfohlen wurde, würde eben genau diese anderen Dinge auch
etwas komplizierter machen, sprich, primär euch beiden noch mehr Haare vom Kopf fressen.
Ich kann euch nur dringendst empfehlen für dieses Projekt einen fähigen Dienstleister zu suchen,
der euch zumindest bei der Plannung etwas unter die Arme greift.
Wir haben min. 40 Außenstandorte mit Anlagen, nur selten mit PCs.
Und was haben die 40 Aussenstandorte nun mit der Segmentierung der so wie es aussieht Hauptstelle zu tun?
Die sind doch wahrscheinlich eh per S2S VPN angebunden.
Oder?
4 VM-Hosts, ca. 25 Server.
Stehen die alle an einem Standort?
In der DMZ tummelt sich jetzt die E-Tankstelle mit der Alarmanlage, das Gäste-WLAN mit dem MDM-Gateway.
Das ist mein Problem.
Das ist mein Problem.
OK, dann pack doch als Nächstes mal die E-Tankstelle, die Alarmanlage, das Gäste-WLAN und das MDM-Gateway, in jeweils eigene VLAN's.
Dann hast du diese Kuh schon mal vom Eis und so kompliziert und aufwendig, sollte diese Aktion auch nicht sein.
Ich würde den Sack jetzt zu machen?
Das bleibt dir überlassen, man kann auch bei gelösten Beiträgen ja trotzdem noch was Nachposten.
Und wenn nicht, auch nicht schlimm.
Dann bekommst du höchstens nach einer Zeit von unserem Putzteufelchen eine kleine Aufräum-Aufforderung. 🙃
Gruss Alex
Ja, ein Kapazitätsproblem ist das ganz klar.
Bilden, testen, umsetzen... nicht ohne!
Ein "schönes" Netzwerk ist mir schon wichtig.
Aber da gehen nur kleine Schritte oder vielleicht wirklich externe Hilfe.
Die Außenstandorte sind meist separate Netze und haben so gesehen nichts mehr mit der Segmentierung zu tun, da hast du Recht.
Aber auch an einem Standort sind manchmal mehrere Gebäude und verschiedene Anwendungen in einem Netz.
Eine Kläranlage baut aus, neues Rechenwerk, BHKW, Pumpwerk.
Das würde ich gleich trennen.
Ansonsten klein anfangen, das denke ich auch.
Gruß Uwe
Bilden, testen, umsetzen... nicht ohne!
Ein "schönes" Netzwerk ist mir schon wichtig.
Aber da gehen nur kleine Schritte oder vielleicht wirklich externe Hilfe.
Die Außenstandorte sind meist separate Netze und haben so gesehen nichts mehr mit der Segmentierung zu tun, da hast du Recht.
Aber auch an einem Standort sind manchmal mehrere Gebäude und verschiedene Anwendungen in einem Netz.
Eine Kläranlage baut aus, neues Rechenwerk, BHKW, Pumpwerk.
Das würde ich gleich trennen.
Ansonsten klein anfangen, das denke ich auch.
Gruß Uwe
3
Moin @Uwe-Kernchen,
vor allem das mit der Kapazität, solltest du bei einem solchen Unterfangen am wenigsten unterschätzen.
Denn ansonsten geht der Schuss auch ganz schnell nach hinten los. 😔
Ja, das stimmt ... dafür wird es in der IT aber auch nie wirklich langweilig. 😁
👍
Also ja, in der Gesamtplannung gehören die Standorte und deren VLAN's natürlich mit berüchsichtigt und diese sollte auch als erstes gemacht werden und genau an diesem Punkt würde ich euch auch eher eine kompetente externe Unterstützung empfehlen, damit ihr im Nachgang nicht zu viel umbauen müsst.
By the way, kann es sein, dass du bei einer Kommune arbeitest?
Jup, schön einen Schritt nach dem anderen, vor allem am Anfang, sonst fliegt man auch in der IT, ganz schnell auf die Schnauze. 🙃
Gruss Alex
Ja, ein Kapazitätsproblem ist das ganz klar.
vor allem das mit der Kapazität, solltest du bei einem solchen Unterfangen am wenigsten unterschätzen.
Denn ansonsten geht der Schuss auch ganz schnell nach hinten los. 😔
Bilden, testen, umsetzen... nicht ohne!
Ja, das stimmt ... dafür wird es in der IT aber auch nie wirklich langweilig. 😁
Ein "schönes" Netzwerk ist mir schon wichtig.
Aber da gehen nur kleine Schritte oder vielleicht wirklich externe Hilfe.
Aber da gehen nur kleine Schritte oder vielleicht wirklich externe Hilfe.
👍
Die Außenstandorte sind meist separate Netze und haben so gesehen nichts mehr mit der Segmentierung zu tun, da hast du Recht.
Aber auch an einem Standort sind manchmal mehrere Gebäude und verschiedene Anwendungen in einem Netz.
Eine Kläranlage baut aus, neues Rechenwerk, BHKW, Pumpwerk.
Das würde ich gleich trennen.
Aber auch an einem Standort sind manchmal mehrere Gebäude und verschiedene Anwendungen in einem Netz.
Eine Kläranlage baut aus, neues Rechenwerk, BHKW, Pumpwerk.
Das würde ich gleich trennen.
Also ja, in der Gesamtplannung gehören die Standorte und deren VLAN's natürlich mit berüchsichtigt und diese sollte auch als erstes gemacht werden und genau an diesem Punkt würde ich euch auch eher eine kompetente externe Unterstützung empfehlen, damit ihr im Nachgang nicht zu viel umbauen müsst.
By the way, kann es sein, dass du bei einer Kommune arbeitest?
Ansonsten klein anfangen, das denke ich auch.
Jup, schön einen Schritt nach dem anderen, vor allem am Anfang, sonst fliegt man auch in der IT, ganz schnell auf die Schnauze. 🙃
Gruss Alex
Ich bin selbständig und arbeite bei meiner Frau.
Die Kunden sind kleinere Wasserverbände.
Hab gerade mit einem Kollegen aus der Industrie gesprochen.
Er schwört auf MAC-based VLANs und sie haben ca. 1000(!) VLANs.
Er sagt: homogene Switchlandschaften, dann gibt es Management-Tools von Cisco, HP und Co.
Mal weiter gebohrt... nö, er dokumentiert die VLANs mit EXCEL. 🙃
Gruß Uwe
Die Kunden sind kleinere Wasserverbände.
Hab gerade mit einem Kollegen aus der Industrie gesprochen.
Er schwört auf MAC-based VLANs und sie haben ca. 1000(!) VLANs.
Er sagt: homogene Switchlandschaften, dann gibt es Management-Tools von Cisco, HP und Co.
Mal weiter gebohrt... nö, er dokumentiert die VLANs mit EXCEL. 🙃
Gruß Uwe
Moin Uwe,
ist im grunde auch egal, den am Ende kochen alle auch nur mit Wasser ...
... oder Excel. 🤪
Na ja, bei 1000 VLAN's haben die sicher auch ein paar mehr Mitarbeitern in der IT sitzen, die auch deutlich mehr Clients/Anwender betreuen müssen.
Ähm ja, dazu fällt mir der folgende Beitrag eines Kollegen gerade ein ...
CISCO Catalyst Center (ehem. DNA-Center)
... 🙃
Gruss Alex
Ich bin selbständig und arbeite bei meiner Frau.
Die Kunden sind kleinere Wasserverbände.
Die Kunden sind kleinere Wasserverbände.
ist im grunde auch egal, den am Ende kochen alle auch nur mit Wasser ...
Mal weiter gebohrt... nö, er dokumentiert die VLANs mit EXCEL. 🙃
... oder Excel. 🤪
Er schwört auf MAC-based VLANs und sie haben ca. 1000(!) VLANs.
Na ja, bei 1000 VLAN's haben die sicher auch ein paar mehr Mitarbeitern in der IT sitzen, die auch deutlich mehr Clients/Anwender betreuen müssen.
Er sagt: homogene Switchlandschaften, dann gibt es Management-Tools von Cisco, HP und Co.
Ähm ja, dazu fällt mir der folgende Beitrag eines Kollegen gerade ein ...
CISCO Catalyst Center (ehem. DNA-Center)
... 🙃
Gruss Alex
Wie gesagt, ein SNMP based NAC erleichtert viel da die Access Switche nicht mehr konfiguriert werden müssen.
1
