Sophos Linux Sensor: bezpieczne zbieranie danych dla pomocy technicznej

W przypadku problemu z Sophos Linux Sensor (SLS) należy zebrać archiwum dla pomocy technicznej oraz odpowiednie logi sensora, najlepiej w trakcie występowania błędu lub bezpośrednio po nim. Zbieranie trwa około 30 sekund. Najpierw należy ustalić sposób wdrożenia: w przypadku Helm dane zbiera się osobno dla każdego węzła, którego dotyczy problem, w przypadku Docker — na hoście Docker, a w przypadku instalacji bezpośredniej — na hoście Linux. Po wysłaniu sygnału debugowania należy natychmiast rozpocząć pobieranie; tymczasowe okno debugowania wynosi 60 sekund.

Ta instrukcja dotyczy wyłącznie Sophos Linux Sensor. SLS nie jest ani Sophos Protection for Linux (SPL), ani jego XDR Sensor, ani jego zasadą Linux Runtime Detection. Umieszczenie w przeglądzie serwerów służy nawigacji i nie oznacza równoważności produktów. Dla SPL obowiązuje osobna instrukcja instalacji i eksploatacji; poniższych poleceń SLS nie wolno tam stosować.

Sprawdzenie systemu docelowego i zgody przed zbieraniem danych

Przed wysłaniem sygnału lub ponownym uruchomieniem należy potwierdzić na podstawie inwentarza wdrożenia i działającej instancji, że problem rzeczywiście dotyczy SLS. W zgłoszeniu do pomocy technicznej należy odnotować host lub klaster, przestrzeń nazw, pod, węzeł lub kontener, zainstalowaną wersję sensora oraz czas wystąpienia błędu ze strefą czasową. Informacje o wersji w zebranym później archiwum uzupełniają tę identyfikację. Ta instrukcja opiera się na procedurze pomocy technicznej zaktualizowanej 5 października 2026 r.; nie wynika z tego minimalna wersja ani zatwierdzenie dla każdej starszej wersji sensora, Helm, Kubernetes lub Docker. W przypadku innych nazw, portów lub braku punktu końcowego monitorowania należy najpierw wyjaśnić rzeczywistą konfigurację wdrożenia z pomocą techniczną.

Potrzebny jest katalog roboczy z ograniczonym dostępem i wystarczającą ilością wolnego miejsca. Podane poniżej nazwy plików odnoszą się do tego katalogu; przed ponownym wykonaniem procedury należy osobno zabezpieczyć istniejące pakiety, aby ich nie nadpisać. Dostęp do archiwum, logów i profili należy ograniczyć do odpowiedzialnych osób oraz ustalić okres przechowywania. Na potrzeby pobierania adresy monitorowania pozostają lokalne. Nie należy tworzyć publicznej usługi, Ingress ani ogólnodostępnego portu debugowania.

Narzędzia muszą być już zatwierdzone i dostępne. Jeśli na hoście Linux z instalacją bezpośrednią brakuje curl, procedura przewiduje następujące polecenia instalacji:

# Systemy oparte na Red Hat
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Należy użyć wyłącznie polecenia odpowiedniego dla dystrybucji, w ramach zatwierdzonego procesu zarządzania pakietami. Instalacja pakietu zmienia host; nie jest częścią samego sprawdzania artykułu. Dla Helm i Docker potrzebne są dodatkowo tar i gzip. W przypadku braku wymaganych narzędzi lub uprawnień należy zatrzymać procedurę przed włączeniem debugowania.

Helm: jeden pakiet dla każdego węzła, którego dotyczy problem

Na komputerze administracyjnym kubectl musi być skonfigurowany dla właściwego klastra. Uprawnienia muszą pozwalać na wyświetlanie podów, odczytywanie ich logów, przekierowywanie portów podów i dodawanie efemerycznego kontenera debugowania. Ponadto środowisko wykonawcze kontenerów musi obsługiwać wskazywanie przestrzeni nazw procesów innego kontenera jako celu. Na tym komputerze potrzebne są curl, tar i gzip.

Klaster musi mieć możliwość pobrania busybox:latest. Jeśli ten rejestr nie jest zatwierdzony, należy wcześniej skopiować obraz do zatwierdzonego, dostępnego rejestru i zastąpić wyłącznie wartość --image tym zweryfikowanym odwołaniem do obrazu. Nie należy łagodzić reguł bezpieczeństwa rejestru, aby wymusić zebranie danych. Kontener efemeryczny stanowi zmianę w podzie; wymaga odpowiedniej zgody operacyjnej.

Wybór poda i utrzymanie przekierowania portu

Chart Helm dla SLS udostępnia jeden pod sensora na każdy monitorowany węzeł Linux. Należy zastąpić <namespace> przestrzenią nazw wydania SLS:

kubectl --namespace <namespace> \
get pods \
--selector app=sophos-linux-sensor \
--output wide

Wynik musi pozwalać przypisać pod sensora do węzła, którego dotyczy problem. <sensor-pod> oznacza dokładnie ten pod, a <node-name> — nazwę jego węzła. Nie należy używać dowolnego prawidłowo działającego poda z tego samego wydania.

W pierwszym terminalu należy przekierować port monitorowania:

kubectl --namespace <namespace> \
port-forward pod/<sensor-pod> 9010:9010

Ten terminal pozostaje otwarty do zakończenia pobierania. Jeśli lokalny port jest już zajęty, należy zatrzymać procedurę i wyjaśnić konflikt, zamiast kończyć obcy proces. Nie należy dodawać powiązania z publicznie dostępnymi adresami. Jeśli przekierowanie zostanie przerwane, musi ponownie działać przed kolejnym pobieraniem.

Wysłanie sygnału, natychmiastowe pobranie i uzupełnienie logów

W drugim terminalu kontener debugowania jest kierowany na kontener SLS. Polecenie wysyła SIGUSR2 do procesu sensora; nie jest poleceniem zakończenia działania sensora:

kubectl --namespace <namespace> \
debug pod/<sensor-pod> \
--image=busybox:latest \
--target=sophos-linux-sensor \
--attach=false -- \
pkill -USR2 -f '[s]ophoslinuxsensor'

Wzorzec wyszukiwania [s]ophoslinuxsensor zapobiega dopasowaniu przez pkill własnego wiersza polecenia. Jeśli pobranie obrazu, sprawdzenie uprawnień lub wskazanie procesu docelowego zakończy się niepowodzeniem, zbieranie danych nie zostało niezawodnie aktywowane. Nie należy bez sprawdzenia dodawać kolejnych kontenerów debugowania; najpierw trzeba wyjaśnić komunikat o błędzie.

Bezpośrednio potem należy pobrać dane w drugim terminalu:

curl --fail --silent --show-error \
--max-time 120 \
http://127.0.0.1:9010/support.tar \
--output sophos-linux-sensor-support-<node-name>.tar

--max-time 120 ogranicza czas wywołania HTTP, ale nie wydłuża okna debugowania. Następnie należy zapisać bieżące logi tego samego kontenera i węzła:

kubectl --namespace <namespace> \
logs pod/<sensor-pod> \
--container sophos-linux-sensor \
--timestamps \
> sophos-linux-sensor-<node-name>.log

Należy wyświetlić zawartość bez rozpakowywania:

tar -tf sophos-linux-sensor-support-<node-name>.tar

Po opisanym poniżej sprawdzeniu kompletności należy zakończyć przekierowanie portu w pierwszym terminalu za pomocą Ctrl+C. Dla każdego kolejnego węzła, którego dotyczy problem, należy użyć osobnego poda i unikatowej nazwy pliku.

Docker: sprawdzenie działającego kontenera i opublikowanego portu

Wszystkie poniższe polecenia wykonuje się na hoście Docker z zatwierdzonymi na nim uprawnieniami Docker. Kontener SLS musi działać; jego port monitorowania musi być już opublikowany na hoście. Domyślny port w kontenerze to 9010. Muszą być dostępne curl, tar i gzip. Późniejsze opublikowanie portu lub ponowne uruchomienie kontenera nie jest tutaj zalecane jako sposób naprawy.

docker ps
docker port <sensor-container> 9010/tcp

<sensor-container> to nazwa lub identyfikator potwierdzonego kontenera SLS. Drugi wynik podaje adres i port hosta. <host-port> należy zastąpić tym portem, a nie automatycznie wartością 9010. Poniższe pobieranie zakłada, że opublikowany adres jest dostępny przez 127.0.0.1 na tym hoście Docker. W przypadku powiązania wyłącznie z innym adresem lub braku wyniku należy najpierw sprawdzić wdrożenie; nie należy dodawać publicznie dostępnego portu.

Poniższe polecenie zmienia stan debugowania na 60 sekund. Nie wolno wykonywać docker kill bez --signal=SIGUSR2:

docker kill --signal=SIGUSR2 <sensor-container>

Natychmiast potem należy pobrać dane z opublikowanego lokalnego punktu końcowego:

curl --fail --silent --show-error \
http://127.0.0.1:<host-port>/support.tar \
--output sophos-linux-sensor-support.tar

Logi i sprawdzenie archiwum należą do tego samego pakietu:

docker logs <sensor-container> \
> sophos-linux-sensor.log 2>&1

tar -tf sophos-linux-sensor-support.tar

Tymczasowy tryb debugowania kończy się automatycznie. Ponowne wywołanie docker ps musi nadal pokazywać właściwy działający kontener; samo to nie dowodzi jednak, że wykrywanie działa.

Host Linux z instalacją bezpośrednią: użycie tymczasowego trybu debugowania

Ten wariant dotyczy SLS działającego bezpośrednio na hoście, a nie kontenera ani /opt/sophos-spl. Wymagane są uprawnienia root i dostęp do lokalnego portu monitorowania. W przypadku instalacji systemd należy wcześniej sprawdzić za pomocą journalctl -u sophoslinuxsensor, czy dziennik dotyczy oczekiwanej usługi i hosta. Jeśli usługi brakuje lub istnieje kilka instancji sensora, należy najpierw wyjaśnić ich przypisanie.

Udokumentowane polecenie dla hosta obejmuje wszystkie aktywne procesy pasujące do wzorca sophoslinuxsensor na hoście. Nie ogranicza się do pojedynczej instancji. Nie należy go wykonywać bez zgody dotyczącej tych instancji lub w przypadku niejasnych nazw procesów.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

Następnie sensor udostępnia informacje dla pomocy technicznej i debugowania przez 60 sekund w punkcie końcowym monitorowania. Należy natychmiast zebrać dane w przygotowanym katalogu roboczym:

curl -O http://localhost:9010/support.tar && gzip support.tar

Zbieranie trwa około 30 sekund. Po pomyślnej kompresji dostępny jest plik support.tar.gz. To wywołanie na hoście nie zawiera ani sprawdzania błędów HTTP, ani limitu czasu; dlatego samo istnienie pliku lub pomyślne wywołanie gzip nie stanowią dowodu kompletności archiwum. Do lokalnego sprawdzenia bez rozpakowywania pakietu:

tar -tzf support.tar.gz

Logi hosta odczytuje się za pomocą:

journalctl -u sophoslinuxsensor

Do bieżącej obserwacji udokumentowano dodatkowo następujące wywołanie:

journalctl -efu sophoslinuxsensor

Należy zakończyć obserwację za pomocą Ctrl+C i zapisać informacje z dziennika potrzebne dla okresu występowania błędu, korzystając z zatwierdzonej metody eksportu. Nie należy traktować ciągłego strumienia danych wyjściowych bez ograniczenia czasowego jako ukończonego pakietu dla pomocy technicznej.

Sprawdzenie archiwum, zawężenie przyczyn błędu i bezpieczne przekazanie

Kompletne archiwum debugowania zawiera wpisy takie jak runtimedetections.yaml, environment.json, goroutine.out i profile.out, a także informacje o metrykach i wersji. Wymienione wpisy są przykładami, a nie gwarancją identycznej zawartości dla każdej wersji. tar musi być w stanie wyświetlić zawartość archiwum bez błędów. Strona błędu HTML, pusty pakiet lub przerwane pobieranie nie są wynikiem nadającym się do wykorzystania.

Jeśli pakiet zawiera tylko metrics.txt i version.json, zbieranie danych debugowania nie było aktywne. Należy sprawdzić instancję docelową, błędy wysyłania sygnału i odstęp czasu. Następnie w odpowiednim wariancie wdrożenia należy ponownie wysłać SIGUSR2 i natychmiast pobrać dane od nowa. W wariancie Helm przekierowanie portu musi działać przez cały czas pobierania. Powtarzające się niepowodzenia należy eskalować do pomocy technicznej wraz z dokładnym komunikatem o błędzie, wersją sensora i czasem wystąpienia błędu; nie należy ich obchodzić przez stały tryb debugowania ani otwarty port sieciowy.

Archiwa, logi i profile mogą zawierać poufną konfigurację, zmienne środowiskowe oraz informacje o hoście i środowisku wykonawczym. Nawet jeśli części konfiguracji są automatycznie maskowane, nie oznacza to, że pakiet jest zanonimizowany i nadaje się do publicznego udostępniania.

Przed przekazaniem należy sprawdzić listę plików i, w razie potrzeby, ich zawartość w odizolowanym środowisku pod kątem danych uwierzytelniających, tokenów, wewnętrznych nazw hostów i danych osobowych. Do usuwania lub maskowania poufnych danych należy używać oddzielnej kopii i dokumentować zmiany; nie należy w sposób niekontrolowany modyfikować profili binarnych. Należy uzgodnić z pomocą techniczną, które treści są potrzebne do diagnozy w niezmienionej postaci. Oryginał należy przechowywać wyłącznie z ograniczonym dostępem i przez uzgodniony okres.

Archiwum i powiązane logi należy przekazywać wyłącznie przez zatwierdzony kanał pomocy technicznej Sophos potwierdzony w zgłoszeniu. Odbiorcę i miejsce przesyłania należy zweryfikować na podstawie istniejącego zgłoszenia, a nie niezamówionej wiadomości. Nie należy używać publicznego zgłoszenia, forum, repozytorium Git ani magazynu multimediów bazy wiedzy. Do pakietu należy dołączyć typ wdrożenia, węzły lub hosty, których dotyczy problem, wersję sensora, czas wystąpienia błędu ze strefą czasową, objaw i wykonane już kroki zbierania danych; nie należy przesyłać danych uwierzytelniających w tekście towarzyszącym.

Profile CPU i pamięci tylko w konkretnych przypadkach

Do zwykłego archiwum dla pomocy technicznej wystarczy tymczasowe włączenie debugowania sygnałem. Poniższe pojedyncze profile stanowią osobną metodę dla problemów z CPU lub pamięcią i używają formatu Google pprof. Przed trwałym skonfigurowaniem debugowania trzeba ustalić, jak faktycznie uruchamiana jest usługa SLS i jak można przywrócić jej konfigurację.

Najpierw należy zabezpieczyć dotychczasową zawartość /etc/sophos/runtimedetections-rules.yaml, dotychczasową wartość lub brak debug oraz efektywne środowisko uruchomieniowe. W szczególności należy ustalić, czy RUNTIMEDETECTIONS_DEBUG jest już ustawiona. Kopia zapasowa tej konfiguracji również jest poufna. Nie należy mylić jej z podobnie nazwanym plikiem runtimedetections.yaml w archiwum dla pomocy technicznej.

Należy wybrać jeden z udokumentowanych sposobów aktywacji:

• Uruchomić sensor z RUNTIMEDETECTIONS_DEBUG=true w jego rzeczywistym środowisku uruchomieniowym. Samo export w powłoce administracyjnej nie zmienia środowiska już działającej usługi.
• Ustawić debug: true w /etc/sophos/runtimedetections-rules.yaml, nie zastępując pozostałych reguł ani nie tworząc sprzecznego drugiego wpisu.

Ponowne uruchomienie przerywa działanie usługi SLS. Zgoda na prace serwisowe, tolerowana przerwa w wykrywaniu i dostęp do pierwotnej konfiguracji muszą być zapewnione wcześniej. To wywołanie systemd dotyczy bezpośredniej instalacji na hoście; nie jest procedurą ponownego uruchamiania dla Helm ani Docker.

Z uprawnieniami root należy wykonać udokumentowane ponowne uruchomienie:

systemctl restart sophoslinuxsensor

Następnie należy sprawdzić stan usługi i dziennik. Dopiero gdy usługa działa i konfiguracja jest prawidłowa, należy zebrać potrzebne profile z lokalnego punktu końcowego:

curl -s http://localhost:9010/debug/pprof/heap > heap.out
curl -s 'http://localhost:9010/debug/pprof/profile?seconds=60' > profile.out

heap.out zbiera próbki wykorzystania pamięci przez aktywne obiekty sterty; profile.out rejestruje wykorzystanie CPU przez 60 sekund. Te wywołania nie zawierają sprawdzania błędów HTTP: samo utworzenie pliku nie dowodzi, że profil jest prawidłowy. Nie należy interpretować pustych plików ani odpowiedzi błędu jako wyników pomiaru; należy sprawdzić punkt końcowy i efektywną konfigurację debugowania, a w razie potrzeby zweryfikować format z pomocą techniczną. Te pliki również pozostają poufne.

Natomiast metryki nie wymagają trybu debugowania ani ponownego uruchomienia związanego z debugowaniem:

curl -s http://localhost:9010/metrics > metrics.out

Przywrócenie stanu debugowania i stanu operacyjnego

W przypadku tymczasowego zbierania danych po upływie 60-sekundowego okna nie należy wysyłać kolejnych sygnałów. Należy pozostawić sensor uruchomiony i na podstawie jego logów lub istniejącego monitorowania operacyjnego sprawdzić, czy nadal działa prawidłowo. Działający proces lub dostępny punkt końcowy metryk nie stanowią pełnego dowodu poprawnego wykrywania i przesyłania danych. W przypadku odmiennego zachowania należy współpracować z pomocą techniczną.

W przypadku trwale skonfigurowanego debugowania nie ma automatycznego przywrócenia po 60 sekundach. Należy przywrócić wcześniej zabezpieczoną wartość debug lub jej pierwotny brak w pliku YAML oraz przywrócić poprzedni stan zmiennej RUNTIMEDETECTIONS_DEBUG ustawionej specjalnie na potrzeby tej diagnozy w rzeczywistej konfiguracji uruchomieniowej. Nie należy bez rozróżnienia nadpisywać innych ustawień ani całej konfiguracji, która w międzyczasie została zmieniona. Dokładna zmiana środowiska zależy od istniejącego mechanizmu uruchamiania; bez znanego stanu bazowego nie istnieje uniwersalne bezpieczne polecenie resetowania.

Dla bezpośrednio zainstalowanej usługi systemd po tym przywróceniu należy ponownie użyć pokazanego powyżej systemctl restart sophoslinuxsensor w zatwierdzonym oknie serwisowym. Należy sprawdzić usługę i dziennik pod kątem błędów uruchamiania lub konfiguracji, porównać efektywne ustawienie debugowania z poprzednim stanem i skontrolować, czy nie pozostał dostęp do profili włączony specjalnie na potrzeby diagnozy. Jeśli debugowanie było aktywne już wcześniej, jego wyłączenie jest dodatkową decyzją operacyjną, a nie przywróceniem stanu.

Należy zakończyć przekierowanie portu Helm i potwierdzić, że jego proces terminalowy zakończył działanie. Efemerycznego kontenera debugowania nie można usunąć z istniejącego poda jak zwykłego kontenera; nie należy usuwać poda sensora wyłącznie w celu uporządkowania pozostałości po tej diagnozie. Jeśli lokalna polityka klastra wymaga odtworzenia poda, odpowiedzialny operator musi zaplanować je osobno, uwzględniając przerwę w wykrywaniu i kontrolę wdrażania.

Po potwierdzeniu odbioru przez pomoc techniczną i upływie ustalonego okresu przechowywania należy zgodnie z lokalną polityką usuwania usunąć pliki archiwów, logów i profili utworzone w ramach tej procedury oraz tymczasowe kopie używane do usuwania lub maskowania poufnych danych. Nie należy usuwać plików przy użyciu symboli wieloznacznych ani usuwać reguł sensora, logów produktu lub danych innych zgłoszeń do pomocy technicznej. Usunięcie pliku nie gwarantuje nadpisania kopii zapasowych, migawek ani bloków SSD; ich przechowywanie podlega właściwej polityce zarządzania pamięcią masową i ochrony danych.