Best Practice: Firmen-Netz und Guest WLAN
Guten Morgen
Aus der Praxis für die Praxis:
Best Practice:
Grossfirmennetz hat ein Guest VLAN.
Das läuft auf einer automomen Insellösung.
Wenn einzelne Fachbereiche einen direkten Internetzugang ohne Services aus dem Firmennetz wollen, beantragen sie bei einem ISP einen Internetzugang. Somit kein Service von der Firmen IT.
Praxis:
Etwas genauer hingeschaut:
Was sind die realen Risiko (Häufigkeit / Schwere), wenn man einzelne Netzwerkgeräte direkt auf den DHCP routet?
Dort beziehen sie eine IP Adresse und können über die Firewall auf das Internet.
Probleme die ich sehe:
1. Authentifikation - wer war wann an diesem Gerät?
2. t.b.c.
Wenn man zusätzlich zum DHCP auch den DNS Server zur Verfügung stellt, wie ändert sich die Gefahrenlage für die Administratoren?
Eine Frage an die Profi Admins die in grösseren Firmennetzen Verantwortung tragen.
Beste Grüsse
Peter
Aus der Praxis für die Praxis:
Best Practice:
Grossfirmennetz hat ein Guest VLAN.
Das läuft auf einer automomen Insellösung.
Wenn einzelne Fachbereiche einen direkten Internetzugang ohne Services aus dem Firmennetz wollen, beantragen sie bei einem ISP einen Internetzugang. Somit kein Service von der Firmen IT.
Praxis:
Etwas genauer hingeschaut:
Was sind die realen Risiko (Häufigkeit / Schwere), wenn man einzelne Netzwerkgeräte direkt auf den DHCP routet?
Dort beziehen sie eine IP Adresse und können über die Firewall auf das Internet.
Probleme die ich sehe:
1. Authentifikation - wer war wann an diesem Gerät?
2. t.b.c.
Wenn man zusätzlich zum DHCP auch den DNS Server zur Verfügung stellt, wie ändert sich die Gefahrenlage für die Administratoren?
Eine Frage an die Profi Admins die in grösseren Firmennetzen Verantwortung tragen.
Beste Grüsse
Peter
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1992954825
Url: https://administrator.de/forum/best-practice-firmen-netz-und-guest-wlan-1992954825.html
Ausgedruckt am: 03.04.2025 um 09:04 Uhr
17 Kommentare
Neuester Kommentar
Morschen.
Eine komplexe Frage an der Stelle, auf die es keine einfach Antwort gibt.
Mit Aufwand ist ein hohes Maß an Sicherheit zu erreichen. Stichworte sind hier DHCP Reservierungen, Port Security, MAC Filterung, Radius, Captive Portal.
Es ist möglich die Leute innerhalb ihres Netzwerksegments (VLANs) zu halten, solange sie sich nicht manuell einfach eine IP Adresse aus einem Subnetz vergeben können, welches "mehr" kann > Port Security / MAC Filterung.
Eine Authentifizierung via Radius sollte hier schon einiges abfackeln. So könnte man ein WLAN für die Firmenangehörigen und eines für Gäste aufspannen. Das für Gäste hätte ein davor geschaltetes Captive Portal und dort wird mitgeschrieben, welches Gerät, wie lange aktiv war. Entsprechende Firewall Logs (wenn entsprechende Hardware vorhanden ist, gehe ich jetzt mal bei der Bezeichnung "Grossfirmennetz" von aus) können dann nachhalten, wohin, welche IP gewandert ist.
Hier kann dir aber entweder eure Administratoren (wenn du das nicht sein solltest) oder eben ein Systemhaus einige Ansatzpunkte liefern.
Gruß
Marc
Eine komplexe Frage an der Stelle, auf die es keine einfach Antwort gibt.
Mit Aufwand ist ein hohes Maß an Sicherheit zu erreichen. Stichworte sind hier DHCP Reservierungen, Port Security, MAC Filterung, Radius, Captive Portal.
Es ist möglich die Leute innerhalb ihres Netzwerksegments (VLANs) zu halten, solange sie sich nicht manuell einfach eine IP Adresse aus einem Subnetz vergeben können, welches "mehr" kann > Port Security / MAC Filterung.
Eine Authentifizierung via Radius sollte hier schon einiges abfackeln. So könnte man ein WLAN für die Firmenangehörigen und eines für Gäste aufspannen. Das für Gäste hätte ein davor geschaltetes Captive Portal und dort wird mitgeschrieben, welches Gerät, wie lange aktiv war. Entsprechende Firewall Logs (wenn entsprechende Hardware vorhanden ist, gehe ich jetzt mal bei der Bezeichnung "Grossfirmennetz" von aus) können dann nachhalten, wohin, welche IP gewandert ist.
Hier kann dir aber entweder eure Administratoren (wenn du das nicht sein solltest) oder eben ein Systemhaus einige Ansatzpunkte liefern.
Gruß
Marc
Moin,
@radiogugu
Aber nur weil ich eine Ip-Adresse ändere, bin ich nicht automatisch in einem anderen VLAN. Eine übergordnete Schicht im ISO/OSI kann zunächst einmal keine untere beeinflussen. Und VLANS finden im EHternet-Frame, also auf Layer 2 statt, nicht aber im IP-Frame, dem Layer 3.
Wenn du alle Menschen namens Walter in einen Raum einsperrst, können die noch so laut brüllen "Ich heiße Horst, nicht Walter.", die bleiben dann weiterhin dort eingesperrt.
@PeterGyger
Zur Lösung:
Generell ein VLAN-Aufspannen und ein Gäste-(W)LAN anbieten ist der erste Schritt. Jenes terminiert an der zentralen Firewall, nicht an internen CoreSwitches (wobei das auch ginge). DHCP und DNS werden von der Firewall bedient (oder einer dedizierten Appliance/ Unix-Kiste). Ggf. kann dies auch der WLAN-Controller übernehmen. Ergänzt wird das ganze mit einem CaptivePortal. Bindet man letzteres an einem RADIUS an, könnte man dies so definieren, dass die Leute sich mit Ihren AD-Credentials authentifizieren müssen. Dann ließen sich weitere Richtlinien implementieren. Wenn irgendwelche Maschinen mal "blank ins Netz wollen/ sollen", fällt ein CaptivePortal sicherlich weg...
@radiogugu
Es ist möglich die Leute innerhalb ihres Netzwerksegments (VLANs) zu halten, solange sie sich nicht manuell einfach eine IP Adresse aus einem Subnetz vergeben können, welches "mehr" kann > Port Security / MAC Filterung.
Die Aussage ist ja quatsch, sorry.Aber nur weil ich eine Ip-Adresse ändere, bin ich nicht automatisch in einem anderen VLAN. Eine übergordnete Schicht im ISO/OSI kann zunächst einmal keine untere beeinflussen. Und VLANS finden im EHternet-Frame, also auf Layer 2 statt, nicht aber im IP-Frame, dem Layer 3.
Wenn du alle Menschen namens Walter in einen Raum einsperrst, können die noch so laut brüllen "Ich heiße Horst, nicht Walter.", die bleiben dann weiterhin dort eingesperrt.
@PeterGyger
Wenn einzelne Fachbereiche einen direkten Internetzugang ohne Services aus dem Firmennetz wollen, beantragen sie bei einem ISP einen Internetzugang. Somit kein Service von der Firmen IT.
D. h. der Fachbereich ruft bei der Telekom, Vodafone, Deutsche Glasfaser, ... an und bestellt einen WAN-Zugang?Zur Lösung:
Generell ein VLAN-Aufspannen und ein Gäste-(W)LAN anbieten ist der erste Schritt. Jenes terminiert an der zentralen Firewall, nicht an internen CoreSwitches (wobei das auch ginge). DHCP und DNS werden von der Firewall bedient (oder einer dedizierten Appliance/ Unix-Kiste). Ggf. kann dies auch der WLAN-Controller übernehmen. Ergänzt wird das ganze mit einem CaptivePortal. Bindet man letzteres an einem RADIUS an, könnte man dies so definieren, dass die Leute sich mit Ihren AD-Credentials authentifizieren müssen. Dann ließen sich weitere Richtlinien implementieren. Wenn irgendwelche Maschinen mal "blank ins Netz wollen/ sollen", fällt ein CaptivePortal sicherlich weg...
Zitat von @em-pie:
@radiogugu
Aber nur weil ich eine Ip-Adresse ändere, bin ich nicht automatisch in einem anderen VLAN. Eine übergordnete Schicht im ISO/OSI kann zunächst einmal keine untere beeinflussen. Und VLANS finden im EHternet-Frame, also auf Layer 2 statt, nicht aber im IP-Frame, dem Layer 3.
Wenn du alle Menschen namens Walter in einen Raum einsperrst, können die noch so laut brüllen "Ich heiße Horst, nicht Walter.", die bleiben dann weiterhin dort eingesperrt.
@radiogugu
Es ist möglich die Leute innerhalb ihres Netzwerksegments (VLANs) zu halten, solange sie sich nicht manuell einfach eine IP Adresse aus einem Subnetz vergeben können, welches "mehr" kann > Port Security / MAC Filterung.
Die Aussage ist ja quatsch, sorry.Aber nur weil ich eine Ip-Adresse ändere, bin ich nicht automatisch in einem anderen VLAN. Eine übergordnete Schicht im ISO/OSI kann zunächst einmal keine untere beeinflussen. Und VLANS finden im EHternet-Frame, also auf Layer 2 statt, nicht aber im IP-Frame, dem Layer 3.
Wenn du alle Menschen namens Walter in einen Raum einsperrst, können die noch so laut brüllen "Ich heiße Horst, nicht Walter.", die bleiben dann weiterhin dort eingesperrt.
Nichts dagegen einzuwenden.
Wenn es jedoch irgendwo eine LAN Dose gibt, die untagged das Management VLAN mitführt und ich meinen Laptop einstöpsle und mir eine IP Adresse aus eben diesem LAN gebe oder ein DHCP meinem Ruf folgt, wäre ich "drin".
Es sei denn Maßnahmen wurden ergriffen.
Oft schon erlebt, dass im Besucherzimmer eine (oder alle) Netzwerkdosen ins normale Firmennetzwerk führten.
Gruß
Marc
Wenn irgendwelche Maschinen mal "blank ins Netz wollen/ sollen", fällt ein CaptivePortal sicherlich weg...
Für solche Maschinen kann man auf der Firewall ja Ausnahmen definieren.
Ansonsten finde ich es sehr befremdlich:
Best Practice:
...
Wenn einzelne Fachbereiche einen direkten Internetzugang ohne Services aus dem Firmennetz wollen, beantragen sie bei einem ISP einen Internetzugang. Somit kein Service von der Firmen IT.
...
Wenn einzelne Fachbereiche einen direkten Internetzugang ohne Services aus dem Firmennetz wollen, beantragen sie bei einem ISP einen Internetzugang. Somit kein Service von der Firmen IT.
Sowas nennt sich wohl Schatten-IT und gilt es m.M.n. mit allen Mitteln zu verhindern!
@radiogugu
Da bin ich wieder bei dir, aber dann bin ich ja außerhalb des für mich vorgesehenen VLANs.
Zusammenfassend: Security ist - wie immer - ein ganzheitliches Thema, welches nicht an der Netzwerkdose beginnt/ aufhört
Da bin ich wieder bei dir, aber dann bin ich ja außerhalb des für mich vorgesehenen VLANs.
Zusammenfassend: Security ist - wie immer - ein ganzheitliches Thema, welches nicht an der Netzwerkdose beginnt/ aufhört
@PeterGyger welche Sicherheitsmaßnahmen gibt es denn aktuell?
Oder ist nur die Policy vorhanden, dass eigene "Internetleitungen" bestellt werden?
Gruß
Marc
Oder ist nur die Policy vorhanden, dass eigene "Internetleitungen" bestellt werden?
Gruß
Marc
Das ist ja auch eine Detailfrage.
"Darf" man den DHCP Server einer Firma für Netzgeräte, welche nur auf das I-net sollen verwenden? Gibt es hier einen Admin eines grösseren Firmennetzes der sagt, dass das "denkbar" ist?
Natürlich darf man das.
Denn in der Regel lässt man für VLANs die Firewall hier auch den DHCP Server spielen oder lässt, wie @Looser27 schrieb. Mit Regelwerken lassen sich dann granular die Zugriffsmöglichkeiten erlauben / einschränken.
Was ist denn für dich ein "grösseres Firmennetz"?
Wir haben in Deutschland ca. 45 und in Polen ca. 80 Clients versorgt. Es gibt ein halbes Dutzend VLANs an jedem Standort für Abteilungen, WLAN und Besprechungsräume.
Prinzipiell skalieren die angesprochenen und angebrachten Maßnahmen sehr weit nach oben.
Gruß
Marc
Moin,
Grundsätzlich empfehle ich dir, keinerlei Geräte für Firmen als auch Guest LAN zu nutzen. Das lässt in den meisten Fällen weder die Sicherheitsvorgaben noch die DSGVO zu. Bau ein völlig dedizierte, logische Struktur davon ab, wo es keinerlei Berührungspunkte gibt.
Gruß,
Dani
"Darf" man den DHCP Server einer Firma für Netzgeräte, welche nur auf das I-net sollen verwenden? Gibt es hier einen Admin eines grösseren Firmennetzes der sagt, dass das "denkbar" ist?
obacht: Wenn es hierbei um einen Windows Server handelt, welcher als DHCP Server agiert, sind evtl. CALs erforderlich!Grundsätzlich empfehle ich dir, keinerlei Geräte für Firmen als auch Guest LAN zu nutzen. Das lässt in den meisten Fällen weder die Sicherheitsvorgaben noch die DSGVO zu. Bau ein völlig dedizierte, logische Struktur davon ab, wo es keinerlei Berührungspunkte gibt.
Eine Frage an die Profi Admins die in grösseren Firmennetzen Verantwortung tragen.
Eigenes VLAN, eigenes VRF über alle Standorte hinweg, dedizierte Internetanschlüsse, dedizierte Router von IT-Dienstleistern, welche auch das Thema HAftung ggf. übernehmen.Gruß,
Dani
Moin,
die PURs von Microsoft für das jeweilige Produkt sind wie immer die erste Anlaufstelle.
Warum glaubst du gibt es eine Windows Server CAL?
Interessant wird wenn Geräte sich verbinden, welche nicht zum Firmennetz gehören und somit erst einmal auch nicht lizenziert sind.
Gruß,
Dani
die PURs von Microsoft für das jeweilige Produkt sind wie immer die erste Anlaufstelle.
Warum glaubst du gibt es eine Windows Server CAL?
s findet ja keine Anmeldung am Windows statt....zumindest nicht im klassischen Sinn.
Das ist ein Märchen, dass sich seit 10 Jahren schon hält. Es geht dabei nicht um die Anmeldung am Windows bzw. Active Directory. Es geht bei der Windows Server CAL darum, dass ein Windows Dienst, in diesen Fall DHCP, angesprochen wird.Interessant wird wenn Geräte sich verbinden, welche nicht zum Firmennetz gehören und somit erst einmal auch nicht lizenziert sind.
Gruß,
Dani
Zitat von @PeterGyger:
Wenn man zusätzlich zum DHCP auch den DNS Server zur Verfügung stellt, wie ändert sich die Gefahrenlage für die Administratoren?
Wenn man zusätzlich zum DHCP auch den DNS Server zur Verfügung stellt, wie ändert sich die Gefahrenlage für die Administratoren?
Die Fragen machen den Eindruck, dass dir Netzwerkgrundlagen hinsichtlich der Unterschiede zwischen Firewalling/VLAN-Segmentierung und Diensten wie DHCP und DNS nicht klar sind. Ich habe schon erlebt, dass ein MAC-Filter auf einem DHCP-Server als Sicherheitsmaßnahme und Ersatz für 802.1x begriffen wurde (weil ja neue Geräte im Netzwerk "keine IP-Adresse erhielten"), deshalb der Hinweis.
Wie Netze geschützt sind, also was Geräte dort "können", und was man diesen Netzen zur Verfügung stellt, sind ganz unterschiedliche Baustellen.
Grüße
Richard

"Darf" man den DHCP Server einer Firma für Netzgeräte, welche nur auf das I-net sollen verwenden?
Dürfen sicher aber kein verantwortungvoller Admin würde ernsthaft sowas mit einem Gastnetz machen. Bestürzung und Entsetzen bei der Frage ist also durchaus berechtigt.Die Problematik ist das du dafür DHCP Relay aktivieren musst was Gast Traffic aus L3 Sicht ins Firmen Lan schleust. Ein NoGo.
@em-pie hat es oben schon richtig gesagt. Ein separate Insellösung ist Unsinn. Zumindestens im Hinblick das man dafür ein separates, reines L2 VLAN betreibt was nur auf der Firewall terminiert ist. Der WLAN Controller steuert dann den Zugriff über Voucher oder Benutzer basierten Preshared Keys inkl. Protokollierung.