Więcej

    Active Scanning w Sieciach Wi-Fi

    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 najoptymalniej 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
    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

    Kącik bezpieczeństwa

    Pozostaje kwestia bezpieczeństwa sieci związana z mechanizmem skanowania aktywnego. Ramki Null Probe Request skutkują wyciągnięciem informacji od AP o wszystkich SSID jakie posiada, nawet tych z używaną opcją ukrycia SSID (Hidden SSID / Cloaking). Samo to nie jest niczym szczególnym, te same informacje są przecież widoczne w ramkach Beacon. Problemem może być natomiast zalanie sieci spreparowanymi ramkami Null Probe Request, czyli atak Probe Request flood. Wroga stacja może cały czas wysyłać ramki Null Probe Request, co poskutkuje ciągłymi odpowiedziami Probe Response od AP. To w konsekwencji może doprowadzić do ogromnego natężenia ramek typu management i braku przestrzeni dla ramek danych. Jak się bronić? W zależności od producenta sprzętu sieciowego możesz mieć możliwość wyłączenia mechanizmu Active Scanning na AP, który tym samym przestanie wysyłać ramki Probe Response. Nie będzie to zgodne ze standardem IEEE 802.11 ale nie wpłynie na samą komunikację.

    Drugi z popularnych ataków to Probe Response flood. Wroga stacja może wysyłać spreparowane ramki Probe Response i tym samym podszywać się pod naszą sieć WLAN. Niczego nieświadomy klient może nawiązać komunikację z tak podstawionym punktem dostępowym i narazić się na atak typu man-in-the-middle. Jak się bronić? Koniecznie włączyć na AP funkcjonalności WIPS/WIDS, które mogą przede wszystkim zneutralizować taki atak, ale także poinformować Cię o jego wystąpieniu.

    Ze względu na drobne ale jakże istotne różnice w zawartości ramek Beacon i Probe Response (chodzi o pole TIM) skanowanie aktywne nie może być określane mianem ekwiwalentu skanowania pasywnego. Jest ono natomiast bardziej efektywnym sposobem poszukiwania sieci bezprzewodowych. W świecie Wi-Fi na pewno jest miejsce dla obu tych technik!

    Gdybyś był klientem to wolałbyś dostać ramkę Beacon czy ramkę Probe Response? 😉

    🗳 Jak przydatna była ta publikacja?

    Średnia ocena 4.8 / 5. Ilość głosów: 5

    Brak ocen. Bądź pierwszy!

    Dziękujemy za ocenę! Zapraszamy Cię do obserwowania NSS w mediach społecznościowych!

    Przykro nam, że ta publikacja okazała się być dla Ciebie nieprzydatna!

    Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.

    Jak możemy poprawić tę publikację?

    Łukasz Kowalski
    Network Architect, Współtwórca Na Styku Sieci
    guest
    0 - Ilość komentarzy
    Inline Feedbacks
    View all comments

    Przygotowujesz się do certyfikacji CCNA?

    Zapisz się na nasz NSSletter, a co tydzień we wtorek rano otrzymasz porcję sieciowej wiedzy oraz porady dotyczące certyfikacji.

    Uzupełniając powyższe pole wyrażasz zgodę na otrzymywanie od GetGoodNet Damian Michalak z siedzibą we Wrocławiu newslettera zawierającego treści edukacyjne. Zgodę możesz wycofać w każdym czasie.

    NSS na Social Media

    1,611FaniLubię
    72ObserwującyObserwuj
    133ObserwującyObserwuj
    1,220SubskrybującySubskrybuj

    Najnowsze artykuły

    spot_img

    Może Cię też zainteresować...

    0
    Co sądzisz na temat tej publikacji? Zostaw proszę komentarzx
    ()
    x