Active Scanning w Sieciach Wi-Fi

Łukasz Kowalski
Łukasz Kowalski Skomentuj

Bez ramek Beacon sieć Wi-Fi nie istnieje. Prawda? Nie do końca! Stacje klienckie mogą wziąć sprawy w swoje ręce i zainicjować poszukiwanie sieci bezprzewodowych korzystając z mechanizmu skanowania aktywnego. Nasze urządzenia korzystają z tej możliwości o wiele częściej niż nam się wydaje, dlatego warto przyjrzeć się temu bliżej.

Skanowanie aktywne

Oprócz biernego oczekiwania na ramki Beacon stacja kliencka może także aktywnie poszukiwać sieci bezprzewodowe. Oczekiwany rezultat jest ten sam w obu przypadkach – urządzenie końcowe pragnie otrzymać informacje niezbędne do nawiązania połączenia z siecią Wi-Fi. Jednakże całkowitym przeciwieństwem jest rola stacji klienckiej – w przypadku skanowania aktywnego urządzenie końcowe niejako nawołuje w poszukiwaniu sieci, rozpoczynając tym samym proces Active Scanning. Stąd też nazwa – jest to skanowanie aktywne z punktu widzenia urządzenia końcowego. Cały proces składa się z trzech opisanych poniżej etapów.

Etap pierwszy – Probe Request

Proces rozpoczyna stacja kliencka wysyłając specjalną ramkę o nazwie Probe Request.

Etap pierwszy - klient wysyła ramkę Probe Request
Etap pierwszy – klient wysyła ramkę Probe Request

Jest to ramka typu management, którą w łatwy sposób można odnaleźć w próbce pakietów zakładając poniższy filtr w programie Wireshark:

(wlan.fc.type == 0) && (wlan.fc.subtype == 4)

W ten sposób wskazujemy, że chcemy zobaczyć wyłącznie ramki typu management (pole Type w nagłówku ramki ustawione na 0) oraz jednocześnie podtypu Probe Request (pole Subtype w nagłówku ramki ustawione na 4). Na poniższym obrazku widać efekt po założeniu wspomnianego filtra:

Ramki Probe Request widoczne w programie Wireshark
Ramki Probe Request widoczne w programie Wireshark

Warto przyjrzeć się bliżej informacjom zawartym w nagłówku ramki Probe Request:

Nagłówek ramki Probe Request
Nagłówek ramki Probe Request

Jak widzisz ramka wysłana jest przez stację kliencką z adresem docelowym ustawionym na Broadcast. Taka ramka zostanie odebrana przez wszystkie punkty dostępowe znajdujące się w zasięgu klienta, a następnie zostanie przeprocesowana i nastąpi ewentualna odpowiedź.

Etap drugi – Probe Response

W ramach odpowiedzi Access Point może wysłać ramkę Probe Response i tym samym rozpocząć drugi etap procesu Active Scanning.

Etap drugi - AP odpowiadają ramkami Probe Response
Etap drugi – AP odpowiadają ramkami Probe Response

To również jest ramka typu management, a w programie Wireshark łatwo ją znajdziesz zakładając poniższy filtr:

(wlan.fc.type == 0) && (wlan.fc.subtype == 5)

W ten sposób wskazujemy, że chcemy zobaczyć wyłącznie ramki typu management (pole Type w nagłówku ramki ustawione na 0) oraz jednocześnie podtypu Probe Response (pole Subtype w nagłówku ramki ustawione na 5). Na poniższym obrazku widać efekt po założeniu wspomnianego filtra:

Ramki Probe Response w programie Wireshark
Ramki Probe Response w programie Wireshark

Ramka Probe Response skierowana jest bezpośrednio do nadawcy ramki Probe Request. Warto również zauważyć, że każdy AP odpowiada własną ramką. Poniższy obrazek przedstawia nagłówek ramki Probe Response:

Nagłówek ramki Probe Response
Nagłówek ramki Probe Response

Etap trzeci – Acknowledgment

Wysłanie ramki Probe Response jest transmisją typu unicast, więc zgodnie ze standardem IEEE 802.11 stacja kliencka musi potwierdzić jej odbiór wysyłając ramkę ACK. Dopiero wtedy wymiana informacji w procesie Active Scanning może być uznana za zakończoną:

Etap trzeci - klient wysyła ramki ACK
Etap trzeci – klient wysyła ramki ACK

Skanowanie aktywne w praktyce

Punkty dostępowe mogą działać na różnych częstotliwościach, mogą korzystać z różnych kanałów, a to wszystko po to, by jak najbardziej optymalnie wykorzystać medium bezprzewodowe. Jest to normalne zachowanie w sieciach Wi-Fi, a stacja kliencka musi się do tego dostosować. W tym celu standard IEEE 802.11 przewiduje poniższą procedurę, dzięki której urządzenie końcowe będzie mogło poszukiwać sieci bezprzewodowe sprawdzając kanał po kanale. W lekkim uproszczeniu wygląda to tak:

1. Przejdź do następnego kanału.
2. Wygraj rywalizację o dostęp do medium bezprzewodowego i wyślij ramkę Probe Request.
3. Poczekaj aż upłynie czas określony w zmiennej MinChannelTime i:
   a. jeśli dotychczas nie odnotowałeś żadnego ruchu to przyjmij, że na tym kanale nie ma urządzeń 802.11 i przejdź do następnego kanału,
   b. jeśli odnotowałeś jakiś ruch (kanał był zajęty) to nasłuchuj aż upłynie czas określony w zmiennej MaxChannelTime i przeprocesuj wszelkie ramki Probe Response jakie zdołasz usłyszeć.

Standard IEEE 802.11 nie określa kanałów jakie powinny być przeskanowane przez klienta. Zakres oraz kolejność skanowanych kanałów jest zależna od producenta i może być określona przez sterownik karty sieciowej i użyty chipset. Podobnie rzecz ma się ze zmiennymi MinChannelTime i MaxChannelTime – długość przebywania na danym kanale zależy od implementacji producenta, a zazwyczaj wynosi od kilku do kilkudziesięciu milisekund.

Jak dotąd nie doprecyzowałem jednej rzeczy – które dokładnie AP odpowiedzą ramką Probe Response? To zależy od rodzaju ramki Probe Request, a możliwości są dwie – przeczytasz o nich w kolejnych rozdziałach.

Direct Probe Request

Pierwsza możliwość to Direct Probe Request. W tym przypadku stacja kliencka wysyła ramkę Probe Request, w której jasno określa poszukiwane SSID. W poniższym przypadku chodzi o SSID „NSS”:

Oprócz tego stacja kliencka określa swoje możliwości, takie jak między innymi wspierane prędkości oraz szczegóły implementacji takich standardów jak IEEE 802.11n (sekcja HT).

Na taką ramkę odpowiedzą tylko takie AP, które ją usłyszą i jednocześnie posiadają w swojej konfiguracji dokładnie wskazane SSID.

Odpowiedź od AP posiadających SSID "NSS"
Odpowiedź od AP posiadających SSID „NSS”

Ramka Probe Response zawiera prawie wszystkie informacje jakie możemy znaleźć w ramce Beacon. Są to zatem między innymi takie parametry jak SSID, częstotliwość, kanał, wspierane standardy i prędkości, poziom zabezpieczeń dostępu itp. Szczegóły odnośnie zawartości ramki Beacon znajdziesz w dedykowanym artykule. Poniższy obrazek przedstawia ramkę Probe Response uchwyconą w programie Wireshark:

To co odróżnia ramkę Probe Response od ramki Beacon to trzy poniższe fakty:

  • ramka Beacon zawiera pole TIM (Traffic Indication Map),
  • ramka Beacon zawiera pole QoS Capability,
  • ramka Probe Response zawiera pole Requested Elements, w którym mogą znajdować się szczególne informacje zażądane przez stację wysyłającą ramkę Probe Request.

Null Probe Request

Druga możliwość to Null Probe Request, którą często określa się też mianem Wildcard SSID. W tym przypadku stacja kliencka wysyła ramkę Probe Request, w której nie podaje SSID. Mówiąc wprost, pole SSID w tej ramce jest puste – stąd wywodzą się przytoczone nazwy. Poniższy filtr pokaże wszystkie ramki Probe Request bez sprecyzowanego SSID:

(wlan.fc.type == 0) && (wlan.fc.subtype == 4) && (wlan.ssid == "")

Na poniższym obrazku widać efekt po założeniu wspomnianego filtra:

Ramki Null Probe Request

Natomiast wnętrze ramki prezentuje się następująco:

Wnętrze ramki Null Probe Request
Wnętrze ramki Null Probe Request

Poza polem SSID wszystkie pozostałe elementy nie różnią się od ramki Direct Probe Request.

Spora różnica jest natomiast widoczna w przypadku odpowiedzi od AP. Tym razem bowiem odpowiedzą wszystkie AP, które usłyszą ramkę Null Probe Request – to jest jedyny warunek. Co więcej, każdy AP wyśle tyle ramek Probe Response, ile posiada skonfigurowanych SSID. W poniższym przykładzie AP środkowy i prawy mają dwa SSID, więc każdy z nich wyśle dwie ramki Probe Response, w każdej informując o konkretnym SSID. Natomiast lewy AP ma tylko jedno SSID i dlatego wyśle tylko jedną odpowiedź.

Odpowiedź na ramkę Null Probe Request
Odpowiedź na ramkę Null Probe Request
Zostaw komentarz
Otrzymuj powiadomienia z tej dyskusji
Powiadom mnie o
guest

0 - Ilość komentarzy
Inline Feedbacks
View all comments