Monitorowanie kondycji i wydajności Sophos NDR

Zielony status Sophos NDR jest ważnym wynikiem kontroli pośredniej, ale nie stanowi dowodu pełnego pokrycia ruchem lustrzanym ani prawidłowego działania całego łańcucha wykrywania. Wiarygodna ocena wymaga osobnego rozpatrzenia sześciu grup sygnałów: Sophos Fusion, Appliance Manager, wejścia SPAN, przesyłania danych, zasobów obliczeniowych i pamięci masowej oraz — jeśli jest używana — niezależnej Investigation Console.

Szybka kontrola: Najpierw sprawdź status NDR w Sophos Fusion. Następnie w Appliance Manager, na karcie NDR, sprawdź wartości dla każdego oczekiwanego portu SPAN, wartość Uploaded oraz historię przepływów. W sekcji Status sprawdź CPU, Memory, Root Disk i Data Disk. Żółty komunikat spanX: packets being dropped oznacza, że odrzucanych jest ponad 10% pakietów sieciowych przetwarzanych przez NDR. Zielony port SPAN spełnia obecnie kryterium produktu wynoszące co najmniej 2% pakietów unicast. Żadne z tych stwierdzeń samo w sobie nie dowodzi, że wszystkie zamierzone sieci są objęte ruchem lustrzanym ani że detekcja dociera do końca łańcucha.

Dopasowanie wskaźników do ich przeznaczenia

Aby otworzyć Appliance Manager w Sophos Fusion, przejdź do Threat Analysis Center > Integrations > Configured > Integration Appliances. W wierszu urządzenia wybierz menu z trzema kropkami, a następnie Open Appliance Manager. Obszar nagłówka zawiera między innymi informacje Version, K3S Helm Chart version, Uptime i System ID. Uwzględniaj je w każdym opisie incydentu, ponieważ dwa urządzenia z pozornie podobnymi objawami mogą korzystać z różnych wersji oprogramowania lub działać przez różny czas.

Status Fusion jako punkt wyjścia

Sophos Fusion rozróżnia trzy stany:

• Czerwony: Integracja NDR nie działa. Komunikat NDR containers not ready, <specific container names> wskazuje aplikacje, które nie są gotowe. Upload to s3 failed ... dotyczy przesyłania danych do chmury. spanX: unhealthy span dotyczy wejścia ruchu z urządzenia sieciowego realizującego mirroring.
• Żółty: Integracja działa, ale występują błędy. Komunikat spanX: packets being dropped jest wyświetlany, gdy odrzucanych jest ponad 10% pakietów sieciowych.
• Zielony: Integracja odbiera ruch SPAN i przetwarza dane pakietowe bez zgłoszonego błędu. Port SPAN jest obecnie klasyfikowany jako prawidłowo działający, jeśli co najmniej 2% obserwowanych pakietów stanowią pakiety unicast.

Te dwie wartości procentowe mają różne mianowniki i nie wolno ich ze sobą kompensować. Próg 2% klasyfikuje skład ruchu docierającego do sensora. Nie oznacza, że wystarczy 2% całego ruchu firmowego ani że NDR może tracić 98%. „Co najmniej 2%” obejmuje dokładnie 2%. Z kolei komunikat o odrzucaniu opisuje odsetek pakietów, które dotarły już do NDR, lecz nie mogą zostać obsłużone z powodu niewystarczających zasobów przetwarzania. Sophos dokumentuje ostrzeżenie dla wartości ponad 10%, a nie „10% lub więcej”.

Ważne: Próg ponad 10% jest kryterium statusu produktu, a nie wartością docelową ani akceptowalnym limitem strat. Nawet wartość poniżej progu zgłoszenia może oznaczać pogorszenie względem własnej wartości bazowej. Podobnie zielony port może dostarczać nieprawidłowo lub niekompletnie dublowany ruch, jeśli tylko jego obserwowany skład spełnia kryterium pakietów unicast.

Osobne sprawdzanie wejścia SPAN i przesyłania danych

W Appliance Manager karta NDR przedstawia wartość przechwytywania dla każdego skonfigurowanego portu SPAN. SPAN Port 2 pojawia się tylko wtedy, gdy skonfigurowano drugi port. Ogólny wykres Network Flows jest wyświetlany w 30-sekundowych przedziałach.

Wskaźniki te odpowiadają na trzy osobne pytania:

1. Czy ruch dociera do każdego oczekiwanego portu SPAN? Brak wartości lub jej nagła, znaczna zmiana kieruje kontrolę najpierw do przełącznika źródłowego, sesji mirroringu lub SPAN, przypisania wirtualnego interfejsu sieciowego oraz ostatnio zmienionych sieci VLAN lub grup portów.
2. Czy skład ruchu jest wiarygodny? Kolor zielony potwierdza jedynie spełnienie aktualnego kryterium pakietów unicast. Historia przepływów musi również odpowiadać typowym porom dnia, lokalizacjom i oczekiwanym szczytom ruchu.
3. Czy NDR może przetwarzać pakiety? Żółty komunikat o odrzucaniu wskazuje wąskie gardło przetwarzania. Nie jest ono tym samym co przeciążony port lustrzany ani utrata pakietów w ścieżce produkcyjnej.

Procent przesyłania danych, również widoczny na karcie NDR, reprezentuje późniejszy etap przetwarzania. Prawidłowe wejście SPAN przy malejącej wartości przesyłania nie wskazuje tej samej klasy awarii co pusty port SPAN. W przypadku komunikatu Upload to s3 failed. Request was received but an error code was returned sprawdź wychodzący dostęp urządzenia do Internetu oraz reguły zapory i serwera proxy. NDR przesyła dane do zasobnika S3 przy użyciu wstępnie podpisanego adresu URL. Jeśli po poprawieniu konfiguracji sieci lub serwera proxy błąd nadal występuje, skontaktuj się z pomocą techniczną Sophos.

W przypadku integracji z kolektorami dzienników innych firm karty w sekcji Integrations zliczają wartości Received, Filtered, Accepted i Uploaded. Te liczniki syslog nie są ani wartością przesyłania NDR, ani wartością przechwytywania SPAN. Nadal są jednak istotne, ponieważ mocno obciążona integracja z kolektorem dzienników działająca na tym samym urządzeniu wykorzystuje jego CPU i Memory.

Ocena CPU, Memory i pamięci masowej

W sekcji Status Appliance Manager pokazuje wykorzystanie CPU, Memory, Root Disk i Data Disk. Ciągłe pełne wykorzystanie poszczególnych rdzeni procesora jest oczekiwane w przypadku NDR: Data Plane Development Kit (DPDK) działa na zarezerwowanych rdzeniach w trybie odpytywania. Nieustannie sprawdza dostępność pakietów, zamiast podczas bezczynności czekać na przerwania.

Sophos podaje dwa konkretne przykłady:

• Na maszynie wirtualnej z 4 rdzeniami CPU jeden rdzeń pozostaje obciążony w 100%.
• Na maszynie wirtualnej z 8 rdzeniami CPU dwa rdzenie pozostają obciążone w 100%.

Tego rodzaju wykorzystanie poszczególnych rdzeni samo w sobie nie jest zatem dowodem przeciążenia i nie musi ustępować przy małym ruchu. Z drugiej strony stwierdzenie „DPDK działa normalnie” nie może służyć do wyjaśniania każdego przypadku wysokiego użycia CPU. Krytyczna staje się kombinacja rosnącego ruchu, pełnego wykorzystania dodatkowych rdzeni, komunikatu packets being dropped, malejącej wartości przesyłania lub historii przepływów, która zmieniła się względem wartości bazowej.

W przypadku urządzeń wirtualnych obowiązują następujące wytyczne dotyczące wydajności:

Wszystkie trzy parametry należy rozpatrywać łącznie. Środowisko może nie przekraczać limitu przepustowości, a mimo to generować wiele pakietów na sekundę, jeśli pakiety są bardzo małe. Gdy wartości przekraczają profil High, Sophos zaleca wdrożenie w sieci wielu urządzeń wirtualnych.

Wartości te dotyczą maszyny wirtualnej, na której działa wyłącznie NDR. Przy dużym obciążeniu każda dodatkowa integracja z kolektorem dzienników uruchomiona na urządzeniu wymaga około 400 MB pamięci RAM i może zużywać dodatkowe zasoby CPU. Dlatego przed zwiększeniem zasobów sprawdź również karty w sekcji Integrations. Przy stałym obciążeniu mieszanym rozdzielenie zadań między wiele urządzeń może być bardziej odpowiednie niż wielokrotne dodawanie zasobów do tej samej maszyny wirtualnej.

Dokumentacja produktu wykorzystana w tym artykule nie określa ogólnego progu ostrzegawczego dla Memory, Root Disk ani Data Disk. Traktowanie dowolnej wartości procentowej jako limitu Sophos byłoby zatem mylące. Istotne są trend, dostępny zapas i jednoczesne objawy. Jeśli wykorzystanie dysku stale rośnie, nie usuwaj ręcznie plików ani kontenerów. Najpierw udokumentuj stan i przedział czasu, a jeśli przyczyna jest niejasna, zachowaj dzienniki dla pomocy technicznej Sophos.

Ustanowienie użytecznej wartości bazowej

Pojedynczy pomiar nie pozwala odróżnić normalnego rytmu dobowego od początku przeciążenia. Dlatego po wdrożeniu i po każdej istotnej zmianie rejestruj porównywalne punkty danych:

• datę, godzinę i strefę czasową, a także oczekiwany okres obciążenia,
• kolor statusu Fusion i dokładną treść komunikatu,
• wartość przechwytywania dla każdego skonfigurowanego portu SPAN,
• procent przesyłania i kształt historii przepływów,
• wykorzystanie poszczególnych rdzeni CPU i ogólne wykorzystanie CPU, a także Memory, Root Disk i Data Disk,
• liczbę vCPU i ilość pamięci RAM przypisane do maszyny wirtualnej,
• szacowane wartości Mbit/s, pakietów/s i przepływów/s lub wartości zmierzone w systemie źródłowym,
• działające równocześnie integracje innych firm i ich aktywność,
• zmiany w przełączniku, hiperwizorze, serwerze proxy, zaporze lub urządzeniu.

Przydatne są pomiary wykonane w okresie niewielkiego ruchu, przy normalnym obciążeniu biznesowym oraz podczas znanego szczytu. Celem nie jest uniwersalna wartość docelowa, lecz porównanie tego samego urządzenia w podobnych warunkach. Dzięki temu nagły spadek wartości na porcie SPAN będzie widoczny, nawet jeśli Fusion nadal pokazuje kolor zielony. Po zmianie zasobów ustanów nową wartość bazową dopiero po ustabilizowaniu stanu.

Rozwiązywanie problemów w bezpiecznej kolejności

1. Zarejestruj zakres problemu: Udokumentuj urządzenie i port SPAN, których dotyczy problem, czas rozpoczęcia, dokładną treść komunikatu Fusion oraz ostatnią zmianę. Przed ponownym uruchomieniem zachowaj zrzuty ekranu lub wyniki pomiarów.
2. Sprawdź wejście: W przypadku komunikatu unhealthy span, braku przepływów lub odchylenia od wartości bazowej portu najpierw sprawdź źródło ruchu lustrzanego, port docelowy lub wirtualny interfejs sieciowy oraz oczekiwane sieci. Dodatkowe zasoby CPU nie naprawią nieprawidłowo skonfigurowanego źródła SPAN.
3. Sprawdź przesyłanie: W przypadku błędu przesyłania do S3 sprawdź wychodzący dostęp do Internetu, zaporę i serwer proxy. Z kolei pomyślne przesyłanie nie naprawi brakującego pokrycia ruchem lustrzanym.
4. Sprawdź wydajność: Gdy odrzucanych jest ponad 10% pakietów, porównaj profil ruchu, inne w pełni wykorzystane rdzenie, przydział vCPU i integracje działające na tym samym urządzeniu. W przypadku maszyny wirtualnej przydziel dodatkowe vCPU; udokumentowany profil High przewiduje 8 vCPU. W przypadku certyfikowanego sprzętu można wdrożyć kolejne urządzenie i rozdzielić między nie ruch SPAN. Przed rozdzieleniem ruchu konieczny jest zatwierdzony plan pokrycia: musi on jednoznacznie przypisywać każdą zamierzoną sieć, sieć VLAN i źródło ruchu lustrzanego do urządzenia docelowego oraz zapobiegać zarówno lukom, jak i niezamierzonym zduplikowanym strumieniom. Przy obciążeniach mieszanych można rozdzielić NDR i kolektory dzienników między osobne urządzenia.
5. Określ zakres ponownego uruchomienia: Jeśli po usunięciu przyczyny NDR nadal nie działa prawidłowo, można rozważyć ukierunkowane ponowne uruchomienie NDR zgodnie z właściwą instrukcją obsługi lub rozwiązywania problemów. Podczas ponownego uruchamiania normalne przetwarzanie NDR nie jest realizowane; ponowne uruchomienie nie zastępuje korekty wydajności. Ponowne uruchomienie lub wyłączenie całej maszyny wirtualnej ma większy zakres oddziaływania i nie powinno być pierwszym krokiem rozwiązywania problemu.

Jeśli zmieniasz liczbę vCPU lub rozkład ruchu, wykonaj to w zatwierdzonym oknie serwisowym i zgodnie z wymaganiami używanej platformy wirtualizacyjnej. Wprowadzaj po jednej zmianie, aby jej efekt pozostał mierzalny. Po rozdzieleniu ruchu sprawdź plan pokrycia względem każdego powstałego portu SPAN; zweryfikuj również zatwierdzoną ścieżkę testu kompleksowego.

Nie myl Investigation Console z urządzeniem NDR

Investigation Console jest osobnym komponentem. Jej stan nie potwierdza ani stanu integracji NDR, ani kompletności źródeł SPAN, ani pomyślnego dostarczenia danych. Dlatego zakres tego artykułu ogranicza się do wyjaśnienia następującej granicy: SPAN, przesyłanie NDR, DPDK i odrzucanie pakietów sprawdza się w integracji NDR oraz w Appliance Manager; sprawdzanie Investigation Console i rozwiązywanie związanych z nią problemów należy do zakresu właściwej dokumentacji operacyjnej konsoli.

Weryfikacja po każdym działaniu

Powtórz kontrole przy obciążeniu porównywalnym z obciążeniem podczas pomiaru początkowego. Korektę można uznać za skuteczną dopiero wtedy, gdy:

• Fusion pokazuje oczekiwany stan bez wcześniejszego czerwonego lub żółtego komunikatu,
• każdy oczekiwany port SPAN jest widoczny i ponownie odpowiada własnej historii bazowej,
• kryterium pakietów unicast nie zostało błędnie użyte jako dowód pokrycia,
• komunikat dotyczący odrzucania ponad 10% pakietów nie pojawia się ponownie,
• przesyłanie i Network Flows pozostają stabilne przez miarodajny okres obserwacji,
• CPU poza oczekiwanymi rdzeniami DPDK, Memory, Root Disk i Data Disk wykazują wystarczający zapas,
• integracje innych firm działające na tym samym urządzeniu nadal przetwarzają oczekiwane dane,
• po rozdzieleniu ruchu każda zamierzona sieć, sieć VLAN i każde źródło ruchu lustrzanego trafiają dokładnie do właściwego urządzenia zgodnie z zatwierdzonym planem pokrycia, a zatwierdzona ścieżka testu kompleksowego działa.

Kontrole te weryfikują stan operacyjny, lecz nie potwierdzają jeszcze pełnego łańcucha wykrywania. Kompleksowe potwierdzenie wymaga dodatkowo zatwierdzonego testu NDR oraz weryfikacji powstałej detekcji.

Kiedy skontaktować się z pomocą techniczną Sophos

Skontaktuj się z pomocą techniczną Sophos, jeśli kontenery nie osiągają stanu gotowości, błąd przesyłania do S3 utrzymuje się mimo potwierdzonej ścieżki internetowej i proxy, port SPAN pozostaje w stanie unhealthy mimo poprawienia konfiguracji źródła, odrzucanie pakietów powraca po odpowiednim zwiększeniu zasobów albo wskaźniki zasobów i komunikaty o stanie są ze sobą sprzeczne.

Przygotuj do eskalacji co najmniej następujące dane:

• nazwę urządzenia, System ID, Version, K3S Helm Chart version i Uptime,
• dokładną treść komunikatu o stanie i błędu, wraz z czasem rozpoczęcia i strefą czasową,
• port SPAN, którego dotyczy problem, wartości przechwytywania i przesyłania oraz historię przepływów,
• wykorzystanie poszczególnych rdzeni CPU, Memory, Root Disk i Data Disk przed działaniem i po nim,
• przydział zasobów maszyny wirtualnej, obserwowany profil ruchu oraz integracje działające na tym samym urządzeniu,
• ostatnie zmiany przełącznika, hiperwizora, zapory lub serwera proxy,
• wykonane działania i ich mierzalne wyniki,
• w przypadku problemów z oddzielną Investigation Console — materiały wymagane przez właściwą dokumentację operacyjną konsoli.

Hasła, klucze prywatne ani inne dane uwierzytelniające nie powinny znaleźć się w zgłoszeniu. Nie uruchamiaj niskopoziomowych poleceń Kubernetes ani nie modyfikuj ręcznie kontenerów na podstawie podejrzeń; w przypadku komunikatu NDR containers not ready zbierz dostępne obserwacje i skoordynuj dalsze działania z pomocą techniczną Sophos.