Wybrać, zainstalować i sprawdzić Sophos Linux Sensor

Sophos Linux Sensor (SLS) zbiera zdarzenia wykonawcze Linuksa i przetwarza je z użyciem Detection Content na alerty lub skonfigurowane reakcje. Może współpracować z istniejącą infrastrukturą logów i powiadomień. SLS to osobny sensor: nie jest Sophos Protection for Linux (SPL), jego XDR Sensor ani zasadą wykrywania runtime w SPL.

Przed pilotażem sprawdza się platformę i uprawnienie, wybiera metodę instalacji oraz wdraża sensor i treść detekcji. Następnie śledzi się alert testowy aż do rzeczywistego odbiorcy. Sam działający proces nie wystarcza. Ten artykuł opisuje instalację bezpośrednio na hoście systemd; kontenery i Kubernetes korzystają z innej metody.

Najpierw licencja i model eksploatacji

Instrukcja Sophos sprawdzona 27 października 2026 r. wymienia Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) lub Sophos MDR Plus (Server) jako produkty uprawniające do SLS. Licencje ewaluacyjne nie uprawniają do tej usługi. Dowolna licencja endpoint ani samo posiadanie serwera Linux nie potwierdzają uprawnienia.

SLS jest licencjonowany na urządzenie. Według Sophos jego instancje nie pojawiają się jednak na liście serwerów Fusion, w widoku Devices ani w jego liczniku licencji. Należy więc prowadzić własny wykaz sensorów. Fusion może odbierać szczegóły detekcji i alerty SLS, lecz nie zarządza sensorem. Brak wpisu serwera SLS nie oznacza nieudanego rejestrowania SPL.

Dla klasycznego zarządzanego agenta serwerowego z wymaganymi komponentami SPL właściwy jest Sophos Protection for Linux. Przy obrazach immutable lub szczególnych platformach kontenerowych SLS ocenia się osobno; samo wymienienie zastosowania nie dopuszcza każdej kombinacji dystrybucji, jądra i runtime.

Przygotować platformę i pilotaż

Aktualne informacje SLS wymagają w chwili kontroli co najmniej 2 GB wolnego miejsca na dysku, 2 GB wolnej pamięci oraz x86_64 lub ARM64. ARM64 wymaga jądra 5.3 lub nowszego. Konkretna dystrybucja, jej aktualne wydanie podrzędne i działające jądro muszą również odpowiadać liście testowanych platform. Minimum jądra innej dystrybucji nie jest ogólnym dopuszczeniem. Platformy legacy mają osobne warunki wsparcia.

Przed pilotażem zapisuje się rolę hosta, dystrybucję, architekturę, jądro, istniejącą ochronę, obciążenie i odbiorcę alertów. Instalacja bezpośrednia wymaga uprawnień root/zarządzania pakietami, właściwego systemd oraz dostępnego lub zatwierdzonego podsystemu debugowania Linuksa potrzebnego SLS. Nie osłabia się prewencyjnie utwardzonego systemu, aby uruchomić skrypt.

Sophos oferuje odrębną metodę Helm dla Kubernetes; Docker, CRI-O i containerd również mają własne instrukcje. Sprawdza się rejestr, widoczność hosta, uprawnienia, obraz treści detekcji i runtime. Polecenia pakietowego z tego przykładu nie przenosi się bez zmian do kontenera sensora.

Przygotować token rejestru we właściwym tenancie

SLS używa osobnego Package Registry API Token, którego wartość zaczyna się od SLS-. Nie jest to krótkotrwały access token OAuth ani Client Secret tożsamości API.

Bieżąca procedura SLS wymaga Super Admin w panelu Fusion Admin klienta, nie w panelu Partner lub Enterprise. W Global Settings > Administration > API Credentials Management > Add Credential tworzy się potrzebną tożsamość z Service Principal Super Admin. Odpowiedzialna osoba najpierw zatwierdza ten szeroki wymóg producenta; nie staje się on domyślną rolą każdego projektu API. Client ID i Client Secret widoczny tylko raz przechowuje się bezpiecznie.

Proces poświadczeń API i OAuth służy do uzyskania bearer tokenu i określenia unikalnego ID tenanta klienta przez whoami/v1. W tym procesie idType musi potwierdzać tenant klienta. Identyfikator partnera nie jest właściwy. Następnie wysyła się POST do /accounts/v1/access-tokens na globalnym hoście API Sophos, z uwierzytelnieniem Bearer, X-Tenant-ID i takim JSON-em:

{
  "label": "SLS Pilot",
  "type": "sophosLinuxSensor"
}

label jest dowolną nazwą administracyjną, a type stałą wartością API. Dostęp do rejestru wykorzystuje pole token odpowiedzi, nie ID obiektu. Opcjonalne expiresAt wybiera się według planu dostępu; Sophos podaje, że data po wygaśnięciu licencji serwera jest skracana do tej granicy. Daleka data z przykładu nie daje stałego uprawnienia.

W kliencie HTTP sprawdza się status i treść odpowiedzi. Tokeny i sekrety nie mogą trafiać do historii powłoki, diagnostyki proxy, zgłoszeń lub zrzutów ekranu. Najpierw wyjaśnia się błąd tenanta, prawa lub tokenu; nie zmienia się na próbę ochrony czy uprawnień całego tenanta.

Instalacja na hoście przez menedżer pakietów

Najpierw przygotowuje się dostęp do rejestru SLS w zatwierdzonym zarządzaniu pakietami. Sophos dokumentuje packages.sophos.com/sophos-linux-sensor/release/ oraz klucz sophos-linux-sensor-archive-keyring.gpg. Klucz pobiera się uwierzytelnioną ścieżką producenta i zapisuje w /etc/sophos-linux-sensor.gpg. Przed użyciem weryfikuje się pochodzenie i aktualny fingerprint poprzez zatwierdzony łańcuch zaufania. gpg --list-packets pokazuje tylko czytelny pakiet klucza; samo to nie dowodzi zaufanego pochodzenia.

Obsługiwane hosty Debian

W odpowiednim pliku .list w /etc/apt/sources.list.d/ dodaje się źródło:

deb [signed-by=/etc/sophos-linux-sensor.gpg] https://packages.sophos.com/sophos-linux-sensor/release/ stable main

Powiązany token zapisuje się w pliku .conf z ograniczonym dostępem w /etc/apt/auth.conf.d/:

machine packages.sophos.com login <SLS-REGISTRY-TOKEN>

Symbol zastępczy zastępuje się otrzymanym tokenem. Plik mogą czytać tylko potrzebne uprzywilejowane procesy zarządzania pakietami; tokenu nie dodaje się także do URL repozytorium. Po weryfikacji podpisu, źródła i praw pliku wykonuje się w zatwierdzonym oknie:

sudo apt-get update
sudo apt-get install sophoslinuxsensor-systemd sophoslinuxcontent

Obsługiwane hosty RPM

Ścieżka RPM używa osobnego pliku .repo w /etc/yum.repos.d/. Nazwa sekcji i nazwa wyświetlana to dowolne przykłady; URL, sprawdzanie podpisu i ścieżka klucza odpowiadają udokumentowanej metodzie:

[sls]
name=Sophos Linux Sensor
baseurl=https://<SLS-REGISTRY-TOKEN>@packages.sophos.com/sophos-linux-sensor/release/
gpgcheck=1
enabled=1
gpgkey=file:///etc/sophos-linux-sensor.gpg

Symbol zastępczy zastępuje się otrzymanym tokenem. Dostęp do zawierającego go pliku jest ograniczony. URL nie może pojawiać się w logach diagnostycznych, zgłoszeniach czy zrzutach. Nie zastępuje się repozytoriów dystrybucji ani nie wyłącza podpisów. Wyświetlana nazwa nie dopuszcza konkretnej dystrybucji lub wersji.

Po poprawnej konfiguracji źródła Sophos wskazuje pakiety:

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Stosuje się wyłącznie metodę właściwą dla rzeczywiście obsługiwanej dystrybucji. Sensor i treść detekcji są konieczne. Zero policies configured oznacza niezaliczony odbiór detekcji, nawet gdy proces działa. Dawne numery wersji w przykładach producenta nie są dzisiejszym wymaganiem instalacyjnym.

Skonfigurować tenant i wyjście alertów

W /etc/sophos/runtimedetections.yaml ustawia się customer_id na sprawdzone ID. Istniejące ustawienia YAML uzupełnia się punktowo, nie zastępując całego pliku przykładem. Przed startem sprawdza się cel i zgodę na dane telemetrii oraz odbiorców alertów. Sophos opisuje domyślne wyjście do stdout; nie łączy to automatycznie każdego oczekiwanego odbiorcy.

Dla pierwszej kontroli zapisuje się rzeczywiste wyjście: lokalny journal, istniejący system logów albo jawnie skonfigurowany odbiorca Sophos. Poświadczenia, cel i format przygotowuje się dla tego wyjścia. Utworzenie tokenu nie potwierdza przesyłania alertów.

Na bezpośrednim hoście systemd uruchamia się i sprawdza:

sudo systemctl start sophoslinuxsensor
sudo systemctl status sophoslinuxsensor
sudo journalctl -u sophoslinuxsensor

Przy błędach startu sprawdza się najpierw platformę, pakiety, rzeczywisty YAML i prawa wskazane w journalu. Instrukcja producenta opisuje wymagane Linux Capabilities; nie zastępuje się ich ogólnymi uprzywilejowanymi kontenerami ani niesprawdzonym setcap na dowolnych plikach.

Sprawdzić detekcję aż do odbiorcy

Po instalacji Default Content i uruchomieniu sensora można na zatwierdzonym pilocie wygenerować opisany alert testowy. Najpierw należy sprawdzić składnię dla zainstalowanej wersji: instalacja w jednym miejscu podaje -test-alert, a osobna instrukcja testu używa --test-alert. Poniższe polecenie stosuje się tylko, gdy dana wersja obsługuje ten zapis:

sophoslinuxsensor --test-alert

Test celowo tworzy zdarzenie. Uzgadnia się go z zespołem odbiorczym zamiast wykonywać niezapowiedziany test produkcyjny. Oczekiwany jest Alert Tester w skonfigurowanym wyjściu. Host, czas i odbiorca muszą się zgadzać; sukces polecenia lub wpis lokalny nie dowodzą zdalnego dostarczenia.

Jeśli składnia nie jest obsługiwana albo alert nie dociera, nie zastępuje się testu prawdziwym złośliwym kodem czy niekontrolowanym atakiem.

Odbiór dokumentuje przynajmniej wersje sensora i treści, rzeczywiste reguły, poprawny start, alert testowy i faktyczny odbiór. Potwierdza tę ścieżkę, nie każdą detekcję, sytuację obciążenia czy prawo do badania MDR. Dodatkowe obciążenie pilota i aplikacje porównuje się z punktem wyjścia.

Reguły, aktualizacje i problemy eksploatacyjne

Standardowa treść znajduje się w /var/lib/sophos/content/runtimedetections-content.yaml i jest nadpisywana przy aktualizacjach. Zmiany umieszcza się w /etc/sophos/runtimedetections-rules.yaml, a nie w pliku producenta. Według dokumentacji Sophos wspiera niezmienioną treść standardową; pomoc dla reguł zmienionych lub własnych wymaga osobnego ustalenia.

Detekcje Core i Enhanced różnią się głębokością oraz wpływem na obciążenie. Więcej treści bez pilota nie jest automatycznie lepszym ustawieniem dla każdego serwera. Sensor i treść aktualizuje się odpowiednim wdrożeniem pakietów lub kontenerów, po czym sprawdza ponownie; jednorazowy odbiór instalacji nie zastępuje aktualizacji.

Przy braku alertów osobno bada się treść, wczytane reguły, zdarzenie, wyjście i przesyłanie. Bezpieczne zbieranie danych wsparcia SLS opisuje logi i pakiety diagnostyczne oraz osobne procedury Helm, Docker i hosta. Planowane usunięcie przygotowuje się na podstawie zapisanych wartości początkowych, pozostałych potrzeb ochrony i właściwej instrukcji producenta. Nie usuwa się usług ani poświadczeń innych hostów.