Diagnostyka urządzenia Sophos NDR Integration Appliance i sensora

Ten podręcznik pomaga zawęzić usterki urządzenia NDR Integration Appliance i sensora NDR. Punktem wyjścia jest dokładny stan w Sophos Fusion; dalej opisano interpretację widocznych stanów i wskaźników oraz sytuacje, w których należy zebrać logi dla Sophos Support.

Stan Connected lub kolor zielony jest tylko kontrolą pośrednią. Nie dowodzi ani pełnego zakresu ruchu lustrzanego, ani pomyślnego przesłania każdego zestawu danych, ani sprawnego wykrywania od początku do końca.

Szybka procedura

1. Zapisać nazwę urządzenia, System ID, czas rozpoczęcia błędu wraz ze strefą czasową i dokładną treść komunikatu.
2. W Sophos Fusion sprawdzić kolor i stan urządzenia, ale jeszcze niczego nie restartować.
3. W Appliance Manager przejrzeć Status, NDR, Integrations i Advanced oraz wykonać zrzuty ekranu ze znacznikiem czasu.
4. Przypisać objaw do klasy usterki: platforma/CPU, ruch wychodzący/przesyłanie, SPAN, rejestracja albo współdzielone zasoby.
5. Wykonać tylko jedną odwracalną korektę należącą do tej klasy usterki.
6. Ponownie sprawdzić te same punkty pomiarowe przy porównywalnym obciążeniu.
7. Jeśli sygnały są sprzeczne, kontenery nie są gotowe albo działanie nie przynosi efektu, zebrać logi i eskalować problem.

Objaw, kontrola i następne działanie

Prawidłowa interpretacja koloru czerwonego, żółtego i zielonego

Czerwony: integracja nie działa

Przy stanie czerwonym konkretny komunikat jest ważniejszy od koloru:

• NDR containers not ready, <specific container names>. oznacza, że co najmniej jedna wymagana aplikacja nie jest gotowa. Jeśli wymieniono dragonfly albo jego widoczny stan jest nietypowy, analizę należy rozpocząć od zgodności CPU i wymagań platformy.
• Upload to s3 failed. Request was received but an error code was returned. Error code: <S3 upload error> oznacza, że urządzenie próbowało przesłać dane do zasobnika S3 przy użyciu wstępnie podpisanego adresu URL i otrzymało kod błędu. Jest to przede wszystkim klasa błędów ruchu wychodzącego/proxy.
• spanX: unhealthy span przypisuje usterkę do wejścia wskazanego portu SPAN. Najpierw należy sprawdzić wysyłający komponent sieciowy lub wirtualną ścieżkę mirroringu.

Żółty: integracja działa z błędami

Komunikat spanX: packets being dropped pojawia się, gdy odrzucanych jest ponad 10% pakietów sieciowych. Przechwytywanie i przetwarzanie pakietów mocno obciąża CPU. Maszyna wirtualna może wymagać dodatkowych vCPU; na certyfikowanym sprzęcie obciążenie można rozdzielić na kolejne urządzenie zgodnie z zatwierdzonym planem zakresu. Uruchomione na tym samym urządzeniu moduły Log Collector mogą dodatkowo obciążać te same zasoby.

Sama zmiana pojemności nie naprawi jednak nakładających się źródeł mirroringu, przeciążonej ścieżki docelowej ani błędnej konfiguracji SPAN. Przed skalowaniem należy więc porównać profil ruchu i topologię.

Zielony: brak aktualnie zgłaszanego błędu integracji

Kolor zielony oznacza, że NDR odbiera ruch SPAN i przetwarza pakiety bez zgłaszanego problemu. Bieżący klasyfikator kondycji wymaga dla zdrowego portu SPAN co najmniej 2% pakietów unicast. Nie dowodzi to, że przechwytywane są wszystkie wymagane sieci VLAN, lokalizacje, kierunki lub przedziały czasu. Nie należy stosować wcześniejszego twierdzenia, że port musi wykazywać 100% ruchu unicast.

Szczegółową interpretację sygnałów kondycji i pojemności zawiera artykuł „Monitorowanie kondycji i pojemności Sophos NDR”.

Jeśli mimo zielonego stanu nadal brakuje oczekiwanych detekcji, należy najpierw wykonać bezpieczną testową detekcję NDR. Jeśli również ten test nie przyniesie dowodu, a podejrzewany jest problem z VLAN, należy zabezpieczyć dla Sophos Support przedział czasu, port SPAN, wybraną sieć VLAN i widoczny stan urządzenia. Ustawienie VLAN Strip wolno zmienić dopiero wtedy, gdy analiza potwierdzi, że do sensora docierają zarówno wybrana sieć VLAN, jak i VLAN0; w przeciwnym razie ustawienie należy pozostawić bez zmian.

Zawężanie lokalnych zdarzeń za pomocą NDR Query

Gdy trzeba oddzielnie sprawdzić przechwytywanie i przesyłanie, NDR Query w Appliance Manager może pokazać lokalną warstwę zdarzeń. Zapytanie jest wykonywane w bazie zdarzeń NDR na tej maszynie wirtualnej urządzenia, a nie w Sophos Data Lake. Należy je wyraźnie odróżnić od wdrażanej oddzielnie Investigation Console, która udostępnia w sieci lokalnej dane przypisanego urządzenia NDR Appliance na potrzeby Threat Hunting.

1. Zapisz urządzenie, którego dotyczy problem, oraz przedział czasu występowania błędu.
2. Otwórz NDR Query, a na stronie Query wybierz Example queries.
3. Skopiuj odpowiednie predefiniowane zapytanie za pomocą Copy, wklej je w polu tekstowym i uruchom przyciskiem Go.
4. Zapisz wynik z sekcji Query Results wraz ze znacznikiem czasu; w razie potrzeby uporządkuj kolumny metodą przeciągania i upuszczania.
5. Porównaj wynik z aktywnością w sekcji NDR i stanem Fusion w tym samym przedziale czasu.

Appliance Manager obsługuje tutaj obecnie wyłącznie predefiniowane zapytania. Nie używaj własnego zapytania SQL ani zapytania z Investigation Console. Lokalny wynik przy braku danych w Fusion kieruje dalszą diagnostykę na przesyłanie i ruch wychodzący. Pusty wynik lokalny kieruje ją najpierw na wejście SPAN, przedział czasu i wybór predefiniowanego zapytania; sam w sobie nie dowodzi jeszcze usterki.

Analiza nieoczekiwanych detekcji Nmap

Jeśli w innych produktach zabezpieczających pojawią się nowe skanowania systemu operacyjnego oparte na Nmap, sprawdź stan OS Detection w sekcji Global NDR Settings. Ta domyślnie wyłączona opcja po włączeniu skanuje co dwie godziny każdy wewnętrzny adres IP zauważony przez NDR. Może to powodować detekcje w innych produktach zabezpieczających.

Porównaj czas aktywacji, urządzenie, adresy IP systemów docelowych i znaczniki czasu detekcji. Jeśli aktywacja nie została zatwierdzona, systemy docelowe są niedozwolone albo występują skutki operacyjne, ponownie wyłącz OS Detection i udokumentuj czas. Następnie monitoruj, czy nie pojawiają się nowe zdarzenia skanowania wywołane przez tę funkcję; już istniejące alerty obsłuż zgodnie z procesem właściwym dla danego narzędzia. Nie powtarzaj ręcznie poleceń Nmap ani nie twórz wyjątków w innych produktach zabezpieczających tylko po to, aby ukryć objaw. Jeśli funkcja ma pozostać włączona, wymaga to udokumentowanej zgody osób odpowiedzialnych za sieć i bezpieczeństwo oraz walidacji przez co najmniej jeden pełny dwugodzinny interwał.

Zawężanie objawów kontenerów i Dragonfly bez CLI

Dragonfly przetwarza dane NDR. W diagnostyce istotne są dwa widoczne wzorce:

• Czerwony komunikat o niegotowych kontenerach może się pojawić, gdy dragonfly utknie w pętli restartów z powodu braku wymaganych instrukcji CPU.
• Jeśli urządzenie ma w Fusion stan Connected, ale dane nie docierają do Data Lake, a Dragonfly ma w Advanced stan Pending, w klastrze VMware EVC trzeba sprawdzić tryb EVC. Sophos wymaga Skylake generation or later; tryb Sandy Bridge nie jest obsługiwany.

Dla maszyn wirtualnych NDR w VMware ESXi lub Hyper-V muszą być dostępne flagi CPU pdpe1gb i avx2. Flaga pdpe1gb jest wymagana do przechwytywania pakietów, a avx2 do funkcji uczenia maszynowego. Większa liczba vCPU nie rekompensuje braku flag. W Hyper-V tryb Processor Compatibility Mode nie jest obsługiwany. W przypadku ESXi obowiązuje ponadto VM Hardware Version 11 lub nowsza oraz udokumentowane wymagania platformy.

Bezpieczna kontrola:

1. W Advanced udokumentować stan i widoczną nazwę kontenera, którego dotyczy problem.
2. W Status zapisać użycie CPU, pamięci, dysku głównego i dysku danych.
3. Porównać hiperwizor, model CPU, ustawienie EVC lub zgodności i flagi udostępniane maszynie wirtualnej z zatwierdzoną dokumentacją platformy.
4. Błędne ustawienie hiperwizora/CPU poprawiać wyłącznie w planowanym oknie serwisowym; wcześniej zapisać wartość początkową i drogę powrotu.
5. Następnie zweryfikować stan VM i urządzenia za pomocą standardowych interfejsów operacyjnych.
6. Jeśli dragonfly nadal ma stan Pending, kontener pozostaje niegotowy albo widać pętlę restartów, utworzyć pakiet logów i eskalować problem.

Wartości platformy i obsługiwane wymagania CPU podsumowano w artykule „Wybór platformy i prawidłowe wymiarowanie sensora Sophos NDR”.

Sprawdzanie przesyłania S3 i łączności wychodzącej

Błąd przesyłania S3 nie oznacza, że nie dociera ruch SPAN. Przechwytywanie i przesyłanie są dwoma oddzielnymi etapami. Dlatego w Appliance Manager, w obszarze NDR, należy zapisać aktywność przechwytywania/przepływów oraz wartość Uploaded dla tego samego przedziału czasu.

Ścieżkę ruchu wychodzącego należy sprawdzać w następującej kolejności:

1. Czy konfiguracja adresu MGMT — DHCP lub ręczna — odpowiada sieci zarządzającej?
2. Czy rozpoznawanie DNS i NTP działają przez przewidziane usługi?
3. Czy trasa domyślna prowadzi przez przewidzianą ścieżkę internetową lub centralną ścieżkę ruchu wychodzącego?
4. Czy Network ACL, Security Group lub lokalna zapora zezwalają na wychodzący ruch HTTPS?
5. Czy Web Proxy zezwala urządzeniu na dostęp do wymaganych celów bez modyfikowania lub blokowania wstępnie podpisanego żądania S3?
6. Czy reguły odpowiadają aktualnym wyjątkom portów i domen Sophos?

Listy zależnych od regionu domen bez symboli wieloznacznych nie należy kopiować ze starych zgłoszeń. W chwili kontroli trzeba ją porównać z aktualnymi wymaganiami Appliance requirements. Tymczasowe otwarcie szerokiego dostępu do całego Internetu nie jest bezpiecznym testem. Zmiany należy wprowadzać pojedynczo, a po każdej sprawdzać ten sam przedział czasu błędu.

Wycofanie: zmienioną testowo regułę proxy, ACL lub zapory należy po kontroli przywrócić do stanu początkowego, chyba że jest trwale potrzebna. Podczas wycofywania muszą pozostać sprawne dotychczas działające ścieżki zarządzania i przesyłania innych integracji.

Nieprawidłowy stan SPAN, odrzucane pakiety lub brakujące przepływy

spanX: unhealthy span

Dla dokładnie wskazanego portu należy sprawdzić:

• oczekiwane źródło i kierunek mirroringu,
• dedykowany interfejs docelowy i fizyczne okablowanie,
• przypisanie karty przechwytującej, grupy portów lub vSwitch,
• w przypadku ERSPAN: adres docelowy, routing, MTU oraz wartości GRE lub VXLAN,
• ostatnie zmiany sieci VLAN, trunku, grupy portów, rozmieszczenia hostów lub sesji mirroringu,
• czy ten sam cel nie jest przypadkowo ponownie użyty jako źródło mirroringu.

Za pomocą hosta pilotażowego należy wygenerować znany, nieszkodliwy ruch unicast i w tym samym przedziale czasu obserwować przewidziany port SPAN oraz przebieg przepływów. Jeśli aktywności nie ma, diagnostyka pozostaje na poziomie źródła, kierunku, filtra, transportu lub przypisania przechwytywania. Przetwarzanie i przesyłanie należy oceniać dopiero po wykazaniu, że ruch dociera na wejście.

spanX: packets being dropped

Przy odrzucaniu ponad 10% pakietów należy dodatkowo zapisać:

• przypisane vCPU i użycie poszczególnych rdzeni,
• przepustowość, liczbę pakietów/s i przepływów/s,
• nowo dodane lub nakładające się źródła mirroringu,
• trend pamięci oraz dysku głównego i dysku danych,
• wszystkie moduły Log Collector na tym samym urządzeniu wraz z wartościami Received, Filtered, Accepted i Uploaded.

Wymiarowanie współdzielonego urządzenia zaczyna się od NDR, a następnie uwzględnia obciążenie kolektorów. Dodatkowymi limitami dla całego urządzenia są maksymalnie 8 000 zdarzeń kolektorów na sekundę oraz, przy 16 GB RAM, maksymalnie 2 GB dla modułów Log Collector. Nawet rdzenie CPU używane przez NDR mogą być współdzielone z innymi integracjami i przez to wpływać na pojemność NDR. Jeśli obciążenie kolektorów trzeba rozdzielić, najpierw należy ustalić odpowiedzialność i urządzenie docelowe, a następnie użyć ogólnego przewodnika po integracjach; ten podręcznik nie zmienia źródeł syslog specyficznych dla producenta.

Przy 4 vCPU DPDK zwykle utrzymuje jeden rdzeń na poziomie 100%, a przy 8 vCPU — dwa rdzenie. Samo to jest normalne. Problem z pojemnością potwierdza dopiero połączenie odrzucanych pakietów, kolejnych wysyconych rdzeni, spadku przesyłania lub zmienionego przebiegu przepływów.

Łańcuch mirroringu, walidację pilotażową i ograniczoną drogę powrotu opisano w artykule „Planowanie i walidacja mirroringu ruchu dla Sophos NDR”.

Diagnostyka rejestracji i stanu Connected

Nowe urządzenie początkowo jest wyświetlane jako Waiting for deployment. Po pomyślnym zakończeniu bootstrapu i uruchomieniu ścieżki zarządzania jego stan w Threat Analysis Center > Integrations > Configured > Integration Appliances zmienia się na Connected.

Jeśli zmiana nie następuje, należy:

1. zidentyfikować właściwe urządzenie według nazwy, platformy oraz wygenerowanego obrazu lub pliku seed,
2. sprawdzić start VM pod kątem ciągłych błędów lub pętli restartów,
3. sprawdzić adres MGMT, VLAN, DHCP lub wartości ręczne, bramę i DNS,
4. sprawdzić NTP i wymagany ruch wychodzący według aktualnych wymagań urządzenia,
5. w przypadku ESXi użyć pliku OVA wygenerowanego przez Fusion tylko do jednej próby wdrożenia; dla innych platform sprawdzić aktualny proces wdrażania,
6. udokumentować czas, widoczny stan i ostatnie dane wyjściowe bootstrapu bez informacji poufnych.

Urządzenia nie wolno usuwać ani instalować ponownie. Ten podręcznik celowo nie zawiera procedury demontażu ani wymiany. Connected potwierdza centralne połączenie i przypisanie, ale nie zakres SPAN, przesyłanie ani detekcję.

Jeśli urządzenie miało już stan Connected, a następnie go utraciło, najpierw sprawdza się ścieżkę zarządzania, ruch wychodzący i dostępność urządzenia. Ustawienia mirroringu nie są pierwszym miejscem diagnostyki, ponieważ SPAN i zarządzanie korzystają z osobnych ścieżek.

Sprawdzanie dostępu do Appliance Manager zamiast usterki sensora

Jeśli otwiera się Open Appliance Manager, ale logowanie kontem zadmin nie działa, należy najpierw potraktować to jako problem logowania, a nie dowód usterki SPAN, przesyłania lub Dragonfly. W razie zapomnienia hasła należy użyć łącza reset it w oknie potwierdzenia Open Appliance Manager i ustawić nowe hasło. Nowe hasło zapisz od razu w systemie zarządzania hasłami; ani starego, ani nowego hasła nie wolno umieszczać na zrzucie ekranu, w dzienniku operacyjnym ani w zgłoszeniu do pomocy technicznej.

Jeśli konto zostało zablokowane wskutek zbyt wielu błędnych prób logowania, udokumentowaną alternatywą jest konsola internetowa hiperwizora obsługującego urządzenie: wybierz tam Unlock Account w sekcji Weblink interface. Ta ścieżka awaryjna wymaga już autoryzowanego dostępu do konsoli internetowej hiperwizora; runbook nie dodaje żadnych poleceń powłoki, SSH ani konsoli i nie wyprowadza z niej innej ścieżki dostępu. Następnie tylko raz sprawdź logowanie przy użyciu bezpiecznie przechowanego hasła. Jeśli konto nadal jest zablokowane, nie próbuj kolejnych haseł, lecz zapisz czas i widoczny komunikat oraz skontaktuj się z Sophos Support.

Konfiguracja zarządzania offline jako ostatni lokalny krok odzyskiwania

Ustawienie Actions > Settings > Management w Appliance Manager wolno zmienić lokalnie tylko wtedy, gdy VM nie ma łączności sieciowej. Jeśli łączność działa, zmianę należy wprowadzić w Sophos Fusion. Sam fakt, że VM jest offline, nie tworzy nowej ścieżki dostępu: lokalna korekta wymaga istniejącej i zatwierdzonej procedury odzyskiwania. Bez takiego dostępu należy zabezpieczyć bieżący adres MGMT-IP, ostatni znany stan Fusion i dane platformy, a następnie eskalować problem.

Przed wybraniem Save porównaj stare i nowe wartości pól IP Assignment, IPv4/Netmask, Gateway IP, DNS, DNS 2 oraz — w stosownych przypadkach — Enable Web Proxy, Web Proxy Type, Proxy URL i Port Number. Dane logowania proxy pozostają w systemie zarządzania hasłami. Zmień wyłącznie wartość, której nieprawidłowość potwierdzono. Jeśli interfejs zażąda potwierdzenia restartu, będzie to restart urządzenia: NDR i wszystkie kolektory logów zostaną przerwane. Dlatego najpierw udokumentuj współdzielone obciążenia, okno serwisowe, oczekiwany nowy adres IP i drogę powrotu.

Po zastosowaniu zmiany sprawdź dostępność pod nowym adresem IP, stan Fusion, przechwytywanie i przesyłanie NDR oraz wszystkie kolektory logów. Jeśli zatwierdzony dostęp odzyskiwania nadal działa, a weryfikacja zakończy się niepowodzeniem, wycofaj dokładnie ostatnią zmianę do zapisanych wartości początkowych. Jeśli interfejs przestał być dostępny, nie zgaduj adresów ani wartości proxy; eskaluj problem wraz ze stanem bazowym, czasem i skutkami. Pełne kontrole wstępne i końcowe zawiera artykuł „Bezpieczna obsługa urządzenia i sensora Sophos NDR”.

Ochrona innych integracji na współdzielonym urządzeniu

Przed każdym restartem lub zmianą zasobów w Fusion należy rozwinąć strzałkę obok nazwy urządzenia i zapisać wszystkie integracje działające na tym samym urządzeniu. W Appliance Manager sekcja Integrations pokazuje ich stan, ostatni restart i liczniki syslog.

• Pojedynczy moduł Log Collector można niezależnie zrestartować za pomocą Restart; NDR i pozostałe integracje pozostają aktywne.
• Restart All dotyczy wszystkich modułów Log Collector, ale nie NDR.
• Restart NDR dotyczy sensora NDR, a nie modułów Log Collector.
• Actions > Restart dotyczy całej VM i przerywa działanie NDR oraz wszystkich modułów Log Collector.
• Actions > Shutdown zatrzymuje całą VM i wszystkie integracje; wymagana jest osobno przetestowana ścieżka ponownego włączenia.

Restart całej VM nie jest pierwszym krokiem diagnostycznym. Najpierw należy zapisać stany i wskaźniki oraz ustalić najmniejszy komponent, którego dotyczy problem. Skutki i bezpieczną kolejność działań opisuje artykuł „Bezpieczna obsługa urządzenia i sensora Sophos NDR”.

Gromadzenie danych diagnostycznych i logów

Pakiet podstawowy

Przed zmianą należy zapisać:

• nazwę urządzenia, System ID, Version, K3S Helm Chart version i Uptime,
• stan Fusion i dokładną treść błędu,
• czas rozpoczęcia i odtworzenia problemu oraz strefę czasową,
• w Status użycie poszczególnych rdzeni CPU, pamięć, dysk główny i dysk danych,
• w NDR przechwytywanie dla każdego skonfigurowanego portu SPAN, Uploaded i przebieg przepływów,
• w Integrations wszystkie moduły Log Collector działające na tym samym urządzeniu wraz ze stanami i licznikami,
• w Advanced widoczny stan kontenerów i ostatni widoczny czas restartu,
• platformę, zasoby VM, profil ruchu i ostatnie zmiany,
• oczekiwany wynik, wynik rzeczywisty i wpływ biznesowy.

Gdy Appliance Manager jest niedostępny

1. W Fusion otworzyć Threat Analysis Center > Integrations > Configured > Integration Appliances.
2. Z menu z trzema kropkami przy właściwym urządzeniu wybrać Collect logs.
3. W kolumnie Log requested otworzyć informację i zapisać wyświetloną nazwę pliku.
4. Przekazać tę nazwę pliku wraz z urządzeniem, przedziałem czasu i treścią błędu do Sophos Support.

Gdy Appliance Manager jest dostępny

1. Z menu z trzema kropkami wybrać Open Appliance Manager, a następnie Open.
2. W Appliance Manager wybrać Actions > Download Log File.
3. Archiwum logów przekazać do istniejącego zgłoszenia wyłącznie uzgodnionym kanałem pomocy technicznej.

Archiwa logów mogą zawierać adresy IP, nazwy hostów i inne poufne dane operacyjne. Hasło zadmin, tokeny, klucze prywatne, dane logowania do proxy i inne informacje poufne nie mogą znaleźć się w zgłoszeniu, zrzucie ekranu ani załączniku.

Kontrolowane włączanie Remote Assistance

Remote Assistance należy aktywować tylko dla konkretnego zgłoszenia do pomocy technicznej. Urządzenie musi być online.

1. W Fusion otworzyć Threat Analysis Center > Integrations > Configured > Integration Appliances.
2. Z menu z trzema kropkami wybrać Remote Assistance.
3. W oknie włączyć Enable.
4. Zaznaczyć potwierdzenie Sophos Group Privacy Notice i wybrać Save.
5. Zaczekać na wyświetlenie Access ID.
6. Przekazać Sophos Support wyłącznie ten Access ID, uzgodnionym kanałem.

Dostęp wygasa automatycznie najpóźniej po siedmiu dniach. Jeśli analiza zakończy się wcześniej, należy w tym samym oknie wyłączyć Enable i udokumentować zakończenie. Remote Assistance nie zastępuje zgłoszenia do pomocy technicznej ani pakietu diagnostycznego.

Bezpieczna walidacja korekty i jej wycofanie

W jednym przebiegu należy zmieniać tylko jedną hipotezę. Wcześniej trzeba zapisać stan początkowy, osobę odpowiedzialną, okno serwisowe i drogę powrotu. Następnie, przy porównywalnym obciążeniu, sprawdzić, czy:

• poprzedni czerwony lub żółty komunikat nie pojawia się ponownie,
• oczekiwany stan urządzenia i ścieżka zarządzania są stabilne,
• każdy przewidziany port SPAN wykazuje aktywność odpowiadającą ruchowi pilotażowemu,
• przebieg przepływów i przesyłanie pozostają stabilne przez miarodajny okres,
• komunikat o odrzucaniu ponad 10% pakietów nie powraca,
• CPU poza oczekiwanymi rdzeniami DPDK, pamięć i przestrzeń dyskowa mają wystarczający zapas,
• wszystkie moduły Log Collector na tym samym urządzeniu nadal przetwarzają dane,
• zmiana platformy udostępnia wymagane flagi CPU i obsługiwany tryb.

Jeśli kontrola kończy się niepowodzeniem lub powstają nowe skutki uboczne, należy wycofać dokładnie ostatnią zmianę. Jeśli nie można przywrócić stanu początkowego, nie należy wykonywać dalszych zmian; trzeba zebrać dane diagnostyczne i otworzyć zgłoszenie w Sophos Support.

Po korekcie technicznej zielona integracja nadal nie jest dowodem detekcji. Dopiero po ustabilizowaniu łańcucha mirroringu i przesyłania należy wykonać procedurę „Generowanie i weryfikacja bezpiecznej testowej detekcji Sophos NDR”.

Eskalacja do Sophos Support

Zgłoszenie w Sophos Support należy otworzyć, jeśli:

• komunikat NDR containers not ready nadal występuje albo dragonfly widocznie pozostaje w stanie Pending lub w pętli restartów,
• wymagane flagi CPU nie są dostępne mimo prawidłowej platformy,
• błąd przesyłania S3 utrzymuje się mimo potwierdzonego działania DNS, proxy, zapory i ścieżki ruchu wychodzącego,
• spanX: unhealthy span utrzymuje się mimo zweryfikowania źródła, kierunku i przypisania celu,
• odrzucanie pakietów powraca po odpowiedniej zmianie pojemności lub rozłożeniu obciążenia,
• stan Connected, lokalne przesyłanie i odbiór w Data Lake są ze sobą sprzeczne,
• bootstrap nie doprowadza do rejestracji albo urządzenie nieoczekiwanie przełącza się między stanami,
• bezpieczna korekta wymagałaby niskopoziomowych ingerencji w kontenery, Kubernetes lub Dragonfly.

W zgłoszeniu należy przesłać pakiet podstawowy, nazwę pliku logów lub archiwum logów, dokładne kroki i mierzalne wyniki. Należy jasno wskazać już wykluczone hipotezy. Sophos Support obsługuje problemy produktu dotyczące instalacji, administracji i działania; zgłoszenie nie jest zleceniem zbadania detekcji.

Detekcja oparta na XDR i zarządzana samodzielnie pozostaje odpowiedzialnością klienta. Sophos MDR bada i obsługuje wyłącznie sprawy MDR zarządzane przez Sophos. Informacje o tworzeniu i eskalowaniu zgłoszenia zawiera artykuł „Otwieranie zgłoszenia do Sophos Support za pomocą Support Assistant”.