WLAN: Single SSID + Multiple VLANs = Multicast-Problem Forum Mobile IT, 62. DFN Betriebstagung, 4.3.2015 Rechenzentrum
Agenda Motivation Wie funktioniert Single SSID + Multiple VLANs? Wie funktioniert Multicast im WLAN? Was ist nun eigentlich das Problem? :) Lösungsansätze und ihre Bewertung Fazit 2
Motivation Einrichtungen, die im WLAN eduroam betreiben, haben sehr wahrscheinlich Single SSID + Multiple VLANs : Eine SSID eduroam, über RADIUS-Attribut wird einem Nutzer ein VLAN zugeordnet, WLAN-AP oder -Controller macht das Forwarding für den Nutzer in diesem entsprechenden VLAN. Das Ganze funktioniert in der Regel sehr gut, aber: Es kann erhebliche Probleme mit Multicast / Broadcast geben! User A VLAN A AP Controller User B VLAN B 3
Motivation Während Evaluationsarbeiten an WLAN-Lösungen stellten wir (RZ der TU Clausthal) fest, dass wir auf WLAN-Clients Broadcasts und Multicasts aus VLANs sahen, denen der Client gar nicht angehörte. Wir stellten fest, dass mehr als die Hälfte der getesteten WLAN-Lösungen verschiedener Hersteller diese VLAN-Leaks aufwiesen. Dinge wie IPv6-Router-Advertisements, IPv4-mDNS, Bonjour und generell fast alle Multicast- & Broadcast-Pakete wurden geleakt. Also haben wir uns mit den Ursachen für das Problem beschäftigt. 4
Wie funktioniert Single SSID + Multiple VLANs? Im klassischen eduroam-szenario wird 802.1x verwendet. Mit der Authentisierung erhält die WLAN- Infrastruktur per RADIUS-Server Informationen zum Client: RADIUS- Server Controller AP User-Name, andere RADIUS-Attribute (z. B. RFC 2868- Attribute für die VLAN-Zuordnung), die MAC ist sowieso bekannt. WLAN-Infrastruktur pflegt diese Informationen in einer Tabelle. Alle Pakete von und zu einer MAC in der Tabelle werden dem dort vermerkten VLAN zugeordnet. 5
Wie funktioniert Single SSID + Multiple VLANs? Im klassischen eduroam-szenario wird 802.1x verwendet. Mit der Authentisierung erhält die WLAN- Infrastruktur per RADIUS-Server Informationen zum Client: RADIUS- Server Controller AP User-Name, andere RADIUS-Attribute (z. B. RFC 2868- Attribute für die VLAN-Zuordnung), die MAC ist sowieso bekannt. WLAN-Infrastruktur pflegt diese Informationen in einer Tabelle. User MAC VLAN mustermann@tuclausthal.de 00:11:22:33:44:55 123 Alle Pakete von und zu einer MAC in der Tabelle werden dem dort vermerkten VLAN zugeordnet. 5
Wie funktioniert Multicast im WLAN? Bei WPA2-Enterprise (802.1x) hat jeder Client einen individuellen Schlüssel für die WPA2-Verschlüsselung. Multicast: AP soll ein einziges Paket an alle assoziierten Clients gleichzeitig senden können. Dafür gibt es Gruppenschlüssel, damit alle Clients das Paket lesen können. Es kann maximal vier Gruppenschlüssel geben. Gruppenschlüssel werden bei jeder Disassoziierung eines Clients erneuert. Broadcast wird wie Multicast behandelt. 6
Wie funktioniert Multicast im WLAN? Schlüssel 5 Bei WPA2-Enterprise (802.1x) hat jeder Client einen individuellen Schlüssel für die WPA2-Verschlüsselung. Multicast: AP soll ein einziges Paket an alle assoziierten Clients gleichzeitig senden können. Dafür gibt es Gruppenschlüssel, damit alle Clients das Paket lesen können. Schlüssel 1 Schlüssel 3 Es kann maximal vier Gruppenschlüssel geben. Gruppenschlüssel werden bei jeder Disassoziierung eines Clients erneuert. Broadcast wird wie Multicast behandelt. Schlüssel 2 Schlüssel 4 6
Wie funktioniert Multicast im WLAN? Gruppenschlüssel Bei WPA2-Enterprise (802.1x) hat jeder Client einen individuellen Schlüssel für die WPA2-Verschlüsselung. Multicast: AP soll ein einziges Paket an alle assoziierten Clients gleichzeitig senden können. Dafür gibt es Gruppenschlüssel, damit alle Clients das Paket lesen können. Es kann maximal vier Gruppenschlüssel geben. Gruppenschlüssel werden bei jeder Disassoziierung eines Clients erneuert. Broadcast wird wie Multicast behandelt. Gruppenschlüssel Gruppenschlüssel Gruppenschlüssel Gruppenschlüssel 6
Was ist nun eigentlich das Problem? :) VLAN = Abgeschlossene Broadcast-Domain; es gibt keine Layer-2-Verbindungen zwischen verschiedenen VLANs, wenn diese nicht explizit geschaltet werden. Im WLAN: Clients sind auf Grund individueller Schlüssel voneinander separiert, Forwarding zu anderen Clients im WLAN wird vom AP/Controller kontrolliert. 7
Was ist nun eigentlich das Problem? :) VLAN = Abgeschlossene Broadcast-Domain; es gibt keine Layer-2-Verbindungen zwischen verschiedenen VLANs, wenn diese nicht explizit geschaltet werden. Im WLAN: Clients sind auf Grund individueller Schlüssel voneinander separiert, Forwarding zu anderen Clients im WLAN wird vom AP/Controller kontrolliert. Aber: Bei Multicast besitzen alle Clients den gleichen Gruppenschlüssel. Was passiert, wenn Client A per RADIUS VLAN A zugeordnet wird und Client B dem VLAN B? Antwort: Client A sieht Multicasts aus VLAN B (und umgekehrt), wenn dies nicht vom Controller verhindert wird! 7
Was ist nun eigentlich das Problem? :) VLAN = Abgeschlossene Broadcast-Domain; es gibt keine Layer-2-Verbindungen zwischen verschiedenen VLANs, wenn diese nicht explizit geschaltet werden. Im WLAN: Clients sind auf Grund individueller Schlüssel voneinander separiert, Forwarding zu anderen Clients im WLAN wird vom AP/Controller kontrolliert. Aber: Bei Multicast besitzen alle Clients den gleichen Gruppenschlüssel. Was passiert, wenn Client A per RADIUS VLAN A zugeordnet wird und Client B dem VLAN B? Antwort: Client A sieht Multicasts aus VLAN B (und umgekehrt), wenn dies nicht vom Controller verhindert wird! Selbst wenn ein Controller verhindert, dass Clients aus verschiedenen VLANs gleiche Gruppenschlüssel haben: Es gibt nur vier Gruppenschlüssel was tun bei mehr als vier VLANs auf einer SSID? 7
Was ist nun eigentlich das Problem? :) VLAN = Abgeschlossene Broadcast-Domain; es gibt keine Layer-2-Verbindungen zwischen verschiedenen VLANs, wenn diese nicht explizit geschaltet werden. Im WLAN: Clients sind auf Grund individueller Schlüssel voneinander separiert, Forwarding zu anderen Clients im WLAN wird vom AP/Controller kontrolliert. Aber: Bei Multicast besitzen alle Clients den gleichen Gruppenschlüssel. Was passiert, wenn Client A per RADIUS VLAN A zugeordnet wird und Client B dem VLAN B? Antwort: Client A sieht Multicasts aus VLAN B (und umgekehrt), wenn dies nicht vom Controller verhindert wird! Selbst wenn ein Controller verhindert, dass Clients aus verschiedenen VLANs gleiche Gruppenschlüssel haben: Es gibt nur vier Gruppenschlüssel was tun bei mehr als vier VLANs auf einer SSID? Das Problem liegt im 802.11-Standard: Dort war es nicht vorgesehen, Clients verschiedenen VLANs zuzuordnen (kein 802.1q). 7
Was ist nun eigentlich das Problem? :) Schlüssel 1 Schlüssel 2 User A: Gehört zu VLAN A User B: Gehört zu VLAN B User A AP Controller User B Gruppenschlüssel Multicast/Broadcast VLAN A VLAN B 8
Was ist nun eigentlich das Problem? :) Schlüssel 1 Schlüssel 2 User A: Gehört zu VLAN A User B: Gehört zu VLAN B User A AP Controller User B Gruppenschlüssel Multicast/Broadcast VLAN A VLAN B 8
Was ist nun eigentlich das Problem? :) Schlüssel 1 Schlüssel 2 User A: Gehört zu VLAN A User B: Gehört zu VLAN B User A AP Controller User B Gruppenschlüssel Multicast/Broadcast VLAN A VLAN B 8
Was ist nun eigentlich das Problem? :) Ungewollte Weitergabe von Strukturinformationen: DHCP-Anfragen und ggf. auch Antworten werden u. U. gesehen. Ungewollte Weitergabe von Informationen möglich, die per Multicast übertragen werden (Multicast-Streams, mdns, Bonjour, IPv6-Router- Advertisements etc.). Wer geschickt Multicast-Traffic generiert, kann aus eigentlich abgeschlossenen Netzen möglicherweise Informationen an Komplizen im WLAN übertragen. Vermutlich DoS und Man-in-the-middle möglich. 9
Mögliche Angriffsszenarios: DoS für IPv6 (gefälschte RAs) Internet IPv6-Router fe80::1:1:1:1 Angreifer VLAN A VLAN B 10
Mögliche Angriffsszenarios: DoS für IPv6 (gefälschte RAs) Default-Router: fe80::1:1:1:1 Tatsächlicher Router schickt Router-Advertisements an ff02::1 (IPv6-Multicast) in VLAN A. Wireless Client in VLAN A erhält RA und stellt korrekten Default-Router ein. Internet IPv6-Router fe80::1:1:1:1 Angreifer VLAN A VLAN B 10
Mögliche Angriffsszenarios: DoS für IPv6 (gefälschte RAs) Internet Default-Router: fe80::2:2:2:2 Tatsächlicher Router schickt Router-Advertisements an ff02::1 (IPv6-Multicast) in VLAN A. Wireless Client in VLAN A erhält RA und stellt korrekten Default-Router ein. Angreifer sendet gefälschten RA (IPv6-Multicast) in VLAN B. Client in VLAN A erhält auf Grund des Leaks RA aus VLAN B und stellt falschen Default-Router ein. Client erreicht für IPv6 keinen Default-Router mehr. IPv6-Router fe80::1:1:1:1 Angreifer VLAN A VLAN B 10
Lösungsansätze und ihre Bewertung 11
Lösungsansätze und ihre Bewertung Keine Lösung: Eigener Gruppenschlüssel für jedes VLAN. - Es kann nur vier Gruppenschlüssel geben (was passiert bei mehr VLANs?). - Man braucht schon in einem einzigen VLAN mehr als einen Gruppenschlüssel, damit bei einer Schlüsselerneuerung keine Pakete verloren gehen. 11
Lösungsansätze und ihre Bewertung Keine Lösung: Eigener Gruppenschlüssel für jedes VLAN. - Es kann nur vier Gruppenschlüssel geben (was passiert bei mehr VLANs?). - Man braucht schon in einem einzigen VLAN mehr als einen Gruppenschlüssel, damit bei einer Schlüsselerneuerung keine Pakete verloren gehen. Idee 1: Konvertiere Multicasts / Broadcasts auf Layer 2 zu Unicast. - Alle Broadcasts bzw. Multicasts haben als Ziel spezielle MAC-Adressen. Konvertiere diese einfach zur Unicast-Adresse jedes assoziierten Clients und schicke jedem Client das Paket mit seinem individuellen Schlüssel. - Vorteil: Lösung funktioniert für alle Protokolle, da Layer 3 und höher keine Rolle spielen. - Nachteil: Skaliert nicht gut in Hotspots, in denen viele Clients auf einem AP assoziiert sind; es kommt zu einer unnötigen Multiplikation von Traffic. 11
Lösungsansätze und ihre Bewertung 12
Lösungsansätze und ihre Bewertung Idee 2: Schalte Multicast (weitestgehend) ab. - Vorteil: Skaliert gut in Hotspots mit vielen Clients pro AP. - Nachteile: Protokolle wie IPv6, Bonjour etc. erfordern zwingend Multicast und funktionieren nicht. Zwingend benötigte Protokolle wie DHCP bedürfen einer Sonderlösung in der AP-/Controller-Software. 12
Lösungsansätze und ihre Bewertung Idee 2: Schalte Multicast (weitestgehend) ab. - Vorteil: Skaliert gut in Hotspots mit vielen Clients pro AP. - Nachteile: Protokolle wie IPv6, Bonjour etc. erfordern zwingend Multicast und funktionieren nicht. Zwingend benötigte Protokolle wie DHCP bedürfen einer Sonderlösung in der AP-/Controller-Software. Idee 3: Konvertiere well-known Multicast-Protokolle zu Unicast und vernachlässige alles andere. - Vorteil: Guter Kompromiss zwischen Idee 1 und 2, da gezielt MC-Protokolle unterstützt werden (IPv6) und trotzdem eine einigermaßen gute Skalierung sichergestellt ist. - Nachteile: Unbekannte Protokolle funktionieren nicht. Fehleranfällig: Wird ein Protokoll nicht sauber erkannt oder unterstützt, kommt es zu ungewollten Effekten im Netz. 12
Lösungsansätze und ihre Bewertung 13
Lösungsansätze und ihre Bewertung Idee 4: Änderungen am 802.11-Standard, um VLANs zu berücksichtigen. - Sicherlich die sauberste Lösung. - Leider die unrealistischste Lösung. 13
Fazit Stand heute gibt es offensichtlich diverse Hersteller, die das Thema nicht sauber im Griff haben. Ein IPv6-Rollout ist nur mit Herstellern möglich, die das Thema korrekt implementieren, da IPv6 zwingend Multicast erfordert. Das Gleiche gilt für Bonjour oder ähnliche Protokolle. Wichtig: Prüfen Sie Ihre vorhandene WLAN-Lösung auf Sicherheit! Werden Pakete geleakt? Falls ja, bewerten Sie sorgfältig, ob Sie mit den Leaks leben können. Beim Prüfen sollten Sie auf folgende Fallstricke achten: - Werden die Einstellungen, die Sie auf Ihrer WLAN-Infrastruktur machen, auch wirklich korrekt implementiert? Wir haben erlebt, dass dies nicht der Fall war! - Glauben Sie den Optionen im Management oder den Handbüchern nicht! Prüfen Sie wirklich selbst! Jeder Betreiber einer WLAN-Infrastruktur sollte den Hersteller in die Pflicht nehmen, das Thema zu adressieren, falls er betroffen ist. 14
Vielen Dank für Ihre Aufmerksamkeit! Dipl.-Math. Christian Strauf Leiter Netzwerkabteilung Rechenzentrum Erzstraße 51 D-38678 Clausthal-Zellerfeld Telefon: (05323) 72-20 86 Telefax: (05323) 72-99 20 86 E-Mail: strauf@rz.tu-clausthal.de URL: http://www.rz.tu-clausthal.de 15