Przejdz do tresci
Avanet

Planowanie i weryfikacja mirroringu ruchu dla Sophos NDR

Sophos NDR

Traffic Mirroring dostarcza do Sophos NDR kopię ruchu sieciowego. W sieciach lokalnych lub zwirtualizowanych zwykle służy do tego SPAN; ruch ze źródeł zdalnych jest enkapsulowany za pomocą ERSPAN przez GRE lub VXLAN; natomiast w AWS używa się opcji VPC > Traffic mirror sessions. Celem nie jest bezkrytyczne tworzenie kopii lustrzanej z jak największej liczby portów. NDR potrzebuje właściwych relacji ruchu, bez pętli, zbędnych duplikatów ani przeciążenia ścieżki docelowej.

Bezpieczny proces wygląda następująco:

  1. określ relacje ruchu i granice, które mają być monitorowane,
  2. wybierz dokładnie jeden odpowiedni punkt obserwacji dla każdej relacji,
  3. sprawdź przepustowość całej ścieżki od źródła do sensora NDR,
  4. najpierw utwórz kopię lustrzaną małego źródła pilotażowego,
  5. etapami zweryfikuj cały łańcuch od źródła po przetwarzanie,
  6. rozszerzaj źródła wyłącznie w sposób kontrolowany i ponawiaj pomiary po każdej zmianie.

Przed aktywacją należy zatwierdzić i udokumentować źródło, kierunek, filtr, miejsce docelowe, okno serwisowe, dozwolony zakres danych oraz osobę odpowiedzialną za wycofanie zmian. Dane przesyłane w kopii lustrzanej mogą zawierać ładunki pakietów i inne informacje wrażliwe. Nie wolno więc zapobiegawczo ani „na wszelki wypadek” szeroko kopiować ruchu z nieprzewidzianych segmentów użytkowników, administracji, tożsamości ani innych segmentów wrażliwych. Źródło pilotażowe należy ograniczyć do zatwierdzonego zakresu operacyjnego i zakresu wynikającego z ochrony prywatności.

Wybór źródeł i punktów obserwacji

Przed rozpoczęciem konfiguracji warto przygotować krótką macierz pokrycia. Zamiast wymieniać w niej wszystkie porty przełącznika, należy uwzględnić istotne ścieżki komunikacji, na przykład:

  • od klientów do Internetu i usług zewnętrznych,
  • od klientów do serwerów wewnętrznych,
  • między serwerami, szczególnie przez granice segmentów lub stref bezpieczeństwa,
  • między centrum danych a oddziałami lub sieciami chmurowymi,
  • ruch wschód–zachód między maszynami wirtualnymi, który nie przechodzi przez fizyczne łącze nadrzędne.

Dla każdej ścieżki wybierz punkt, w którym widoczne są oba kierunki ruchu. Zwykle będzie to łącze trunk, sieć VLAN lub port w pobliżu granicy segmentu. Łącze z Internetem zapewnia dobrą widoczność ruchu północ–południe, ale nie pokazuje ruchu lokalnego w tej samej sieci VLAN. Z kolei fizyczny przełącznik nie widzi ruchu pozostającego w obrębie tego samego vSwitcha. Takich luk nie da się wywnioskować z zielonego statusu sensora — trzeba je zidentyfikować na podstawie topologii i macierzy testów.

Źródło i kierunek

W zależności od platformy źródłem SPAN może być port, grupa portów lub sieć VLAN. Jeśli to możliwe, wybierz both, czyli kopiowanie ruchu przychodzącego i wychodzącego. Kopiowanie tylko jednego kierunku może ukryć odpowiedzi, błędy i części sesji.

Łącze trunk lub cała sieć VLAN upraszcza zapewnienie pokrycia, ale zwiększa ilość danych i prawdopodobieństwo duplikatów. Poszczególne porty dostępowe pozwalają precyzyjniej wybrać ruch, lecz łatwiej je przeoczyć podczas przenoszenia systemów lub przy dynamicznych obciążeniach. Wybór powinien zatem wynikać z relacji ruchu, a nie z liczby dostępnych źródeł.

Miejsce docelowe

Miejscem docelowym kopii lustrzanej jest wyłącznie ścieżka przechwytywania sensora NDR:

  • w przypadku maszyny wirtualnej — grupa portów lub vSwitch, do którego podłączono SPAN1 albo SPAN2,
  • w przypadku połączenia fizycznego — dedykowany port przełącznika połączony z interfejsem SPAN,
  • w przypadku ERSPAN — skonfigurowany adres docelowy GRE lub VXLAN sensora,
  • w AWS — NDR SPAN Target utworzony przez stos CloudFormation.

Interfejs zarządzający nie należy do tego łańcucha jako miejsce docelowe SPAN. Port docelowy nie może być również używany jako zwykłe źródło ani wysyłać ruchu produkcyjnego z powrotem do sieci.

Unikanie pętli i zduplikowanych pakietów

Port Mirroring kopiuje pakiety i nie może kierować ich z powrotem do produkcyjnej ścieżki przekazywania. Pętla może powstać na przykład wtedy, gdy miejsce docelowe SPAN zostanie ponownie objęte mirroringiem lub użyte jako zwykłe łącze nadrzędne. Częściej występują duplikaty danych: ten sam pakiet jest przechwytywany na porcie dostępowym i łączu nadrzędnym, po obu stronach granicy segmentu albo jednocześnie przez lokalny SPAN i ERSPAN.

Przed aktywacją sprawdź następujące kwestie:

  • Interfejs docelowy pełni wyłącznie rolę miejsca docelowego i nigdy nie jest źródłem tej samej ani pokrywającej się sesji.
  • Jeśli to możliwe, ścieżka ruchu od początku do końca jest kopiowana dokładnie na jednej istotnej granicy.
  • Dwa porty SPAN nie odbierają ruchu z pokrywających się źródeł, chyba że pokrywanie zostało udokumentowane i celowo zaplanowane na potrzeby ograniczonego czasowo testu.
  • Ruch rozgłoszeniowy i multicast nie jest zbierany w wielu punktach tej samej domeny warstwy 2.
  • W przypadku klastra lub vMotion ustalono, który host i które łącze nadrzędne odbierają fizyczną kopię ruchu. Maszyna wirtualna NDR używająca standardowego SPAN z fizycznego przełącznika musi pozostać na hoście ESXi odbierającym ten ruch.
  • W AWS dla każdego interfejsu ENI i zamierzonego zakresu ruchu istnieje tylko niezbędna sesja. Sprawdzono również kolejność sesji i filtry.

Duplikaty zużywają zasoby przechwytywania, tunelu i CPU, nie poprawiając pokrycia operacyjnego. Podejrzana jest sytuacja, gdy po dodaniu źródła liczba pakietów lub bajtów niemal się podwaja, mimo że ruch produkcyjny się nie zmienił. W takim przypadku wyłącz ostatnio dodane źródło i sprawdź topologię pod kątem pokrywania się ruchu.

Konfiguracja SPAN lokalnie lub w hiperwizorze

Dokładna składnia zależy od przełącznika i hiperwizora. Niezależnie od platformy model pozostaje taki sam: wybierz źródło i kierunek, określ dedykowane miejsce docelowe oraz upewnij się, że wirtualna grupa portów przechwytywania zezwala na odbiór w trybie promiscuous.

W przypadku sesji na przełączniku Sophos niewielka konfiguracja pilotażowa może na przykład kopiować ruch z portów od 1 do 4 w obu kierunkach na port 8:

configure terminal
monitor session 1 destination interface gigabitethernet 0/8 allow-ingress
monitor session 1 source interface gigabitethernet 0/1 both
monitor session 1 source interface gigabitethernet 0/2 both
monitor session 1 source interface gigabitethernet 0/3 both
monitor session 1 source interface gigabitethernet 0/4 both
save
end
show monitor session 1

Numery interfejsów są przykładami i muszą odpowiadać rzeczywistemu okablowaniu. Przed zapisaniem konfiguracji sprawdź, czy port 0/8 prowadzi wyłącznie do ścieżki przechwytywania NDR. W przypadku urządzeń innych producentów używaj udokumentowanych przez nich poleceń SPAN; podobne nazwy nie oznaczają automatycznie identycznego działania.

W przypadku standardowego vSwitcha ESXi ustaw dla grupy portów przechwytywania wartość VLAN ID 4095, a dla opcji Promiscuous mode w sekcji Security wybierz Accept. Ruch kopiowany fizycznie wymaga ponadto dedykowanego łącza nadrzędnego między przełącznikiem a odpowiednim vSwitchem. Wewnętrzny ruch maszyn wirtualnych może wymagać osobnego wirtualnego źródła kopii lustrzanej. W środowisku Hyper-V interfejs przechwytywania NDR musi być podłączony do właściwego vSwitcha jako miejsce docelowe mirroringu portów; konfigurację platformy zweryfikuj niezależnie od ustawień sensora NDR.

Sophos NDR domyślnie włącza SPAN Port 1, natomiast SPAN Port 2 jest domyślnie wyłączony. Drugi port SPAN jest przydatny tylko wtedy, gdy odbiera ruch z osobnego źródła bez zbędnego pokrywania się. Korzystanie z SPAN Port 2 wymaga maszyny wirtualnej z co najmniej 8 vCPU.

Używanie ERSPAN z GRE lub VXLAN

ERSPAN przesyła kopie ruchu ze zdalnych źródeł do sensora przez sieć IP. Ścieżka transportowa staje się więc elementem analizy przepustowości i usterek: MTU, routing, listy ACL oraz ewentualna fragmentacja mogą wpływać na przechwytywanie, nawet jeśli sesja źródłowa jest skonfigurowana prawidłowo.

Skonfiguruj odpowiedni interfejs przechwytywania w sekcji Settings programu Sophos Appliance Manager:

VXLAN

  1. Włącz opcję Enable ERSPAN obok właściwego portu SPAN.
  2. W sekcji Tunnel Protocol wybierz vxlan.
  3. W polu IP Address wprowadź adres interfejsu VTEP.
  4. Ustaw VXLAN ID i VXLAN Port dokładnie tak, jak skonfigurowano je w źródle enkapsulującym ruch.
  5. Wybierz Save.

GRE

  1. Włącz opcję Enable ERSPAN obok właściwego portu SPAN.
  2. W sekcji Tunnel Protocol wybierz gre.
  3. W polu IP Address wprowadź adres interfejsu docelowego GRE.
  4. Wprowadź GRE Port zgodny z konfiguracją źródła.
  5. Wybierz Save.

Zmiany ustawień SPAN zaczynają obowiązywać dopiero po ponownym uruchomieniu maszyny wirtualnej. Przed restartem sprawdź, czy to samo urządzenie obsługuje inne integracje — zbieranie ich danych również zostanie przerwane. Po ponownym uruchomieniu jeszcze raz zweryfikuj parametry tunelu i przetwarzanie.

Jednoczesne używanie SPAN i VXLAN na tym samym urządzeniu jest często spotykanym rozwiązaniem. VXLAN i GRE należy używać równocześnie na jednym urządzeniu tylko wtedy, gdy źródła, przepustowość oraz domeny awarii są wyraźnie rozdzielone i udokumentowane.

Mirroring ruchu w AWS

W AWS architektura opiera się na tym samym modelu: źródłem kopii lustrzanej (Mirror Source) jest interfejs ENI zatwierdzonego obciążenia, a nie interfejs zarządzający ENI sensora NDR; miejsce docelowe (Mirror Target) i filtr muszą należeć do wdrożonego projektu NDR. Ogranicz filtr do zamierzonego zakresu danych. Samo wdrożenie AWS oraz tworzenie sesji Traffic Mirror Session opisano w artykule „Wdrażanie Sophos NDR w AWS”, dlatego nie są tutaj powtarzane.

Do odbioru rozwiązania użyj opisanego poniżej łańcucha dowodów. Samo istnienie sesji AWS nie dowodzi ani przepływu pakietów do miejsca docelowego, ani ich przetworzenia, wysłania czy wykrycia.

Ograniczenie obciążenia przed odbiorem

SPAN Port 2 nie zwiększa wydajności: do jego włączenia maszyna wirtualna potrzebuje co najmniej 8 vCPU, ale drugie wejście dostarcza dodatkowy ruch, a tym samym zwiększa zapotrzebowanie na moc obliczeniową. Używaj go tylko z osobnym, niepokrywającym się źródłem. Jeśli po aktywacji wzrośnie natężenie ruchu lub utrata pakietów, sprawdź, czy SPAN2 nie spowodował dodatkowego lub zduplikowanego obciążenia.

Artykuł „Monitorowanie kondycji i wydajności Sophos NDR” wyjaśnia, jak interpretować status oraz sygnały ruchu unicast i odrzucania pakietów, a także oceniać wydajność. Procedury rozwiązywania problemów na podstawie objawów opisano w artykule „Diagnostyka NDR Integration Appliance i sensora”. W zależności od platformy zwiększenie wydajności może wymagać dodania zasobów CPU maszyny wirtualnej lub rozdzielenia niepokrywających się źródeł między kolejną appliance; inne integracje intensywnie korzystające z CPU trzeba zaplanować oddzielnie. Samo dodanie SPAN2 nie zwiększa wydajności przetwarzania.

Weryfikacja: od źródła do detekcji

Przeprowadź weryfikację przy użyciu znanego hosta pilotażowego i określonego okna czasowego. Pozwala to przypisać błąd do konkretnego etapu zamiast jednocześnie zmieniać konfigurację przełącznika, tunelu, sensora i Sophos Fusion.

1. Konfiguracja i topologia

  • Porównaj źródło, kierunek i miejsce docelowe z macierzą pokrycia.
  • Sprawdź status sesji SPAN lub AWS podawany przez producenta.
  • Upewnij się, że miejsce docelowe nie jest jednocześnie źródłem.
  • W przypadku ERSPAN zweryfikuj adres docelowy, parametry GRE lub VXLAN oraz ścieżkę sieciową.
  • W przypadku platform wirtualnych sprawdź przypisanie interfejsu NIC przechwytywania, grupy portów lub vSwitcha.

2. Pakiety w miejscu docelowym

Użyj kontrolowanego ruchu testowego unicast z hosta pilotażowego, aby sprawdzić, czy pakiety docierają do zamierzonego miejsca przechwytywania. Jako dowód zapisz okno czasowe, interfejs docelowy, oczekiwane adresy źródłowy i docelowy oraz — tam, gdzie ma to zastosowanie — oba kierunki. Ten etap potwierdza dotarcie testowanych pakietów do zamierzonego miejsca docelowego, ale jeszcze nie ich przetworzenie ani wysłanie. Sam ruch rozgłoszeniowy nie jest miarodajnym testem. Jeśli pakietów brakuje, początkowo ogranicz analizę do źródła, filtra, kierunku, transportu i wirtualnej grupy portów.

3. Przechwytywanie i przepływ na właściwym porcie SPAN

W sekcji Sophos Appliance Manager > NDR zapisz wyświetlany procent przechwytywania dla konkretnego, zamierzonego portu SPAN oraz aktywność na wykresie Total Flow w 30-sekundowym oknie. Obie wartości muszą być czasowo zgodne z ruchem pilotażowym. Potwierdza to aktywność na wybranym wejściu, ale wskazania nie dowodzą pełnego przechwycenia pakietów, prawidłowego zakresu danych, obecności obu kierunków ani pomyślnego wysłania.

Obecna klasyfikacja Sophos uznaje port SPAN za prawidłowy, gdy co najmniej 2 procent pakietów sieciowych stanowi ruch unicast. Wartość ta jest wyłącznie minimalnym kryterium kondycji — jedynie wyklucza zerowy udział ruchu unicast w obserwowanej próbce. Nieprawidłowy, częściowy, zduplikowany, nieaktualny lub nieodpowiedni strumień danych także może spełnić próg 2 procent. Wartość ta nie potwierdza zatem oczekiwanego źródła i kierunku, użyteczności ruchu, pokrycia, wyświetlanego poziomu przechwytywania, wysyłania ani detekcji. Starsze odniesienia do 100 procent ruchu unicast nie są używane jako bieżące wymaganie.

4. Przetwarzanie i wysyłanie

W sekcji Sophos Appliance Manager > NDR zapisz wyświetlany procent wysyłania dla tego samego okna czasowego i porównaj jego czas z aktywnością przechwytywania oraz przepływu. Dokumentuje to aktywność wysyłania, lecz nie dowodzi, że wysłano każdy skopiowany pakiet ani że później zostanie utworzona detekcja. Status Connected potwierdza przede wszystkim połączenie urządzenia i nie zastępuje tego dowodu. Jeśli sygnały kondycji, przechwytywania, wysyłania i odrzucania pakietów są rozbieżne, wykonaj systematyczną diagnostykę urządzenia i sensora.

5. Pokrycie operacyjne

Dla każdego wiersza macierzy pokrycia wygeneruj ukierunkowany, dozwolony ruch testowy oraz zapisz czas, urządzenie testowe, oczekiwany segment, źródło, miejsce docelowe i kierunek. Powiąż z tym testem dowody z etapów od 2 do 4. Tylko takie próbki pokazują, że testowane ścieżki są co do zasady przechwytywane; nie stanowią dowodu dla niesprawdzonych segmentów ani okien czasowych.

6. Nieszkodliwa detekcja od początku do końca

Dopiero po pomyślnym odbiorze kopii lustrzanej wykonaj osobną, zatwierdzoną procedurę „Generowanie i weryfikacja bezpiecznej detekcji testowej Sophos NDR”. Ten artykuł nie przewiduje generowania testu. Zweryfikuj wynik dla oczekiwanego urządzenia testowego i okna czasowego w sekcji Threat Analysis Center > Detections, a następnie powiąż go z poprzednim łańcuchem dowodów. Zaobserwowana tam detekcja testowa potwierdza przetestowaną ścieżkę od początku do końca; nie gwarantuje wykrycia każdej techniki ataku ani pokrycia innych ścieżek.

Stopniowe zawężanie przyczyn rozbieżności

Jeśli odbiór się nie powiedzie, badaj wyłącznie pierwszy etap, dla którego brakuje oczekiwanego dowodu: najpierw rzeczywistą ścieżkę źródłową, kierunek i filtr; następnie okablowanie miejsca docelowego lub przypisanie wirtualnego interfejsu przechwytywania; w przypadku ERSPAN później transport i zgodność parametrów tunelu; następnie przechwytywanie i przepływ na właściwym porcie; na końcu wysyłanie i detekcję. Zielony status ani co najmniej 2 procent ruchu unicast nie pozwalają pominąć żadnego z tych etapów. Wprowadzaj tylko jedną zmianę naraz i ponawiaj pomiar z użyciem tego samego źródła pilotażowego oraz okna czasowego.

Jeśli brakuje tylko jednego kierunku lub segmentu, porównaj macierz pokrycia z rzeczywistą ścieżką fizyczną albo wirtualną, bez pochopnego dodawania kolejnych segmentów wrażliwych lub wszystkich portów. Jeśli natężenie ruchu jest nietypowo wysokie, sprawdź każde udokumentowane nakładanie się źródeł względem liczników i widoczności ruchu pilotażowego. Proces ten kończy się odbiorem kopii lustrzanej i lokalizacją usterki; w przypadku błędów sensora, wysyłania lub platformy kontynuuj diagnostykę urządzenia i sensora.

Bezpieczne wycofywanie zmian wprowadzonych w tej procedurze

Przed każdym rozszerzeniem zapisz identyfikator sesji, źródła, kierunki, filtry, miejsce docelowe, parametry tunelu i wartości bazowe natężenia ruchu. Poniższa procedura wycofania obejmuje wyłącznie nowe zmiany konfiguracji kopii lustrzanej wprowadzone w ramach tej procedury; nie jest instrukcją demontażu urządzenia, stosu chmurowego ani innej infrastruktury.

W razie problemów wycofaj zmiany w odwrotnej kolejności:

  1. usuń ostatnio dodane źródło lokalne; usuń sesję AWS Traffic Mirror Session utworzoną na potrzeby tej procedury,
  2. przywróć ostatnio rozszerzony filtr do udokumentowanego zakresu pilotażowego,
  3. wyłącz nowo włączony ERSPAN lub przywróć poprzednie parametry tunelu,
  4. wyłącz SPAN Port 2, jeśli spowodował nowe obciążenie lub nakładanie się źródeł,
  5. przywróć poprzednią sesję przełącznika, jeśli zmieniono fizyczną kopię lustrzaną,
  6. ponownie sprawdź przepływ pakietów, współczynnik odrzucania, status integracji i ruch pilotażowy.

Wycofanie ustawień SPAN w Sophos również wymaga wybrania Save i ponownego uruchomienia maszyny wirtualnej, zanim zmiana zacznie obowiązywać. Trzeba także uwzględnić wpływ na inne integracje działające na tym samym urządzeniu. Wycofanie jest zakończone dopiero wtedy, gdy nie tylko status ponownie jest zielony, lecz także wcześniej udokumentowane ścieżki pilotażowe są widoczne bez nowych duplikatów i problematycznej utraty pakietów.