Prawidłowa analiza logów i usług Sophos Endpoint w Windows

Sophos Endpoint w systemie Windows składa się z wielu komponentów ochrony, aktualizacji i komunikacji. Czerwony Health State nie oznacza więc automatycznie awarii całego agenta. Wiarygodna diagnostyka zaczyna się od przypisania objawu do komponentu, a następnie sprawdzenia wyłącznie jego logu w odpowiednim przedziale czasu.

Większość logów operacyjnych znajduje się w C:\ProgramData\Sophos. Logi instalacji są natomiast zwykle zapisane w C:\Windows\Temp, C:\Windows\SystemTemp albo w %TEMP% konta, które uruchomiło instalator. Od nowszych wersji Core Agent niektóre logi interfejsu użytkownika znajdują się w %LOCALAPPDATA%.

Szybki przebieg:

1. Zanotuj czas zdarzenia, strefę czasową i widoczny objaw.
2. W Sophos Endpoint Agent > About > Open Endpoint Self Help Tool sprawdź najpierw Services i Components.
3. Zanotuj platformę, wersję Core Agent i zainstalowane komponenty; licencja i Agent Mode określają oczekiwany stan.
4. Wybierz odpowiedni log poniżej i czytaj od pierwszego istotnego błędu.
5. Po korekcie odśwież Self Help i powtórz ten sam test. Do eskalacji zachowaj również SDU z tego samego przedziału czasu.

W obszarze Computer details > Status Central rozdziela ogólny stan na Communication, Operations, Services, System, Threat i Update. Szczegóły Good, Warning, Bad oraz Info mogą różnić się zależnie od systemu operacyjnego i wersji agenta. Dlatego zawsze powiąż kategorię z problemem z dokładnym komponentem w Endpoint Self Help, zamiast wnioskować o awarii usługi wyłącznie na podstawie ogólnego koloru.

Od objawu do właściwego logu

Nazwy plików i przypisanie usług mogą zmieniać się wraz z wersją Core Agent. Przed oceną porównaj wersję zainstalowanego pakietu z omówieniem aktualizacji Sophos Endpoint i zmian komponentów; w samej diagnostyce kieruj się komponentami właściwymi dla zainstalowanej wersji i plikami rzeczywiście obecnymi na danym urządzeniu.

Updates i AutoUpdate

SophosUpdate.log jest najważniejszym logiem rzeczywistego procesu Update. W aktualnych wspieranych wersjach Windows sau-service.log pokazuje, kiedy Central albo zmieniona Update lub Communication Policy uruchomiła aktualizację. SophosLaunchUpdate.log dokumentuje rozpoczęcie procesu Update.

Błędu Update nie ocenia się wyłącznie na podstawie ostatniego wiersza Error. Najpierw należy sprawdzić:

1. jaki Update Target był rzeczywiście używany,
2. czy uczestniczył dostęp bezpośredni, proxy albo Update Cache,
3. który błąd HTTP lub TLS wystąpił jako pierwszy,
4. czy ten sam czas jest widoczny w logu Firewall lub proxy.

Nieprawidłowe wpisy w pliku Windows Hosts mogą kierować cele Sophos pod błędny adres. Przy powtarzalnych błędach należy porównać SophosUpdate.log, DNS, proxy i równoczesny Packet Capture.

Klasyczna usługa Sophos AutoUpdate Service nie występuje już na nowoczesnym Windows. Jeśli brakuje jej na wyraźnie wspieranej platformie Legacy, napraw z prawami administratora buforowany AutoUpdate MSI i ponownie uruchom About > Update Now. Tej starej procedury MSI nie stosuje się na Windows 10 x64, Windows Server 2016 ani nowszych.

Komunikacja z Central i Policies

Sophos MCS Client utrzymuje połączenie z Sophos Fusion (dawniej Sophos Central). McsClient.log odpowiada na pytanie, czy Endpoint dociera do Central. McsAgent.log pokazuje następnie przetworzone Policies i polecenia. Aktualny czas Last Active w Central jest dobrym wskaźnikiem działania MCS, ale jest aktualizowany najwyżej mniej więcej raz na godzinę.

Przy błędzie komunikacji należy sprawdzić Broker Address, DNS, routing, proxy i Firewall. Po poprawieniu konfiguracji można ponownie uruchomić usługę Sophos MCS Client i odświeżyć Endpoint Self Help. Tamper Protection wyłącza się tylko wtedy, gdy wymaga tego konkretna operacja.

Ochrona, blokady i Cleanup

sed.log jest głównym logiem operacyjnym Sophos Endpoint Defense. Zawiera między innymi dostęp do chronionych kluczy Registry, procesów i plików oraz zablokowane akcje. seds.log pomaga ustalić, czy sterowniki i usługa zostały załadowane.

Dla procesu usuwania zagrożeń istotne są SophosCleanup.log i powiązane Scan_*.log. Pokazują wykryte zagrożenie, wykonaną akcję, kontrolę Safestore i czas trwania. Przed przywróceniem z Safestore należy ustalić, czy plik jest bezpieczny i dlaczego został wykryty.

Pojedynczy wpis w logu nie jest jeszcze podstawą do zezwolenia. Wyjątek tworzy się dopiero po sprawdzeniu pliku, wydawcy, hasha, reputacji i potrzeby biznesowej.

W Splashtop Streamer 3.5.6.0 liczne szybko rotujące i zmieniane logi mogą wypełnić kolejkę skanowania Sophos i zwiększyć CPU oraz RAM. Preferowana jest aktualizacja do 3.5.8.0 lub nowszej i restart. Tylko gdy to niemożliwe, oceń rzeczywistą ścieżkę logu jako wąski wyjątek dla grupy; globalne wykluczenie całego Splashtop jest zbyt szerokie.

Inną przyczyną wysokiego CPU SEDService.exe jest reguła Sysmon File Delete archiwizująca pliki .bin w C:\ProgramData\Sophos. sed.log wielokrotnie wskazuje wtedy archiwum Sysmon. Wyklucz tę strukturę z archiwizacji FileDelete Sysmon, a nie ze skanowania Sophos. Po przeładowaniu Sysmon SEDService.exe powinien przetworzyć otwarte dzienniki i obciążenie powinno spaść.

Windows Security Audit Logging: wolumen i wycofywanie zmian

Enable additional audit policy logging jest domyślnie włączone w Sophos Endpoint Core Agent 2026.1 i Sophos Server Core Agent 2026.1. Lista dodatkowych zdarzeń audytu Windows, której nie można konfigurować indywidualnie, wzbogaca dane na potrzeby wykrywania i Threat Hunting. Zdarzenia te znajdują się w Windows Security Event Log, a nie w tekstowym logu Sophos w C:\ProgramData\Sophos. Opisane tutaj powiązania i wycofywanie zmian dotyczą urządzeń Endpoint z systemem Windows oraz Windows Server; nie opisują funkcji Linux.

Faktycznie stosowaną polityką zarządza się dla Endpoint w Threat Protection, a dla Server w Server Threat Protection. Sam wzrost wolumenu zdarzeń nie jest błędem ochrony. Przed wyłączeniem funkcji sprawdź przechowywanie logów i przetwarzanie w SIEM, ponieważ mniejsza ilość danych audytu ogranicza możliwości badania późniejszych ataków.

Przypisanie zdarzeń do podkategorii audytu

Tabela zawiera angielskie nazwy podkategorii Windows. W niemieckojęzycznej wersji Windows nazwy mogą być inne; w lokalnych poleceniach należy używać identyfikatora GUID ustalonego w sposób opisany poniżej. Identyfikatory wskazują powiązania, a nie plan testów: nie każda rola serwera ani aktywność generuje każde zdarzenie. Do weryfikacji wykorzystuj istniejącą, autoryzowaną aktywność operacyjną; nie wprowadzaj zmian kont, zadań ani usług wyłącznie na potrzeby testu.

Stan początkowy, przechowywanie i zabezpieczenie materiału dowodowego

Przed planowaną zmianą udokumentuj dla każdego urządzenia nazwę polityki i jej przypisanie, wersję Core Agent, rolę serwera, czas zmiany ze strefą czasową oraz osoby odpowiedzialne. Dla każdej objętej zmianą podkategorii zapisz osobno ustawienia audytu sukcesów i niepowodzeń oraz ustal, czy wymagają ich GPO, konfiguracja bazowa zabezpieczeń lub inny produkt. Jeśli funkcja jest już aktywna, nowa kopia dokumentuje tylko bieżący stan, a nie automatycznie stan sprzed zmiany wprowadzonej przez Sophos. Bez wcześniejszej, wiarygodnej konfiguracji i zgody właściciela nie wyłączaj żadnej podkategorii na podstawie przypuszczeń.

Poniższe polecenia są przeznaczone do wykonania w wierszu polecenia Windows uruchomionym jako administrator. Odczytują konfigurację lub zapisują plik kopii zapasowej; nie zmieniają ustawień audytu. C:\Audit-Sicherung to przykład katalogu, który należy wcześniej utworzyć, z ograniczonym dostępem i wystarczającą ilością wolnego miejsca. Przy każdym zbieraniu danych używaj nowej nazwy pliku, aby zachować stan początkowy.

auditpol /get /category:* /r
auditpol /list /subcategory:* /v
auditpol /backup /file:"C:\Audit-Sicherung\audit-vorher.csv"
wevtutil gl Security
wevtutil gli Security

Kopia CSV obejmuje systemowe ustawienia audytu, ustawienia audytu dla użytkowników oraz opcje audytu; nie zastępuje kopii zapasowej GPO. Zabezpiecz wyniki zapytań wraz z dokumentacją zmiany. Na potrzeby późniejszego porównania zapisz z listy identyfikator GUID konkretnej podkategorii wraz z jej nazwą wyświetlaną lokalnie.

wevtutil gl Security pokazuje między innymi maksymalny rozmiar, ścieżkę logu i tryb przechowywania; wevtutil gli Security pokazuje stan logu. Sprawdź log Security w Podglądzie zdarzeń Windows: zapisz najstarszy nadal dostępny znacznik czasu, zdarzenia w ustalonym przedziale porównawczym i dominujące identyfikatory. Przed zmianą i po niej, przy porównywalnym obciążeniu, porównaj liczbę zdarzeń w danym przedziale czasu, lokalnie dostępny okres historii, wolne miejsce oraz tempo napływu danych do SIEM, opóźnienie i odrzucone zdarzenia. Sam rozmiar pliku logu działającego w trybie cyklicznym nie wskazuje, ile historii jest nadal dostępne.

Przy retention:false nowe zdarzenia nadpisują najstarsze po osiągnięciu maksymalnego rozmiaru. Przy retention:true bez automatycznej kopii zapasowej odrzucane są wtedy nowe zdarzenia. autoBackup:true wymaga retention:true; archiwa nadal potrzebują miejsca i kontrolowanych zasad przechowywania. Dlatego nie zmniejszaj rozmiaru logu bez indywidualnej oceny i nie utożsamiaj opcji „nie nadpisuj” z nieograniczonym przechowywaniem. Zmiany maksymalnego rozmiaru, trybu przechowywania lub archiwizacji uzgodnij z osobami odpowiedzialnymi za Windows/SIEM i wcześniej udokumentuj wszystkie trzy wartości początkowe. Podczas wycofywania zmian przywróć dokładnie te wartości we właściwej konfiguracji lokalnej lub GPO i sprawdź je przez wevtutil gl Security. Nie przywróci to zdarzeń, które zostały już nadpisane lub odrzucone.

Przed ingerencją wyeksportuj istotne zdarzenia, zamiast opróżniać Security Log. Również w tym przypadku użyj nowej nazwy pliku i chronionej lokalizacji docelowej z wystarczającą ilością miejsca:

wevtutil epl Security "C:\Audit-Sicherung\Security-vorher.evtx"

Otwórz wyeksportowany plik w Podglądzie zdarzeń i sprawdź wymagany przedział czasu. Dane audytu mogą zawierać informacje o użytkownikach, kontach i aktywności; odpowiednio ogranicz dostęp, przesyłanie i przechowywanie.

Selektywne wycofywanie zmian po wyłączeniu ustawienia w polityce

Najpierw wyłącz Enable additional audit policy logging w faktycznie stosowanej polityce Endpoint Threat Protection lub Server Threat Protection, zapisz zmianę i sprawdź odbiór polityki na urządzeniu. Już włączone ustawienia audytu Windows pozostają aktywne i w razie potrzeby wymagają ręcznego przywrócenia poprzedniego stanu. Nie usuwaj całej polityki audytu: wpłynęłoby to również na ustawienia wymagane niezależnie od Sophos. Nie przywracaj też bez weryfikacji całej kopii CSV, ponieważ od czasu jej utworzenia mogły zostać wprowadzone uzasadnione zmiany.

Dopiero po uzyskaniu zgody osób odpowiedzialnych za Windows/bezpieczeństwo przywróć pojedynczo potwierdzone wcześniejsze wartości podkategorii, których dotyczyła zmiana. Poniższy przykład zmieniający konfigurację ma zastosowanie wyłącznie wtedy, gdy wcześniej audyt sukcesów był włączony, a audyt niepowodzeń wyłączony. Zastąp cały <GUID> ustalonym identyfikatorem GUID podkategorii wraz z {...}; symbol zastępczy nie nadaje się do wykonania. Przed ustawieniem ponownie odczytaj lokalny stan:

auditpol /get /subcategory:"<GUID>"
auditpol /set /subcategory:"<GUID>" /success:enable /failure:disable
auditpol /get /subcategory:"<GUID>"

Dla innych potwierdzonych stanów początkowych dobierz obie wartości niezależnie: enable zachowuje lub włącza dany rodzaj audytu, a disable go wyłącza. Tylko jeśli oba rodzaje były wcześniej wyłączone i żaden inny obowiązujący wymóg ich nie wymaga, należy wyłączyć oba dla tej konkretnej podkategorii. Podkategoria może sterować większą liczbą zdarzeń niż wymienione tutaj identyfikatory; ta zmiana nie jest filtrem pojedynczych Event IDs.

Po każdej zmianie porównaj wartości oczekiwane i rzeczywiste, a później ponownie odczytaj je po standardowym odświeżeniu GPO/produktu oraz sprawdź wymagany przepływ zdarzeń i wolumen logów/danych w SIEM. Jeśli ustawienia zostaną ponownie włączone, najpierw ustal sterujące nimi GPO lub inny produkt zabezpieczający — nie próbuj wielokrotnie przeciwdziałać im lokalnie. Jeśli stan początkowy, odpowiedzialność lub odbiór polityki Sophos pozostają niejasne, wstrzymaj wycofywanie zmian i eskaluj ustalenia dotyczące polityki, agenta, audytu i wolumenu danych. Aby przywrócić dodatkową widoczność, ponownie włącz opcję Sophos i po odbiorze polityki sprawdź stan audytu i przepływ zdarzeń; nie uzupełni to luki w danych powstałej w międzyczasie.

Prawidłowa ocena usług

Self Help rozróżnia Windows SCM Services i Sophos SCM Services. Tylko pierwsza grupa jest zarejestrowana w Windows Service Control Manager i widoczna w services.msc. Sophos SCM Services działają jako procesy, ale nie pojawiają się w tej konsoli. Na nowoczesnych platformach Sophos Live Query, Sophos Health Service i Sophos System Protection Service zostały przeniesione do drugiej grupy od Core Agent 2025.2. Sam brak wpisu w services.msc nie dowodzi więc błędu instalacji.

Sophos opisuje tę konsolidację w 2025.2.1 jako optymalizację wydajności. Diagnostyka musi jednak odpowiadać zainstalowanej wersji Core Agent i właściwemu artykułowi Self Help: bieżący artykuł Services jest wyraźnie przeznaczony dla Core Agent 2026.1, a inne pakiety mogą wymagać innego postępowania. Najpierw sprawdź stan w Self Help; narzędzie wskazuje też, czy usługą zarządza Windows SCM czy Sophos SCM. Procedury naprawcze wymagają praw administratora i wyłączonej Tamper Protection; nie wykonuj ich tylko dlatego, że stara lista usług wygląda inaczej.

W Core Agent 2025.x ten rzadki przypadek może wystąpić po nieudanej aktualizacji funkcji Windows 11 z 23H2 do 24H2 lub 25H2 zakończonej wycofaniem zmian. Równoczesny update DecisionCache może rozbieżnie ustawić rejestr i pliki. Endpoint staje się czerwony, System Protection nie startuje, a C:\ProgramData\Sophos\Endpoint Defense\Logs\SSP.log zgłasza brak wersji reguł.

Nie czekaj do 96 godzin bez System Protection. Tymczasowo przypisz urządzeniu politykę Update Management ze wspieranym pakietem FTS lub LTS. Wywołana w ten sposób ponowna instalacja koryguje powiązania. Usuń urządzenie z przypisania polityki naprawczej dopiero po potwierdzeniu zielonego stanu Health, działania komponentu i aktualnego logu SSP. Ręczna korekta rejestru wymaga Tamper Protection Override, backupu i dokładnie zgodnego katalogu reguł.

Oficjalna lista komponentów i usług zawiera między innymi poniższe powiązania. Tabela pomaga w diagnostyce, ale nie jest pełną listą oczekiwanego stanu każdego urządzenia:

Wymagane komponenty zależą od platformy, Agent Mode i licencji. XDR Sensor instaluje na przykład komponenty telemetrii, ale nie pełną ochronę Sophos przed malware. Najpierw należy więc ustalić oczekiwany stan w Central, a dopiero potem porównać go z usługami i procesami.

Ochrona sieci i Web

SophosNetFilter.log zawiera połączenia z witrynami i akcje Web Control oraz kontroli internetowej w czasie rzeczywistym. SophosIPS.log pokazuje konfigurację i treści wykryć ochrony przed zagrożeniami sieciowymi. SntpService.log zawiera między innymi informacje o Isolation i innych funkcjach sieciowych.

Przy zablokowanej witrynie należy porównać czas, URL, proces i efektywną Policy. Na podstawie samego logu nie zawsze można rozpoznać, czy jako pierwsze zablokowały Endpoint Web Control, DNS Protection czy wcześniejszy Firewall. Te punkty kontroli sprawdza się osobno.

Interfejs użytkownika i Self Help

W aktualnych wersjach Core Agent pliki SophosUI.Net.log i SophosUITray.log znajdują się w:

%LOCALAPPDATA%\Sophos\Sophos UI\Logs

Dokumentują akcje w lokalnym interfejsie oraz przy ikonie na pasku zadań. Od Core Agent 2026.1 logi Self Help mogą być dodatkowo zapisywane dla użytkownika w %LOCALAPPDATA%\Sophos\Endpoint Self Help\Logs. Zależnie od komponentu nadal istotny jest również katalog komputera C:\ProgramData\Sophos\Endpoint Self Help\Logs.

Poprawna analiza logu

Przed otwarciem logu należy określić wąski przedział występowania błędu wraz ze strefą czasową. Następnie czyta się od pierwszego istotnego błędu w przód. Późniejsze błędy następcze, takie jak service unavailable, timeout albo component unhealthy, często są jedynie konsekwencjami.

Wiarygodna notatka zawiera:

• widoczny objaw i powtarzalny test,
• nazwę logu, timestamp i pierwszą istotną wiadomość,
• używaną ścieżkę Endpoint, proxy, Cache lub Relay,
• porównanie z działającym urządzeniem,
• przetestowaną zmianę i mierzalny wynik.

Poziomu logowania nie zwiększa się profilaktycznie na stałe. Szczegółowe logowanie MCS może zawierać wrażliwe dane komunikacyjne i zajmować dodatkowe miejsce. Należy je włączyć tylko na określony czas według aktualnej instrukcji Sophos, a następnie przywrócić standardowy poziom.

Sophos Support może zażądać diagnostic message trail dla MCS. Na Windows 10 x64 lub Server 2016 i nowszych jest on domyślnie aktywny od Core Agent 2023.2; kroki XML służące do jego włączenia i późniejszego wyłączenia dotyczą wyłącznie platform Legacy. Pliki trail mogą zawierać dane polityk i komunikacji, dlatego należy przekazać je bezpiecznie wraz z SDU. Po zebraniu danych wyłącz nagrywanie na platformie Legacy, ponieważ w przeciwnym razie może zapełnić dysk.

Zabezpieczenie logów dla Support

Pojedyncze logi pomagają w lokalnym zawężeniu problemu. Do eskalacji należy dodatkowo utworzyć pakiet SDU z tego samego przedziału czasu. Pakiet może zawierać Hostnames, użytkowników, ścieżki, adresy IP i dane konfiguracyjne, dlatego wymaga chronionego przesyłania.

Pełne zbieranie danych opisuje Diagnozowanie Sophos Endpoint za pomocą Self Help i SDU. Błędy instalacji są osobno omawiane w artykule Systematyczne rozwiązywanie problemów z instalacją Sophos Endpoint w Windows.

Często zadawane pytania