Renforcer Sophos AP6 contre AirSnitch : bien planifier l'isolation des clients

La vulnérabilité AirSnitch référencée sous sophos-sa-20260421-airsnitch concerne toutes les versions d’AP6 actuellement classées comme affectées. L’exposition réelle dépend de la conception du SSID, de la configuration, de la variante d’attaque et du réseau en amont. Trois chemins orientés injection sont pertinents pour AP6 : GTK Abuse, Broadcast Reflection et Gateway Bouncing. AirSnitch seul ne permet pas une attaque complète de type homme du milieu sur AP6.

⚠️ Aucun correctif complet : il n’existe actuellement ni mitigation complète, ni remédiation, ni version corrigée pour cette classe d’attaques. Les mesures ci-dessous réduisent le risque sans l’éliminer. Juste avant chaque vague de déploiement, vérifiez l’état actuel des versions AP6 et de la remédiation. Si cet état a changé, arrêtez le déploiement et réévaluez les protections, le pilote et le retour arrière.

Procédure rapide : consignez d’abord l’état initial exact. Sur un seul SSID pilote, vérifiez ou activez Client isolation et Proxy ARP sous My Products > Wireless > SSIDs > nom du SSID > Advanced Settings. Placez les appareils de confiance et non fiables sur des SSID et VLAN distincts, bloquez à la passerelle le trafic entre clients, y compris les chemins hairpin possibles, et ne pilotez les contrôles anti-usurpation pris en charge qu’après validation de la topologie. WPA2/WPA3 Enterprise et 802.11w renforcent la sécurité, mais ne résolvent pas complètement AirSnitch.

Pourquoi Client isolation ne suffit pas

L’option Central Client isolation bloque les communications entre appareils Wi-Fi reliés au même point d’accès. Des appareils du même sous-réseau peuvent encore communiquer s’ils sont connectés à des points d’accès différents. Cette limite L2 locale ordinaire doit être distinguée d’un chemin routé ou réfléchi.

Avec Gateway Bouncing, l’écart entre les couches 2 et 3 est précisément exploité : une trame préparée est envoyée vers la passerelle en amont, puis routée vers la victime. Le blocage de la transmission directe par l’AP ne couvre donc pas automatiquement ce chemin L3 ou hairpin. Un état Central au vert ne prouve ni l’efficacité de la règle de passerelle ni l’isolation entre plusieurs AP.

Proxy ARP permet à l’AP de répondre aux requêtes ARP destinées aux appareils Wi-Fi connectés. Il réduit l’exposition aux broadcasts et constitue donc un contournement AirSnitch important. Il ne remplace pas l’isolation client, la séparation par VLAN, les règles de pare-feu ou la validation du chemin retour.

Consigner l’état initial exact avant le pilote

Avant le premier Save, consignez au minimum pour chaque SSID concerné, de préférence par export ou captures datées :

• le nom du SSID, Enable SSID, les AP6 assignés et les bandes activées ;
• le mode de chiffrement, la sélection RADIUS et les valeurs d’authentification utiles, sans les secrets ;
• l’état de Client isolation, Proxy ARP et 802.11w ;
• le mode Client connection et les ID de VLAN statiques ou fournis par RADIUS ;
• l’uplink de l’AP, les VLAN autorisés, le sous-réseau client, la passerelle, DHCP, DNS et les règles existantes ;
• les paramètres DHCP Snooping, IP Source Guard ou uRPF, ports, rôles de confiance et exceptions compris ;
• deux clients de test connus, l’AP pilote, un second AP et les flux autorisés et bloqués actuellement opérationnels.

Ces valeurs constituent la référence de retour arrière. « Restaurer les réglages précédents » n’est sûr que si les cases, assignations, VLAN et règles précédents sont connus. Comme Save met à jour tous les AP assignés au SSID et peut brièvement déconnecter les clients, limitez le premier changement à un SSID de test ou à un seul AP pilote.

Renforcer le SSID AP6 par couches

1. Activer Client isolation et Proxy ARP

Accédez à My Products > Wireless > SSIDs, sélectionnez le SSID pilote et ouvrez Advanced Settings. Sous Security, activez Client isolation. Activez ensuite Proxy ARP sous Quality of service, en n’enregistrant d’abord que pour le périmètre pilote prévu.

L’isolation client protège le chemin direct entre clients du même AP. Proxy ARP réduit les broadcasts ARP en répondant pour les appareils Wi-Fi connectés. Les deux options se complètent, mais ne ferment complètement ni le chemin entre AP, ni toutes les variantes broadcast/multicast, ni le chemin via une passerelle en amont.

Avant un déploiement plus large, testez les applications nécessitant une découverte locale, par exemple l’impression ou le casting. Si une fonction nécessaire tombe en panne, ne supprimez pas tout le renforcement et ne créez pas d’exception directe entre pairs. Placez la découverte contrôlée ou l’accès interclients dans une politique ou une passerelle de découverte conçue séparément, avec des règles étroites.

2. Séparer les zones de confiance avec des SSID et des VLAN

Les appareils non fiables, BYOD, IoT et internes administrés ne doivent pas partager un réseau client plat. Utilisez des SSID et VLAN distincts avec leurs propres politiques et évitez de mélanger clients fiables et non fiables sur le même SSID et, lorsque possible, sur le même AP.

Central se contente de marquer le trafic client avec l’ID de VLAN choisi ; switch, passerelle, DHCP, DNS et règles doivent exister hors de Central. Configurer un SSID AP6 avec un VLAN décrit le montage complet. Un ID de VLAN seul n’est pas une frontière de sécurité : la politique de passerelle ou de pare-feu détermine les zones et destinations accessibles.

3. Bloquer les chemins L3 et hairpin à la passerelle

Sur la passerelle ou le pare-feu, bloquez le trafic L3 entre clients aussi strictement que possible, y compris celui que la passerelle renverrait vers le même sous-réseau client. N’autorisez que les destinations et services nécessaires. La journalisation de la règle pilote permet de prouver que le trafic de test emprunte réellement ce chemin.

Cette distinction est essentielle : selon le chemin Wi-Fi et de commutation, des appareils du même VLAN peuvent communiquer directement sans passer par la passerelle. Une règle de pare-feu ne bloque que le trafic qui atteint le pare-feu. Si le trafic entre AP est ponté localement, l’architecture doit employer une segmentation Wi-Fi, switch ou VLAN appropriée pour l’obliger à franchir la frontière de politique contrôlée. Une règle « client-to-client deny » nominale sans chemin de données prouvé n’est pas un critère de réussite.

4. N’appliquer l’anti-usurpation en amont que si l’environnement le permet

Les protections supplémentaires comprennent DHCP Snooping, IP Source Guard et la validation de source à la passerelle, telle que uRPF, lorsque le switch ou la passerelle les prend en charge. Ces contrôles dépendent de l’environnement : uplinks de confiance, serveurs DHCP, clients statiques, relais, routage asymétrique et redondance influencent leur configuration sûre.

Ne les activez pas aveuglément sur tous les ports. Documentez d’abord les associations et chemins légitimes, puis testez un contrôle sur le segment pilote. Le renouvellement DHCP, les appareils statiques, le basculement de passerelle et le chemin retour doivent rester opérationnels. Sans configuration constructeur vérifiée pour le switch ou routeur utilisé, laissez ce point ouvert et consultez sa documentation ou son support.

5. Bien situer Enterprise et 802.11w

Avec WPA2-Personal, WPA3-Personal ou un mode personnel mixte, la Group Temporal Key partagée par les clients d’un même SSID peut être détournée pour GTK Abuse. Avanet recommande donc WPA2/WPA3 Enterprise (802.1X) avec RADIUS externe plutôt qu’une authentification à clé partagée. Cela améliore le contrôle d’accès et réduit les accès non autorisés, mais n’élimine pas les vecteurs d’attaque fondés sur GTK. Pilotez séparément migration et compatibilité avec RADIUS et WPA3 Enterprise pour AP6.

802.11w n’est disponible que pour les SSID AP6 et protège les trames de gestion après l’établissement d’une connexion sécurisée en les chiffrant et les authentifiant. Activez-le comme renforcement supplémentaire après un test de compatibilité client. Ce n’est ni une isolation du trafic de données ni une remédiation AirSnitch, et il ne valide pas un contrôle AirSnitch.

Valider en deux phases avant le déploiement général

Le pilote valide le véritable chemin de données, pas seulement les cases. Appliquez les critères d’acceptation propres à chaque phase :

Phase 1 : un AP pilote et validation sur le même AP

1. Configuration : Central affiche les valeurs attendues pour Client isolation, Proxy ARP, le VLAN et éventuellement 802.11w. Seul l’AP pilote prévu est assigné.
2. Infrastructure autorisée : les deux clients reçoivent la configuration IP prévue, résolvent le DNS et n’atteignent que l’infrastructure et les services externes autorisés. Testez ces destinations séparément des tests entre pairs.
3. Même AP : connectez les deux clients à l’AP pilote. Avec Client isolation activé, toute communication directe entre clients doit échouer, quels que soient le protocole ou le service ; un service direct entre pairs n’est pas une exception autorisée.
4. Exploitation et découverte : testez le renouvellement DHCP ainsi que les flux d’impression, de casting ou de découverte nécessaires. Toute découverte contrôlée ou tout accès interclients nécessaire doit traverser une politique ou une passerelle de découverte conçue séparément, et non un transfert direct entre pairs. Rattachez d’abord toute panne inattendue à la couche modifiée.

Phase 2 : un second AP contrôlé et validation entre AP

1. Extension contrôlée : seulement après la réussite de la phase 1, assignez exactement un second AP contrôlé. Central doit alors afficher exactement ces deux AP avec la configuration prévue ; n’ajoutez pas encore les autres AP.
2. AP différents : connectez un client à chaque AP dans le même sous-réseau et répétez les tests de refus entre clients. Les attentes liées à Client isolation ne remplacent pas ce test entre AP.
3. Couche 3 et hairpin : utilisez les journaux de la passerelle ou une capture de paquets pour prouver si chaque chemin de test franchit la frontière de politique et rencontre la règle de refus prévue, y compris un chemin rerouté vers le réseau client. Ne reproduisez pas volontairement un exploit sur un WLAN de production.
4. Répétition et autorisation : reconnectez les clients, testez au moins un autre type de client, répétez les contrôles de l’infrastructure autorisée et vérifiez l’état de configuration des deux AP. Ne déployez par petites vagues qu’après la réussite des deux phases.

Ces deux phases montrent uniquement que les contrôles définis et les chemins normaux fonctionnent comme prévu dans cet environnement. Elles ne prouvent aucune remédiation complète d’AirSnitch.

Revenir exactement à l’état initial

En cas d’échec, arrêtez le déploiement et ne modifiez pas simultanément SSID, VLAN, passerelle et switch. Retirez d’abord les assignations d’AP supplémentaires ou ramenez le SSID au périmètre pilote. Restaurez ensuite la référence documentée pour chaque couche modifiée :

1. Central : états initiaux de Client isolation, Proxy ARP et 802.11w, mode de connexion client, VLAN, bandes et assignations d’AP.
2. Passerelle/pare-feu : supprimez seulement les nouvelles règles pilotes ou restaurez positions, sources, destinations, services, actions et journalisation consignés.
3. Protection switch/passerelle : annulez uniquement les changements pilotes de DHCP Snooping, IP Source Guard ou uRPF, y compris les anciennes affectations de confiance et exceptions.
4. Contrôle : attendez l’état de configuration Central, puis retestez DHCP, DNS, services autorisés, destinations bloquées et SSID existants avec les clients connus.

Ne supprimez pas un SSID, VLAN ou une règle de production comme première action de reprise. Si l’état initial est ambigu, arrêtez-vous et clarifiez-le avec les responsables réseau ou le support Sophos plutôt que de créer un état inconnu. Le risque AirSnitch subsiste après le retour arrière : celui-ci rétablit le service, mais ne corrige pas la vulnérabilité.