Aller au contenu
Avanet

Analyser la télémétrie Wi-Fi AP6 avec Live Discover

Live Discover permet d’analyser de manière interactive la télémétrie Wi-Fi envoyée par les points d’accès AP6 au Sophos Data Lake. Le chemin direct est Threat Analysis Center > Live Discover > WiFi. Exécutez d’abord une requête intégrée sur une courte période et ne passez au SQL personnalisé qu’après avoir obtenu des données.

Vérifiez d’abord la disponibilité : la documentation générale de Live Discover exige Sophos EDR, XDR ou MDR. La page AP6 ne définit toutefois pas de combinaison de droits spécifique et sans ambiguïté. Ne déduisez donc aucune licence AP6 précise de ce guide. Vérifiez la présence de WiFi, Data Lake > NSG WiFi et nsg_wifi_data dans votre tenant, puis clarifiez toute incertitude avec Sophos ou votre partenaire.

Procédure rapide : ouvrez WiFi, sélectionnez une requête Data Lake intégrée, choisissez au maximum 30 jours, cliquez sur Run Query, puis utilisez si nécessaire Designer Mode et Schema > NSG WiFi > nsg_wifi_data.

Ce que voit la requête — et ce qu’elle ne voit pas

Le chemin de gestion et de télémétrie AP6 fournit des enregistrements à Sophos Fusion (anciennement Sophos Central) et au Data Lake. Une requête Data Lake lit ces données déjà chargées. Elle n’interroge pas directement un client Wi-Fi et ne modifie ni le SSID, ni les paramètres radio, ni l’acheminement du trafic utilisateur Wi-Fi.

nsg_wifi_data peut contenir l’identité et le firmware de l’AP, les adresses MAC et IP du client, les noms d’hôte et d’utilisateur, l’état de connexion, le site, le nom du réseau, la bande, le RSSI et des messages de log. Il s’agit de métadonnées opérationnelles, et non d’une preuve que Live Discover capture le contenu des paquets Wi-Fi. Lors d’un diagnostic, séparez le chemin de gestion/télémétrie du chemin de données Wi-Fi : l’absence de résultat ne prouve pas une panne Wi-Fi, et un Wi-Fi fonctionnel ne prouve pas l’arrivée de la télémétrie dans le Data Lake.

Commencer en sécurité avec une requête intégrée

  1. Dans Sophos Fusion, ouvrez Threat Analysis Center > Live Discover > WiFi.
  2. Sélectionnez une requête intégrée pertinente. Designer Mode n’est pas nécessaire.
  3. Sous Select a Time Period, commencez par les dernières 24 heures ou 7 jours. Une requête ne peut couvrir plus de 30 jours. Pour une recherche plus longue, utilisez des fenêtres distinctes sans chevauchement.
  4. Cliquez sur Run Query, puis comparez les lignes, la période et l’AP6 ou le client attendu.
  5. Une fois ce test concluant, activez Designer Mode. Pour modifier ou créer une requête, choisissez Data Lake comme Source et vérifiez les champs du tenant sous Schema > NSG WiFi > nsg_wifi_data.

Cette séquence distingue un problème de données ou de droits d’une erreur SQL et évite les recherches inutilement larges.

Requêtes personnalisées prudentes

Ces exemples n’utilisent que des champs du schéma AP6 documenté. Limitez aussi la période dans l’interface. Commencez avec une courte fenêtre et LIMIT ; n’utilisez les identifiants que dans le cadre d’une investigation autorisée.

Historique d’un client pilote connu

SELECT timestamp, device_name, device_model, client_mac, client_ip,
       client_hostname, client_conn_status, wireless_network_name,
       wireless_band, wireless_rssi
FROM nsg_wifi_data
WHERE client_mac = '02:00:00:00:00:01'
ORDER BY timestamp DESC
LIMIT 200;

02:00:00:00:00:01 n’est qu’un exemple d’adresse administrée localement. Remplacez-la par l’adresse MAC actuellement utilisée par le client. Les adresses privées ou aléatoires peuvent changer. Sophos ne documente pas de valeurs fixes pour client_conn_status : observez les valeurs renvoyées avant de les filtrer.

Examiner les observations radio

SELECT timestamp, device_name, client_mac, wireless_network_name,
       wireless_band, wireless_rssi, client_bandwidth
FROM nsg_wifi_data
WHERE wireless_rssi IS NOT NULL
ORDER BY timestamp DESC
LIMIT 200;

Le RSSI est un instantané de télémétrie. Une valeur isolée ne prouve pas un problème radio ; examinez ensemble l’évolution, l’AP, la bande et les déplacements du client.

Examiner la télémétrie de logs AP6

SELECT timestamp, device_name, log_severity, log_component,
       log_subtype, log_message
FROM nsg_wifi_data
WHERE log_message IS NOT NULL
ORDER BY timestamp DESC
LIMIT 200;

Ne présumez pas de valeurs de sévérité non documentées. Observez d’abord les valeurs obtenues, puis ajoutez un filtre plus précis à une copie de la requête.

Confidentialité et éléments de preuve fiables

Adresses MAC et IP, noms d’hôte et d’utilisateur, SSID, sites et numéros de série peuvent identifier des personnes ou appareils. Interrogez uniquement les champs requis sur la période utile la plus courte, limitez l’accès aux rôles autorisés et traitez les exports selon vos procédures d’incident et de suppression. Anonymisez les identifiants dans les tickets et captures sauf s’ils sont indispensables à la corrélation.

Une preuve fiable consigne la période, la version de la requête, l’AP6 ou le client attendu et des champs de corrélation tels que timestamp, device_name et client_mac. Comparez les horodatages au fuseau du tenant Central et à l’heure de l’événement sur le terminal. Ici, timestamp indique l’heure de collecte ou de l’événement, tandis que ingestion_timestamp indique l’arrivée de l’enregistrement dans le Data Lake. Une ingestion nettement plus tardive révèle un envoi retardé, et non un événement survenu aussi tard.

Diagnostiquer et arrêter sans risque

WiFi ou le schéma est absent

Vérifiez d’abord le tenant, le rôle administrateur et la disponibilité du produit. Ne tentez pas de résoudre l’incertitude liée aux droits AP6 en modifiant l’AP ou le SSID. Transmettez à Sophos ou au partenaire une capture du menu absent et des informations de tenant non sensibles.

Une requête intégrée ne renvoie aucune ligne

Comparez la période, l’AP6 attendu et l’activité connue du client, puis vérifiez NSG WiFi > nsg_wifi_data sous Schema. Une requête Data Lake lisant la télémétrie chargée, contrôlez séparément l’accès Wi-Fi et l’état de gestion de l’AP6. Si les données restent absentes, conservez la fenêtre, le nom de la requête, l’identité de l’AP6 et l’heure pour le support Sophos.

Seul le SQL personnalisé échoue

Revenez à la requête intégrée inchangée. Si elle fonctionne, copiez les champs depuis le schéma, réduisez le nombre de colonnes et ajoutez les filtres un par un. N’utilisez ni tables ou états supposés, ni automatisation REST/API comme contournement.

Arrêt ou retour en arrière

Ces requêtes sont en lecture seule : aucune configuration Wi-Fi n’est à annuler. Arrêtez en ne lançant plus de requête et en quittant Designer Mode. Aucun interrupteur séparé pour désactiver la télémétrie AP6 n’est décrit ici. Ne modifiez donc pas au hasard les réglages AP6, SSID ou uplink ; si l’envoi des données doit cesser, confirmez la procédure propre au tenant avec Sophos. Supprimez séparément les résultats exportés selon votre politique de confidentialité.