Härda Sophos AP6 mot AirSnitch: planera klientisolering rätt

AirSnitch-sårbarheten med beteckningen sophos-sa-20260421-airsnitch gäller alla AP6-versioner som för närvarande klassificeras som berörda. Den faktiska exponeringen beror på SSID-design, konfiguration, attackvariant och uppströmsnät. Tre injektionsinriktade vägar är relevanta för AP6: GTK Abuse, Broadcast Reflection och Gateway Bouncing. AirSnitch ensamt kan inte ge en fullständig man-in-the-middle-attack på AP6.

⚠️ Ingen fullständig lösning: det finns för närvarande ingen fullständig riskbegränsning, korrigering eller korrigerad version för denna attackklass. Åtgärderna nedan minskar risken men eliminerar den inte. Kontrollera aktuell AP6-versions- och korrigeringsstatus omedelbart före varje utrullningsvåg. Om statusen har ändrats stoppar du utrullningen och omprövar skyddsåtgärder, pilot och återställningsplan.

Snabb väg: dokumentera först den exakta baslinjen. Kontrollera eller aktivera Client isolation och Proxy ARP på ett pilot-SSID under My Products > Wireless > SSIDs > SSID-namn > Advanced Settings. Separera betrodda och obetrodda enheter med olika SSID:n och VLAN, blockera klient-till-klienttrafik inklusive möjliga hairpinvägar på gatewayen och pilottesta stödda anti-spoofing-kontroller först efter topologiverifiering. WPA2/WPA3 Enterprise och 802.11w ger ytterligare härdning men är inte fullständiga AirSnitch-lösningar.

Varför Client isolation inte räcker

Client isolation blockerar bara kommunikation mellan trådlösa enheter på samma accesspunkt. Enheter i samma subnät kan fortfarande kommunicera om de är anslutna till olika accesspunkter. Denna normala lokala L2-gräns måste skiljas från en routad eller reflekterad väg.

Vid Gateway Bouncing skickas en manipulerad ram till uppströmsgatewayen och routas tillbaka till offret. Att enbart blockera direkt vidarebefordran i AP:n täcker inte automatiskt denna L3-/hairpinväg. Grön Central-status bevisar inte heller gatewaypolicy eller isolering mellan AP:n.

Proxy ARP låter AP:n besvara ARP-förfrågningar som är avsedda för anslutna trådlösa enheter. Det minskar broadcastexponering och är en viktig AirSnitch-åtgärd, men ersätter inte klientisolering, VLAN-separering, brandväggspolicy eller kontroll av returvägen.

Dokumentera exakt återställningsbaslinje före piloten

Före första Save dokumenterar du minst följande för varje berört SSID, helst med en export eller daterade skärmbilder:

SSID-namn, Enable SSID, tilldelade AP6-enheter och aktiverade frekvensband;
krypteringsläge, RADIUS-val och relevanta autentiseringsvärden, utan att registrera hemligheter;
aktuell status för Client isolation, Proxy ARP och 802.11w;
läget Client connection och statiska eller RADIUS-levererade VLAN-ID:n;
AP-uplink, tillåtna VLAN, klientsubnät, gateway, DHCP, DNS och befintliga gateway- eller brandväggsregler;
inställningar för DHCP Snooping, IP Source Guard eller uRPF, inklusive portar, förtroenderoller och undantag;
två kända testklienter, pilot-AP:n, en andra AP samt fungerande tillåtna och blockerade flöden.

Detta är återställningsbaslinjen. ”Återställ tidigare inställningar” är säkert endast när tidigare kryssrutor, tilldelningar, VLAN och regler är kända. Save uppdaterar alla AP:n som tilldelats SSID:t och kan kort koppla från klienter; begränsa därför första ändringen till ett test-SSID eller en pilot-AP.

Härda AP6-SSID:t i lager

1. Aktivera Client isolation och Proxy ARP

Öppna My Products > Wireless > SSIDs, välj pilot-SSID:t och öppna Advanced Settings. Aktivera Client isolation under Security. Aktivera sedan Proxy ARP under Quality of service och spara inledningsvis endast för det planerade pilotomfånget.

Client isolation skyddar den direkta vägen mellan klienter på samma AP. Proxy ARP minskar ARP-broadcast genom att svara för anslutna trådlösa enheter. Alternativen kompletterar varandra men stänger inte helt vägen mellan AP:n, alla broadcast- eller multicastvarianter eller vägen via en uppströmsgateway.

Före en bredare utrullning testar du program som kräver lokal discovery, till exempel skrivare och casting. Om en nödvändig funktion slutar fungera ska du inte ta bort all härdning eller skapa ett direkt peer-undantag. Led kontrollerad discovery eller åtkomst mellan klienter genom en separat utformad policy- eller discoverygateway med snävt avgränsade regler.

2. Separera förtroendezoner med SSID:n och VLAN

Obetrodda, BYOD-, IoT- och internt hanterade enheter bör inte dela ett platt klientnät. Använd separata SSID:n och VLAN med egna säkerhetspolicyer. Blanda inte betrodda och obetrodda klienter på samma SSID och, där det är möjligt, inte heller på samma AP.

Central taggar endast klienttrafiken med valt VLAN-ID; switch, gateway, DHCP, DNS och policyer måste finnas utanför Central. Konfigurera ett AP6-SSID med VLAN beskriver hela konfigurationen. Ett VLAN-ID är inte i sig en säkerhetsgräns: gateway- eller brandväggspolicyn avgör vilka zoner och mål som kan nås.

3. Blockera L3- och hairpinvägar på gatewayen

Blockera Layer 3-trafik mellan klienter så strikt som möjligt på gatewayen eller brandväggen, inklusive trafik som gatewayen skulle routa tillbaka till samma klientsubnät. Tillåt endast uttryckligen nödvändiga mål och tjänster. Loggning på pilotregeln hjälper dig att bevisa om testtrafiken verkligen följer den vägen.

Skillnaden är viktig: beroende på switch- och wifi-vägen kan enheter i samma VLAN kommunicera direkt utan att passera gatewayen. En brandväggsregel kan bara blockera trafik som når brandväggen. Om trafik mellan AP:n bryggas lokalt måste designen använda lämplig wifi-, switch- eller VLAN-segmentering för att tvinga den genom den kontrollerade policygränsen. En nominell client-to-client-denyregel utan en bevisad dataväg är inget framgångskriterium.

4. Använd anti-spoofing uppströms endast där det passar

Ytterligare skydd omfattar DHCP Snooping, IP Source Guard och källvalidering på gatewayen, till exempel uRPF, där switch eller gateway stöder det. Kontrollerna beror på miljön: betrodda uplinks, DHCP-servrar, statiska klienter, reläer, asymmetrisk routing och redundans påverkar en säker konfiguration.

Aktivera dem inte blint på alla portar. Dokumentera först bindningar och legitima vägar och testa sedan en kontroll på pilotsegmentet. DHCP-förnyelse, statiska enheter, gateway-failover och returvägar måste fortsätta fungera. Om det saknas en verifierad leverantörskonfiguration för den aktuella switchen eller routern lämnar du punkten öppen och använder leverantörens dokumentation eller support.

5. Sätt Enterprise och 802.11w i rätt sammanhang

I WPA2-Personal, WPA3-Personal och blandade personliga lägen kan den delade Group Temporal Key missbrukas för GTK Abuse. Avanet rekommenderar därför WPA2/WPA3 Enterprise (802.1X) med extern RADIUS. Det förbättrar åtkomstkontrollen men eliminerar inte GTK-baserade attackvägar. Pilottesta migreringen med RADIUS och WPA3 Enterprise för AP6.

802.11w finns endast för AP6-SSID:n och skyddar managementramar efter att en säker anslutning har upprättats genom att kryptera och autentisera dem. Aktivera det som ytterligare härdning efter kompatibilitetstest av klienterna. Det är varken datatrafikisolering eller AirSnitch-korrigering och får inte räknas som ett godkänt AirSnitch-test.

Validera i två faser före bred utrullning

Piloten validerar den verkliga datavägen, inte bara kryssrutorna. Använd acceptanskriterierna för den aktuella fasen:

Fas 1: en pilot-AP och validering på samma AP

Konfiguration: Central visar de förväntade värdena för Client isolation, Proxy ARP, VLAN och valfritt 802.11w. Endast avsedd pilot-AP är tilldelad.
Godkänd infrastruktur: båda testklienterna får avsedd IP-konfiguration, kan slå upp DNS och når endast godkänd infrastruktur och externa tjänster. Testa dessa mål separat från peer-to-peer-testerna.
Samma AP: anslut båda klienterna till pilot-AP:n. När Client isolation är aktiverat måste all direkt kommunikation mellan klienterna misslyckas, oavsett protokoll eller tjänst; en direkt peer-tjänst är inget tillåtet undantag.
Drift och discovery: testa DHCP-förnyelse och nödvändiga utskrifts-, casting- eller discoveryflöden. Nödvändig kontrollerad discovery eller åtkomst mellan klienter måste gå genom en separat utformad policy- eller discoverygateway, inte direkt peer-vidarebefordran. Koppla oväntade fel till det ändrade lagret innan du gör fler ändringar.

Fas 2: en kontrollerad andra AP och validering mellan AP:n

Kontrollerad utökning: tilldela exakt en kontrollerad andra AP först när fas 1 har godkänts. Central ska nu visa exakt dessa två AP:n med förväntad konfiguration; lägg inte till övriga AP:n ännu.
Olika AP:n: anslut en klient till vardera AP:n i samma klientsubnät och upprepa deny-testerna mellan klienter. Ersätt inte detta test mellan AP:n med förväntningar från Client isolation.
Layer 3 och hairpin: använd gatewayloggar eller packet capture för att bevisa om varje testväg korsar policygränsen och träffar avsedd denyregel, inklusive en väg som routas tillbaka till klientnätet. Återskapa inte avsiktligt ett exploit i ett produktions-WLAN.
Upprepa och godkänn: återanslut, testa minst en annan klienttyp, upprepa kontrollerna av godkänd infrastruktur och verifiera båda AP:ns konfigurationsstatus. Rulla ut i små grupper först när båda faserna har godkänts.

De här två faserna visar endast att definierade kontroller och normala datavägar fungerar som avsett i den här miljön. De bevisar inte fullständig korrigering av AirSnitch.

Återställ exakt till baslinjen

Om ett test misslyckas stoppar du utrullningen och ändrar inte SSID, VLAN, gateway och switch samtidigt. Ta först bort ytterligare AP-tilldelningar eller begränsa SSID:t till pilotomfånget igen. Återställ sedan exakt den dokumenterade baslinjen för varje ändrat lager:

Central: återställ ursprunglig status för Client isolation, Proxy ARP och 802.11w, läget Client connection, VLAN, band och AP-tilldelningar.
Gateway/brandvägg: ta endast bort nya pilotregler eller återställ dokumenterade regelpositioner, källor, mål, tjänster, åtgärder och loggningsvärden.
Switch-/gatewayskydd: återställ endast pilotändringar av DHCP Snooping, IP Source Guard eller uRPF, inklusive tidigare förtroende- och undantagstilldelningar.
Verifiering: vänta på Centrals konfigurationsstatus och testa sedan DHCP, DNS, tillåtna tjänster, blockerade mål och befintliga SSID:n igen med de kända klienterna.

Ta inte bort ett produktions-SSID, VLAN eller en befintlig regel som första återställningssteg. Om baslinjen är oklar ska du stoppa och reda ut den med nätverksansvariga eller Sophos Support i stället för att skapa ett okänt tillstånd genom fler ändringar. AirSnitch-risken kvarstår efter återställningen: den återupprättar tjänsten men åtgärdar inte sårbarheten.