Instalacja i wdrażanie Sophos Protection for Linux

Ważna granica produktu: sekcja w przewodniku wdrażania Sophos nosi nazwę Deployment to Linux i znajduje się w części poświęconej Endpoint. Jej odsyłacze dla systemu Linux prowadzą jednak do obszarów Server Protection i Sophos Protection for Linux (SPL) w Sophos Fusion (dawniej Sophos Central). Linux nie korzysta więc z opisywanego w sąsiednich rozdziałach instalatora Endpoint dla Windows i macOS, lecz z własnego agenta serwerowego, oddzielnych zasad, wymagań, informacji o wersjach i procedur instalacji.

Cały proces od przygotowania tenantu po eksploatację opisuje ścieżka wdrażania Endpoint. Ten artykuł obejmuje w niej wyłącznie oddzielną ścieżkę serwerów Linux.

Na pojedynczym serwerze Linux wybierz najpierw tryb ochrony w obszarze My Environment > Installers: Download Linux Server Installer dla pełnej ochrony przed złośliwym oprogramowaniem albo Download XDR Sensor Linux Server Installer dla sensora XDR, który sam takiej ochrony nie zapewnia. Pobrany dla właściwego tenantu i trybu instalator SophosSetup.sh oznacz jako wykonywalny i uruchom z uprawnieniami roota. Na wielu systemach rozprowadzaj ten instalator za pomocą kontrolowanego systemu dystrybucji oprogramowania, zaczynając od --test. Jeśli SPL ma być już zawarty w szablonie maszyny wirtualnej, zastosuj udokumentowaną procedurę obrazu wzorcowego Linux, aby każdy klon otrzymał własną tożsamość urządzenia. Sophos zaleca rozważenie tego podejścia w środowiskach automatycznego skalowania, równoważenia obciążenia lub obejmujących wiele maszyn wirtualnych.

Przed pierwszym urządzeniem pilotażowym

Zatwierdź instalację dopiero po sprawdzeniu następujących punktów:

• Licencja i wymagany zakres ochrony: w obszarze Server Protection dostępne są dwa oddzielne pliki instalacyjne dla systemu Linux. XDR Sensor wymaga licencji XDR i według Sophos sam nie chroni przed zagrożeniami; musi mu towarzyszyć ochrona innego producenta. Przed pobraniem sprawdź wybrany tryb i dostępną licencję.
• Obsługiwana platforma: dystrybucja, wersja, architektura i jądro muszą odpowiadać bieżącej macierzy obsługi SPL. Sophos publikuje aktualnie testowane platformy i wymagania systemowe w informacjach o wersji. Niewymienione, wzmocnione, minimalne, niestandardowe lub starsze warianty podlegają dodatkowym ograniczeniom wsparcia. SPL nie należy instalować na siłę w dystrybucjach niezmiennych (immutable); dla takich systemów Sophos wskazuje oddzielny Sophos Linux Sensor.
• Wymagania podstawowe: podczas przeglądu treści z 14 września 2026 r. informacje o wersji SPL wymagały 2,5 GB wolnego miejsca, 2 GB wolnej pamięci RAM, architektury x86_64 lub ARM64, działającego obsługiwanego systemd, Bash oraz glibc 2.17 lub nowszej, a na ARM64 — 2.18 lub nowszej. ARM64 wymagał dodatkowo jądra 5.3 lub nowszego. Instalator wymagał programu curl, a wtyczka AV — narzędzia setcap z pakietu libcap2-bin, libcap lub libcap-progs. Ta opatrzona datą podstawa nie zastępuje bieżącej kontroli przed zatwierdzeniem.
• Dostęp sieciowy: urządzenie musi mieć dostęp do Sophos Fusion podczas instalacji i po niej. DNS, HTTPS, proxy, TLS Inspection oraz ewentualnie Message Relay i Update Cache należy przetestować z każdej planowanej sieci serwerowej zgodnie z wymaganiami dotyczącymi sieci i proxy.
• Istniejąca ochrona: Sophos Anti-Virus for Linux nie może działać równolegle z SPL. SAV trzeba wcześniej usunąć albo zmigrować podczas uruchamiania instalatora za pomocą --uninstall-sav. Przy samym XDR Sensor ochrona innego producenta musi natomiast pozostać aktywna, ponieważ sensor nie zapewnia ochrony przed złośliwym oprogramowaniem. W przypadku pełnej ochrony SPL przed złośliwym oprogramowaniem możliwość równoległego działania innych produktów antywirusowych należy przed pilotażem ocenić oddzielnie na podstawie deklaracji ich producentów.
• Plan wdrożenia: przed rozpoczęciem zapisz grupę docelową, grupę Central, zakres produktów, wielkość pilotażu, kryteria zatrzymania, okno serwisowe i sposób powrotu.

Utrzymywanie informacji o wersjach, platformach i sieci

Ten artykuł stanowi wewnętrzną podstawę kontroli wymagań specyficznych dla systemu Linux. Osoba odpowiedzialna sprawdza bieżące informacje o wersji SPL oraz macierz obsługi dystrybucji i jąder w portalu Sophos co miesiąc, a także przed każdym pilotażem i każdą falą wdrożenia. W dokumentacji zmiany należy zapisać datę kontroli, osobę sprawdzającą, wydanie SPL, dystrybucję, jej wersję, architekturę, jądro, minimalne zasoby, odstępstwa i decyzję o zatwierdzeniu. Jeśli bieżące dane różnią się od powyższej podstawy opatrzonej datą, przed następną falą zaktualizuj kryteria pilotażu i ten artykuł; stare wartości nie stanowią zatwierdzenia.

Powiązany przewodnik sieciowy jest właścicielem wspólnego procesu listy dozwolonych i proxy, w tym miejsc docelowych zależnych od systemu Linux i licencji. W przypadku pakietów oprogramowania, wdrażania aktualizacji etapami, Update Cache i Message Relay należy również postępować zgodnie z artykułem Aktualizacje Sophos Endpoint, cache i Message Relay. Pilotaż systemu Linux musi mimo to potwierdzić rzeczywistą ścieżkę i zainstalowaną wersję SPL z każdej planowanej sieci serwerowej.

Najpierw sprawdź systemy plików i zasoby

Tylko przy pełnej ochronie przed złośliwym oprogramowaniem z zainstalowanym produktem antivirus: SPL może niezawodnie skanować i poddawać kwarantannie wyłącznie pliki na jawnie obsługiwanych systemach plików. Podczas przeglądu źródeł 20 września 2026 r. Sophos wymieniał bfs, btrfs, cifs, devtmpfs, ecryptfs, ext2, ext3, ext4, fuse, fuseblk, iso9660, jfs, jfs2, msdos, nfs, nfs4, overlay, squashfs, tmpfs, udf, vfat, xfs i zfs. Przed każdą falą porównaj listę z aktualną dokumentacją SPL. Na urządzeniu pilotażowym z ochroną AV wyświetl wszystkie zamontowane cele i ich typy:

findmnt -rn -o TARGET,FSTYPE

W trybie AV sprawdź nie tylko / i ścieżkę instalacji, ale każdy punkt montowania z danymi biznesowymi, kontenerami, udziałami sieciowymi lub planowanymi celami skanowania. System plików spoza listy nie zostaje zatwierdzony tylko dlatego, że pierwszy test wygląda poprawnie. Sophos zaleca wyłączenie takich systemów ze skanowania; wtyczka AV automatycznie wyłącza systemy ze znanymi problemami i zapisuje zdarzenie w soapd.log. Dla samego XDR Sensor cele skanowania, kwarantanna i ten dziennik AV nie są kryteriami odbioru.

SPL zarządza limitami procesora i pamięci za pomocą cgroups systemu Linux. Według Sophos ustawienia domyślne są odpowiednie dla większości środowisk, dlatego przed pilotażem nie ustawiaj ogólnych limitów. Jeśli wymagają ich zasady operacyjne, najpierw zmierz obciążenie i tolerancję aplikacji, a następnie przeczytaj lokalnie zainstalowany plik /opt/sophos-spl/base/etc/cgroup-resource-limits-README.txt. Jest on miarodajny, ponieważ opcje, komponenty i prawidłowe wartości mogą się zmieniać. Własne wartości zapisuje się w /opt/sophos-spl/base/etc/cgroup-limits.conf; CPU podaje się procentowo ze znakiem %, a pamięć — zależnie od opcji — w MB lub procentach. SPL odrzuca wartości spoza obsługiwanego zakresu i stosuje domyślne. Artykuł celowo nie podaje uniwersalnych liczb.

Po instalacji lub zmianie wykonaj poniższe kontrole odpowiednio do faktycznie zainstalowanego trybu:

1. Tylko z produktem antivirus: findmnt pokazuje aktualnie obsługiwany typ każdego planowanego celu skanowania.
2. Jeśli zmieniono limity cgroup: /opt/sophos-spl/logs/base/watchdog.log potwierdza konfigurację zastosowaną do faktycznie zainstalowanych składników i nie zawiera błędów konfiguracji.
3. Jeśli zmieniono limity cgroup: dziennik systemowy nie wykazuje procesów zakończonych przez cgroup SPL. Nie każdy system Linux zachowuje dziennik po restarcie; jeśli historia błędów ma być dostępna później, skonfiguruj trwałe przechowywanie dziennika zgodnie z lokalnymi zasadami.

Instalacja pojedynczego serwera przez Sophos Fusion

1. W Sophos Fusion przejdź do My Environment > Installers.
2. W sekcji Server Protection wybierz odpowiedni plik instalacyjny: Download Linux Server Installer dla pełnej ochrony przed złośliwym oprogramowaniem albo Download XDR Sensor Linux Server Installer dla samego sensora XDR (wymagana licencja XDR i aktywna ochrona innego producenta). Nie używaj instalatora Endpoint dla Windows ani macOS. Oferowany oddzielnie Sophos Linux Sensor (SLS) nie jest sensorem SPL XDR.
3. Przenieś SophosSetup.sh bezpieczną, chronioną przed nieuprawnionym dostępem metodą na docelowy serwer Linux.
4. Przejdź do katalogu pobierania i nadaj uprawnienie do wykonania:

chmod +x SophosSetup.sh

5. Najpierw uruchom testy wstępne bez instalacji:

sudo ./SophosSetup.sh --test

6. Jeżeli testy zakończą się powodzeniem, uruchom instalator:

sudo ./SophosSetup.sh

Bez opcji --install-dir SPL instaluje się w /opt/sophos-spl/. Pomyślne zakończenie procesu powłoki nie oznacza jeszcze odbioru wdrożenia; następnie należy sprawdzić rejestrację, faktycznie zainstalowane składniki, odpowiednie zasady i stan w Central oraz lokalnie. Opisane niżej kontrole AV nie dotyczą samego XDR Sensor.

Pobieranie instalatora bezpośrednio na serwer

Aby pobrać plik ręcznie z powłoki, skopiuj w Sophos Fusion adres odsyłacza wcześniej wybranego instalatora dla systemu Linux (pełna ochrona albo XDR Sensor) i wstaw go w miejsce symbolu zastępczego w poniższym poleceniu:

wget '<LINUX-INSTALLER-LINK>' -O SophosSetup.sh
chmod +x SophosSetup.sh
sudo ./SophosSetup.sh --test
sudo ./SophosSetup.sh

Zastąp <LINUX-INSTALLER-LINK> adresem skopiowanym z własnego tenantu dla wybranego trybu. Adresu URL i pobranego pliku nie wolno umieszczać w publicznych repozytoriach skryptów, zgłoszeniach ani ogólnodostępnych udziałach. W powtarzalnych wdrożeniach artefakt instalacyjny należy dostarczać za pośrednictwem chronionego mechanizmu dystrybucji pakietów lub sekretów na własnej platformie.

Wdrażanie skryptem na wielu systemach Linux

Masowe wdrożenie zaczyna się od kilku reprezentatywnych serwerów. Pilotaż powinien objąć różnice w dystrybucji, jądrze, architekturze, wzmocnieniu systemu, trasie proxy, lokalizacji, obciążeniu i istniejącym oprogramowaniu zabezpieczającym. Dopiero po pozytywnym odbiorze można rozpocząć następną ograniczoną falę.

Poniższy skrypt to przykład wyłącznie pełnej ochrony przed złośliwym oprogramowaniem z dodatkową licencją XDR, a nie wdrożenia samego XDR Sensor. Używa pobranego w tym celu Linux Server Installer, przypisuje urządzenie do podgrupy LinuxServers\Pilot i żąda składników antivirus oraz xdr:

#!/usr/bin/env bash
set -euo pipefail

if (( EUID != 0 )); then
  printf 'Ten skrypt wdrożeniowy musi być uruchomiony jako root.\n' >&2
  exit 1
fi

installer='/var/tmp/SophosSetup.sh'
chmod 700 "$installer"

"$installer" --test
"$installer" \
  --group='LinuxServers\Pilot' \
  --products=antivirus,xdr \
  --tag=Rollout:wave-0 \
  --tag=ManagedBy:automation

Dostosuj ścieżkę grupy do własnej struktury Central. Jeśli wskazana grupa lub podgrupa jeszcze nie istnieje, instalator ją utworzy. Dlatego przed wdrożeniem dokładnie sprawdź ścieżkę: literówka może utworzyć niepożądaną nową grupę. W przypadku --products produkty bez licencji nie zostaną zainstalowane; według bieżącej strony CLI dozwolone wartości to antivirus, mdr i xdr. Kolejne argumenty --tag=<key>:<value> dodają tagi urządzenia. Jeśli klucze się powtarzają, Central pokazuje tylko ostatnią przekazaną wartość.

W tym przykładzie set -euo pipefail zapobiega dalszemu wykonywaniu skryptu i pozornemu powodzeniu po nieudanym teście wstępnym lub instalacji. System dystrybucji oprogramowania musi przekazywać rzeczywisty kod zakończenia i nie może bez końca ponawiać instalacji na hostach, na których się nie powiodła. Ponieważ Sophos nie publikuje na stronie CLI stałej tabeli znaczeń liczbowych kodów zakończenia, o wyniku nie decyduje wymyślone mapowanie kodów, lecz łączna kontrola lokalna i w Central.

Ważne opcje instalatora

Zmienne środowiskowe umieszcza się przed, a opcje wiersza poleceń po wywołaniu instalatora.

Identyfikatory UID i GID kont i grup tworzonych przez SPL można określić opcjami --user-ids-to-configure i --group-ids-to-configure. Używaj ich tylko wtedy, gdy lokalne wymagania dotyczące tożsamości lub wzmocnienia systemu narzucają stałe identyfikatory; Sophos wyraźnie ogranicza ich działanie do udokumentowanych kont i grup SPL.

W przypadku opcji --install-dir=<basis> SPL znajduje się w katalogu <basis>/sophos-spl. Wszystkie dalsze ścieżki dzienników, wersji, rejestracji i deinstalacji trzeba odpowiednio dostosować; ścieżki /opt/sophos-spl/... podane w artykule dotyczą instalacji standardowej. Ścieżki wtyczki AV dotyczą ponadto wyłącznie hostów z zainstalowanym produktem antivirus.

Określanie Message Relay i Update Cache

Zwykle SophosSetup.sh zawiera przekaźniki i pamięci podręczne skonfigurowane w Central. Instalator porządkuje je na podstawie liczbowej bliskości względem adresu IP urządzenia i wybiera najbliższą dostępną usługę; jeżeli żadna nie jest dostępna, łączy się bezpośrednio z Central. Ten wybór można jawnie zastąpić na czas instalacji:

sudo ./SophosSetup.sh \
  --message-relays=192.0.2.10:8190 \
  --update-caches=192.0.2.10:8191

192.0.2.10 jest adresem dokumentacyjnym i należy go zastąpić. Sophos wskazuje port 8190 dla Message Relay i 8191 dla Update Cache. Wartość none wymusza bezpośrednie połączenie z Central dla danej opcji. Nadpisanie obowiązuje podczas instalacji; później agent ponownie korzysta z najbliższych skonfigurowanych usług, chyba że urządzenie zostanie do nich ręcznie przypisane w Central.

Obraz wzorcowy dla wirtualnych systemów Linux

Zainstalowanego i zarejestrowanego systemu Linux nie wolno klonować bez zmian. Przed zapisaniem szablonu wyrejestruj maszynę wirtualną obrazu wzorcowego z Sophos Fusion. Każdy uruchomiony z niej klon zarejestruje się później automatycznie z własną tożsamością, gdy tylko wystartuje i uzyska dostęp do sieci.

1. W pełni przygotuj system operacyjny i aplikacje na wzorcowej maszynie wirtualnej.
2. W obszarze My Environment > Installers pobierz Linux Server Installer albo XDR Sensor Linux Server Installer odpowiednio do planowanego trybu ochrony.
3. Zainstaluj SPL zgodnie z powyższą instrukcją i sprawdź jego stan.
4. Przejdź do katalogu rejestracji i wyrejestruj wzorcową maszynę wirtualną:

cd /opt/sophos-spl/base/bin/
sudo ./registerCentral --deregister

5. Natychmiast wyłącz maszynę wirtualną i zapisz obraz, gdy jest wyłączona.
6. Nie uruchamiaj ponownie maszyny wzorcowej po wyrejestrowaniu. Ponowne uruchomienie zarejestruje ją ponownie; przed zapisaniem trzeba będzie ponownie ją wyrejestrować.
7. Uruchom co najmniej dwa klony z zapisanego obrazu i sprawdź, czy oba pojawiają się w Central jako oddzielne urządzenia.

Jeżeli miejsce instalacji zostało zmienione opcją --install-dir, katalog sophos-spl znajduje się w podanej ścieżce. Polecenie obrazu wzorcowego trzeba wtedy uruchomić z odpowiedniego katalogu base/bin tej instalacji.

Odbiór instalacji

Pilotaż jest zaliczony dopiero po pomyślnym wykonaniu wszystkich poniższych kontroli:

1. W obszarze My Products > Server > Servers dla każdego hosta widoczny jest dokładnie jeden oczekiwany obiekt urządzenia. Stan, ostatnia aktywność i zainstalowane składniki na stronie szczegółów serwera są wiarygodne.
2. Urządzenie znajduje się we właściwej grupie i otrzymuje zasady serwerowe odpowiednie dla faktycznie zainstalowanych składników. Przy pełnej ochronie przed złośliwym oprogramowaniem musi działać właściwa Server Threat Protection Policy; w przypadku zasad aktualizacji obowiązuje pierwsza pasująca zasada.
3. Usługa działa lokalnie:

sudo systemctl status sophos-spl

4. Tylko z zainstalowanym produktem antivirus: wersja Server Protection wyświetlana w Central odpowiada wersji zgłaszanej lokalnie:

sudo cat /opt/sophos-spl/plugins/av/VERSION.ini

Sophos wskazuje dokładnie ten plik wtyczki AV do porównywania wersji. W przypadku samego XDR Sensor nie wymagaj jego obecności: zamiast tego porównaj na stronie szczegółów serwera faktycznie zainstalowane składniki, wyświetlane wersje, stan i ostatnią aktywność z wybranym trybem sensora, a lokalnie sprawdź połączenie z Sophos Fusion w dzienniku MCS/zarządzania właściwym dla zainstalowanej wersji: /opt/sophos-spl/logs/base/sophosspl/management.log lub, w przypadku pakietów LTS, ewentualnie w starszych dziennikach mcsrouter.log i sophos_managementagent.log. Nazwy i ścieżkę dzienników sprawdź w zainstalowanym pakiecie; nie wnioskuj o działaniu sensora z samej obecności lub braku dziennika czy ścieżki AV.

5. Tylko z zainstalowanym produktem antivirus: dla testu EICAR On-Access w obowiązującej zasadzie Server Threat Protection muszą być włączone zarówno Real-time scanning - Local files and network shares, jak i Enable scan for Server Protection for Linux Agent; ustawienie właściwe dla systemu Linux jest domyślnie wyłączone. Następnie sprawdź wykrycie w /opt/sophos-spl/plugins/av/log/av.log i na stronie podsumowania serwera. Sam XDR Sensor nie zapewnia ani wykrywania złośliwego oprogramowania w tym teście, ani skanowania na żądanie; zamiast tego oddzielnie sprawdź nadal aktywną ochronę innego producenta według jego udokumentowanej procedury.

Zatrzymaj szeroką falę, jeśli brakuje urządzeń, pojawiają się duplikaty, urządzenia pozostają w złym stanie, nie otrzymują oczekiwanych składników lub zasad albo zakłócają działanie krytycznych obciążeń biznesowych.

Zatrzymywanie, wycofywanie lub usuwanie wdrożenia

Wycofanie zaczyna się od zatrzymania dystrybucji. Zatrzymaj nowe przypisania celów i automatyczne ponowienia, odizoluj falę objętą problemem oraz zachowaj ostatni działający stan maszyny wirtualnej, pakietu lub konfiguracji. Odinstalowanie nie przywraca automatycznie usuniętego lub zastąpionego oprogramowania ochronnego innego producenta.

Pełną procedurę lokalnego usuwania, czyszczenia cgroup, weryfikacji, obsługi rekordu w Central i odzyskiwania opisano w artykule Całkowite odinstalowanie Sophos Protection for Linux. Polecenia usuwania pozostaw w tym runbooku zamiast kopiować je do zadania instalacji lub wdrożenia.

Tamper Protection nie jest dostępny dla Sophos Protection for Linux, dlatego nie ma zastosowania do tego wycofania. Mimo to przed zamknięciem zmiany sprawdź pozostałe zasady serwerowe, przywróć przewidzianą ochronę i ustal sposób obsługi rekordu urządzenia w Central.

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

Test --test lub instalacja kończy się niepowodzeniem

Zapisz dokładne polecenie, dystrybucję, jądro, architekturę i wynik. Po wykryciu błędu instalacji Thin Installer automatycznie uruchamia Sophos Diagnostic Utility (SDU) i zapisuje plik sophos_diagnose.tgz w katalogu Thin Installera. Archiwum zawiera dzienniki instalacji i informacje o systemie przeznaczone dla pomocy technicznej Sophos.

Poniższe polecenie uruchamiaj wyłącznie na żądanie pomocy technicznej Sophos albo w ramach kontrolowanego odtwarzania problemu. Ponownie uruchamia instalator, włącza wyjście debugowania powłoki i zachowuje tymczasowy katalog instalacji.

sudo OVERRIDE_INSTALLER_CLEANUP=1 \
  DEBUG_THIN_INSTALLER=1 \
  bash -x ./SophosSetup.sh 2>&1 | tee install.log

OVERRIDE_INSTALLER_CLEANUP=1 zachowuje katalog tymczasowy /tmp/SophosCentralInstall_<uuid>. Dzienniki mogą zawierać nazwy hostów, wewnętrzne ścieżki i szczegóły sieciowe, dlatego przed ich udostępnieniem trzeba sprawdzić zawartość.

Katalog /tmp jest zamontowany z opcją noexec

Nie osłabiaj na stałe zabezpieczeń /tmp. Utwórz odpowiedni wykonywalny katalog tymczasowy i ustaw TMPDIR tylko dla instalatora:

sudo TMPDIR=/var/tmp ./SophosSetup.sh --test
sudo TMPDIR=/var/tmp ./SophosSetup.sh

TMPDIR zmienia wyłącznie miejsce plików tymczasowych, a nie domyślny katalog instalacji /opt/sophos-spl.

Urządzenie nie pojawia się w Sophos Fusion

Najpierw sprawdź DNS, TCP 443, proxy, TLS Inspection i aktualną listę dozwolonych domen. Następnie w dzienniku MCS/zarządzania właściwym dla zainstalowanej wersji wyszukaj wybraną ścieżkę połączenia i potwierdzenie udanego połączenia: /opt/sophos-spl/logs/base/sophosspl/management.log lub, w przypadku pakietów LTS, ewentualnie starsze dzienniki mcsrouter.log i sophos_managementagent.log. Nazwy i ścieżkę dzienników sprawdź w zainstalowanym pakiecie. Sophos pokazuje w aktualnym management.log na przykład komunikaty Successful connection via environment proxy i Connection method: Proxy.

Jeśli niezarządzane jeszcze urządzenie Linux nie może pobrać konfiguracji proxy z Central, Sophos dokumentuje jako rozwiązanie startowe plik z wpisem http_proxy=https://<PROXY_ADDRESS>:<PROXY_PORT>: w systemach opartych na Debianie w /etc/default/sophos-spl, a w RHEL, CentOS i Amazon Linux w /etc/sysconfig/sophos-spl. Następnie wykonaj:

sudo systemctl restart sophos-spl
sudo systemctl status sophos-spl

Na koniec sprawdź dziennik MCS/zarządzania właściwy dla zainstalowanej wersji (w przypadku LTS ewentualnie mcsrouter.log i sophos_managementagent.log).

Pełna ochrona przed złośliwym oprogramowaniem jest zainstalowana, ale Real-Time Scanning nie działa

Tylko z zainstalowanym produktem antivirus: w obszarze My Products > Server > Policies otwórz obowiązującą zasadę Threat Protection. Muszą być włączone zarówno Real-time scanning - Local files and network shares, jak i Enable scan for Server Protection for Linux Agent. Do diagnostyki Sophos wskazuje lokalne pliki zasad /opt/sophos-spl/base/mcs/policy/CORC_policy.xml i /opt/sophos-spl/plugins/av/var/on_access_policy.json oraz dziennik /opt/sophos-spl/plugins/av/log/soapd.log. Dla samego XDR Sensor nie jest to objaw usterki; ochronę przed złośliwym oprogramowaniem musi zapewniać produkt innego producenta.

Niestandardowa ścieżka instalacji nie działa z SELinux Enforcing

Nie obchodź problemu przez użycie --notest ani globalne wyłączenie SELinux. Nowy katalog bazowy nie może być dowiązaniem symbolicznym ani zawierać podkatalogu sophos-spl. Po jego utworzeniu przenieś kontekst SELinux z /opt do nowej ścieżki:

sudo semanage fcontext -a -e /opt <PFAD_ZUM_NEUEN_INSTALLATIONSVERZEICHNIS>

Następnie uruchom instalator ze sprawdzoną opcją --install-dir. Jeśli brakuje polecenia semanage, najpierw zainstaluj pakiet administracyjny SELinux właściwy dla dystrybucji; nie wyłączaj mechanizmu bezpieczeństwa.

Cel skanowania AV nie jest skanowany lub procesy są kończone

Tylko z zainstalowanym produktem antivirus: dla nieskanowanego celu najpierw sprawdź typ i punkt montowania poleceniem findmnt -rn -o TARGET,FSTYPE. W /opt/sophos-spl/plugins/av/log/soapd.log wyszukaj is not supported and will be excluded from scanning. Nie wymuszaj przez --notest systemu automatycznie wyłączonego lub nieudokumentowanego; pozostaw cel poza skanowaniem do czasu użycia aktualnie obsługiwanego typu albo potwierdzenia konkretnej konfiguracji przez Sophos Support.

Przy nieoczekiwanym zakończeniu procesu sprawdź /opt/sophos-spl/logs/base/watchdog.log, a następnie dziennik jądra:

sudo journalctl -k -b

Zachowaj komunikaty oom-kill, Memory cgroup out of memory lub o odrzuconych wartościach wraz z aktywnym cgroup-limits.conf i obciążeniem z chwili błędu. Nie zmieniaj liczb w ciemno: zbyt wysokie limity SPL mogą odebrać zasoby aplikacji, a zbyt niskie zakończyć procesy ochronne. Zmiany wykonuj w oknie serwisowym według lokalnego README; Sophos wymaga zatrzymania sophos-spl.service przed edycją i ponownego uruchomienia po niej. Ponownie sprawdź stan usługi, watchdog.log, dziennik, stan Central i krytyczną aplikację.

Klony współdzielą tożsamość lub szablon pojawia się ponownie

Zatrzymaj wdrożenie. Sprawdź, czy po wykonaniu registerCentral --deregister wzorzec został rzeczywiście wyłączony i zapisany w stanie wyłączonym. Jeżeli został ponownie uruchomiony, wyrejestruj go jeszcze raz przed zapisaniem. Nie używaj wadliwego klonu jako kolejnego szablonu; utwórz go ponownie z prawidłowo przygotowanego obrazu wzorcowego.

Często zadawane pytania