Naar de inhoud
Avanet

Sophos AP6 tegen AirSnitch beveiligen: clientisolatie goed plannen

Central Wireless

De AirSnitch-kwetsbaarheid met kenmerk sophos-sa-20260421-airsnitch geldt voor alle AP6-versies die momenteel als getroffen zijn aangemerkt. De feitelijke blootstelling hangt af van SSID-ontwerp, configuratie, aanvalsvariant en het upstreamnetwerk. Voor AP6 zijn drie injectiegerichte paden relevant: GTK Abuse, Broadcast Reflection en Gateway Bouncing. AirSnitch alleen kan op AP6 geen volledige man-in-the-middle-aanval opleveren.

⚠️ Geen volledige oplossing: er is momenteel geen volledige mitigatie, herstel of gerepareerde versie voor deze aanvalsklasse. De onderstaande maatregelen verkleinen het risico, maar nemen het niet weg. Controleer direct vóór elke uitrolgolf de actuele AP6-versie- en herstelstatus. Stop de uitrol en beoordeel maatregelen, pilot en rollback opnieuw als die status is gewijzigd.

Snelle aanpak: leg eerst de exacte beginsituatie vast. Controleer of activeer op één pilot-SSID Client isolation en Proxy ARP via My Products > Wireless > SSIDs > SSID-naam > Advanced Settings. Scheid vertrouwde en niet-vertrouwde apparaten met SSID’s en VLAN’s, blokkeer client-naar-clientverkeer en mogelijke hairpinpaden op de gateway en test ondersteunde anti-spoofing pas nadat de topologie is gevalideerd. WPA2/WPA3 Enterprise en 802.11w zijn aanvullende beveiliging, geen volledige AirSnitch-oplossing.

Waarom Client isolation niet voldoende is

Client isolation blokkeert alleen communicatie tussen draadloze apparaten op hetzelfde access point. Apparaten in hetzelfde subnet kunnen nog communiceren wanneer ze met verschillende access points zijn verbonden. Dit normale lokale L2-grensvlak verschilt van een gerouteerd of gereflecteerd pad.

Bij Gateway Bouncing gaat een speciaal frame naar de upstreamgateway en wordt het via Layer 3 naar het slachtoffer teruggerouteerd. Alleen directe forwarding op het AP blokkeren dekt dit L3-/hairpinpad niet automatisch af. Een groene Central-status bewijst evenmin gatewaybeleid of isolatie tussen AP’s.

Proxy ARP laat het AP ARP-verzoeken voor verbonden draadloze apparaten beantwoorden. Dat beperkt broadcastblootstelling en is een belangrijke AirSnitch-maatregel, maar vervangt clientisolatie, VLAN-scheiding, firewallbeleid en controle van het retourpad niet.

Leg vóór de pilot de exacte uitgangssituatie vast

Noteer vóór de eerste Save voor elke betrokken SSID ten minste het volgende, bij voorkeur via een export of gedateerde screenshots:

  • SSID-naam, Enable SSID, toegewezen AP6’s en ingeschakelde frequentiebanden;
  • encryptiemodus, RADIUS-selectie en relevante authenticatiewaarden, zonder geheimen vast te leggen;
  • huidige status van Client isolation, Proxy ARP en 802.11w;
  • modus Client connection en statische of via RADIUS toegewezen VLAN-ID’s;
  • AP-uplink, toegestane VLAN’s, clientsubnet, gateway, DHCP, DNS en bestaande gateway- of firewallregels;
  • instellingen voor DHCP Snooping, IP Source Guard of uRPF, inclusief poorten, vertrouwensrollen en uitzonderingen;
  • twee bekende testclients, het pilot-AP, een tweede AP en de momenteel werkende toegestane en geblokkeerde verkeersstromen.

Deze waarden vormen de rollbackbasis. “Vorige instellingen herstellen” is alleen veilig als de eerdere selectievakjes, toewijzingen, VLAN’s en regels bekend zijn. Omdat Save alle AP’s bijwerkt die aan een SSID zijn toegewezen en clients kort kan verbreken, beperkt u de eerste wijziging tot een test-SSID of één pilot-AP.

Beveilig de AP6-SSID in lagen

1. Schakel Client isolation en Proxy ARP in

Ga naar My Products > Wireless > SSIDs, selecteer de pilot-SSID en open Advanced Settings. Schakel onder Security Client isolation in. Schakel daarna onder Quality of service Proxy ARP in en sla de wijziging eerst alleen voor de geplande pilotomvang op.

Client isolation beschermt het directe pad tussen clients op hetzelfde AP. Proxy ARP vermindert ARP-broadcasts doordat het AP namens verbonden draadloze apparaten antwoordt. De opties vullen elkaar aan, maar sluiten niet het volledige pad tussen AP’s, elke broadcast- of multicastvariant of het pad via een upstreamgateway af.

Test vóór een bredere uitrol toepassingen die lokale detectie nodig hebben, zoals printers, casting en andere discoverydiensten. Als een noodzakelijke functie uitvalt, schakel dan niet standaard alle beveiliging uit en maak geen directe peeruitzondering. Breng gecontroleerde discovery of toegang tussen clients onder in een afzonderlijk ontworpen beleids- of discoverygateway met nauw begrensde regels.

2. Scheid vertrouwenszones met SSID’s en VLAN’s

Niet-vertrouwde, BYOD-, IoT- en beheerde interne apparaten horen niet samen in één plat clientnetwerk. Gebruik afzonderlijke SSID’s en VLAN’s met eigen beveiligingsbeleid en meng vertrouwde en niet-vertrouwde clients niet op dezelfde SSID en, waar mogelijk, ook niet op hetzelfde AP.

Central tagt clientverkeer alleen met de geselecteerde VLAN-ID; switch, gateway, DHCP, DNS en beleid moeten buiten Central bestaan. Een AP6-SSID met VLAN configureren beschrijft de volledige inrichting. Een VLAN-ID alleen is geen beveiligingsgrens: het gateway- of firewallbeleid bepaalt welke zones en bestemmingen bereikbaar zijn.

3. Blokkeer L3- en hairpinpaden op de gateway

Blokkeer op de gateway of firewall client-naar-clientverkeer op Layer 3 zo strikt mogelijk, inclusief verkeer dat de gateway naar hetzelfde clientsubnet zou terugrouteren. Sta alleen expliciet vereiste bestemmingen en diensten toe. Logging op de pilotregel helpt aantonen of het testverkeer dat pad daadwerkelijk volgt.

Dit onderscheid is belangrijk: afhankelijk van het switch- en draadloze pad kunnen apparaten in hetzelfde VLAN rechtstreeks communiceren zonder de gateway te passeren. Een firewallregel kan alleen verkeer blokkeren dat de firewall bereikt. Als verkeer tussen AP’s lokaal wordt gebridged, moet geschikte wifi-, switch- of VLAN-segmentatie het door de gecontroleerde beleidsgrens dwingen. Een nominale client-naar-client-denyregel zonder bewezen datapad is geen succescriterium.

4. Pas upstream anti-spoofing alleen toe waar het past

Aanvullende maatregelen zijn DHCP Snooping, IP Source Guard en bronvalidatie op de gateway, zoals uRPF, als de switch of gateway dit ondersteunt. Deze controles zijn omgevingsafhankelijk: vertrouwde uplinks, DHCP-servers, statische clients, relays, asymmetrische routering en redundantie beïnvloeden een veilige configuratie.

Schakel ze niet blind op alle poorten in. Documenteer eerst bindings en legitieme paden en test daarna één controle op het pilotsegment. DHCP-vernieuwing, statische apparaten, gatewayfailover en retourpaden moeten blijven werken. Als er geen geverifieerde leveranciersconfiguratie voor de gebruikte switch of router bestaat, laat dit punt dan open en raadpleeg de documentatie of ondersteuning van die leverancier.

5. Plaats Enterprise en 802.11w in de juiste context

In WPA2-Personal, WPA3-Personal en gemengde persoonlijke modi kan de Group Temporal Key die clients van dezelfde SSID delen, worden misbruikt voor GTK Abuse. Avanet adviseert daarom WPA2/WPA3 Enterprise (802.1X) met externe RADIUS in plaats van authenticatie met een gedeelde sleutel. Dit verbetert de toegangscontrole en vermindert ongeautoriseerde toegang, maar elimineert GTK-gebaseerde aanvalsvectoren niet. Test migratie en clientcompatibiliteit afzonderlijk met RADIUS en WPA3 Enterprise voor AP6.

802.11w is alleen beschikbaar voor AP6-SSID’s en beschermt managementframes na het opzetten van een beveiligde verbinding door ze te versleutelen en te authenticeren. Schakel dit na een clientcompatibiliteitstest in als aanvullende beveiliging. Het is geen isolatie van dataverkeer of AirSnitch-herstel en telt niet als geslaagde AirSnitch-controle.

Valideer in twee fasen vóór de brede uitrol

De pilot valideert het werkelijke datapad, niet alleen de selectievakjes. Gebruik de acceptatiecriteria van de actuele fase:

Fase 1: één pilot-AP en validatie op hetzelfde AP

  1. Configuratie: Central toont de verwachte waarden voor Client isolation, Proxy ARP, VLAN en eventueel 802.11w. Alleen het bedoelde pilot-AP is toegewezen.
  2. Goedgekeurde infrastructuur: beide testclients krijgen de bedoelde IP-instellingen, lossen DNS op en bereiken alleen goedgekeurde infrastructuur en externe diensten. Test deze bestemmingen afzonderlijk van de peer-to-peertests.
  3. Hetzelfde AP: verbind beide clients met het pilot-AP. Als Client isolation is ingeschakeld, moet alle directe communicatie tussen clients mislukken, ongeacht protocol of dienst; een directe peerdienst is geen toegestane uitzondering.
  4. Werking en discovery: test DHCP-vernieuwing en benodigde print-, casting- of discoveryprocessen. Benodigde gecontroleerde discovery of toegang tussen clients moet via een afzonderlijk ontworpen beleids- of discoverygateway lopen, niet via directe peerforwarding. Koppel onverwachte storingen eerst aan de gewijzigde laag voordat u meer wijzigt.

Fase 2: één gecontroleerd tweede AP en validatie tussen AP’s

  1. Gecontroleerde uitbreiding: wijs pas na een geslaagde fase 1 precies één gecontroleerd tweede AP toe. Central moet nu precies deze twee AP’s met de verwachte configuratie tonen; voeg de overige AP’s nog niet toe.
  2. Verschillende AP’s: verbind één client met elk AP in hetzelfde clientsubnet en herhaal de client-naar-client-denytests. Vervang deze test tussen AP’s niet door verwachtingen op basis van Client isolation.
  3. Layer 3 en hairpin: gebruik gatewaylogs of een packet capture om aan te tonen of elk testpad de beleidsgrens passeert en de bedoelde denyregel raakt, inclusief een pad dat naar het clientnetwerk wordt teruggerouteerd. Boots niet bewust een exploit na op een productie-WLAN.
  4. Herhalen en vrijgeven: maak opnieuw verbinding, test minstens één ander clienttype, herhaal de controles van goedgekeurde infrastructuur en controleer de configuratiestatus van beide AP’s. Rol pas na een geslaagde afronding van beide fasen in kleine groepen uit.

Deze twee fasen tonen alleen aan dat de gedefinieerde controles en normale datapaden in deze omgeving naar behoren werken. Dit bewijst geen volledige oplossing voor AirSnitch.

Rol exact terug naar de uitgangssituatie

Als een test mislukt, stopt u de uitrol en wijzigt u SSID, VLAN, gateway en switch niet tegelijkertijd. Verwijder eerst aanvullende AP-toewijzingen of beperk de SSID weer tot de pilotomvang. Herstel daarna voor elke gewijzigde laag exact de gedocumenteerde uitgangssituatie:

  1. Central: herstel de oorspronkelijke status van Client isolation, Proxy ARP en 802.11w, de Client connection-modus, het VLAN, de banden en AP-toewijzingen.
  2. Gateway/firewall: verwijder alleen nieuwe pilotregels of herstel de vastgelegde regelposities, bronnen, bestemmingen, diensten, acties en loggingwaarden.
  3. Switch-/gatewaybeveiliging: draai alleen de pilotwijzigingen aan DHCP Snooping, IP Source Guard of uRPF terug, inclusief de eerdere vertrouwens- en uitzonderingstoewijzingen.
  4. Controle: wacht op de Central-configuratiestatus en test vervolgens DHCP, DNS, toegestane diensten, geblokkeerde bestemmingen en bestaande SSID’s opnieuw met de bekende clients.

Verwijder niet als eerste herstelstap een productie-SSID, VLAN of bestaande regel. Als de uitgangssituatie onduidelijk is, stop dan en stem af met de netwerkbeheerders of Sophos Support in plaats van door verdere wijzigingen een onbekende toestand te creëren. Het AirSnitch-risico blijft na de rollback bestaan: rollback herstelt de dienstverlening, maar verhelpt de kwetsbaarheid niet.