Wdrażanie Sophos NDR w AWS

Sophos NDR działa w AWS jako urządzenie integracyjne oparte na EC2. Odbiera ono kopię wybranego ruchu VPC za pośrednictwem VPC Traffic Mirroring, pasywnie go analizuje i przesyła dane NDR do Sophos Data Lake. Urządzenie nie działa w trybie inline i nie zastępuje ani Security Groups, ani zapory sieciowej.

Niezawodny przebieg procesu w skrócie wygląda następująco: ustal kwestie licencyjne i zakresy odpowiedzialności, udokumentuj szczegóły sieci AWS, utwórz urządzenie w Sophos Fusion, pobierz wygenerowany szablon CloudFormation, zasubskrybuj ofertę Marketplace, utwórz stos, dodaj dokładnie jedną kontrolowaną Mirror Session, ogranicz dostęp administracyjny i osobno zweryfikuj każdą warstwę.

⚠️ Ten runbook celowo nie zawiera kompletnej procedury wycofania wdrożenia. Bezpieczna kolejność i skutki usuwania stosu, urządzenia oraz zasobów EC2, EBS, ENI, Security Group, Elastic IP, mirroringu i Marketplace nie zostały w pełni zweryfikowane. Nie wolno zatem „sprzątać” nieudanego wdrożenia za pomocą improwizowanej kolejności usuwania.

Architektura i decyzje przed rozpoczęciem

CloudFormation tworzy dwie logicznie oddzielone ścieżki sieciowe:

Management Interface znajduje się w Public Subnet i korzysta z przypisanego adresu Elastic IP Address. Tą ścieżką odbywa się dostęp przez SSH i do Sophos Appliance Manager.
SPAN interface odbiera ruch lustrzany. Utworzony przez szablon NDR SPAN Target służy jako Mirror Target.
Traffic mirror session łączy wybrany źródłowy interfejs ENI z tym celem. Również tworzony przez szablon NDR Traffic Mirror Filter określa, które pakiety są kopiowane.
Urządzenie przetwarza kopie i wysyła dane NDR do Sophos. Oryginalne przepływy pozostają na swojej zwykłej ścieżce danych AWS.

Najważniejsza decyzja projektowa nie brzmi więc „którą całą VPC monitorujemy?”, lecz który interfejs ENI będzie odpowiednim Mirror Source. Zacznij od jednego udokumentowanego interfejsu ENI należącego do systemu testowego. Pozwala to ograniczyć ilość danych, koszty i zakres potencjalnych błędów. Kolejne źródła dodawaj dopiero po odbiorze technicznym.

Przed wdrożeniem udokumentuj w planie wdrożenia co najmniej:

konto AWS, Region, VPC, Availability Zone i tagi właściciela;
identyfikator VPC oraz identyfikatory Management Subnet i SPAN Subnet;
co najmniej jeden adres Elastic IP przypisany na koncie AWS na potrzeby Management Interface; jest to wymaganie dotyczące konta, ale udokumentowana lista parametrów nie udostępnia go jako danych wejściowych szablonu, które można wybrać z wyprzedzeniem;
typy EC2 obecnie obsługiwane przez Sophos: c5n.2xlarge, c6i.4xlarge lub c7i.16xlarge z wirtualizacją Nitro; typ faktycznie użyty należy sprawdzić w bieżącym szablonie dzierżawy oraz na instancji po wdrożeniu;
nazwę istniejącego SSH Key Pair i bezpieczne miejsce przechowywania Private Key;
Security Group dla SSH i stałe sieci źródłowe administratorów;
początkowy interfejs ENI pełniący funkcję Mirror Source i zespół odpowiedzialny za powiązane obciążenie;
oczekiwany, zwykły ruch testowy tego interfejsu ENI;
centrum kosztów, alarm budżetowy oraz akceptację kosztów infrastruktury AWS i warunków Marketplace wyświetlanych dla tego konta.

VPC, Subnets i Elastic IP

Możesz użyć istniejącej VPC i istniejących Subnets. Nie opieraj jednak wyboru wyłącznie na nazwach:

Zaplanuj Management Subnet jako Public Subnet. Przed jego wybraniem sprawdź Route Table i przewidzianą ścieżkę do internetu.
Wskaż SPAN Subnet dla NDR SPAN interface. Zapisz Subnet i Availability Zone razem z Mirror Source, zamiast później wnioskować o tych wartościach z nazw zasobów.
Adres Elastic IP należy do Management Interface, a nie do strony SPAN. Upewnij się wcześniej, że na koncie jest przypisany co najmniej jeden adres Elastic IP. Nie zakładaj, że stos użyje konkretnego istniejącego adresu: po osiągnięciu stanu CREATE_COMPLETE ustal i zapisz adres rzeczywiście utworzony lub użyty oraz jego powiązanie z ENI.
Szablon automatycznie wybiera AMI i Region na podstawie AWS Region, do którego przesłano szablon. Nie wymuszaj innego AMI przez ręczną zmianę szablonu.

Security Groups i SSH Key Pair

Użyj istniejącego AWS Key Pair, którego Private Key jest już bezpiecznie przechowywany. CloudFormation wymaga nazwy Key Pair; Private Key nie jest zapisywany w Sophos Fusion ani w szablonie. Bez Private Key udokumentowany przez Sophos dostęp SSH do urządzenia AWS nie będzie później możliwy.

Przygotuj Security Group, która zezwala na SSH wyłącznie z administracyjnej sieci dostępowej, na przykład ze stałego firmowego adresu IP wyjścia jako /32 albo przez kontrolowany Jump Host. Nie udostępniaj ani SSH, ani TCP 8443 dla 0.0.0.0/0.

Szablon tworzy również InternalMgmtSG. Po wdrożeniu zezwól w niej na TCP 8443 wyłącznie z rzeczywistych źródeł administracyjnych. Jeśli to samo urządzenie obsługuje także Log Collector, zezwól na Syslog tylko z użyciem protokołu i portu wymaganego przez odpowiedni konektor oraz tylko z wewnętrznych sieci źródłowych. Samo VPC Traffic Mirroring nie wymaga ogólnej reguły Syslog z internetu.

Wcześniejsza weryfikacja łączności wychodzącej

Samo istnienie Public Subnet i Elastic IP nie dowodzi, że działa ścieżka wychodząca. Przed użyciem opcji Submit odpowiedzialny zespół sieciowy musi potwierdzić, że Management Interface może komunikować się na zewnątrz przez przewidzianą trasę oraz Internet Gateway lub zatwierdzoną scentralizowaną architekturę ruchu wychodzącego. Sprawdź rozwiązywanie nazw DNS, Route Table, Network ACL, reguły wychodzące Security Group oraz reguły serwera proxy i nadrzędnej zapory sieciowej.

Wymagane miejsca docelowe i porty nie są kopiowane do tego runbooka. W czasie wprowadzania zmiany porównaj zamiast tego aktualne wyjątki portów i domen dla urządzeń Sophos z regułami ruchu wychodzącego. Te zezwolenia są istotne dla uruchamiania, aktualizacji, rejestracji i przesyłania danych; potwierdzenie łączności z jednym miejscem docelowym nie zastępuje pełnego porównania.

Wymagania wstępne, role, licencja i koszty

Do konfiguracji są wymagane:

konto AWS z istniejącą VPC, Subnets i Availability Zones;
konto Sophos Fusion;
co do zasady pakiet Sophos Network Detection and Response integration license pack;
co najmniej jedna odpowiednia źródłowa instancja EC2 lub jej ENI;
co najmniej jeden adres Elastic IP Address przypisany na koncie AWS;
zapisany AWS SSH Key Pair;
aktualna akceptacja zmiany obejmująca mirroring sieciowy i przetwarzane w jego ramach dane.

W miarę możliwości podziel prace następująco, bez wymyślania niepotwierdzonych nazw zasad IAM:

Administrator Sophos Fusion tworzy konfigurację NDR i pobiera szablon.
Osoba upoważniona do zakupów akceptuje warunki oferty Sophos Integration Appliance w AWS Marketplace.
Administrator AWS z uprawnieniami wymaganymi dla stosu i przywoływanych zasobów sieciowych tworzy zasoby CloudFormation, EC2, VPC Traffic Mirroring, Security Group i Elastic IP.
Odpowiedzialny zespół sieciowy lub zespół obciążenia potwierdza Mirror Source, działanie filtra, okno testowe i oczekiwany ruch.

Sophos nie wskazuje osobnej minimalnej roli Fusion właściwej dla NDR w tym procesie. Jeśli opcje Add Configuration, Download image lub Open Appliance Manager nie są widoczne, nie należy zgadywać: Super Admin powinien sprawdzić rzeczywiste uprawnienia w dzierżawie i licencję.

Jedyny uwzględniony tutaj wyjątek ma wąski zakres: Sophos dokumentuje, że klienci MSP Flex z licencją XDR mogą zintegrować Sophos NDR bez dodatkowego Integration License Pack. Nie oznacza to, że każda subskrypcja XDR lub MDR obejmuje NDR, ani że wyjątek dotyczy licencji Term. Potwierdź zatem konkretne uprawnienie dzierżawy/SKU w Fusion, a w razie niejasności — w Sophos lub u partnera zakupowego, korzystając z aktualnych zasad licencjonowania integracji Sophos.

CloudFormation tworzy płatne zasoby AWS. Urządzenie wirtualne jest objęte odpowiednim uprawnieniem Sophos NDR; nie wynika z tego jednak publiczna cena katalogowa ani informacja o konkretnej ofercie Marketplace dla konta. Przed użyciem opcji Submit sprawdź aktualnie wyświetlane warunki Marketplace. Osobno oszacuj koszty w kategoriach AWS: EC2, pamięć masowa, publiczny adres IPv4/Elastic IP, transfer danych i VPC Traffic Mirroring. Ten runbook celowo nie podaje stałych kwot: Region, czas działania, ilość danych i model cenowy AWS wpływają na wyliczenie. Tagi i alarm budżetowy muszą znaleźć się w zmianie przed rozpoczęciem mirroringu produkcyjnego.

1. Tworzenie urządzenia i szablonu CloudFormation w Sophos Fusion

W Sophos Fusion otwórz Threat Analysis Center > Integrations > Marketplace.
Otwórz Sophos Network Detection and Response (NDR).
W sekcji Data Ingest (Security Alerts) kliknij Add Configuration.
W polu Step 1 wprowadź unikatową nazwę i opis, na przykład ndr-aws-prod-eu1 i NDR Sensor für AWS Produktions-VPC eu1.
W polu Step 2, w sekcji Virtual platform, wybierz AWS.
Kliknij Save. Sophos wygeneruje plik CloudFormation aws_ndr_cf_latest.json.
Otwórz Threat Analysis Center > Integrations > Configured, a następnie kartę Integration Appliances.
Znajdź właśnie utworzone urządzenie. W prawej kolumnie otwórz menu z trzema kropkami, wybierz Download image i zapisz plik aws_ndr_cf_latest.json w chronionym folderze zmiany.

Plik JSON pochodzi z własnej dzierżawy Fusion i właśnie utworzonego urządzenia. Nie używaj starego pliku z innej dzierżawy lub zmiany. Nie edytuj szablonu ręcznie w celu wymuszenia nieobsługiwanych typów instancji, obrazów AMI lub wariantów sieciowych.

2. Subskrybowanie oferty Marketplace

W AWS Marketplace wyszukaj Sophos Integration Appliance.
Na stronie Product Overview kliknij Continue to Subscribe.
Na stronie Subscribe to this software sprawdź warunki i zaakceptuj je tylko po uzyskaniu wymaganej zgody zakupowej. Następnie kliknij Continue to Configuration.
Na stronie Configure this software sprawdź wersję i Region. Muszą być zgodne z planem wdrożenia. Kliknij Continue to Launch.
Na stronie Launch this software najpierw otwórz Usage instructions i udokumentuj wyświetlane instrukcje dostępu.
Kliknij Launch. AWS otworzy Create stack.

Subskrypcja Marketplace jest warunkiem zaakceptowania przez AWS oprogramowania przywoływanego w szablonie. Dlatego w razie niedostępnego AMI lub błędu dotyczącego uprawnienia do oferty zacznij diagnostykę od subskrypcji, Region i wersji, a nie od modyfikowania pliku JSON.

3. Tworzenie stosu CloudFormation

Przed wypełnieniem formularza sprawdź parametry szablonu aktualnie wygenerowanego z tej dzierżawy. Jeśli udostępnia udokumentowany parametr typu instancji EC2, wybierz wyłącznie typ obecnie obsługiwany przez Sophos i zapisz nazwę oraz wartość parametru. Jeśli takiego parametru nie ma, typ wybiera szablon; nie edytuj ręcznie pliku JSON. W obu przypadkach po utworzeniu sprawdź faktycznie uruchomiony typ EC2.

W sekcji Create stack pozostaw zaznaczoną opcję Template is ready.
W sekcji Specify template wybierz Upload a template file.
Kliknij Choose file, wybierz właśnie wygenerowany plik aws_ndr_cf_latest.json, a następnie kliknij Next.
W sekcji Specify stack details wprowadź unikatową wartość Stack name, na przykład sophos-ndr-prod-eu1.
W sekcji Network Configuration wprowadź:
- zaplanowaną, istniejącą VPC;
- Public Subnet dla NDR Management Interface;
- Subnet dla NDR SPAN interface;
- przygotowaną Security Group dla administracyjnego dostępu SSH.
W sekcji EC2 Instance Configuration wybierz istniejący SSH Key Pair. Ponownie sprawdź, czy Private Key jest dostępny i chroniony.
Kliknij Next. W sekcji Configure stack options sprawdź tagi i pozostałe opcje AWS. Nie akceptuj wartości domyślnych bez sprawdzenia; porównaj je ze zmianą.
Sprawdź podsumowanie i kliknij Submit.
Poczekaj na stan CREATE_COMPLETE. Według Sophos trwa to zazwyczaj od pięciu do sześciu minut; rozstrzygające są zdarzenia CloudFormation, a nie ten szacowany czas.

Przed utworzeniem Mirror Session w stosie lub powiązanych zasobach AWS muszą być widoczne co najmniej: oczekiwane urządzenie Sophos, jego rzeczywisty typ EC2, interfejsy Management ENI i SPAN ENI, NDR SPAN Target, NDR Traffic Mirror Filter, InternalMgmtSG oraz faktycznie używany adres Elastic IP wraz z jego powiązaniem. Jeśli brakuje któregokolwiek elementu lub stos nie kończy się stanem CREATE_COMPLETE, nie twórz Mirror Session.

4. Tworzenie jednej Traffic Mirror Session

Nie każdy interfejs EC2 ENI ani każda topologia automatycznie nadają się na Mirror Source. Przed utworzeniem sesji sprawdź w aktualnej dokumentacji AWS obsługiwane typy instancji źródłowych, wymagania wstępne i ograniczenia dotyczące Mirror Target oraz konkretną topologię Source/Target, Region i Availability Zone. Sprawdź również w Service Quotas i na podstawie limitów AWS dla Traffic Mirroring, czy limity dla źródeł, sesji, celów i filtrów są wystarczające. Ta weryfikacja AWS stanowi osobny punkt akceptacji; lista typów urządzeń obsługiwanych przez Sophos nie potwierdza możliwości mirroringu dowolnego interfejsu ENI obciążenia.

Otwórz VPC > Traffic mirror sessions > Create traffic mirror session i świadomie wypełnij pola:

Name Tag: opisowa nazwa, na przykład ndr-prod-app01;
Description: cel i odniesienie do zmiany, na przykład Mirror app01 ENI to Sophos NDR - CHG-1234;
Mirror Source: ENI zatwierdzonego systemu testowego, a nie tylko instancja EC2 o podobnej nazwie;
Mirror Target: utworzony przez stos NDR SPAN Target;
Session number: numer odpowiedni dla tego Source. AWS używa go do ustalania kolejności, gdy to samo Source ma wiele sesji. Przed wybraniem numeru zinwentaryzuj istniejące sesje;
VNI: 1;
Filter: utworzony przez stos NDR Traffic Mirror Filter.

Kliknij Create dopiero po przeprowadzonej przez dwie osoby weryfikacji Source, Target, Session number, VNI i Filter. VNI = 1 i użycie wygenerowanego filtra to wymagania produktu. Natomiast Source, nazwa, opis i Session number muszą odpowiadać własnemu środowisku AWS.

Podczas pierwszego testu nie dodawaj kolejnych źródeł „na wszelki wypadek”. Dodatkowa Mirror Session zwiększa ilość danych, koszty i zakres analizy, dlatego wymaga osobnej akceptacji merytorycznej.

5. Konfigurowanie dostępu administracyjnego i poświadczeń

W AWS Console wyszukaj nazwę urządzenia, wybierz kartę EC2 i otwórz instancję Sophos Appliance.
Na stronie Instance Summary otwórz kartę Security, a następnie InternalMgmtSG.
W sekcji Inbound rules dodaj TCP 8443 wyłącznie dla zatwierdzonych administracyjnych zakresów CIDR. Udokumentuj Rule ID, źródło i odniesienie do zmiany.
W Sophos Fusion otwórz Threat Analysis Center > Integrations > Configured > Integration Appliances.
Otwórz menu urządzenia z trzema kropkami i wybierz Open Appliance Manager.
W oknie potwierdzenia kliknij reset it, aby ustawić hasło.
Zaloguj się przy użyciu stałej nazwy użytkownika zadmin i ustawionego hasła.

Traktuj hasło zadmin jako uprzywilejowany sekret. Przechowuj je w zatwierdzonym sejfie haseł, a nie w szablonie CloudFormation, zgłoszeniu ani na zrzucie ekranu. Wszyscy administratorzy używają tego samego hasła Appliance Manager. Jeśli zostanie utracone, ustaw je ponownie przez Open Appliance Manager > reset it.

Weryfikacja wdrożenia i pierwszej rejestracji

Sam status działającej instancji EC2 nie potwierdza ani ścieżki mirroringu, ani rejestracji. Sprawdź elementy w następującej kolejności:

CloudFormation: Stos ma stan CREATE_COMPLETE; oczekiwane zasoby są dostępne i nie ma pominiętych ani zakończonych niepowodzeniem zdarzeń.
Powiązania sieciowe: VPC, Management Subnet, SPAN Subnet, Elastic IP, oba interfejsy ENI i SSH Key Pair są zgodne z planem wdrożenia.
Ekspozycja: SSH i TCP 8443 są dostępne wyłącznie z zatwierdzonych sieci administracyjnych. Nie istnieje nowa reguła zarządzania z 0.0.0.0/0.
Konfiguracja mirroringu: Sesja wskazuje dokładnie zatwierdzony Source ENI, NDR SPAN Target, VNI 1 i NDR Traffic Mirror Filter. Session number i istniejące sesje równoległe są udokumentowane.
Połączenie z Sophos: Urządzenie jest widoczne w sekcji Integration Appliances; jego status NDR w Sophos Fusion jest zielony, Open Appliance Manager otwiera oczekiwane miejsce docelowe, a logowanie jako zadmin działa.
Wstępna ścieżka danych: W zatwierdzonym oknie testowym wygeneruj zwykły, nieszkodliwy ruch na Mirror Source ENI. Na karcie NDR w Appliance Manager sprawdź procent przesłanych danych, procent przechwytywania dla skonfigurowanego portu SPAN oraz wykres Total flows. Zapisz czas pomiaru i wartości. Detection nie jest wymagane w tym teście infrastruktury.
Kontrola negatywna: Niezatwierdzone źródło administracyjne nie może uzyskać dostępu do TCP 8443. Ta kontrola potwierdza ograniczenie dostępu administracyjnego, a nie wykrywanie NDR.

Zapisz Stack ID, nazwę urządzenia, identyfikator i typ instancji, Management ENI i SPAN ENI, faktyczne powiązanie EIP, Mirror Session ID, Source ENI, Target, Filter, VNI, identyfikatory reguł Security Group, pomiary NDR i okno odbioru. W tym zapisie nie należy umieszczać sekretów. Odbiór ten potwierdza jedynie wdrożenie i pierwszą rejestrację. Następnie w pełni zweryfikuj lustrzaną ścieżkę danych zgodnie z artykułem Konfigurowanie i weryfikowanie Traffic Mirroring dla Sophos NDR, a potem wykonaj bezpieczny kompleksowy test wykrywania. Ani udane logowanie, ani zwykły ruch testowy nie dowodzą samodzielnie, że cały łańcuch wykrywania działa.

Rozwiązywanie problemów według objawów

Stos nie osiąga stanu `CREATE_COMPLETE`

Najpierw otwórz kartę stosu Events i analizuj zdarzenia od pierwszego, które zakończyło się niepowodzeniem, zamiast cofać się od ostatniego błędu będącego jego skutkiem.

W przypadku błędów dotyczących uprawnień do oferty Marketplace lub AMI: sprawdź subskrypcję, zaakceptowane warunki, wersję i Region.
W przypadku błędów uprawnień: poproś administratora AWS o sprawdzenie akcji i zasobu wskazanych w konkretnym zdarzeniu. Nie nadawaj ogólnej zasady administratora jako szybkiego rozwiązania.
W przypadku parametrów sieciowych: porównaj identyfikatory VPC i Subnet, przypisany Elastic IP lub dostępny limit EIP, Security Group oraz SSH Key Pair z planem wdrożenia.
W przypadku błędów pojemności lub limitu: sprawdź wybrany, obsługiwany typ instancji oraz konkretny komunikat o błędzie AWS. Nie przechodź na typ, którego szablon nie oferuje.

Dopóki stos jest niekompletny, nie twórz ani Mirror Session, ani dodatkowych Inbound Rules.

Urządzenie działa, ale nie dociera do niego ruch lustrzany

Sprawdź łańcuch w następującej kolejności:

Czy Mirror Source jest rzeczywiście interfejsem ENI, przez który przepływa ruch testowy?
Czy Mirror Target to NDR SPAN Target z tego stosu, a nie podobnie nazwany cel z innego środowiska?
Czy VNI ma wartość 1?
Czy wybrano NDR Traffic Mirror Filter?
Czy Session number koliduje z zamierzoną kolejnością przetwarzania innych sesji tego samego Source?
Czy w udokumentowanym oknie rzeczywiście wygenerowano ruch przez ten interfejs ENI?

Zmieniaj tylko jedną z tych zmiennych naraz, a następnie powtarzaj ten sam test. Szerszy filtr lub wybór Source nie zastępuje analizy przyczyny źródłowej.

Nie można utworzyć Mirror Session

Najpierw przeczytaj konkretny komunikat o błędzie interfejsu API AWS lub konsoli; nie zmieniaj jednocześnie Source, Target i Filter.
Ponownie sprawdź Source ENI i typ jego instancji EC2 pod kątem aktualnych wymagań wstępnych i ograniczeń AWS dotyczących Traffic Mirroring.
Porównaj topologię Source/Target oraz wybór Region/Availability Zone z aktualną dokumentacją AWS.
Sprawdź odpowiednie limity Traffic Mirroring w Service Quotas. Złóż wniosek o ich zwiększenie lub zmień projekt w ramach standardowej zmiany AWS, zamiast usuwać istniejące sesje bez weryfikacji.

Rejestracja lub przesyłanie danych NDR nie działa

Najpierw sprawdź ścieżkę ustaloną w sekcji Wcześniejsza weryfikacja łączności wychodzącej. W szczególności DNS, Route Table, Internet Gateway lub zatwierdzona architektura ruchu wychodzącego, Network ACL, reguły wychodzące Security Group, serwer proxy i nadrzędna zapora sieciowa muszą być ze sobą zgodne. Ponownie porównaj reguły z aktualnymi wyjątkami portów i domen Sophos. Według Sophos błąd przesyłania związany ze wstępnie podpisanym adresem URL S3 często wskazuje, że serwer proxy lub zapora blokuje wychodzący ruch internetowy. Nie rozszerzaj ogólnie dostępu wychodzącego; udokumentuj konkretnie blokowane miejsce docelowe i zezwól wyłącznie na wyjątek aktualnie wymagany przez Sophos.

Appliance Manager jest niedostępny przez TCP 8443

Sprawdź, czy InternalMgmtSG zezwala na bieżący publiczny adres źródłowy administratora.
Sprawdź powiązanie Elastic IP z Management Interface oraz wybrany Public Subnet.
Upewnij się, że Open Appliance Manager otwiera oczekiwane urządzenie.
Jeśli regułę tymczasowo rozszerzono do 0.0.0.0/0, natychmiast ponownie ją ogranicz; szeroki dostęp nie jest krokiem diagnostycznym.

Problem z hasłem badaj dopiero wtedy, gdy działa ścieżka sieciowa.

Logowanie jako `zadmin` nie działa lub Appliance Manager jest zablokowany

W przypadku nieznanego hasła użyj w Sophos Fusion opcji Open Appliance Manager > reset it. Jeśli urządzenie wyraźnie wyświetla komunikat o blokadzie, Sophos dokumentuje dla AWS następującą interwencję przez SSH:

redis-cli --no-auth-warning -h redis-master.default.svc.cluster.local -p 6379 -a $(jq -r .RedisPassword /etc/dragonfly/sensorapi_config.json) SET userlockout '{"attempt":0,"locked":false}'

Uruchom to polecenie wyłącznie w sesji SSH odpowiedniej instancji Sophos NDR EC2, używając Private Key wybranego podczas wdrożenia. Ten runbook celowo nie podaje nazwy użytkownika systemu operacyjnego ani pełnej składni SSH, ponieważ sprawdzona strona Sophos ich nie dokumentuje. Pobierz aktualne dane tożsamości połączenia z Usage instructions subskrybowanej oferty Marketplace lub wyjaśnij je z Sophos Support; nie zgaduj. Przed połączeniem porównaj adres docelowy, identyfikator instancji i odcisk hosta z inwentarzem AWS. Polecenie zmienia stan blokady, ale nie ustawia nowego hasła. Używaj go tylko wtedy, gdy blokada jest wyraźnie widoczna, a nie jako ogólnego rozwiązania problemów z logowaniem. Następnie spróbuj zalogować się przy użyciu dotychczasowego hasła; jeśli to nie zadziała, ustaw je ponownie w Sophos Fusion. Polecenie i wynik, bez hasła ani Private Key, zapisz w dokumentacji zmiany.

Ograniczone wycofanie zmiany zamiast niezweryfikowanego demontażu

Przed każdą ręczną zmianą Security Group wyeksportuj stan początkowy lub udokumentuj go za pomocą identyfikatorów reguł. Jeśli nowa reguła TCP 8443 lub Syslog spowoduje problem, możesz usunąć dokładnie tę ręcznie dodaną regułę i zweryfikować udokumentowany stan początkowy. Jest to wąski sposób wycofania własnej zmiany reguły ruchu przychodzącego, a nie demontaż urządzenia NDR.

Celowo nie podano tutaj kompletnej kolejności usuwania stosu, subskrypcji Marketplace, obiektu urządzenia ani zasobów EC2/EBS, ENI, Elastic IP, Traffic Mirror Session, Target, Filter i Security Groups. Runbook nie twierdzi również, że usunięcie stosu CloudFormation rozwiązuje kwestię wszystkich powiązanych zasobów, kosztów, obiektów Sophos lub skutków dotyczących danych. Dopóki te zależności nie zostaną zweryfikowane z aktualną dokumentacją producenta i w testach, zasoby usuwaj wyłącznie w ramach osobno sprawdzonej zmiany wycofującej je z eksploatacji.