Proteggere Sophos AP6 da AirSnitch: pianificare correttamente l'isolamento client

La vulnerabilità AirSnitch identificata come sophos-sa-20260421-airsnitch riguarda tutte le versioni di AP6 attualmente classificate come interessate. L’esposizione effettiva dipende dal design dell’SSID, dalla configurazione, dalla variante d’attacco e dalla rete upstream. Per AP6 sono rilevanti tre percorsi orientati all’iniezione: GTK Abuse, Broadcast Reflection e Gateway Bouncing. AirSnitch da solo non consente un attacco man-in-the-middle completo su AP6.

⚠️ Nessuna correzione completa: attualmente non esistono una mitigazione completa, una remediation o una versione corretta per questa classe di attacchi. Le misure seguenti riducono il rischio, ma non lo eliminano. Subito prima di ogni fase del rollout, verifica lo stato attuale delle versioni AP6 e della remediation. Se lo stato è cambiato, interrompi il rollout e rivaluta protezioni, pilot e rollback.

Percorso rapido: registra prima la baseline esatta. Su un solo SSID pilota verifica o abilita Client isolation e Proxy ARP in My Products > Wireless > SSIDs > nome SSID > Advanced Settings. Separa dispositivi attendibili e non attendibili su SSID e VLAN distinti, blocca sul gateway il traffico tra client includendo i possibili percorsi hairpin e pilota i controlli anti-spoofing supportati solo dopo aver verificato la topologia. WPA2/WPA3 Enterprise e 802.11w sono protezioni aggiuntive, non soluzioni AirSnitch complete.

Perché Client isolation non basta

L’opzione Central Client isolation blocca la comunicazione tra dispositivi wireless connessi allo stesso access point. I dispositivi nella stessa subnet possono ancora comunicare se sono connessi ad access point diversi. Questo normale limite L2 locale deve essere distinto da un percorso instradato o riflesso.

Nel Gateway Bouncing viene sfruttato proprio il divario tra Layer 2 e Layer 3: un frame costruito ad hoc viene inviato al gateway upstream e da questo instradato verso la vittima. Il blocco del forwarding diretto sull’AP non copre automaticamente questo percorso L3 o hairpin. Uno stato Central verde non dimostra né la policy del gateway né l’isolamento tra AP.

Proxy ARP permette all’AP di rispondere alle richieste ARP destinate ai dispositivi wireless connessi. Riduce l’esposizione ai broadcast ed è quindi un importante workaround AirSnitch. Non sostituisce isolamento client, separazione VLAN, policy firewall o verifica del percorso di ritorno.

Registra la baseline esatta prima del pilot

Prima del primo Save, registra almeno quanto segue per ogni SSID interessato, preferibilmente con un export o screenshot datati:

• nome SSID, Enable SSID, AP6 assegnati e bande abilitate;
• modalità di cifratura, selezione RADIUS e valori di autenticazione rilevanti, senza segreti;
• stato attuale di Client isolation, Proxy ARP e 802.11w;
• modalità Client connection e ID VLAN statici o forniti da RADIUS;
• uplink AP, VLAN consentite, subnet client, gateway, DHCP, DNS e regole gateway/firewall esistenti;
• impostazioni DHCP Snooping, IP Source Guard o uRPF con porte, ruoli trusted ed eccezioni;
• due client di test noti, AP pilota, secondo AP e flussi consentiti e bloccati attualmente funzionanti.

Questi valori sono la baseline di rollback. “Ripristinare le impostazioni precedenti” è sicuro solo se checkbox, assegnazioni, VLAN e regole precedenti sono note. Poiché Save aggiorna tutti gli AP assegnati all’SSID e può disconnettere brevemente i client, limita la prima modifica a un SSID di test o a un solo AP pilota.

Proteggi l’SSID AP6 a più livelli

1. Abilita Client isolation e Proxy ARP

Vai a My Products > Wireless > SSIDs, seleziona l’SSID pilota e apri Advanced Settings. In Security abilita Client isolation. Poi abilita Proxy ARP in Quality of service, salvando inizialmente solo per l’ambito pilota previsto.

Client isolation protegge il percorso diretto tra client dello stesso AP. Proxy ARP riduce i broadcast ARP rispondendo per i dispositivi wireless connessi. Le opzioni si completano, ma non chiudono completamente il percorso tra AP, ogni variante broadcast/multicast o il percorso attraverso un gateway upstream.

Prima del rollout esteso, prova le applicazioni che richiedono discovery locale, come stampanti o casting. Se una funzione necessaria smette di funzionare, non rimuovere indistintamente tutte le protezioni e non creare un’eccezione peer diretta. Inserisci la discovery controllata o l’accesso tra client in una policy o in un gateway di discovery progettati separatamente, con regole ristrette.

2. Separa le zone di trust con SSID e VLAN

Dispositivi non attendibili, BYOD, IoT e interni gestiti non dovrebbero condividere una rete client piatta. Usa SSID e VLAN distinti con policy proprie ed evita di mescolare client attendibili e non attendibili sullo stesso SSID e, dove possibile, sullo stesso AP.

Central si limita a marcare il traffico client con l’ID VLAN scelto; switch, gateway, DHCP, DNS e policy devono esistere fuori da Central. Configurare un SSID AP6 con una VLAN descrive l’intero setup. Un ID VLAN da solo non è un confine di sicurezza: è la policy del gateway o firewall a stabilire zone e destinazioni raggiungibili.

3. Blocca i percorsi L3 e hairpin sul gateway

Sul gateway o firewall blocca il traffico Layer 3 tra client nel modo più restrittivo possibile, compreso quello che il gateway instraderebbe di nuovo nella stessa subnet client. Consenti solo destinazioni e servizi necessari. Il logging della regola pilota aiuta a provare che il traffico di test percorra davvero quel cammino.

La distinzione è fondamentale: in base al percorso wireless e di switching, i dispositivi nella stessa VLAN possono comunicare direttamente senza attraversare il gateway. Una regola firewall blocca solo il traffico che raggiunge il firewall. Se il traffico tra AP è bridged localmente, il design deve usare una segmentazione wireless, switch o VLAN adeguata per forzarlo attraverso il confine di policy controllato. Una regola nominale “client-to-client deny” senza un percorso dati dimostrato non è un criterio di successo.

4. Applica l’anti-spoofing upstream solo dove appropriato

Le protezioni aggiuntive comprendono DHCP Snooping, IP Source Guard e validazione della sorgente sul gateway, come uRPF, dove supportati da switch o gateway. Questi controlli dipendono dall’ambiente: uplink trusted, server DHCP, client statici, relay, routing asimmetrico e ridondanza incidono sulla configurazione sicura.

Non abilitarli alla cieca su tutte le porte. Documenta prima binding e percorsi legittimi, poi prova un controllo sul segmento pilota. Rinnovo DHCP, dispositivi statici, failover del gateway e percorso di ritorno devono continuare a funzionare. Se manca una configurazione verificata del produttore per lo switch o router usato, lascia aperto il punto e risolvilo con la relativa documentazione o il supporto.

5. Inquadra correttamente Enterprise e 802.11w

Con WPA2-Personal, WPA3-Personal o modalità personali miste, la Group Temporal Key condivisa dai client dello stesso SSID può essere abusata per GTK Abuse. Avanet raccomanda quindi WPA2/WPA3 Enterprise (802.1X) con RADIUS esterno al posto dell’autenticazione a chiave condivisa. Questo migliora il controllo accessi e riduce gli accessi non autorizzati, ma non elimina i vettori d’attacco basati su GTK. Pilota separatamente migrazione e compatibilità con RADIUS e WPA3 Enterprise per AP6.

802.11w è disponibile solo per SSID AP6 e protegge i management frame dopo l’instaurazione di una connessione sicura cifrandoli e autenticandoli. Abilitalo come protezione aggiuntiva dopo il test di compatibilità dei client. Non è isolamento del traffico dati né remediation AirSnitch e non deve valere come gate AirSnitch superato.

Valida in due fasi prima del rollout esteso

Il pilot verifica il percorso dati reale, non solo le checkbox. Applica i criteri di accettazione della fase corrente:

Fase 1: un AP pilota e validazione sullo stesso AP

1. Configurazione: Central mostra i valori attesi per Client isolation, Proxy ARP, VLAN ed eventualmente 802.11w. È assegnato solo l’AP pilota previsto.
2. Infrastruttura approvata: entrambi i client ricevono la configurazione IP prevista, risolvono il DNS e raggiungono solo l’infrastruttura e i servizi esterni approvati. Verifica queste destinazioni separatamente dai test peer-to-peer.
3. Stesso AP: collega entrambi i client all’AP pilota. Con Client isolation abilitato, ogni comunicazione diretta tra i client deve fallire, indipendentemente dal protocollo o servizio; un servizio peer diretto non è un’eccezione consentita.
4. Operatività e discovery: prova il rinnovo DHCP e i flussi necessari di stampa, casting o discovery. La discovery controllata o l’accesso tra client eventualmente necessari devono attraversare una policy o un gateway di discovery progettati separatamente, non un inoltro peer diretto. Prima di altre modifiche, attribuisci gli errori inattesi al livello cambiato.

Fase 2: un secondo AP controllato e validazione tra AP

1. Espansione controllata: solo dopo il superamento della fase 1, assegna esattamente un secondo AP controllato. Central deve ora mostrare esattamente quei due AP con la configurazione prevista; non aggiungere ancora gli altri AP.
2. AP diversi: collega un client a ciascun AP nella stessa subnet e ripeti i test di blocco tra client. Le aspettative di Client isolation non sostituiscono questo test tra AP.
3. Layer 3 e hairpin: usa i log del gateway o una cattura dei pacchetti per provare se ogni percorso di test attraversa il confine di policy e incontra la deny rule prevista, incluso un percorso instradato di nuovo verso la rete client. Non riprodurre intenzionalmente un exploit su una WLAN di produzione.
4. Ripetizione e autorizzazione: riconnetti i client, prova almeno un altro tipo di client, ripeti le verifiche dell’infrastruttura approvata e controlla lo stato di configurazione di entrambi gli AP. Solo dopo il superamento di entrambe le fasi procedi con il rollout a piccoli gruppi.

Queste due fasi dimostrano solo che i controlli definiti e i normali percorsi dati funzionano come previsto in questo ambiente. Non dimostrano una remediation completa di AirSnitch.

Esegui il rollback esatto alla baseline

Se un test fallisce, interrompi il rollout e non modificare contemporaneamente SSID, VLAN, gateway e switch. Rimuovi prima le assegnazioni AP aggiuntive o riporta l’SSID all’ambito pilota. Poi ripristina la baseline documentata per ogni livello cambiato:

1. Central: stati originali di Client isolation, Proxy ARP e 802.11w, modalità Client connection, VLAN, bande e assegnazioni AP.
2. Gateway/firewall: rimuovi solo le nuove regole pilota oppure ripristina posizioni, sorgenti, destinazioni, servizi, azioni e logging registrati.
3. Protezione switch/gateway: annulla solo le modifiche pilota a DHCP Snooping, IP Source Guard o uRPF, incluse le precedenti assegnazioni trust ed eccezioni.
4. Verifica: attendi lo stato di configurazione Central, poi riprova DHCP, DNS, servizi consentiti, destinazioni bloccate e SSID esistenti con i client noti.

Non eliminare un SSID, una VLAN o una regola di produzione come primo passo di ripristino. Se la baseline non è chiara, fermati e chiariscila con i responsabili di rete o il supporto Sophos invece di creare uno stato ignoto con altre modifiche. Il rischio AirSnitch rimane dopo il rollback: il rollback ripristina il servizio, ma non corregge la vulnerabilità.