7
VLAN Security
Hallo!
Ich habe eine Frage zum Thema VLANs und Subnetting.
Mit den "Grundregeln" bin ich zu 90% vertraut. Ich suche eine spezialisierte Lösung.
Angenommen, ich habe zwei Standorte, sagen wir einen "sicheren" und einen "unsicheren". Jeder Standort soll seine eigene Kollisionsdomain und ein eigenes VLAN erhalten. Kollisionsdomain, damit die Clients direkt über die vorhandenen Switches kommunizieren können, ohne über Router/Firewall zu gehen. VLAN, um beide Standorte deutlich zu trennen.
Beispiel:
- Sicherer Standort: VLAN10, Subnet 192.168.10.0/24
- unsicherer Standort: VLAN20, Subnet 192.168.20.0/24
Jetzt sind mehrere WLAN-APs an beiden Standorten aktiv, sollen aber auch beide Sublans "abdecken", d.h. Clients sollen sich an beiden Standorten einwählen können.
WLAN1: SSID=S1, DHCP=192.168.10.64/26, VLAN=10
WLAN2: SSID=S2, DHCP=192.168.20.64/26, VLAN=20
Z.B. soll sich ein Client, der per SSID und Kennwort VLAN 10 zugeordnet ist, auch im WLAN des "unsicheren Standorts" einwählen können. Mir ist leider nicht klar, wie man das am besten realisiert.
Variante 1:
Einfachster Fall: beide Standorte "kennen" VLAN10, sodass der AP auch am "unsicheren" Standort den authentifizierten WLAN-Client in VLAN 10 routet. Problem: Jeder kann sich an den VLAN10-Port statt des APs hängen und auf das VLAN10 zugreifen. Das ist eigentlich nicht gewünscht. (Der Standort ist eben "unsicher".)
Variante 2:
Am "Unsicheren Standort" gibt es kein VLAN10, sondern stattdessen ein VLAN11. APs am unsicheren Standort leiten entsprechende Clients in VLAN11 statt VLAN10. Damit könnten diese Clients aber nicht mehr dem Ziel-LAN zugeordnet werden, da ich in pfSense keine VLANs als Subnet eines bestehenden VLANs einrichten kann.
Ich möchte aber, dass der Client immer dieselbe IP erhält, egal ober sich am sicheren oder unsicheren Standort ins WLAN verbindet. Die Idee war, am "unsicheren" Standort zwar VLAN11 zu nutzen, aber eine IP aus dem VLAN10-Subnet zu vergeben.
Geht sowas? Vor- / Nachteile?
Ich könnte in pfSense VLAN10 und VLAN11 bridgen, aber dann hätte ich den Vorteil verloren.
VLANs scheinen nur dann Sicherheit zu bieten, wenn der Zugang zu den Switch-Ports geschützt ist. Das scheint häufig nicht erwähnt zu werden und ist gerade mein größtes Problem.
Viele Grüße,
McJoey
Ich habe eine Frage zum Thema VLANs und Subnetting.
Mit den "Grundregeln" bin ich zu 90% vertraut. Ich suche eine spezialisierte Lösung.
Angenommen, ich habe zwei Standorte, sagen wir einen "sicheren" und einen "unsicheren". Jeder Standort soll seine eigene Kollisionsdomain und ein eigenes VLAN erhalten. Kollisionsdomain, damit die Clients direkt über die vorhandenen Switches kommunizieren können, ohne über Router/Firewall zu gehen. VLAN, um beide Standorte deutlich zu trennen.
Beispiel:
- Sicherer Standort: VLAN10, Subnet 192.168.10.0/24
- unsicherer Standort: VLAN20, Subnet 192.168.20.0/24
Jetzt sind mehrere WLAN-APs an beiden Standorten aktiv, sollen aber auch beide Sublans "abdecken", d.h. Clients sollen sich an beiden Standorten einwählen können.
WLAN1: SSID=S1, DHCP=192.168.10.64/26, VLAN=10
WLAN2: SSID=S2, DHCP=192.168.20.64/26, VLAN=20
Z.B. soll sich ein Client, der per SSID und Kennwort VLAN 10 zugeordnet ist, auch im WLAN des "unsicheren Standorts" einwählen können. Mir ist leider nicht klar, wie man das am besten realisiert.
Variante 1:
Einfachster Fall: beide Standorte "kennen" VLAN10, sodass der AP auch am "unsicheren" Standort den authentifizierten WLAN-Client in VLAN 10 routet. Problem: Jeder kann sich an den VLAN10-Port statt des APs hängen und auf das VLAN10 zugreifen. Das ist eigentlich nicht gewünscht. (Der Standort ist eben "unsicher".)
Variante 2:
Am "Unsicheren Standort" gibt es kein VLAN10, sondern stattdessen ein VLAN11. APs am unsicheren Standort leiten entsprechende Clients in VLAN11 statt VLAN10. Damit könnten diese Clients aber nicht mehr dem Ziel-LAN zugeordnet werden, da ich in pfSense keine VLANs als Subnet eines bestehenden VLANs einrichten kann.
Ich möchte aber, dass der Client immer dieselbe IP erhält, egal ober sich am sicheren oder unsicheren Standort ins WLAN verbindet. Die Idee war, am "unsicheren" Standort zwar VLAN11 zu nutzen, aber eine IP aus dem VLAN10-Subnet zu vergeben.
Geht sowas? Vor- / Nachteile?
Ich könnte in pfSense VLAN10 und VLAN11 bridgen, aber dann hätte ich den Vorteil verloren.
VLANs scheinen nur dann Sicherheit zu bieten, wenn der Zugang zu den Switch-Ports geschützt ist. Das scheint häufig nicht erwähnt zu werden und ist gerade mein größtes Problem.
Viele Grüße,
McJoey
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3503201480
Url: https://administrator.de/forum/vlan-security-3503201480.html
Ausgedruckt am: 26.12.2024 um 13:12 Uhr
7 Kommentare
Neuester Kommentar
Hi,
Du sprichst von Collisiondomain, meinst aber Broadcastdomain!
Jetzt sind mehrere WLAN-APs an beiden Standorten aktiv, sollen aber auch beide Sublans "abdecken", d.h. Clients sollen sich an beiden Standorten einwählen können.
Definiere, was Du unter "Standort" verstehst! Normalerweise versteht man darunter geographisch entfernte Lokationen.
Wie sind diese Standorte untereinander verbunden? Mit welcher Technologie, Bandbreite und Geschwindigkeit?
ein Enterprise-AP routet normalerweise nicht, sondern bridget
Selbstverständlich bietet ein VLAN als solches keinen Schutz gegen unberechtigten Zugriff, wenn die unauthorisierte Person physischen Zugriff auf einen Switchport hat, an dem dieses anliegt (und zwar egal ob untagged oder tagged). Etwas anderes wird kein Mensch mit Verstand je behaupten.
Bei einem WLAN-Accesspoint muss man also entweder dafür sorgen, dass dieser bzw. der zugehörige Netzwerkport nicht im physischen Zugriff durch Unberechtigte steht oder diesen Port absichern ( z.B. mittels 802.1X, Portsecurity oder ähnlichem). Alternativ muss man halt dafür sorgen, dass keine sensiblen VLANs an diesen Netzwerkport anliegen. Die meisten WLAN-Systeme der Enterprise-Klasse bieten bspw. nicht nur die Möglichkeit, Traffic lokal auszukoppeln, sondern alternativ auch in einen Tunnel zu schieben (z.B. Capwap, GRE, SSL oder IPSec).
Gruß
sk
Zitat von @McJoey:
Jeder Standort soll seine eigene Kollisionsdomain und ein eigenes VLAN erhalten. Kollisionsdomain, damit die Clients direkt über die vorhandenen Switches kommunizieren können, ohne über Router/Firewall zu gehen.
Jeder Standort soll seine eigene Kollisionsdomain und ein eigenes VLAN erhalten. Kollisionsdomain, damit die Clients direkt über die vorhandenen Switches kommunizieren können, ohne über Router/Firewall zu gehen.
Du sprichst von Collisiondomain, meinst aber Broadcastdomain!
Jetzt sind mehrere WLAN-APs an beiden Standorten aktiv, sollen aber auch beide Sublans "abdecken", d.h. Clients sollen sich an beiden Standorten einwählen können.
Definiere, was Du unter "Standort" verstehst! Normalerweise versteht man darunter geographisch entfernte Lokationen.
Wie sind diese Standorte untereinander verbunden? Mit welcher Technologie, Bandbreite und Geschwindigkeit?
Variante 1:
Einfachster Fall: beide Standorte "kennen" VLAN10, sodass der AP auch am "unsicheren" Standort den authentifizierten WLAN-Client in VLAN 10 routet.
Einfachster Fall: beide Standorte "kennen" VLAN10, sodass der AP auch am "unsicheren" Standort den authentifizierten WLAN-Client in VLAN 10 routet.
ein Enterprise-AP routet normalerweise nicht, sondern bridget
Problem: Jeder kann sich an den VLAN10-Port statt des APs hängen und auf das VLAN10 zugreifen. Das ist eigentlich nicht gewünscht. (Der Standort ist eben "unsicher".)
...
VLANs scheinen nur dann Sicherheit zu bieten, wenn der Zugang zu den Switch-Ports geschützt ist. Das scheint häufig nicht erwähnt zu werden und ist gerade mein größtes Problem.
...
VLANs scheinen nur dann Sicherheit zu bieten, wenn der Zugang zu den Switch-Ports geschützt ist. Das scheint häufig nicht erwähnt zu werden und ist gerade mein größtes Problem.
Selbstverständlich bietet ein VLAN als solches keinen Schutz gegen unberechtigten Zugriff, wenn die unauthorisierte Person physischen Zugriff auf einen Switchport hat, an dem dieses anliegt (und zwar egal ob untagged oder tagged). Etwas anderes wird kein Mensch mit Verstand je behaupten.
Bei einem WLAN-Accesspoint muss man also entweder dafür sorgen, dass dieser bzw. der zugehörige Netzwerkport nicht im physischen Zugriff durch Unberechtigte steht oder diesen Port absichern ( z.B. mittels 802.1X, Portsecurity oder ähnlichem). Alternativ muss man halt dafür sorgen, dass keine sensiblen VLANs an diesen Netzwerkport anliegen. Die meisten WLAN-Systeme der Enterprise-Klasse bieten bspw. nicht nur die Möglichkeit, Traffic lokal auszukoppeln, sondern alternativ auch in einen Tunnel zu schieben (z.B. Capwap, GRE, SSL oder IPSec).
Gruß
sk
Der TO bringt hier leider im Eifer des Gefechts vieles durcheinander wie Kollege @sk oben schon zu Recht sagt.
Wenn man die Anforderung jetzt richtig versteht und auf die eigentliche Anforderung runterbricht geht es ja lediglich um ein bzw. zwei WLANs die im MSSID Betrieb arbeiten und die Zuweisung von Usern zu den entsprechenden MSSID WLANs und damit zu den VLANs.
Die Verhaltensweisen sind dann aber sehr einfach:
Option 1.) ist eine statische MSSID Zuweisung wie oben schon geschildert.
MSSID1 mappt auf VLAN 10 und MSSID2 mappt auf VLAN 20.
Hier ist jetzt die SSID (WLAN Name) entscheident.
Wenn die SSIDs in beiden Standort unterschiedliche Namen haben wird bei jedem User ein entsprechendes WLAN Profil angelegt. Insgesamt hat also jeder User 4 einzelnen WLAN Profile auf dem Endgerät und bestimmt so über die WLAN SSID die er wählt in welches WLAN bzw. dann VLAN er sich verbindet.
Option2) wäre ein Setup OHNE MSSIDs aber mit dynamischer VLAN Zuweisung der Clients über WPA-Enterprise und Radius im WLAN.
Hier bestimmt dann nicht die SSID sondern der 802.1x Username oder die Mac Adresse des Endgerätes in welches VLAN der Nutzer gemappt wird.
VLAN übergreifende Aktivitäten von bestimmten Usern regelt in beiden Optionen dann ein Router oder eine Firewall die die beiden VLANs 10 und 20 mit einem bestimmten Regelwerk routingtechnisch verbindet.
Eigentlich eine sehr einfache und überschaubare Logik!
Wenn man die Anforderung jetzt richtig versteht und auf die eigentliche Anforderung runterbricht geht es ja lediglich um ein bzw. zwei WLANs die im MSSID Betrieb arbeiten und die Zuweisung von Usern zu den entsprechenden MSSID WLANs und damit zu den VLANs.
Die Verhaltensweisen sind dann aber sehr einfach:
Option 1.) ist eine statische MSSID Zuweisung wie oben schon geschildert.
MSSID1 mappt auf VLAN 10 und MSSID2 mappt auf VLAN 20.
Hier ist jetzt die SSID (WLAN Name) entscheident.
Wenn die SSIDs in beiden Standort unterschiedliche Namen haben wird bei jedem User ein entsprechendes WLAN Profil angelegt. Insgesamt hat also jeder User 4 einzelnen WLAN Profile auf dem Endgerät und bestimmt so über die WLAN SSID die er wählt in welches WLAN bzw. dann VLAN er sich verbindet.
Option2) wäre ein Setup OHNE MSSIDs aber mit dynamischer VLAN Zuweisung der Clients über WPA-Enterprise und Radius im WLAN.
Hier bestimmt dann nicht die SSID sondern der 802.1x Username oder die Mac Adresse des Endgerätes in welches VLAN der Nutzer gemappt wird.
VLAN übergreifende Aktivitäten von bestimmten Usern regelt in beiden Optionen dann ein Router oder eine Firewall die die beiden VLANs 10 und 20 mit einem bestimmten Regelwerk routingtechnisch verbindet.
Eigentlich eine sehr einfache und überschaubare Logik!
Ja, mag ein paar Begriffe durcheinander bringen. Seit den 80ern hat sich einiges getan.
Dem TO geht es eigentlich eher um die Sicherheit, nicht darum, wie die Zuweisung erfolgt. Letztere ist klar, ich habe einen WLC, die Zuweisung erfolgt dynamisch (Option 2).
Nun ist ein Client über ein einen AP in meinem Büro angemeldet/verbunden und in VLAN 10 gemappt. Perfekt. Er bewegt sich jetzt aber in den "unsicheren" Bereich (z.B. Ferienwohnung). Dort ist auch ein AP. Wenn jetzt der Switch in der Ferienwohnung (an dem der AP angeschlossen ist) einfach nur VLAN 10 über den Trunk weiterleitet, dann kann jeder Angreifer ebenfalls auf das gesamte VLAN 10 zugreifen, in dem er den passenden Switch-Port nutzt. Darum gings mir.
Da der Switch in der Ferienwohnung unsicher ist, darf an diesem gar kein VLAN 10 "anliegen".
Meine erste Idee war dann eben ein eigenes VLAN 11 für diesen Fall, und das Routing in pfSense. Das klappte nur mit den IP-Adressen nicht.
Aber @sk hat ja schon eine Lösung genannt: der AP tunnelt den Datenverkehr.
Viele Grüße
McJoey
Dem TO geht es eigentlich eher um die Sicherheit, nicht darum, wie die Zuweisung erfolgt. Letztere ist klar, ich habe einen WLC, die Zuweisung erfolgt dynamisch (Option 2).
Nun ist ein Client über ein einen AP in meinem Büro angemeldet/verbunden und in VLAN 10 gemappt. Perfekt. Er bewegt sich jetzt aber in den "unsicheren" Bereich (z.B. Ferienwohnung). Dort ist auch ein AP. Wenn jetzt der Switch in der Ferienwohnung (an dem der AP angeschlossen ist) einfach nur VLAN 10 über den Trunk weiterleitet, dann kann jeder Angreifer ebenfalls auf das gesamte VLAN 10 zugreifen, in dem er den passenden Switch-Port nutzt. Darum gings mir.
Da der Switch in der Ferienwohnung unsicher ist, darf an diesem gar kein VLAN 10 "anliegen".
Meine erste Idee war dann eben ein eigenes VLAN 11 für diesen Fall, und das Routing in pfSense. Das klappte nur mit den IP-Adressen nicht.
Aber @sk hat ja schon eine Lösung genannt: der AP tunnelt den Datenverkehr.
Viele Grüße
McJoey
Wenn jetzt der Switch in der Ferienwohnung (an dem der AP angeschlossen ist) einfach nur VLAN 10 über den Trunk weiterleitet, dann kann jeder Angreifer ebenfalls auf das gesamte VLAN 10 zugreifen
Nein, das kann er nicht!Der AP macht ja die Authentisierung und weist diesem Client dann dynamisch das VLAN 10 zu bzw. tagged einzig nur den spezifischen Traffic dieses einzelnen Users mit der ID 10, die der Switch dann natürlich nutz um den Traffic ins VLAN 10 zu forwarden. Klassischer Standard also.
Ein 2ter User hat eine andere User ID und bekommt ggf. dann eine andere VLAN ID zugewiesen oder auch die 10. Die VLAN Nutzung ist doch rein User bezogen und bestimmen immer nur die User Credentials im Radius Server! Hier irrst du also was potentielle Angreifer angeht...
Da der Switch in der Ferienwohnung unsicher ist
Das ist dann aber ein ganz anderes Problem was ja erstmal mit dem Primären nichts zu tun hat. Und WAS genau ist unsicher für dich?? Keine User Authenthisierung? Keine Port Authentisierung? Keine...?Vermutlich geht es dir aber um die Absicherung der Switchports selber an dem der oder die APs angeschlossen sind.
darf an diesem gar kein VLAN 10 "anliegen".
Gut, das VLAN 10 liegt ja auch nur tagged an. Ein Angreifer müsste also schon etwas Netzwerk KnoffHoff haben um einen Client tagged zu konfigurieren aber du hast letztendich recht. Richtige Sicherheit in dem Sinne ist das natürlich nicht, keine Frage.Um den Switch abzusichern musst du dann natürlich auch 802.1x Port Security einsetzen oder du musst den AP Traffic zusätzlich tunneln mit CapWap, Capsman etc.
Einige Switches (z.B. Ruckus ICX u.a.) supporten die Zuweisung von VLANs entweder Tagged und Untagged an dem AP Port über ein Radius Attribut (U,T). Hier kann man dann sog. Multiport Authentication mit der AP Mac Adresse machen und gibt mit "U:<MgmtVLAN-ID>, T:10, T:20" dem Port via Radius mit das er UNtagged im AP Management Netz und Tagged in 10 und 20 liegt. Der AP Controller Traffic öffnet damit diesen 802.1x gesicherten Port für die 3 VLANs und sichert so den Switchport. Viele andere Hersteller supporten das ebenso.
Wenn nicht bleibt dir nur das AP Tunnelverfahren über die Mac Adresse (MAB) oder Dot1x Usernamen sofern der AP Letzteres supportet. Ist natürlich wenig skalierbar und ein Performancefresser aber dann die einzige Option wenn du Tagging nicht per Radius mitgeben kannst.
Cisco APs, sei es im Lightweight (Controller) Mode oder Standalone Mode, supporten beides natürlich problemlos!
Hallo @sk!
Stimmt, hat sich in der "alten Zeit" zu tief eingebrannt.
So ist es auch. Allerdings nicht weit und per 1GE Kabel verbunden. Denk einfach ein eine Ferienwohnung zwei Stockwerke höher.
Einfaches Cat7 Ethernet-Kabel über Netgear Managed Switches. (GS116E). Die können max. Gigabit. Mehr wird auch nicht benötigt. Innerhalb der Ferienwohnung werden zur Abdeckung 3 APs benötigt (Wände sind bis zu 80cm dick) , 2 APs müssen leider über PowerLAN angebunden werden, da kein Kabel gelegt werden kann/darf.
Okay, ist auch eigentlich völlig klar. Viele Beispiele scheinen jedoch zu implizieren, dass die Switchports geschützt sind und reden immer von erhöhter Sicherheit.
Da meine Switches keine Portsecurity unterstützen, bleibt mir nur letztere Option.
Das scheint mir eine hervorragende Lösung zu sein. Jetzt hoffe ich nur, dass meine 3702I von Cisco (via WLC) sowas können.
Danke für den Tipp!
Viele Grüße
McJoey
Stimmt, hat sich in der "alten Zeit" zu tief eingebrannt.
Jetzt sind mehrere WLAN-APs an beiden Standorten aktiv, sollen aber auch beide Sublans "abdecken", d.h. Clients sollen sich an beiden Standorten einwählen können.
Definiere, was Du unter "Standort" verstehst! Normalerweise versteht man darunter geographisch entfernte Lokationen.So ist es auch. Allerdings nicht weit und per 1GE Kabel verbunden. Denk einfach ein eine Ferienwohnung zwei Stockwerke höher.
Wie sind diese Standorte untereinander verbunden? Mit welcher Technologie, Bandbreite und Geschwindigkeit?
Einfaches Cat7 Ethernet-Kabel über Netgear Managed Switches. (GS116E). Die können max. Gigabit. Mehr wird auch nicht benötigt. Innerhalb der Ferienwohnung werden zur Abdeckung 3 APs benötigt (Wände sind bis zu 80cm dick) , 2 APs müssen leider über PowerLAN angebunden werden, da kein Kabel gelegt werden kann/darf.
Problem: Jeder kann sich an den VLAN10-Port statt des APs hängen und auf das VLAN10 zugreifen. Das ist eigentlich nicht gewünscht. (Der Standort ist eben "unsicher".) VLANs scheinen nur dann Sicherheit zu bieten, wenn der Zugang zu den Switch-Ports geschützt ist. Das scheint häufig nicht erwähnt zu werden und ist gerade mein größtes Problem.
Selbstverständlich bietet ein VLAN als solches keinen Schutz gegen unberechtigten Zugriff, wenn die unauthorisierte Person physischen Zugriff auf einen Switchport hat, an dem dieses anliegt (und zwar egal ob untagged oder tagged). Etwas anderes wird kein Mensch mit Verstand je behaupten.Okay, ist auch eigentlich völlig klar. Viele Beispiele scheinen jedoch zu implizieren, dass die Switchports geschützt sind und reden immer von erhöhter Sicherheit.
Bei einem WLAN-Accesspoint muss man also entweder dafür sorgen, dass dieser bzw. der zugehörige Netzwerkport nicht im physischen Zugriff durch Unberechtigte steht oder diesen Port absichern ( z.B. mittels 802.1X, Portsecurity oder ähnlichem). Alternativ muss man halt dafür sorgen, dass keine sensiblen VLANs an diesen Netzwerkport anliegen.
Da meine Switches keine Portsecurity unterstützen, bleibt mir nur letztere Option.
Die meisten WLAN-Systeme der Enterprise-Klasse bieten bspw. nicht nur die Möglichkeit, Traffic lokal auszukoppeln, sondern alternativ auch in einen Tunnel zu schieben (z.B. Capwap, GRE, SSL oder IPSec).
Das scheint mir eine hervorragende Lösung zu sein. Jetzt hoffe ich nur, dass meine 3702I von Cisco (via WLC) sowas können.
Danke für den Tipp!
Viele Grüße
McJoey
Hallo aqui!
Schon klar. Angriffe via WLAN sind so eher oder gar nicht möglich.
Ein Angreifer könnte aber den AP trennen und seinen eigenen Laptop stattdessen anschließen und diesen auf VLAN 10 konfigurieren. Dann hat er vollen Zugriff auf VLAN 10, sofern der Switch keine Portsecurity bietet. Das können meine Switches leider nicht, auch den Zugang zu Switch und APs kann ich nicht absichern.
Ja, über WLAN-User mach ich mir auch keine Sorgen. Nur über die, die eben physischen Zugang zum Switch oder den APs haben.
Alle Netzwerkkomponenten in der "Ferienwohnung" sind von dort frei zugänglich. Zudem haben meine Switches keine Port-Authentisierung o.ä.. Wer in diesen Räumen ist, kann aber auch einfach den ganzen Switch trennen und das Uplink-Kabel in seinen Laptop stecken. Mein internes LAN soll dadurch nicht so einfach kompromittierbar sein.
Im Grunde schon, aber dafür bräuchte ich vermutlich andere Switches.
Die bisher einfachste Überlegung ist, dass ich in diesen Räumen zwar WLAN habe, dann aber in einem dedizierten VLAN und mit anderer IP als im Büro.
Der Uplink des Switches geht in einen eigenen Port in pfSense, hier kann ich mit Firewall-Regeln sehr viel anstellen.
Eben, Security by Obscurity war noch nie meins
Erschwerend kommt hinzu, dass ich tatsächlich mit Angreifern rechnen muss
Nur, damit ich nicht schon wieder einer falschen Annahme unterliege: diese 802.1x Port Security muss der Switch von sich aus unterstützen, richtig? Dann fällt diese Option erstmal aus.
Das wird auf jeden Fall beim nächsten Switch-Kauf beachtet. Ich befürchte nur, dass das dann in Richtung Layer 3 Switch geht, und sie sind leider zurzeit außerhalb meines Budgets.
Das Tunneln scheint mir aber die tatsächlich beste Lösung zu sein, müsste doch auch ohne 802.1x gehen oder?
Das klingt wirklich toll!
Habs aber grad gesucht, das ist ne ganz andere Preisklasse. Bestimmt später mal machbar, aber aktuell... wäre das Overkill
Ich hatte in der Vergangenheit andere Situationen, wo das echt geholfen hätte. Hier passen Kosten/Nutzen leider nicht.
Jetzt bin ich etwas irritiert, worauf bezieht sich der letzte Halbsatz?
Vermutlich auf die Switches. Nein, das kann ich leider nicht.
Wenn ich einen Tunnel habe zwischen AP und pfSense, und sich der AP dazu bei pfSense authentifiziert, kann dann der AP nicht intern VLAN-getaggte Pakete über den Tunnel schicken?
Oder meinst du, dass jeder WLAN-Client einen eigenen Tunnel aufbaut und sich mit eigener MAC oder .1x Username identifiziert?
Das klingt allerdings gut!
Viele Grüße
McJoey
Zitat von @aqui:
Der AP macht ja die Authentisierung und weist diesem Client dann dynamisch das VLAN 10 zu bzw. tagged einzig nur den spezifischen Traffic dieses einzelnen Users mit der ID 10, die der Switch dann natürlich nutz um den Traffic ins VLAN 10 zu forwarden. Klassischer Standard also.
Wenn jetzt der Switch in der Ferienwohnung (an dem der AP angeschlossen ist) einfach nur VLAN 10 über den Trunk weiterleitet, dann kann jeder Angreifer ebenfalls auf das gesamte VLAN 10 zugreifen
Nein, das kann er nicht!Der AP macht ja die Authentisierung und weist diesem Client dann dynamisch das VLAN 10 zu bzw. tagged einzig nur den spezifischen Traffic dieses einzelnen Users mit der ID 10, die der Switch dann natürlich nutz um den Traffic ins VLAN 10 zu forwarden. Klassischer Standard also.
Schon klar. Angriffe via WLAN sind so eher oder gar nicht möglich.
Ein Angreifer könnte aber den AP trennen und seinen eigenen Laptop stattdessen anschließen und diesen auf VLAN 10 konfigurieren. Dann hat er vollen Zugriff auf VLAN 10, sofern der Switch keine Portsecurity bietet. Das können meine Switches leider nicht, auch den Zugang zu Switch und APs kann ich nicht absichern.
Ein 2ter User hat eine andere User ID und bekommt ggf. dann eine andere VLAN ID zugewiesen oder auch die 10. Die VLAN Nutzung ist doch rein User bezogen und bestimmen immer nur die User Credentials im Radius Server! Hier irrst du also was potentielle Angreifer angeht...
Ja, über WLAN-User mach ich mir auch keine Sorgen. Nur über die, die eben physischen Zugang zum Switch oder den APs haben.
Da der Switch in der Ferienwohnung unsicher ist
Das ist dann aber ein ganz anderes Problem was ja erstmal mit dem Primären nichts zu tun hat. Und WAS genau ist unsicher für dich?? Keine User Authenthisierung? Keine Port Authentisierung? Keine...?Alle Netzwerkkomponenten in der "Ferienwohnung" sind von dort frei zugänglich. Zudem haben meine Switches keine Port-Authentisierung o.ä.. Wer in diesen Räumen ist, kann aber auch einfach den ganzen Switch trennen und das Uplink-Kabel in seinen Laptop stecken. Mein internes LAN soll dadurch nicht so einfach kompromittierbar sein.
Vermutlich geht es dir aber um die Absicherung der Switchports selber an dem der oder die APs angeschlossen sind.
Im Grunde schon, aber dafür bräuchte ich vermutlich andere Switches.
Die bisher einfachste Überlegung ist, dass ich in diesen Räumen zwar WLAN habe, dann aber in einem dedizierten VLAN und mit anderer IP als im Büro.
Der Uplink des Switches geht in einen eigenen Port in pfSense, hier kann ich mit Firewall-Regeln sehr viel anstellen.
darf an diesem gar kein VLAN 10 "anliegen".
Gut, das VLAN 10 liegt ja auch nur tagged an. Ein Angreifer müsste also schon etwas Netzwerk KnoffHoff haben um einen Client tagged zu konfigurieren aber du hast letztendich recht. Richtige Sicherheit in dem Sinne ist das natürlich nicht, keine Frage.Eben, Security by Obscurity war noch nie meins
Erschwerend kommt hinzu, dass ich tatsächlich mit Angreifern rechnen muss
Um den Switch abzusichern musst du dann natürlich auch 802.1x Port Security einsetzen oder du musst den AP Traffic zusätzlich tunneln mit CapWap, Capsman etc.
Nur, damit ich nicht schon wieder einer falschen Annahme unterliege: diese 802.1x Port Security muss der Switch von sich aus unterstützen, richtig? Dann fällt diese Option erstmal aus.
Das wird auf jeden Fall beim nächsten Switch-Kauf beachtet. Ich befürchte nur, dass das dann in Richtung Layer 3 Switch geht, und sie sind leider zurzeit außerhalb meines Budgets.
Das Tunneln scheint mir aber die tatsächlich beste Lösung zu sein, müsste doch auch ohne 802.1x gehen oder?
Einige Switches (z.B. Ruckus ICX u.a.) supporten die Zuweisung von VLANs entweder Tagged und Untagged an dem AP Port über ein Radius Attribut (U,T). Hier kann man dann sog. Multiport Authentication mit der AP Mac Adresse machen und gibt mit "U:<MgmtVLAN-ID>, T:10, T:20" dem Port via Radius mit das er UNtagged im AP Management Netz und Tagged in 10 und 20 liegt. Der AP Controller Traffic öffnet damit diesen 802.1x gesicherten Port für die 3 VLANs und sichert so den Switchport. Viele andere Hersteller supporten das ebenso.
Das klingt wirklich toll!
Habs aber grad gesucht, das ist ne ganz andere Preisklasse. Bestimmt später mal machbar, aber aktuell... wäre das Overkill
Ich hatte in der Vergangenheit andere Situationen, wo das echt geholfen hätte. Hier passen Kosten/Nutzen leider nicht.
Wenn nicht bleibt dir nur das AP Tunnelverfahren über die Mac Adresse (MAB) oder Dot1x Usernamen sofern der AP Letzteres supportet. Ist natürlich wenig skalierbar und ein Performancefresser aber dann die einzige Option wenn du Tagging nicht per Radius mitgeben kannst.
Jetzt bin ich etwas irritiert, worauf bezieht sich der letzte Halbsatz?
Vermutlich auf die Switches. Nein, das kann ich leider nicht.
Wenn ich einen Tunnel habe zwischen AP und pfSense, und sich der AP dazu bei pfSense authentifiziert, kann dann der AP nicht intern VLAN-getaggte Pakete über den Tunnel schicken?
Oder meinst du, dass jeder WLAN-Client einen eigenen Tunnel aufbaut und sich mit eigener MAC oder .1x Username identifiziert?
Cisco APs, sei es im Lightweight (Controller) Mode oder Standalone Mode, supporten beides natürlich problemlos!
Das klingt allerdings gut!
Viele Grüße
McJoey
Zudem haben meine Switches keine Port-Authentisierung o.ä..
Oha.... dann ist so oder so ja alle sinnfrei weil dann auch bei AP Tunneling Angreifer dann sogar ungehinderten Zugang zum WLAN Controller Netz bekommen. Damit ist ja an sich die ganze Diskussion etwas sinnfrei wenn du da weiter eine völlig offene Flanke hast. Falsche Hardware dort!Security by Obscurity war noch nie meins
Dennoch setzt du dann so einen Dummswitch wider besseres Wissen ein? diese 802.1x Port Security muss der Switch von sich aus unterstützen, richtig?
Ja.Ich befürchte nur, dass das dann in Richtung Layer 3 Switch geht
Nöö, jeder popelige, managebare L2 Switch kann das. Mikrotiks haben sogar gleich einen Radius Server an Bord und fangen bei 25€ an. müsste doch auch ohne 802.1x gehen oder?
Ja, aber belässt dann den Switchport wieder ungeschützt mit Zugriff dann direkt aus WLAN Management... das ist ne ganz andere Preisklasse.
Na ja...nicht wirklich!https://www.ebay.de/itm/315121094135?epid=1167339674&itmmeta=01HPQ2A ...
https://www.ebay.de/itm/145496392494?itmmeta=01HPQ2A6FST414QCEV8ZFABE0C& ...
https://www.ebay.de/itm/176165677992?itmmeta=01HPQ2A6FSNS2NBW92PTR19YW1& ...
Hier passen Kosten/Nutzen leider nicht.
Bei popeligen 40€ für so einen Switch?worauf bezieht sich der letzte Halbsatz?
Was genau meinst du. Das Tunneling ein massiver Performancefresser ist ist ja hinreichend bekannt. Genau deshalb machen Controller ja heutzutage alle Local Termination. Gut für 3 oder 5 APs ist mit sparsamer Auslastung das sicher kein Problem. Wenn ich einen Tunnel habe zwischen AP und pfSense
Da hast du wohl was gründlich missverstanden... Der Tunnel ist immer zw. AP und WLAN Controller! Oder wo hast du gelesen das die pfSense WLAN Tunneltechniken wie CapWap usw. supportet oder WLAN Controller Support an Bord hat. kann dann der AP nicht intern VLAN-getaggte Pakete über den Tunnel schicken?
Ja, das ist ja gerade der Witz dabei. Der AP encapsuliert den gesamten Traffic inklusive Tags usw. in einem Tunnel ähnlich einem VPN. Der gesamte Traffic wird dann mit und ohne Tags am Controller in die Infrastruktur ausgekoppelt. Klassischer Standard wie man früher WLAN Controller betrieben hat.Solche banalen Basics sollte man aber schon wissen wenn man einen (WLC) Controller betreibt: 🧐
https://de.wikipedia.org/wiki/Control_And_Provisioning_of_Wireless_Acces ...
https://www.cisco.com/c/de_de/support/docs/wireless/wireless-lan-control ...
