Qu'est-ce qu'une 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. Un briefing technique Purple. Introduction et contexte. Bienvenue dans ce briefing 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 WiFi invité, d'un réseau de vente au détail multisite ou d'un programme d'analyse de site, la compréhension des probe requests n'est pas facultative. C'est le fondement 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é au 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 un réseau. 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. Considérez cela comme l'appareil qui crie 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 à l'insu du propriétaire de l'appareil. Et pour les architectes réseau et les exploitants 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 la mécanique. 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 de débits pris en charge, l'élément de débits étendus pris en charge et les informations de capacité, y compris les capacités HT — c'est-à-dire à haut débit — et 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 sonde générique. Ici, le champ SSID est vide — l'appareil demande essentiellement à tout point d'accès à portée de s'identifier. Le second est une probe request dirigé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 réponse à la sonde (probe response) — reflète une grande partie du contenu de la trame de balise (beacon frame). Elle comprend le SSID, le BSSID, l'intervalle de balise, l'horodatage et l'ensemble complet des capacités. C'est cet échange qui permet à un appareil de dresser la liste des 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 est le cycle de probe request et de réponse que je viens de décrire. Le balayage passif est différent — l'appareil écoute simplement 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 opèrent. C'est là que cela devient important sur le plan opérationnel. Dans un lieu à haute densité — un stade, un centre de conférences, une grande surface de vente — vous pouvez avoir des milliers d'appareils envoyant simultanément des probe requests sur plusieurs canaux. Cela crée ce que l'on appelle des conditions de tempête de sondes (probe storm). Chaque probe request 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 des clients connectés. C'est pourquoi les points d'accès de classe entreprise intègrent de série le filtrage des probe requests et la limitation du débit. Parlons maintenant des adresses MAC et de l'importance capitale de ce sujet pour les analyses. Historiquement, chaque probe request transportait la véritable adresse MAC matérielle de l'appareil — un identifiant unique de 48 bits au niveau mondial, gravé dans la carte d'interface réseau. Les analyses basées sur les sondes étaient donc extrêmement fiables. Vous pouviez suivre un appareil dans votre établissement, mesurer le temps de séjour, identifier les visiteurs réguliers et établir des cartes thermiques de fréquentation en toute confiance. 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 probe requests. Au lieu de diffuser la véritable adresse MAC matérielle, les appareils génèrent désormais une adresse MAC aléatoire pour la recherche. Sur iOS, cette randomisation se fait 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 une recherche. Sur Android, l'implémentation varie selon le fabricant. L'impact pratique pour les exploitants de sites 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. Le nombre d'appareils uniques est gonflé. L'identification des visiteurs réguliers à partir des seules données de sondes 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 lie les analyses à la session authentifiée, et non à l'adresse matérielle, ce qui vous donne 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 probe requests que les analystes de la sécurité réseau doivent comprendre. Comme les probe requests sont des trames de gestion non cryptées, elles sont visibles par toute personne disposant d'un outil de capture de paquets en mode moniteur. Une probe request 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 véritable faille de confidentialité. Un appareil qui se déplace dans votre établissement diffuse les noms de tous les réseaux auxquels il s'est connecté. C'est l'une des raisons pour lesquelles la randomisation MAC a été introduite à l'origine. Du point de vue de la surface d'attaque, les probe requests permettent des attaques de type Evil Twin. Un attaquant qui capture une probe request 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 Enhanced Open et SAE (Simultaneous Authentication of Equals) de WPA3 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 à ce que vous devez concrètement faire dans le cadre d'un déploiement réel. Premièrement, si vous déployez ou modernisez un réseau WiFi invité dans un espace à haute densité, l'emplacement de vos points d'accès et la planification des canaux doivent tenir compte de la surcharge liée aux probe requests. Utilisez une stratégie de largeur de canal minimale — 20 MHz sur 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 AP ne répondent qu'aux appareils dont la force du signal est supérieure à un certain seuil. Cela réduit considérablement le bruit des trames de gestion. Deuxièmement, si vous effectuez des analyses de fréquentation ou de temps de séjour, acceptez le fait que les données basées uniquement sur les sondes ne sont plus suffisantes. Votre stratégie d'analyse doit s'articuler autour de sessions authentifiées. Cela signifie que votre Captive Portal ou votre parcours d'intégration doit être suffisamment fluide pour que les visiteurs se connectent réellement. Les données de Purple montrent que les sites disposant d'un parcours d'intégration bien conçu — connexion sociale, saisie d'e-mail ou flux sans mot de passe — enregistrent des taux de connexion de 60 à 80 % des appareils présents sur le site. C'est votre population d'analyse. Troisièmement, pour la conformité au GDPR au Royaume-Uni et dans l'UE, la collecte de données de probe requests — même anonymisées — nécessite une évaluation minutieuse de la base juridique. Si vous capturez et stockez des trames de sondes à des fins d'analyse, vous devez documenter votre base 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. Travaillez avec votre DPO avant de déployer tout système d'analyse basé sur les sondes. Quatrièmement, méfiez-vous des tempêtes de sondes 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 AP 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 minimal, la limitation du débit des réponses aux sondes et à veiller à ce que votre bande 5 GHz soit correctement annoncée afin que les appareils compatibles la préfèrent à la bande 2,4 GHz. Questions-réponses rapides. Permettez-moi de passer en revue quelques questions qui reviennent régulièrement. Puis-je utiliser les probe requests pour compter la fréquentation sans Captive Portal ? Techniquement oui, mais depuis iOS 14, la précision est médiocre. Vous constaterez des comptages uniques gonflés et aucune donnée sur les visiteurs réguliers. Pour tout ce qui va au-delà d'estimations grossières, vous avez besoin de sessions authentifiées. Les probe requests fonctionnent-elles sur les réseaux WiFi 6E à 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 à 6 GHz. Quelle est la différence entre une probe request et une association request ? Une probe request intervient avant l'association — l'appareil découvre les réseaux. Une association request 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.11. La randomisation MAC est-elle cohérente une fois connecté ? Sur iOS, oui — l'appareil utilise une adresse MAC aléatoire 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, est la bonne architecture. Résumé et prochaines étapes. Pour résumer : les probe requests sont le cœur de la découverte WiFi. Chaque appareil de 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é fiables, performants pour l'analyse et conformes. 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é 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 à haute densité et doit être traitée dès la phase de conception de l'infrastructure. Quatre : les probe requests 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 les pratiques d'hygiène réseau peuvent atténuer. Si vous souhaitez aller plus loin, la documentation technique de Purple explique comment notre plateforme indépendante du matériel capture et traite les données de sondes parallèlement aux données de session authentifiées pour vous fournir des analyses précises sur vos sites. Vous pouvez également explorer nos guides sur le guidage WiFi et la trilatération, qui s'appuient directement sur les principes fondamentaux des probe requests que nous avons abordés aujourd'hui. Merci pour votre écoute. C'était un briefing technique Purple.