Sophos AP6 gegen AirSnitch härten: Client-Isolation richtig planen

Die unter sophos-sa-20260421-airsnitch geführte AirSnitch-Schwachstelle betrifft AP6 in allen derzeit als betroffen eingestuften Versionen. Die tatsächliche Exposition hängt von SSID-Design, Konfiguration, Angriffsvariante und vorgelagertem Netz ab. Für AP6 sind drei injektionsorientierte Pfade relevant: GTK Abuse, Broadcast Reflection und Gateway Bouncing. AirSnitch allein ermöglicht bei AP6 keinen vollständigen Man-in-the-Middle-Angriff.

⚠️ Kein vollständiger Fix: Derzeit gibt es weder eine vollständige Mitigation noch eine Remediation oder korrigierte Version für diese Angriffsklasse. Die folgenden Massnahmen reduzieren das Risiko, beseitigen es aber nicht. Unmittelbar vor jeder Rollout-Welle den aktuellen AP6-Versions- und Behebungsstatus prüfen. Hat sich der Status geändert, stoppt man den Rollout und bewertet Schutzmassnahmen, Pilot und Rückweg neu.

Schnellweg: Zuerst den exakten Ausgangsstand sichern. Dann bei einer einzelnen Pilot-SSID Client isolation und Proxy ARP unter My Products > Wireless > SSIDs > SSID-Name > Advanced Settings prüfen beziehungsweise aktivieren. Vertrauenswürdige und nicht vertrauenswürdige Geräte auf getrennte SSIDs und VLANs legen, am Gateway Client-zu-Client-Verkehr einschliesslich möglicher Hairpin-Pfade sperren und unterstützte Anti-Spoofing-Funktionen nur nach Topologieprüfung pilotieren. WPA2/WPA3 Enterprise und 802.11w sind zusätzliche Härtungen, aber keine vollständige AirSnitch-Lösung.

Warum Client isolation allein nicht ausreicht

Die Central-Option Client isolation blockiert die Kommunikation zwischen WLAN-Geräten, die mit demselben Access Point verbunden sind. Geräte im selben Subnetz können weiterhin miteinander kommunizieren, wenn sie an unterschiedlichen Access Points hängen. Das ist die gewöhnliche lokale L2-Isolationsgrenze des AP und muss von einem gerouteten oder reflektierten Pfad unterschieden werden.

Beim Gateway Bouncing wirkt gerade die Lücke zwischen Layer 2 und Layer 3: Ein präparierter Frame wird zum Upstream-Gateway weitergeleitet und von dort zum Opfer zurückgeroutet. Eine reine Sperre der direkten Übertragung am AP deckt diesen L3-/Hairpin-Pfad nicht automatisch ab. Auch ein grüner Central-Status beweist weder eine wirksame Gateway-Regel noch Isolation über mehrere APs.

Proxy ARP lässt den AP ARP-Anfragen für verbundene WLAN-Geräte beantworten. Das reduziert die Broadcast-Exposition und ist deshalb ein wichtiger AirSnitch-Workaround. Es ersetzt jedoch weder Client-Isolation noch VLAN-Trennung, Firewall-Regeln oder eine Prüfung des Rückwegs.

Vor dem Pilot den exakten Ausgangsstand sichern

Für jede betroffene SSID hält man vor dem ersten Save mindestens Folgendes fest, idealerweise als Export oder datierter Screenshot:

• SSID-Name, Enable SSID, zugewiesene AP6 und aktivierte Frequenzbänder;
• Verschlüsselungsmodus, RADIUS-Auswahl und alle relevanten Authentifizierungswerte ohne Geheimnisse;
• bisheriger Zustand von Client isolation, Proxy ARP und 802.11w;
• Client connection-Modus und statische beziehungsweise RADIUS-gelieferte VLAN-IDs;
• AP-Uplink, erlaubte VLANs, Clientnetz, Gateway, DHCP, DNS und bestehende Gateway-/Firewall-Regeln;
• vorhandene DHCP-Snooping-, IP-Source-Guard- oder uRPF-Einstellungen samt Ports, Vertrauensrollen und Ausnahmen;
• zwei bekannte Testclients, Pilot-AP, zweiter AP und aktuell funktionierende erlaubte sowie gesperrte Verbindungen.

Diese Werte sind die Rollback-Baseline. «Vorherige Einstellungen wiederherstellen» ist nur sicher, wenn die vorherigen Checkboxen, Zuweisungen, VLANs und Regeln tatsächlich dokumentiert sind. Da Save alle der SSID zugewiesenen APs aktualisiert und Clients kurz trennen kann, begrenzt man die erste Änderung auf eine Test-SSID oder einen einzelnen Pilot-AP.

AP6-SSID in Schichten härten

1. Client isolation und Proxy ARP aktivieren

Man öffnet My Products > Wireless > SSIDs, wählt die Pilot-SSID und öffnet Advanced Settings. Unter Security aktiviert man Client isolation. Danach aktiviert man unter Quality of service Proxy ARP und speichert die Änderung zunächst nur für den geplanten Pilotumfang.

Client-Isolation schützt den direkten Pfad zwischen Clients desselben AP. Proxy ARP reduziert ARP-Broadcasts, indem der AP für die verbundenen WLAN-Geräte antwortet. Beide Einstellungen ergänzen sich, schliessen aber weder den Cross-AP-Pfad noch jede Broadcast-/Multicast-Variante oder den Weg über ein Upstream-Gateway vollständig.

Vor dem breiten Rollout prüft man Anwendungen, die lokale Erkennung benötigen, etwa Drucker-, Casting- oder andere Discovery-Dienste. Wenn eine geschäftlich notwendige Funktion ausfällt, wird weder pauschal die gesamte Härtung entfernt noch eine direkte Peer-Ausnahme angelegt. Kontrollierte Discovery oder Inter-Client-Zugriffe werden über eine separat entworfene Policy- beziehungsweise Discovery-Gateway-Lösung mit eng begrenzten Regeln geführt.

2. Vertrauenszonen mit SSIDs und VLANs trennen

Nicht vertrauenswürdige, BYOD-, IoT- und interne verwaltete Geräte gehören nicht in ein flaches gemeinsames Clientnetz. Man verwendet getrennte SSIDs und VLANs mit eigenen Sicherheitsrichtlinien und vermeidet es, vertrauenswürdige und nicht vertrauenswürdige Clients auf derselben SSID und – wo machbar – auf demselben AP zu mischen.

Central markiert den Clientverkehr nur mit der gewählten VLAN-ID; Switch, Gateway, DHCP, DNS und Regeln müssen ausserhalb von Central bereitstehen. Der vollständige Aufbau steht unter AP6-SSID mit VLAN einrichten. Eine VLAN-ID allein ist keine Sicherheitsgrenze: Erst die Gateway-/Firewall-Policy bestimmt, welche Zonen und Ziele erreichbar sind.

3. L3- und Hairpin-Pfade am Gateway sperren

Am Gateway beziehungsweise an der Firewall sperrt man Client-zu-Client-Verkehr auf Layer 3 so eng wie möglich, einschliesslich Verkehr, den das Gateway zum selben Clientnetz zurückleiten würde. Erlaubt werden nur konkret benötigte Ziele und Dienste. Logging für die Pilotregel hilft zu erkennen, ob Testverkehr tatsächlich diesen Pfad nimmt.

Das ist entscheidend: Geräte im selben VLAN können sich je nach Switching- und WLAN-Pfad direkt erreichen, ohne das Gateway zu passieren. Eine Firewall-Regel kann nur Verkehr blockieren, der die Firewall tatsächlich durchläuft. Wenn Cross-AP-Verkehr lokal gebridgt wird, muss das Design ihn mit geeigneter WLAN-, Switch- oder VLAN-Segmentierung zur kontrollierten Policy-Grenze zwingen. Eine nominelle «Client-to-client deny»-Regel ohne belegten Datenpfad ist kein Erfolgskriterium.

4. Upstream-Anti-Spoofing nur passend zur Umgebung einsetzen

Als zusätzliche Schutzschicht kommen DHCP Snooping, IP Source Guard und Gateway-Quellvalidierung wie uRPF infrage, soweit Switch beziehungsweise Gateway diese Funktionen unterstützen. Diese Kontrollen sind umgebungsabhängig: Vertrauenswürdige Uplinks, DHCP-Server, statische Clients, Relays, asymmetrisches Routing und Redundanz beeinflussen die sichere Konfiguration.

Man aktiviert sie daher nicht blind auf allen Ports. Zuerst dokumentiert man Bindings und legitime Pfade, dann testet man eine Funktion auf dem Pilotsegment. DHCP-Erneuerung, statische Geräte, Gateway-Failover und Rückweg müssen weiter funktionieren. Fehlt eine verifizierte Herstellerkonfiguration für den eingesetzten Switch oder Router, bleibt dieser Punkt offen und wird mit dessen Dokumentation oder Support geklärt.

5. Enterprise und 802.11w richtig einordnen

Bei persönlichen WPA2-, WPA3- oder gemischten persönlichen Modi kann der zwischen Clients derselben SSID geteilte Group Temporal Key für GTK Abuse missbraucht werden. Avanet empfiehlt deshalb WPA2/WPA3 Enterprise (802.1X) mit externem RADIUS statt Shared-Key-Authentifizierung. Das verbessert Zugangskontrolle und reduziert unautorisierten Zugang, beseitigt den GTK-basierten Angriffsvektor jedoch nicht. Migration und Clientkompatibilität werden im Ablauf RADIUS und WPA3 Enterprise für AP6 separat pilotiert.

802.11w ist nur für AP6-SSIDs verfügbar und schützt Management-Frames nach dem Aufbau einer sicheren Verbindung durch Verschlüsselung und Authentifizierung. Man aktiviert es nach einem Client-Kompatibilitätstest als zusätzliche Härtung. Es ist weder Datenverkehrs-Isolation noch eine Remediation für AirSnitch und darf nicht als bestandenes AirSnitch-Gate gewertet werden.

Vor dem breiten Rollout in zwei Phasen validieren

Der Pilot prüft den realen Datenpfad, nicht nur Checkboxen. Die Abnahmekriterien richten sich nach der jeweiligen Phase:

Phase 1: ein Pilot-AP und Prüfung am selben AP

1. Konfiguration: Central muss die erwarteten Werte für Client isolation, Proxy ARP, VLAN und optional 802.11w zeigen. Nur der vorgesehene Pilot-AP ist zugewiesen.
2. Freigegebene Infrastruktur: Beide Testclients erhalten die geplante IP-Konfiguration, lösen DNS auf und erreichen nur freigegebene Infrastruktur- und externe Dienste. Diese Ziele werden getrennt von den Peer-to-Peer-Tests geprüft.
3. Gleicher AP: Beide Clients werden mit dem Pilot-AP verbunden. Bei aktiviertem Client isolation muss jede direkte Client-zu-Client-Kommunikation unabhängig von Protokoll oder Dienst fehlschlagen; ein direkter Peer-Dienst ist keine zulässige Ausnahme.
4. Betrieb und Discovery: DHCP-Erneuerung sowie benötigte Druck-, Casting- oder Discovery-Abläufe prüfen. Erforderliche kontrollierte Discovery oder Inter-Client-Zugriffe müssen über eine separat entworfene Policy- beziehungsweise Discovery-Gateway-Lösung laufen, nicht über direkte Peer-Weiterleitung. Unerwartete Ausfälle zuerst dem geänderten Layer zuordnen.

Phase 2: genau ein kontrollierter zweiter AP und Cross-AP-Prüfung

1. Kontrollierte Erweiterung: Erst nach erfolgreicher Phase 1 genau einen kontrollierten zweiten AP zuweisen. Central muss nun genau diese beiden APs mit der erwarteten Konfiguration zeigen; weitere APs werden noch nicht hinzugefügt.
2. Unterschiedliche APs: Je einen Client mit jedem AP im selben Clientnetz verbinden und die Client-zu-Client-Deny-Tests wiederholen. Die Erwartung aus Client isolation ersetzt diesen Cross-AP-Test nicht.
3. Layer 3 und Hairpin: Mit Gateway-Logs oder Packet Capture belegen, ob jeder Testpfad die Policy-Grenze passiert und die vorgesehene Deny-Regel trifft, einschliesslich eines in das Clientnetz zurückgerouteten Pfads. Nicht durch absichtliches Nachbauen eines Exploits auf einem produktiven WLAN testen.
4. Wiederholung und Freigabe: Neu verbinden, mindestens einen weiteren Clienttyp testen, die Prüfungen der freigegebenen Infrastruktur wiederholen und den Konfigurationsstatus beider APs kontrollieren. Erst nach Bestehen beider Phasen in kleinen Wellen ausrollen.

Diese beiden Phasen zeigen nur, dass die definierten Kontrollen und normalen Datenpfade in dieser Umgebung wie geplant arbeiten. Sie beweisen keine vollständige Behebung von AirSnitch.

Exakt auf die Baseline zurückrollen

Bei einem Fehler stoppt man den Rollout und ändert nicht gleichzeitig SSID, VLAN, Gateway und Switch. Man entfernt zunächst weitere AP-Zuweisungen beziehungsweise begrenzt die SSID wieder auf den Pilotumfang. Danach stellt man pro geändertem Layer genau die dokumentierte Baseline wieder her:

1. Central: ursprüngliche Zustände von Client isolation, Proxy ARP und 802.11w, ursprünglichen Client-Connection-Modus, VLAN, Bänder und AP-Zuweisungen setzen.
2. Gateway/Firewall: nur die neu angelegten Pilotregeln entfernen oder die vorher gesicherten Regelpositionen, Quellen, Ziele, Dienste, Aktionen und Logging-Werte wiederherstellen.
3. Switch/Gateway-Schutz: nur die im Pilot geänderten DHCP-Snooping-, IP-Source-Guard- oder uRPF-Werte samt vorherigen Trust- und Ausnahmezuordnungen zurücksetzen.
4. Kontrolle: Central-Konfigurationsstatus abwarten und mit den bekannten Clients DHCP, DNS, erlaubte Dienste, gesperrte Ziele und bestehende SSIDs erneut prüfen.

Man löscht keine produktive SSID, kein VLAN und keine bestehende Regel als ersten Rückweg. Ist die Ausgangslage nicht eindeutig dokumentiert, stoppt man und klärt sie mit Netzwerkverantwortlichen oder Sophos Support, statt durch weitere Änderungen einen unbekannten Zustand zu erzeugen. Das AirSnitch-Risiko bleibt nach dem Rollback bestehen; der Rückweg stellt den Betrieb wieder her, er behebt die Schwachstelle nicht.