AP6-WLAN-Telemetrie mit Live Discover untersuchen

Mit Live Discover lässt sich die von AP6 Access Points an den Sophos Data Lake übermittelte WLAN-Telemetrie interaktiv untersuchen. Der direkte Einstieg ist Threat Analysis Center > Live Discover > WiFi. Zuerst sollte eine integrierte Abfrage mit einem kurzen Zeitraum ausgeführt werden; eigene SQL-Abfragen folgen erst, wenn damit Daten sichtbar sind.

Verfügbarkeit vorab prüfen: Die allgemeine Live-Discover-Dokumentation nennt Sophos EDR, XDR oder MDR als Voraussetzung. Die AP6-Dokumentation legt jedoch keine eindeutige spezielle AP6-Entitlement-Kombination fest. Deshalb keine konkrete AP6-Lizenz aus dieser Anleitung ableiten: Im eigenen Tenant prüfen, ob WiFi, Data Lake > NSG WiFi und nsg_wifi_data vorhanden sind, und Unklarheiten mit Sophos oder dem Partner klären.

Kurzablauf: WiFi öffnen, eine integrierte Data-Lake-Abfrage auswählen, höchstens 30 Tage einstellen, Run Query ausführen und erst danach bei Bedarf den Designer Mode sowie Schema > NSG WiFi > nsg_wifi_data verwenden.

Was die Abfrage sieht – und was nicht

Der AP6-Management- und Telemetriepfad liefert Datensätze an Sophos Fusion (ehemals Sophos Central) und den Data Lake. Eine Data-Lake-Abfrage liest diese bereits hochgeladenen Datensätze. Sie ist keine Abfrage direkt auf einem WLAN-Client und verändert weder SSID, Funkparameter noch die Weiterleitung des WLAN-Nutzdatenverkehrs.

Die Tabelle nsg_wifi_data kann unter anderem AP-Identität und -Firmware, Client-MAC- und IP-Adresse, Host- und Benutzernamen, Verbindungsstatus, Standort, WLAN-Name, Band, RSSI sowie Logmeldungen enthalten. Das ist Betriebsmetadaten-Telemetrie, kein Beleg dafür, dass Live Discover den Inhalt der übertragenen WLAN-Pakete erfasst. Management-/Telemetriepfad und WLAN-Datenpfad müssen deshalb bei der Fehlersuche getrennt betrachtet werden: Fehlende Abfrageergebnisse beweisen keinen WLAN-Ausfall, und ein funktionierendes WLAN beweist nicht, dass Telemetrie im Data Lake angekommen ist.

Sicher mit einer integrierten Abfrage starten

1. In Sophos Fusion Threat Analysis Center > Live Discover > WiFi öffnen.
2. Eine passende integrierte Abfrage auswählen. Dafür muss Designer Mode nicht eingeschaltet sein.
3. Unter Select a Time Period zunächst beispielsweise die letzten 24 Stunden oder 7 Tage wählen. Eine einzelne Abfrage darf höchstens 30 Tage umfassen. Für längere Untersuchungen getrennte, nicht überlappende Zeitfenster verwenden.
4. Run Query wählen und Ergebniszeilen, Zeitraum und erwarteten AP6 beziehungsweise Client vergleichen.
5. Erst nach diesem Basistest Designer Mode einschalten. Beim Bearbeiten oder Erstellen einer Abfrage Data Lake als Source wählen und über Schema > NSG WiFi > nsg_wifi_data die im eigenen Tenant verfügbaren Felder kontrollieren.

Dieser Ablauf trennt ein Daten- oder Berechtigungsproblem von einem Fehler in eigener SQL-Syntax. Er vermeidet auch unnötig breite Abfragen.

Konservative eigene Abfragen

Die folgenden Beispiele verwenden nur Felder aus dem dokumentierten AP6-Schema. Der Zeitraum wird zusätzlich im Zeitwähler der Oberfläche begrenzt. Zuerst mit kleinem Zeitraum und LIMIT arbeiten; MAC-Adressen und andere Identifikatoren nur in einem autorisierten Incident verwenden.

Verbindungshistorie eines bekannten Pilotclients

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 ist nur ein lokal verwaltetes Beispiel und muss durch die aktuell am Client verwendete MAC-Adresse ersetzt werden. Private beziehungsweise zufällige MAC-Adressen können sich ändern. Sophos dokumentiert keine festen Werte für client_conn_status; deshalb zuerst die tatsächlich zurückgegebenen Werte ansehen, bevor danach gefiltert wird.

Funkbeobachtungen prüfen

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;

RSSI ist eine Momentaufnahme aus der Telemetrie. Einzelwerte nicht als alleinigen Beweis für ein Funkproblem verwenden; Verlauf, AP, Band und Clientwechsel gemeinsam prüfen.

AP6-Logtelemetrie sichten

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;

Auch hier keine undokumentierten Severity-Werte voraussetzen. Erst das Ergebnisvokabular prüfen und danach eine Kopie der Abfrage enger filtern.

Datenschutz und saubere Beweisführung

MAC- und IP-Adressen, Host- und Benutzernamen, SSIDs, Standorte und Seriennummern können Personen oder Geräten zugeordnet werden. Deshalb nur benötigte Felder und den kleinsten sinnvollen Zeitraum abfragen, Zugriff auf autorisierte Rollen begrenzen und Exporte nach dem eigenen Lösch- und Incident-Prozess behandeln. In Tickets und Screenshots Identifikatoren anonymisieren, sofern sie für die Korrelation nicht zwingend benötigt werden.

Ein belastbarer Nachweis enthält den gewählten Zeitraum, die Abfrageversion, den erwarteten AP6 oder Pilotclient und einige korrelierende Felder wie timestamp, device_name und client_mac. Zeitstempel immer mit der Zeitzone des Central-Tenants und der Endgeräteereignisse abgleichen. Dabei bezeichnet timestamp den Zeitpunkt der Erfassung beziehungsweise des Ereignisses, ingestion_timestamp dagegen die Aufnahme des Datensatzes in den Data Lake. Liegt der zweite Wert deutlich später, spricht das für einen verzögerten Upload und nicht für ein entsprechend spätes Ereignis.

Fehler eingrenzen und sicher abbrechen

WiFi oder das Schema fehlt

Zuerst Tenant, Adminrolle und Produktverfügbarkeit prüfen. Die unklare AP6-Entitlement-Frage nicht durch Änderungen am Access Point oder an der SSID zu lösen versuchen. Einen Screenshot des fehlenden Menüs und Tenantdetails ohne sensible Daten an Sophos beziehungsweise den Partner geben.

Die integrierte Abfrage liefert keine Zeilen

Zeitraum, erwarteten AP6 und bekannte Clientaktivität vergleichen. Danach unter Schema kontrollieren, ob NSG WiFi > nsg_wifi_data vorhanden ist. Da Data-Lake-Abfragen hochgeladene Telemetrie lesen, WLAN-Erreichbarkeit und AP6-Managementstatus getrennt prüfen. Bleiben Daten trotz bekannter Aktivität aus, Zeitfenster, Abfragename, AP6-Identität und Zeitpunkt für Sophos Support sichern.

Nur die eigene SQL-Abfrage schlägt fehl

Zur unveränderten integrierten Abfrage zurückkehren. Funktioniert sie, Feldnamen direkt aus dem Schema übernehmen, die Abfrage auf wenige Spalten reduzieren und Filter schrittweise ergänzen. Nicht mit vermuteten Tabellen, Statuswerten oder REST/API-Automation ausweichen.

Abbruch oder Rückweg

Diese Abfragen sind lesend; es gibt keine WLAN-Konfigurationsänderung zurückzunehmen. Eine laufende Untersuchung sicher abbrechen, indem keine weitere Abfrage gestartet und Designer Mode verlassen wird. Hier ist kein separater Schalter zum Deaktivieren der AP6-Telemetrie beschrieben. Deshalb dafür nicht eigenmächtig AP6-, SSID- oder Uplink-Einstellungen ändern; falls die Datenbereitstellung beendet werden muss, den für den eigenen Tenant dokumentierten Weg mit Sophos klären. Bereits exportierte Ergebnisse separat nach der Datenschutzrichtlinie entfernen.