Przejdz do tresci
Avanet

Zabezpieczanie Sophos AP6 przed AirSnitch: właściwa izolacja klientów

Central Wireless

Luka AirSnitch oznaczona jako sophos-sa-20260421-airsnitch dotyczy wszystkich wersji AP6 obecnie uznawanych za podatne. Rzeczywiste narażenie zależy od projektu SSID, konfiguracji, wariantu ataku i sieci nadrzędnej. Dla AP6 istotne są trzy ścieżki iniekcji: GTK Abuse, Broadcast Reflection i Gateway Bouncing. Sam AirSnitch nie umożliwia pełnego ataku man-in-the-middle na AP6.

⚠️ Brak pełnej poprawki: obecnie nie istnieje kompletna mitygacja, remediacja ani poprawiona wersja dla tej klasy ataków. Poniższe środki ograniczają ryzyko, lecz go nie eliminują. Bezpośrednio przed każdą falą wdrożenia sprawdź aktualny stan wersji AP6 i remediacji. Jeśli stan się zmienił, zatrzymaj wdrożenie i ponownie oceń zabezpieczenia, pilotaż oraz rollback.

Szybka ścieżka: najpierw zapisz dokładny stan bazowy. Na jednym pilotażowym SSID sprawdź lub włącz Client isolation i Proxy ARP w My Products > Wireless > SSIDs > nazwa SSID > Advanced Settings. Rozdziel urządzenia zaufane i niezaufane na osobne SSID i VLAN-y, zablokuj na bramie ruch między klientami, w tym możliwe ścieżki hairpin, a obsługiwane mechanizmy anti-spoofing testuj dopiero po weryfikacji topologii. WPA2/WPA3 Enterprise i 802.11w to dodatkowe zabezpieczenia, a nie pełne rozwiązanie AirSnitch.

Dlaczego Client isolation nie wystarcza

Client isolation blokuje komunikację tylko między urządzeniami bezprzewodowymi połączonymi z tym samym punktem dostępowym. Urządzenia w tej samej podsieci mogą nadal komunikować się przez różne punkty dostępowe. Tę zwykłą lokalną granicę L2 trzeba odróżnić od ścieżki routowanej lub odbitej.

W Gateway Bouncing spreparowana ramka trafia do bramy nadrzędnej, a następnie jest routowana z powrotem do ofiary. Samo zablokowanie bezpośredniego przekazywania przez AP nie obejmuje automatycznie ścieżki L3/hairpin. Zielony status Central nie potwierdza też polityki bramy ani izolacji między AP.

Proxy ARP pozwala AP odpowiadać na zapytania ARP przeznaczone dla podłączonych urządzeń bezprzewodowych. Ogranicza ekspozycję na broadcast i jest ważnym środkiem AirSnitch, ale nie zastępuje izolacji, VLAN-ów, polityki firewalla ani kontroli ścieżki powrotnej.

Zapisz dokładny stan bazowy przed pilotażem

Przed pierwszym Save zapisz co najmniej poniższe informacje dla każdego objętego zmianą SSID, najlepiej w eksporcie lub na zrzutach ekranu z datą:

  • nazwę SSID, stan Enable SSID, przypisane urządzenia AP6 i włączone pasma;
  • tryb szyfrowania, wybór RADIUS i istotne wartości uwierzytelniania, bez zapisywania sekretów;
  • bieżący stan Client isolation, Proxy ARP i 802.11w;
  • tryb Client connection oraz statyczne lub dostarczane przez RADIUS identyfikatory VLAN;
  • uplink AP, dozwolone VLAN-y, podsieć klientów, bramę, DHCP, DNS i istniejące reguły bramy lub firewalla;
  • ustawienia DHCP Snooping, IP Source Guard lub uRPF, w tym porty, role zaufania i wyjątki;
  • dwóch znanych klientów testowych, pilotażowy AP, drugi AP oraz obecnie działające przepływy dozwolone i blokowane.

To jest baza rollbacku. „Przywrócenie poprzednich ustawień” jest bezpieczne tylko wtedy, gdy poprzednie opcje, przypisania, VLAN-y i reguły są znane. Save aktualizuje wszystkie AP przypisane do SSID i może chwilowo rozłączyć klientów, dlatego pierwszą zmianę ogranicz do testowego SSID lub jednego AP.

Zabezpiecz SSID AP6 warstwowo

1. Włącz Client isolation i Proxy ARP

W My Products > Wireless > SSIDs wybierz SSID pilotażowy i otwórz Advanced Settings. W sekcji Security włącz Client isolation, a następnie w Quality of service włącz Proxy ARP. Początkowo zapisz zmianę tylko dla zaplanowanego zakresu pilotażu.

Client isolation chroni bezpośrednią ścieżkę między klientami tego samego AP. Proxy ARP ogranicza rozgłoszenia ARP, odpowiadając w imieniu podłączonych urządzeń bezprzewodowych. Te opcje uzupełniają się, ale nie zamykają całkowicie ścieżki między AP, wszystkich wariantów broadcast lub multicast ani drogi przez bramę nadrzędną.

Przed szerszym wdrożeniem sprawdź aplikacje wymagające lokalnego wykrywania, na przykład drukarki i casting. Jeśli potrzebna funkcja przestanie działać, nie wyłączaj domyślnie wszystkich zabezpieczeń ani nie twórz bezpośredniego wyjątku między klientami. Kontrolowane discovery lub dostęp między klientami skieruj przez osobno zaprojektowaną bramę polityki lub discovery ze ściśle ograniczonymi regułami.

2. Rozdziel strefy zaufania za pomocą SSID i VLAN-ów

Urządzenia niezaufane, BYOD, IoT i zarządzane urządzenia wewnętrzne nie powinny współdzielić jednej płaskiej sieci klientów. Użyj osobnych SSID i VLAN-ów z odrębnymi politykami bezpieczeństwa. Nie mieszaj klientów zaufanych i niezaufanych w tym samym SSID, a jeśli to możliwe — również na tym samym AP.

Central jedynie oznacza ruch klienta wybranym identyfikatorem VLAN; switch, brama, DHCP, DNS i polityki muszą istnieć poza Central. Pełną konfigurację opisuje artykuł Konfiguracja SSID AP6 z VLAN-em. Sam identyfikator VLAN nie stanowi granicy bezpieczeństwa: o dostępnych strefach i celach decyduje polityka bramy lub firewalla.

3. Zablokuj ścieżki L3 i hairpin na bramie

Na bramie lub firewallu blokuj ruch Layer 3 między klientami możliwie restrykcyjnie, również ruch, który brama kierowałaby z powrotem do tej samej podsieci klientów. Zezwalaj wyłącznie na konkretnie wymagane cele i usługi. Logowanie reguły pilotażowej pomaga potwierdzić, czy ruch testowy rzeczywiście przechodzi tą ścieżką.

To rozróżnienie jest istotne: zależnie od ścieżki przełączania i sieci bezprzewodowej urządzenia w tym samym VLAN-ie mogą komunikować się bezpośrednio, bez przechodzenia przez bramę. Reguła firewalla może blokować tylko ruch, który dociera do firewalla. Jeśli ruch między AP jest lokalnie mostkowany, należy wymusić jego przejście przez kontrolowaną granicę polityki za pomocą odpowiedniej segmentacji Wi-Fi, switcha lub VLAN. Sama reguła „client-to-client deny” bez potwierdzonej ścieżki danych nie jest kryterium sukcesu.

4. Stosuj mechanizmy anti-spoofing tylko tam, gdzie pasują

Dodatkowe zabezpieczenia obejmują DHCP Snooping, IP Source Guard i walidację źródła na bramie, na przykład uRPF, jeśli switch lub brama je obsługuje. Te mechanizmy zależą od środowiska: zaufane uplinki, serwery DHCP, klienci statyczni, relay, routing asymetryczny i redundancja wpływają na bezpieczną konfigurację.

Nie włączaj ich bez analizy na wszystkich portach. Najpierw udokumentuj bindingi i prawidłowe ścieżki, a następnie przetestuj jeden mechanizm w segmencie pilotażowym. Odnowienie DHCP, urządzenia statyczne, przełączenie awaryjne bramy i ścieżka powrotna muszą nadal działać. Jeśli nie ma zweryfikowanej konfiguracji producenta dla używanego switcha lub routera, pozostaw ten punkt otwarty i skorzystaj z jego dokumentacji lub wsparcia.

5. Właściwie oceń rolę Enterprise i 802.11w

W trybach WPA2-Personal, WPA3-Personal i mieszanych współdzielony Group Temporal Key może zostać wykorzystany do GTK Abuse. Avanet zaleca dlatego WPA2/WPA3 Enterprise (802.1X) z zewnętrznym RADIUS. Poprawia to kontrolę dostępu, ale nie eliminuje wektorów opartych na GTK. Migrację przeprowadź pilotażowo według RADIUS i WPA3 Enterprise dla AP6.

802.11w jest dostępne tylko dla SSID AP6 i chroni ramki zarządzające po ustanowieniu bezpiecznego połączenia, szyfrując je i uwierzytelniając. Włącz je po sprawdzeniu zgodności klientów jako dodatkowe zabezpieczenie. Nie jest to izolacja ruchu danych ani remediacja AirSnitch i nie należy uznawać go za zaliczony test ochrony przed AirSnitch.

Zweryfikuj dwie fazy przed szerszym wdrożeniem

Pilotaż weryfikuje rzeczywistą ścieżkę danych, a nie tylko zaznaczone opcje. Stosuj kryteria akceptacji właściwe dla bieżącej fazy:

Faza 1: jeden AP pilotażowy i weryfikacja na tym samym AP

  1. Konfiguracja: Central pokazuje oczekiwane wartości Client isolation, Proxy ARP, VLAN i opcjonalnie 802.11w. Przypisany jest tylko planowany AP pilotażowy.
  2. Zatwierdzona infrastruktura: obaj klienci testowi otrzymują właściwą konfigurację IP, rozwiązują nazwy DNS i uzyskują dostęp wyłącznie do zatwierdzonej infrastruktury oraz usług zewnętrznych. Te cele sprawdź osobno od testów peer-to-peer.
  3. Ten sam AP: podłącz obu klientów do AP pilotażowego. Przy włączonym Client isolation każda bezpośrednia komunikacja między klientami musi się nie powieść, niezależnie od protokołu lub usługi; bezpośrednia usługa peer nie jest dozwolonym wyjątkiem.
  4. Działanie i discovery: sprawdź odnowienie DHCP oraz wymagane procesy drukowania, castingu i discovery. Wymagane kontrolowane discovery lub dostęp między klientami muszą przechodzić przez osobno zaprojektowaną bramę polityki lub discovery, a nie bezpośrednie przekazywanie między klientami. Przed kolejną zmianą przypisz nieoczekiwane awarie do zmienionej warstwy.

Faza 2: dokładnie jeden kontrolowany drugi AP i weryfikacja między AP

  1. Kontrolowane rozszerzenie: dopiero po pomyślnym zakończeniu fazy 1 przypisz dokładnie jeden kontrolowany drugi AP. Central musi teraz pokazywać dokładnie te dwa AP z oczekiwaną konfiguracją; nie dodawaj jeszcze pozostałych AP.
  2. Różne AP: podłącz po jednym kliencie do każdego AP w tej samej podsieci i powtórz testy blokowania ruchu między klientami. Oczekiwania dotyczące Client isolation nie zastępują tego testu między AP.
  3. Layer 3 i hairpin: użyj logów bramy lub przechwytywania pakietów, aby potwierdzić, czy każda ścieżka testowa przekracza granicę polityki i trafia we właściwą regułę deny, w tym ścieżka kierowana z powrotem do sieci klientów. Nie odtwarzaj celowo exploita w produkcyjnej sieci WLAN.
  4. Powtórzenie i dopuszczenie: połącz klientów ponownie, sprawdź co najmniej inny typ klienta, powtórz testy zatwierdzonej infrastruktury i zweryfikuj stan konfiguracji obu AP. Dopiero po zaliczeniu obu faz wdrażaj zmiany małymi etapami.

Te dwie fazy pokazują jedynie, że zdefiniowane mechanizmy i normalne ścieżki danych działają zgodnie z założeniami w tym środowisku. Nie dowodzą pełnej remediacji AirSnitch.

Przywróć dokładnie stan bazowy

Jeśli test zakończy się niepowodzeniem, zatrzymaj wdrożenie i nie zmieniaj jednocześnie SSID, VLAN-u, bramy i switcha. Najpierw usuń dodatkowe przypisania AP lub ponownie ogranicz SSID do zakresu pilotażowego. Następnie przywróć udokumentowany stan bazowy każdej zmienionej warstwy:

  1. Central: przywróć pierwotne stany Client isolation, Proxy ARP i 802.11w, tryb Client connection, VLAN, pasma oraz przypisania AP.
  2. Brama/firewall: usuń tylko nowe reguły pilotażowe albo przywróć zapisane pozycje reguł, źródła, cele, usługi, działania i wartości logowania.
  3. Ochrona switcha/bramy: wycofaj tylko pilotażowe zmiany DHCP Snooping, IP Source Guard lub uRPF, w tym wcześniejsze role zaufania i wyjątki.
  4. Weryfikacja: poczekaj na stan konfiguracji Central, a następnie ponownie sprawdź DHCP, DNS, dozwolone usługi, blokowane cele i istniejące SSID z użyciem znanych klientów.

Nie usuwaj produkcyjnego SSID, VLAN-u ani istniejącej reguły jako pierwszego kroku odzyskiwania. Jeśli stan bazowy nie jest jasny, zatrzymaj się i wyjaśnij go z administratorami sieci lub pomocą techniczną Sophos zamiast tworzyć nieznany stan przez dalsze zmiany. Ryzyko AirSnitch pozostaje po rollbacku: rollback przywraca usługę, ale nie usuwa luki.