Was ist ein Probe Request? Funktionsweise der Netzwerkerkennung von Geräten

Was ist ein Probe Request? So erkennen Geräte Netzwerke. Ein technisches Briefing von Purple. Einführung und Kontext. Willkommen zu diesem technischen Briefing von Purple. Ich werde Sie durch einen der grundlegendsten – und am häufigsten missverstandenen – Mechanismen im Enterprise-WiFi führen: den Probe Request. Wenn Sie für ein Gäste-WiFi, ein standortübergreifendes Filialnetzwerk oder ein Venue-Analytics-Programm verantwortlich sind, ist das Verständnis von Probe Requests unverzichtbar. Es ist das Fundament für alles Weitere – von der Besucherfrequenz- und Verweildaueranalyse bis hin zu den Herausforderungen der MAC-Randomisierung und der GDPR-Konformität. Lassen Sie uns also direkt einsteigen. Jedes Mal, wenn ein Gerät – ein Smartphone, ein Laptop, ein Tablet – nicht mit einem Netzwerk verbunden ist, sucht es kontinuierlich nach einem. Dieser Suchvorgang beginnt mit einem Probe Request. Es handelt sich dabei um einen Management-Frame, der unter IEEE 802.11 definiert ist und vom Client-Gerät gesendet wird, nicht vom Access Point. Stellen Sie es sich so vor, als würde das Gerät in den Raum rufen: „Ist hier jemand, den ich kenne?“ Der Access Point hört zu, und wenn er die Anfrage erkennt, antwortet er. Dies geschieht Hunderte Male am Tag, oft ohne dass der Besitzer des Geräts überhaupt etwas davon mitbekommt. Und für Netzwerkarchitekten und Betreiber von Veranstaltungsorten sind diese Probe Requests eine Goldgrube an Betriebsdaten – vorausgesetzt, man weiß, wie man sie korrekt erfasst und interpretiert. Technische Details. Gehen wir tiefer in die Funktionsweise ein. Ein Probe Request ist ein Layer-2-Management-Frame, der auf den 2,4-GHz- oder 5-GHz-Funkbändern übertragen wird. Unter dem Standard IEEE 802.11 ist er als Management-Frame vom Subtyp 4 klassifiziert. Der Frame enthält mehrere wichtige Informationselemente: das SSID-Feld, das Element für die unterstützten Datenraten (Supported Rates), das Element für die erweiterten unterstützten Datenraten (Extended Supported Rates) sowie Leistungseigenschaften wie HT- (High-Throughput) und VHT-Leistungsmerkmale für 802.11ac-Geräte. Es gibt zwei Arten von Probe Requests. Der erste ist ein Broadcast-Probe-Request, manchmal auch als Wildcard-Probe bezeichnet. Hierbei ist das SSID-Feld leer – das Gerät fordert im Wesentlichen jeden Access Point in Reichweite auf, sich zu identifizieren. Der zweite Typ ist ein gerichteter (directed) Probe Request, bei dem das SSID-Feld einen bestimmten Netzwerknamen enthält. Dies geschieht, wenn das Gerät aktiv nach einem Netzwerk sucht, mit dem es zuvor verbunden war und das in seiner Liste bevorzugter Netzwerke gespeichert ist. Die Antwort des Access Points – der Probe-Response-Frame – spiegelt einen Großteil des Inhalts des Beacon-Frames wider. Sie enthält die SSID, die BSSID, das Beacon-Intervall, den Zeitstempel und die vollständigen Leistungseigenschaften. Dieser Austausch ermöglicht es einem Gerät, seine Liste der verfügbaren Netzwerke aufzubauen, noch bevor der Benutzer überhaupt seine WiFi-Einstellungen öffnet. Es gibt einen wichtigen Unterschied zwischen aktivem und passivem Scannen. Aktives Scannen ist der soeben beschriebene Zyklus aus Sendeanfragen (Probe Requests) und -antworten (Probe Responses). Passives Scannen funktioniert anders – das Gerät lauscht einfach auf Beacon-Frames, die Access Points regelmäßig, typischerweise alle 100 Millisekunden, ausstrahlen. Passives Scannen ist langsamer, verbraucht aber weniger Strom. Die meisten modernen Geräte nutzen eine Kombination aus beidem, je nach Energiestatus und der regulatorischen Domäne, in der sie betrieben werden. Hier wird es betrieblich relevant. In Veranstaltungsorten mit hoher Dichte – wie einem Stadion, einem Konferenzzentrum oder einer großen Einzelhandelsfläche – können Tausende von Geräten gleichzeitig Sendeanfragen über mehrere Kanäle senden. Dies führt zu sogenannten Probe-Storm-Bedingungen. Jede Sendeanfrage verbraucht Sendezeit (Airtime). In einem schlecht konzipierten Netzwerk kann dieser Overhead durch Management-Frames den Durchsatz für verbundene Clients messbar beeinträchtigen. Aus diesem Grund implementieren Access Points der Enterprise-Klasse standardmäßig eine Filterung und Ratenbegrenzung von Sendeanfragen. Sprechen wir nun über MAC-Adressen und warum dies für Analysen von enormer Bedeutung ist. Historisch gesehen trug jede Sendeanfrage die echte Hardware-MAC-Adresse des Geräts – eine weltweit eindeutige 48-Bit-Kennung, die fest in die Netzwerkschnittstellenkarte eingebrannt ist. Dies machte probebasierte Analysen äußerst zuverlässig. Sie konnten ein Gerät auf Ihrem Gelände verfolgen, die Verweildauer messen, wiederkehrende Besucher identifizieren und mit hoher Zuverlässigkeit Heatmaps der Besucherströme erstellen. Das änderte sich im Jahr 2020 mit iOS 14 und zuvor mit Android 10 erheblich. Apple und Google führten die Randomisierung von MAC-Adressen für Sendeanfragen ein. Anstatt die echte Hardware-MAC auszustrahlen, generieren Geräte nun eine zufällige MAC-Adresse für den Scanvorgang. Unter iOS erfolgt diese Randomisierung pro SSID – das bedeutet, dass das Gerät eine konsistente, zufällige MAC-Adresse verwendet, wenn es eine Verbindung zu einem bestimmten Netzwerk herstellt, aber eine andere, wenn es nach Netzwerken sucht. Unter Android variiert die Implementierung je nach Hersteller. Die praktischen Auswirkungen für Betreiber von Veranstaltungsorten sind erheblich. Probebasierte Besucherstromanalysen, die auf persistenten MAC-Adressen basierten, sind für nicht verbundene Geräte mittlerweile unzuverlässig. Die Anzahl der eindeutigen Geräte wird künstlich aufgebläht. Die Identifizierung wiederkehrender Besucher allein anhand von Sendedaten ist nicht mehr tragbar. Die Lösung – und hier wird authentifiziertes Gäste-WiFi entscheidend – besteht darin, Ihre Identitätsebene von der MAC-Adresse auf den authentifizierten Benutzer zu verlagern. Wenn sich ein Besucher über ein Captive Portal oder einen Social-Login verbindet, erfassen Sie eine persistente, konsentierte Identität, die die MAC-Randomisierung übersteht. Die Gäste-WiFi-Plattform von Purple macht genau das – sie verknüpft die Analysen mit der authentifizierten Sitzung und nicht mit der Hardware-Adresse. So erhalten Sie präzise, GDPR-konforme Besucherstromdaten, unabhängig vom MAC-Verhalten des Geräts. Es gibt auch eine sicherheitsrelevante Dimension bei Probe Requests, die Netzwerksicherheitsanalysten verstehen müssen. Da Probe Requests unverschlüsselte Management-Frames sind, sind sie für jeden sichtbar, der ein Paketaufzeichnungstool im Monitor-Modus verwendet. Ein gerichteter Probe Request offenbart die SSIDs von Netzwerken, mit denen sich ein Gerät zuvor verbunden hat – die sogenannte Preferred Network List oder PNL. Dies stellt ein echtes Datenschutzrisiko dar. Ein Gerät, das sich durch Ihren Standort bewegt, sendet die Namen aller Netzwerke aus, mit denen es jemals verbunden war. Dies ist einer der Gründe, warum die MAC-Randomisierung überhaupt erst eingeführt wurde. Aus Sicht der Angriffsfläche ermöglichen Probe Requests sogenannte Evil-Twin-Angriffe. Ein Angreifer, der einen gerichteten Probe Request für eine bestimmte SSID abfängt, kann einen betrügerischen Access Point mit dieser SSID einrichten und darauf warten, dass sich das Gerät automatisch verbindet. Die Protokolle von WPA3 für Enhanced Open und die gleichzeitige Authentifizierung von Gleichwertigen – SAE – mindern dieses Risiko erheblich, aber nur, wenn Ihre Infrastruktur diese unterstützt und erzwingt. Implementierungsempfehlungen und Fallstricke. Kommen wir nun dazu, was Sie in einer realen Bereitstellung tatsächlich damit tun. Erstens: Wenn Sie ein Gäste-WiFi-Netzwerk an einem hochfrequentierten Standort bereitstellen oder aktualisieren, müssen Ihre Access-Point-Platzierung und Ihre Kanalplanung den Overhead von Probe Requests berücksichtigen. Nutzen Sie eine Strategie mit minimaler Kanalbreite – 20 MHz bei 2,4 GHz – und implementieren Sie minimale RSSI-Schwellenwerte, um zu verhindern, dass sich weit entfernte Geräte verbinden. Die meisten Enterprise-Controller ermöglichen die Einrichtung einer Filterung für Probe Responses, sodass APs nur auf Geräte reagieren, die eine bestimmte Signalstärke überschreiten. Dies reduziert das Rauschen durch Management-Frames erheblich. Zweitens: Wenn Sie Analysen zur Besucherfrequenz oder Verweildauer durchführen, müssen Sie akzeptieren, dass reine Probe-Daten nicht mehr ausreichen. Ihre Analysestrategie muss auf authentifizierten Sitzungen aufbauen. Das bedeutet, dass Ihr Captive Portal oder Ihr Onboarding-Prozess so reibungslos gestaltet sein muss, dass sich die Besucher tatsächlich verbinden. Die Daten von Purple zeigen, dass Standorte mit einem gut gestalteten Onboarding-Erlebnis – Social Login, E-Mail-Erfassung oder ein passwortloser Ablauf – Verbindungsraten von 60 bis 80 Prozent der Geräte vor Ort verzeichnen. Das ist Ihre Zielgruppe für die Analyse. Drittens: Für die GDPR-Konformität in Großbritannien und der EU erfordert die Erfassung von Probe-Request-Daten – selbst in anonymisierter Form – eine sorgfältige Prüfung der Rechtsgrundlage. Wenn Sie Probe-Frames für Analysen erfassen und speichern, müssen Sie Ihr berechtigtes Interesse dokumentieren und die Datenminimierung sicherstellen. Die Richtlinien des ICO zum WiFi-Tracking sind eindeutig: Wenn Sie eine Person anhand der Daten identifizieren können, selbst indirekt, handelt es sich um personenbezogene Daten. Stimmen Sie sich mit Ihrem Datenschutzbeauftragten ab, bevor Sie ein probe-basiertes Analysesystem einführen. Viertens: Achten Sie auf Probe Storms in dichten Umgebungen. Wenn Sie an einem Standort mit hoher Besucherfrequenz einen unerklärlichen Durchsatzeinbruch feststellen, prüfen Sie Ihre AP-Protokolle und achten Sie auf die Management-Frame-Raten. Ein Probe Storm ist oft die Ursache. Die Lösung ist eine Kombination aus minimalem RSSI-Filtering, Probe-Response-Rate-Limiting und der Sicherstellung, dass Ihr 5-GHz-Band richtig beworben wird, damit fähige Geräte es gegenüber 2,4 GHz bevorzugen. Schnelle Fragerunde. Lassen Sie uns ein paar Fragen durchgehen, die regelmäßig auftauchen. Kann ich Probe Requests verwenden, um die Besucherzahl ohne Captive Portal zu erfassen? Technisch gesehen ja, aber seit iOS 14 ist die Genauigkeit gering. Sie werden überhöhte Unique-Counts und keine Daten über wiederkehrende Besucher sehen. Für alles, was über grobe Schätzungen hinausgeht, benötigen Sie authentifizierte Sitzungen. Funktionieren Probe Requests in 6-GHz-WiFi-6E-Netzwerken? Ja, aber mit Unterschieden. Das 6-GHz-Band nutzt einen Erkennungsmechanismus namens FILS — Fast Initial Link Setup — und Out-of-Band-Discovery, was die Probe-Dynamik verändert. Wenn Sie WiFi 6E bereitstellen, prüfen Sie die Dokumentation Ihres Herstellers zum 6-GHz-Scanning-Verhalten. Was ist der Unterschied zwischen einem Probe Request und einem Association Request? Ein Probe Request erfolgt vor der Assoziierung — das Gerät sucht nach Netzwerken. Ein Association Request erfolgt nach der Authentifizierung, wenn das Gerät formell den Beitritt zu einem bestimmten Netzwerk anfordert. Es handelt sich um unterschiedliche Phasen der 802.11-Verbindungs-State-Machine. Bleibt die MAC-Randomisierung nach dem Verbindungsaufbau konsistent? Unter iOS ja — das Gerät verwendet eine stabile, randomisierte MAC für eine bestimmte SSID. Unter Android variiert dies. Einige Implementierungen randomisieren bei jeder Verbindung neu. Aus diesem her ist eine sitzungsbasierte Identität, und nicht eine MAC-basierte Identität, die richtige Architektur. Zusammenfassung und nächste Schritte. Fazit: Probe Requests sind der Herzschlag der WiFi-Erkennung. Jedes Gerät an Ihrem Standort erzeugt sie ständig. Ihre Struktur, ihre Grenzen und ihre Sicherheitsimplikationen zu verstehen, ist grundlegend für die Entwicklung zuverlässiger, analysefähiger und konformer WiFi-Gastzugänge. Die wichtigsten Erkenntnisse sind diese. Erstens: Probe-basierte Analysen ohne Authentifizierung sind in einer Welt nach der MAC-Randomisierung unzuverlässig. Zweitens: Authentifiziertes WiFi-Gästenetzwerk ist Ihre Identitätsebene — es macht Ihre Analysen präzise und Ihre Daten GDPR-konform. Drittens: Das Management von Probe Storms ist ein reales betriebliches Problem in hochfrequentierten Standorten und muss bereits bei der Infrastrukturplanung berücksichtigt werden. Viertens: Directed Probe Requests legen die bevorzugte Netzwerkliste Ihres Geräts offen — ein echtes Sicherheitsrisiko, das durch WPA3 und bewährte Netzwerkpraktiken gemindert werden kann. Wenn Sie tiefer einsteigen möchten, beschreibt die technische Dokumentation von Purple, wie unsere hardwareunabhängige Plattform Probe-Daten zusammen mit authentifizierten Sitzungsdaten erfasst und verarbeitet, um Ihnen präzise Standortanalysen zu liefern. Sie können auch unsere Leitfäden zu WiFi-Wayfinding und Trilateration lesen, die direkt auf den heute behandelten Grundlagen zu Probe Requests aufbauen. Vielen Dank fürs Zuhören. Dies war ein technisches Briefing von Purple.