AirSnitch knackt WLAN: Warum „Client Isolation“ oft nur Beruhigungstablette ist

Wenn du in einem Café im „Free Wi‑Fi“ hängst, tröstet dich ein Satz im Router-Menü besonders zuverlässig: Client Isolation. Klingt nach „die Gäste sehen sich gegenseitig nicht“ – also: safe.

Das Problem: Viele WLANs verkaufen Isolation als Schalter, nicht als Sicherheitsmodell. Ich nenne das Muster hier „AirSnitch“: eine Sammlung ganz realer Wege, wie „Client Isolation“ in typischen Setups umgangen wird — nicht mit Hollywood-Hacks, sondern mit Protokolldetails, Fehlkonfigurationen und dem Umstand, dass „Isolation“ oft nur für eine Ebene gilt. [1]

Was Isolation wirklich (nicht) garantiert

Client Isolation verhindert typischerweise, dass zwei WLAN-Clients direkt miteinander sprechen (L2/L3 innerhalb des gleichen SSID-Segments). Sie verhindert aber nicht automatisch:

  • dass du über andere Wege im lokalen Netz landest (Captive Portal, DNS/ARP-Spielchen, Routing-Fallen)
  • dass ein Angreifer dich in ein Evil‑Twin‑Netz lockt
  • dass deine eigenen Geräte durch „praktische“ Freigaben (AirDrop/SMB/Printer) zur offenen Tür werden

    Die einzige brauchbare Heuristik

    Öffentliches WLAN ist per Default ein feindliches Netz. Wenn du es nutzen musst: VPN an, Sharing aus, Updates aktuell, und nichts tun, was du nicht auch auf einem fremden LAN tun würdest. [2]

Mini-Checkliste (30 Sekunden, die sich lohnen): [3]

  • „Privates WLAN“/„MAC randomization“ am Handy aktivieren [4] [5]
  • Auto-Join für offene Netze aus
  • Wenn möglich: eigener Hotspot statt Fremdnetz

    Isolation ist nicht gleich Verschlüsselung (und warum das wichtig ist)

    Ein häufiger Denkfehler: „Wenn die Clients isoliert sind, kann mir niemand was.“

Falsch – Isolation ist Trennung, nicht Schutz vor Mitlesen.

  • In einem offenen WLAN (ohne WPA2/WPA3) ist der Funkverkehr prinzipiell ein Partygespräch. Isolation kann verhindern, dass Geräte direkt miteinander reden – aber sie verhindert nicht automatisch, dass jemand auf dem gleichen Funkkanal Traffic beobachtet, Metadaten sammelt oder dich in die falsche Richtung schubst (DNS, Captive-Portal-Tricks, Evil Twin). [3]
  • In einem verschlüsselten WLAN (WPA2/WPA3) ist Mitlauschen deutlich schwerer – aber dann ist die Frage: Wer darf sich überhaupt einloggen? Ein gemeinsames Passwort in einem Café ist besser als „open“, aber immer noch eine Einladung an „alle, die’s wissen“. [2] Wenn du nur eine einzige Regel mitnimmst, dann diese: „Client Isolation“ ist ein Komfort-Feature für Betreiber, nicht dein Sicherheitsgurt als Nutzer. Dein Sicherheitsgurt ist: Verschlüsselung + Ende-zu-Ende (HTTPS) + VPN + saubere Geräteeinstellungen.

Praktisch bedeutet das (kurz, aber ernst gemeint):

  • Laptop: Netzwerkprofil auf „Öffentlich“, eingehende Verbindungen blocken (Firewall an), Datei-/Druckerfreigaben aus.
  • Mac: AirDrop auf „Aus“ oder „Nur Kontakte“, Freigaben/Remote Login aus, Firewall aktiv.
  • Windows: „Netzwerkprofil: Öffentlich“, „Netzwerkerkennung“ aus, SMB-Freigaben aus.
  • Phone: Hotspot/WLAN-Sharing-Funktionen aus, Auto-Join für offene Netze deaktivieren. Und ja: VPN ist nicht optional, wenn du im Fremdnetz arbeitest. Es macht das WLAN nicht „vertrauenswürdig“, aber es reduziert die Angriffsfläche drastisch, weil es Traffic bündelt und Manipulation schwieriger macht.

Die stille Angriffsfläche: Discovery & Sharing im Gäste-WLAN

Isolation hin oder her: Die meisten „WLAN-Vorfälle“ entstehen nicht, weil jemand ein supergeniales Funk-Exploit zündet. Sie entstehen, weil Geräte freiwillig Dinge anbieten.

Was im privaten Netz nett ist, ist im öffentlichen Netz absurd:

  • AirDrop/„In der Nähe teilen“ auf „für alle“
  • SMB-/Dateifreigaben (Windows/Mac)
  • Drucker im Netz, die ohne Auth funktionieren
  • Chromecast/AirPlay, die auf Broadcast-Discovery setzen Das wirkt harmlos, weil es nach „nur Sichtbarkeit“ aussieht. In der Praxis ist Sichtbarkeit der halbe Einstieg: Wenn ich sehe, dass da ein Service ist, kann ich versuchen, ihn zu triggern, umzuleiten oder Menschen zu überreden („Oh, du musst nur kurz diese App installieren…“).

Wenn du Betreiber*in bist und „Casting“ oder „Drucken“ anbieten willst, mach’s bewusst:

  • eigene SSID/VLAN nur für das Feature
  • klare Gerätegrenzen (nur bestimmte MACs/Rooms/Zeitslots)
  • Logging/Rate-Limits, damit Missbrauch auffällt Wenn du Nutzer*in bist: Stell dein Gerät so ein, dass es im Fremdnetz nichts anbietet**. Dann kann man dich auch weniger „finden“ – und AirSnitch & Co. werden automatisch weniger relevant, weil die Angriffsoberfläche schrumpft.

Wie „Client Isolation“ in der Praxis bricht (ohne Film-Hacker-Vibes)

Das Spannende an AirSnitch (und an der ganzen „Isolation“-Debatte) ist weniger ein einzelner Magic-Trick, sondern ein Muster: Isolation ist oft eine lokale Policy an einem Gerät – und sobald dein WLAN aus mehr als „ein Access Point, ein Netz“ besteht, entstehen Ausnahmen, Übergänge und Lecks.

Typische Klassen von Problemen, die in echten Umgebungen immer wieder auftauchen:

  1. Multicast/Broadcast ist der Hintereingang. Viele Komfort-Protokolle leben davon, dass Geräte sich im lokalen Netz „finden“ (mDNS/Bonjour, SSDP/UPnP, Chromecast‑Discovery). Wenn das nicht sauber gefiltert wird, bekommen Clients trotz Isolation genug Signal, um miteinander zu interagieren – oder zumindest, um Ziele und Services zu entdecken.

  2. „Nur kurz fürs Portal“ wird zur Dauer-Ausnahme. Captive Portals, Hotspot-Controller, Gäste-Tracking: Betreiber bauen Sonderwege ein, damit Login-Seiten, Payment, Drucker oder „Room Cast“ funktionieren. Jede Sonderregel ist eine Chance, dass aus „nur Internet“ wieder „doch lokal erreichbar“ wird.

  3. Roaming, Mesh, Repeater: ein Netz, viele Interpretationen. In Hotels/Coworking-Spaces hängen mehrere APs/Controller/Switches zusammen. Wenn Isolation nicht überall gleich umgesetzt wird (oder an einer Stelle aus Performance‑Gründen abgeschwächt), reicht ein „schwaches Glied“, damit der ganze Claim „Clients sehen sich nicht“ faktisch falsch wird.

  4. Layer-Mixups: L2 dicht, L3 offen (oder umgekehrt). Manche Implementierungen blocken nur bestimmte Traffic-Arten. Das fühlt sich im UI wie „an/aus“ an, ist technisch aber eine Sammlung von Filtern. Und Filter sind berüchtigt dafür, dass sie fast alles abdecken – bis jemand genau den fehlenden Frame/Port/Stack nutzt.

Der Takeaway: Selbst wenn dein Router „Client Isolation: ON“ sagt, ist das kein formales Sicherheitsversprechen, sondern bestenfalls eine Wahrscheinlichkeitsbremse.

Wenn du Betreiber*in bist: so wird aus „Schalter“ ein Sicherheitsmodell

Wenn du ein Gäste-WLAN verantwortest, musst du nicht sofort zum Enterprise-Stack greifen. Aber du brauchst ein paar klare Prinzipien:

  • Trenne Gäste wirklich vom Rest (VLAN/Firewall), nicht nur per AP-Checkbox. „Keine Client‑to‑Client“-Regel gehört auch auf die zentrale Firewall/Router-Ebene – dann gilt sie unabhängig davon, über welchen AP jemand gerade online ist. Auf AP‑Ebene ist das häufig als ap_isolate umgesetzt. [1]
  • Blockiere lokale Netze konsequent. Gäste sollten nicht in RFC1918‑Adressräume (192.168/10/172.16) oder interne IPv6‑Segmente routen können. Erlaube nur das, was sie brauchen: DNS, HTTP(S), ggf. NTP.
  • Reduziere Discovery-Lärm. Wenn du AirPlay/Chromecast nicht aktiv anbietest, dann filtere mDNS/SSDP. Komfort ist nett – aber im Gäste-WLAN ist Komfort sehr oft gleichbedeutend mit Angriffsfläche.
  • Offenes WLAN ist ein historischer Unfall. Wo möglich: WPA2/WPA3 statt „open“. Selbst wenn es „nur“ ein gemeinsames Passwort ist, ist das in der Praxis oft schon ein großer Schritt gegen triviale Mitlauscher-Szenarien.
  • Teste wie ein Angreifer, nicht wie ein Admin. Einmal pro Quartal: mit einem zweiten Gerät ins Gäste-WLAN, nach lokalen Services scannen, versuchen zu pingen, AirDrop/AirPlay-Visibility prüfen. Wenn du irgendwas im lokalen Netz siehst, ist die Isolation wahrscheinlich eher Marketing.

    Fazit

    „Client Isolation“ ist wie ein Schloss an der Zimmertür in einem Hostel: besser als nichts, aber nicht die Art von Sicherheit, auf der du sensible Arbeit aufbauen solltest.

Für Nutzer bleibt die Reihenfolge simpel: VPN an → Sharing aus → keine lokalen Dienste → misstrauisch bleiben.

Referenzen

  1. Quelle 1: https://git.w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
  2. Quelle 2: https://www.wi-fi.org/security
  3. Quelle 3: https://attack.mitre.org/techniques/T1557/
  4. Quelle 4: https://support.apple.com/en-us/102509
  5. Quelle 5: https://source.android.com/docs/core/connect/wifi-mac-randomization