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 de WiFi invité, d'un réseau de vente au détail multisite ou d'un programme d'analyse de fréquentation, 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é 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, et elle 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 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. Approfondissement technique. 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 de capacité, y compris les capacités HT - 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, parfois appelée probe 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, 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é auparavant 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 en grande partie le contenu de la trame beacon. Elle comprend le SSID, le BSSID, l'intervalle de beacon, l'horodatage et l'ensemble complet des capacités. Cet échange est ce qui permet à un appareil de créer 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 demande et de réponse de sonde que je viens de décrire. Le balayage passif est différent - le périphérique é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 périphériques 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 sur le plan opérationnel. Dans un lieu à forte densité - un stade, un centre de conférences, une grande surface de vente - vous pouvez avoir des milliers de périphériques qui envoient simultanément des demandes de sonde sur plusieurs canaux. Cela crée ce que l'on appelle des conditions de tempête de sondes. Chaque demande 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 des clients connectés. C'est pourquoi les points d'accès de classe entreprise intègrent par défaut le filtrage des demandes de sonde et la limitation du débit. Parlons maintenant des adresses MAC et de la raison pour laquelle cela importe énormément pour les analyses. Historiquement, chaque demande de sonde contenait la véritable adresse MAC matérielle du périphérique - un identifiant unique de 48 bits au niveau mondial intégré à la carte d'interface réseau. Cela rendait les analyses basées sur les sondes extrêmement fiables. Vous pouviez suivre un périphérique dans votre établissement, mesurer le temps de visite, identifier les visiteurs récurrents et élaborer des cartes de chaleur 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 demandes de sonde. Au lieu de diffuser la véritable adresse MAC matérielle, les périphériques génèrent désormais une adresse MAC randomisée pour le balayage. Sur iOS, cette randomisation s'effectue par SSID - ce qui signifie que le périphérique utilise une adresse MAC randomisée 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 de sites est important. Les analyses de fréquentation basées sur les sondes qui s'appuyaient sur des adresses MAC persistantes ne sont désormais plus fiables pour les périphériques non connectés. Le nombre de périphériques uniques est gonflé. L'identification des visiteurs récurrents à 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 des adresses 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 des données de fréquentation précises et conformes au GDPR, quel que soit le comportement de l'adresse MAC du périphérique. Il existe également une dimension de sécurité liée aux requêtes de sondage (probe requests) que les analystes de sécurité réseau doivent comprendre. Comme ces requêtes de sondage 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 sondage ciblée révèle les SSID des réseaux auxquels un appareil s'est précédemment 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 circule dans 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 MAC a été introduite à l'origine. Du point de vue de la surface d'attaque, les requêtes de sondage permettent de réaliser des attaques de type evil twin. Un attaquant qui capture une requête de sondage ciblée pour un SSID spécifique peut configurer 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. Très bien, passons à ce que vous devez concrètement faire avec cela dans le cadre d'un déploiement réel. Tout d'abord, 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 de vos canaux doivent tenir compte de la surcharge liée aux requêtes de sondage. Utilisez une stratégie de largeur de canal minimale - 20 MHz sur la bande 2.4 GHz - et configurez des seuils 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 requêtes de sondage afin que les points d'accès ne répondent qu'aux appareils situés au-dessus d'une certaine force 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 présence, vous devez accepter que les données basées uniquement sur les requêtes de sondage ne soient plus suffisantes. Votre stratégie d'analyse doit s'articuler autour des sessions authentifiées. Cela signifie que votre Captive Portal ou votre parcours d'intégration doit être assez fluide pour que les visiteurs se connectent réellement. Les données de Purple montrent que les établissements disposant d'une expérience d'intégration 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 pour cent 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 issues des requêtes de sondage - même anonymisées - nécessite une évaluation rigoureuse de la base juridique. Si vous capturez et stockez des trames de sondage à des fins d'analyse, vous devez documenter votre intérêt légitime et veiller à la minimisation des données. Les directives de l'ICO concernant 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. Consultez votre DPO avant de déployer tout système d'analyse basé sur les requêtes de sondage. Quatrièmement, surveillez les 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 à fort passage, analysez les journaux de vos points d'accès et examinez les taux de trames d'administration. Une tempête de sondes en est souvent la cause. La solution consiste à combiner le filtrage RSSI minimal, la limitation du taux de réponse aux sondes et à s'assurer que votre bande 5 GHz est correctement annoncée pour 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 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 uniques gonflés et aucune donnée sur les visiteurs récurrents. Pour tout ce qui va au-delà d'estimations approximatives, des sessions authentifiées sont nécessaires. 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 (probe request) et une requête d'association (association request) ? 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 distinctes 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 une 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é fiables, compatibles avec les analyses 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 à forte densité et doit être traitée dès l'étape 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 indépendante 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 abordés aujourd'hui. Merci pour votre écoute. C'était un point technique Purple.