Qu'est-ce qu'un Probe Request ? Comprendre comment les appareils découvrent les réseaux

Qu'est-ce qu'une Probe Request ? Comprendre comment les appareils découvrent les réseaux. Une note technique Purple. Introduction et contexte. Bienvenue dans cette note technique Purple. Je vais vous présenter l'un des mécanismes les plus fondamentaux - et les plus fréquemment mal compris - du WiFi d'entreprise : la probe request. Si vous êtes responsable d'un déploiement de WiFi invité, d'un réseau de vente au détail multi-sites ou d'un programme d'analyse de fréquentation, la compréhension des probe requests n'est pas facultative. C'est le socle sur lequel repose tout le reste - de l'analyse de la fréquentation et de la mesure du temps de séjour aux défis de la randomisation MAC et à la conformité GDPR. Alors, entrons dans le vif du sujet. Chaque fois qu'un appareil - un smartphone, un ordinateur portable, une tablette - n'est pas connecté à un réseau, il recherche constamment une connexion. Ce processus de recherche commence par une probe request. Il s'agit d'une trame de gestion, définie par la norme IEEE 802.11, qui est transmise par l'appareil client, et non par le point d'accès. Voyez cela comme si l'appareil criait dans la pièce : "Y a-t-il quelqu'un que je connais ici ?" Le point d'accès écoute et, s'il reconnaît la demande, il répond. Cela se produit des centaines de fois par jour, souvent sans même que le propriétaire de l'appareil ne le sache. Et pour les architectes réseau et les gestionnaires de sites, ces probe requests sont une mine d'or de données opérationnelles - si vous savez comment les capturer et les interpréter correctement. Analyse technique approfondie. Allons plus loin dans les aspects techniques. Une probe request est une trame de gestion de Couche 2 transmise sur les bandes radio 2,4 GHz ou 5 GHz. Selon la norme IEEE 802.11, elle est classée comme une trame de gestion de sous-type 4. La trame contient plusieurs éléments d'information clés : le champ SSID, l'élément des débits pris en charge, l'élément des débits étendus pris en charge, et les informations sur les capacités, y compris le HT - à savoir le haut débit - et les capacités VHT pour les appareils 802.11ac. Il existe deux types de probe requests. Le premier est une probe request de diffusion (broadcast), parfois appelée probe générique (wildcard). Ici, le champ SSID est vide - l'appareil demande essentiellement à n'importe quel point d'accès à portée de s'identifier. Le second est une probe request ciblée (directed), où le champ SSID contient un nom de réseau spécifique. Cela se produit lorsque l'appareil recherche activement un réseau auquel il s'est déjà connecté et qu'il a enregistré dans sa liste de réseaux préférés. La réponse du point d'accès - la trame de probe response - reproduit une grande partie du contenu de la trame beacon. Elle comprend le SSID, le BSSID, l'intervalle de beacon, l'horodatage et l'ensemble complet des fonctionnalités. C'est cet échange qui permet à un appareil de construire sa liste de réseaux disponibles avant même que l'utilisateur n'ouvre ses paramètres WiFi.Il existe désormais une distinction importante entre le balayage actif et le balayage passif. Le balayage actif correspond au cycle de requête et de réponse de sonde que je viens de décrire. Le balayage passif est différent - l'appareil se contente d'écouter les trames de balise que les points d'accès diffusent périodiquement, généralement toutes les 100 millisecondes. Le balayage passif est plus lent mais consomme moins d'énergie. La plupart des appareils modernes utilisent une combinaison des deux, en fonction de leur état d'alimentation et du domaine réglementaire dans lequel ils fonctionnent. C'est là que cela devient important d'un point de vue opérationnel. Dans un espace à forte densité - un stade, un centre de conférences, une grande surface de vente - vous pouvez avoir des milliers d'appareils qui envoient simultanément des requêtes de sonde sur plusieurs canaux. Cela crée ce que l'on appelle des conditions de tempête de sondes. Chaque requête de sonde consomme du temps d'antenne. Dans un réseau mal conçu, cette surcharge de trames de gestion peut dégrader de manière mesurable le débit pour les clients connectés. C'est pourquoi les points d'accès de classe entreprise intègrent de série le filtrage des requêtes de sonde et la limitation du débit. Parlons maintenant des adresses MAC et de la raison pour laquelle cela revêt une importance capitale pour les analyses. Historiquement, chaque requête de sonde transportait la véritable adresse MAC matérielle de l'appareil - un identifiant unique de 48 bits gravé à l'échelle mondiale dans la carte d'interface réseau. Cela rendait les analyses basées sur les sondes extrêmement fiables. Vous pouviez suivre un appareil dans votre établissement, mesurer le temps de visite, identifier les visiteurs réguliers et concevoir des cartes thermiques de fréquentation avec une grande précision. Cela a considérablement changé avec iOS 14 en 2020 et Android 10 avant lui. Apple et Google ont introduit la randomisation des adresses MAC pour les requêtes de sonde. Au lieu de diffuser la véritable adresse MAC matérielle, les appareils génèrent désormais une adresse MAC aléatoire pour le balayage. Sur iOS, cette randomisation s'effectue par SSID - ce qui signifie que l'appareil utilise une adresse MAC aléatoire cohérente lorsqu'il se connecte à un réseau spécifique, mais une adresse différente lorsqu'il effectue un sondage. Sur Android, l'implémentation varie selon le fabricant. L'impact pratique pour les exploitants d'établissements est important. Les analyses de fréquentation basées sur les sondes qui s'appuyaient sur des adresses MAC persistantes ne sont plus fiables pour les appareils non connectés. Les comptages d'appareils uniques sont gonflés. L'identification des visiteurs réguliers à partir des seules données de sonde n'est plus viable. La solution - et c'est là que le WiFi invité authentifié devient essentiel - consiste à déplacer votre couche d'identité de l'adresse MAC vers l'utilisateur authentifié. Lorsqu'un visiteur se connecte via un captive portal ou une connexion sociale, vous capturez une identité persistante et consentie qui survit à la randomisation MAC. La plateforme de WiFi invité de Purple fait exactement cela - elle associe les analyses à la session authentifiée, et non à l'adresse matérielle, vous fournissant ainsi des données de fréquentation précises et conformes au GDPR, quel que soit le comportement MAC de l'appareil. Il existe également une dimension de sécurité liée aux requêtes de sonde que les analystes de sécurité réseau doivent comprendre. Comme les requêtes de sonde sont des trames de gestion non chiffrées, elles sont visibles par toute personne disposant d'un outil de capture de paquets en mode moniteur. Une requête de sonde dirigée révèle les SSID des réseaux auxquels un appareil s'est déjà connecté - ce que l'on appelle la liste des réseaux préférés, ou PNL. Il s'agit d'une réelle faille de confidentialité. Un appareil qui traverse votre établissement diffuse les noms de tous les réseaux auxquels il s'est déjà connecté. C'est l'une des raisons pour lesquelles la randomisation des adresses MAC a été introduite à l'origine. Du point de vue de la surface d'attaque, les requêtes de sonde permettent des attaques de type "evil twin". Un attaquant qui capture une requête de sonde dirigée pour un SSID spécifique peut mettre en place un point d'accès malveillant avec ce SSID et attendre que l'appareil s'y connecte automatiquement. Les protocoles de WPA3 (Enhanced Open et l'authentification simultanée d'égaux - SAE) atténuent considérablement ce risque, mais seulement si votre infrastructure les prend en charge et les applique. Recommandations de mise en œuvre et pièges à éviter. Passons maintenant à l'application concrète de ces concepts dans un déploiement réel. Premièrement, si vous déployez ou modernisez un réseau WiFi invité dans un espace à forte densité, l'emplacement de vos points d'accès et la planification des canaux doivent tenir compte de la surcharge liée aux requêtes de sonde. Utilisez une stratégie de largeur de canal minimale - 20 MHz sur la bande 2.4 GHz - et mettez en œuvre des seuils de RSSI minimaux pour empêcher les appareils éloignés de s'associer. La plupart des contrôleurs d'entreprise vous permettent de configurer le filtrage des réponses aux sondes afin que les points d'accès ne répondent qu'aux appareils situés au-dessus d'une certaine puissance de signal. Cela réduit considérablement le bruit des trames de gestion. Deuxièmement, si vous analysez la fréquentation ou le temps de séjour, vous devez accepter le fait que les données issues uniquement des sondes ne suffisent plus. Votre stratégie analytique doit s'appuyer sur des sessions authentifiées. Cela signifie que votre Captive Portal ou votre parcours d'authentification doit être suffisamment fluide pour que les visiteurs se connectent réellement. Les données de Purple montrent que les établissements dotés d'une expérience d'accès bien conçue - connexion via les réseaux sociaux, collecte d'e-mails ou parcours sans mot de passe - enregistrent des taux de connexion de 60 à 80 % des appareils présents. C'est là que réside votre population d'analyse. Troisièmement, pour la conformité GDPR au Royaume-Uni et dans l'UE, la collecte de données de requêtes de sonde - même anonymisées - nécessite une évaluation rigoureuse de la base légale. Si vous capturez et stockez des trames de sonde à des fins d'analyse, vous devez documenter votre motif d'intérêt légitime et veiller à la minimisation des données. Les directives de l'ICO sur le suivi WiFi sont claires : si vous pouvez identifier un individu à partir des données, même indirectement, il s'agit de données personnelles. Collaborez avec votre DPO avant de déployer tout système d'analyse basé sur les requêtes de sonde.Quatrièmement, méfiez-vous des tempêtes de requêtes de sonde (probe storms) dans les environnements denses. Si vous constatez une dégradation inexpliquée du débit dans un lieu à forte fréquentation, consultez les journaux de vos points d'accès et examinez les taux de trames de gestion. Une tempête de sondes en est souvent la cause. La solution consiste à combiner le filtrage RSSI minimum, la limitation du taux de réponse aux sondes et à s'assurer que votre bande 5 GHz est correctement annoncée afin que les appareils compatibles la préfèrent à la bande 2,4 GHz. Questions - Réponses rapides. Passons en revue quelques questions qui reviennent régulièrement. Puis-je utiliser les requêtes de sonde pour compter la fréquentation sans Captive Portal ? Techniquement oui, mais depuis iOS 14, la précision est médiocre. Vous constaterez des volumes de visiteurs uniques gonflés et aucune donnée sur les visiteurs récurrents. Pour tout ce qui va au-delà d'estimations approximatives, vous avez besoin de sessions authentifiées. Les requêtes de sonde fonctionnent-elles sur les réseaux WiFi 6E en 6 GHz ? Oui, mais avec des différences. La bande 6 GHz utilise un mécanisme de découverte appelé FILS - Fast Initial Link Setup - et une découverte hors bande, ce qui modifie la dynamique des sondes. Si vous déployez du WiFi 6E, vérifiez la documentation de votre fournisseur concernant le comportement de balayage en 6 GHz. Quelle est la différence entre une requête de sonde et une requête d'association ? Une requête de sonde intervient avant l'association - l'appareil découvre les réseaux. Une requête d'association intervient après l'authentification, lorsque l'appareil demande formellement à rejoindre un réseau spécifique. Ce sont des étapes différentes de la machine d'état de connexion 802.1X. La randomisation MAC est-elle cohérente une fois connecté ? Sur iOS, oui - l'appareil utilise une adresse MAC randomisée stable pour un SSID donné. Sur Android, cela varie. Certaines implémentations effectuent une nouvelle randomisation à chaque connexion. C'est pourquoi l'identité basée sur la session, et non sur l'adresse MAC, constitue la bonne architecture. Résumé et prochaines étapes. Pour résumer : les requêtes de sonde sont le cœur de la découverte WiFi. Chaque appareil présent dans votre établissement en génère constamment. Comprendre leur structure, leurs limites et leurs implications en matière de sécurité est fondamental pour concevoir des déploiements de WiFi invités fiables, conformes et compatibles avec l'analyse de données. Les points clés à retenir sont les suivants. Un : les analyses basées sur les sondes sans authentification ne sont pas fiables dans un monde post-randomisation MAC. Deux : le WiFi invités authentifié est votre couche d'identité - c'est ce qui rend vos analyses précises et vos données conformes au GDPR. Trois : la gestion des tempêtes de sondes est une réelle préoccupation opérationnelle dans les lieux à forte densité et doit être traitée dès la phase de conception de l'infrastructure. Quatre : les requêtes de sonde dirigées exposent la liste des réseaux préférés de votre appareil - un véritable risque de sécurité que le WPA3 et de bonnes pratiques d'hygiène réseau peuvent atténuer. Si vous souhaitez approfondir le sujet, la documentation technique de Purple explique comment notre plateforme agnostique vis-à-vis du matériel capture et traite les données de sonde parallèlement aux données de session authentifiées pour vous fournir des analyses précises sur vos établissements. Vous pouvez également explorer nos guides sur le guidage WiFi et la trilatération, qui s'appuient directement sur les principes fondamentaux des requêtes de sonde que nous avons abordés aujourd'hui. Merci pour votre écoute. C'était un briefing technique Purple.