Przypisywanie dzienników usług Sophos Firewall

W Sophos Firewall istnieją trzy ważne poziomy diagnostyki: dzienniki zdarzeń w Log Viewer, narzędzia diagnostyczne w WebAdmin oraz pliki usług i dzienników na zaporze. Log Viewer najlepiej nadaje się do szybkich pytań, takich jak „czy połączenie zostało dozwolone, czy zablokowane?”. Pliki w katalogu /log są ważniejsze, gdy usługa nie uruchamia się, tunel VPN jest niestabilny, filtry internetowe działają nieoczekiwanie lub pomoc techniczna potrzebuje szczegółowych danych.

W tym artykule uporządkowano najważniejsze usługi i pliki dziennika według typowych problemów administracyjnych. Jest on również pomocny, gdy w panelu, Advanced Shell lub zgłoszeniu do pomocy technicznej pojawia się techniczna nazwa usługi i nie jest od razu jasne, z którą funkcją zapory jest związana. Nazwy takie jak zebra, warren, awed, garner lub strongswan nie są oczywiste w codziennej pracy.

Wybór narzędzi i wymagania

Przed przeszukaniem plików dziennika powinno być jasne, które narzędzie zapewnia najszybszą odpowiedź. Wiele przypadków można już zawęzić za pomocą Log Viewer lub Packet Capture. Powłoka staje się naprawdę przydatna tylko wtedy, gdy trzeba sprawdzić samą usługę lub pomoc techniczna potrzebuje szczegółowych danych dziennika.

Które narzędzie do rozwiązywania problemów jest odpowiednie?

Nie każdy problem z zaporą sieciową zaczyna się od powłoki. Inne narzędzie jest często szybsze:

• Połączenie dozwolone czy zablokowane? Testowanie reguły zapory za pomocą Log Viewer, Policy Test i Packet Capture.
• Cały Log Viewer nie pokazuje nowych zdarzeń? Sprawdzanie filtrów, rejestrowania i zależnego od wersji workaroundu z Garner.
• Cały firewall nieoczekiwanie się zrestartował? Najpierw rozróżnić reboot urządzenia, failover HA i awarię usługi, a następnie zabezpieczyć sysinit.log, syslog.log oraz CTR.
• Pakiety docierają, ale nie wiadomo, czy są przekazywane dalej? Używanie Packet Capture w WebAdmin Sophos Firewall.
• Przechwytywanie ma trwać dłużej, zostać zapisane jako PCAP lub przeanalizowane w Wireshark? Sophos Firewall tcpdump: przechwytywanie pakietów przez CLI.
• Podejrzewa się zmianę konfiguracji jako przyczynę? Sprawdzanie dzienników Audit Trail w Sophos Firewall.
• Zmiana z Sophos Fusion (dawniej Sophos Central) utknęła? Sprawdzanie kolejki zadań zapory w Sophos Fusion.
• Potrzebne są raporty lub historia w Sophos Fusion? Włączanie i obsługa Sophos Firewall Central Reporting.
• Dzienniki mają być długoterminowo przechowywane w SIEM, SOC lub na serwerze logów? Wysyłanie danych Syslog z Sophos Firewall do SIEM.
• Przepływ ruchu, szczyty przepustowości lub wzorce komunikacji są w centrum uwagi? Konfiguracja monitorowania sFlow w Sophos Firewall.
• Usługa nie działa lub pomoc techniczna potrzebuje dzienników? Ten artykuł.
• Zabezpieczyć lokalne dzienniki dla pomocy technicznej Sophos lub Avanet? Zabezpieczanie dzienników Sophos Firewall do celów wsparcia i analizy.
• Przygotować zgłoszenie do pomocy technicznej? Otwieranie zgłoszenia do pomocy technicznej Sophos: przygotowanie i portal.

Kolejność ma znaczenie. Log Viewer zwykle najszybciej pokazuje, która reguła lub który moduł podjął decyzję. Packet Capture potwierdza przepływ pakietów w WebAdmin. tcpdump przydaje się, gdy potrzebne jest dłuższe przechwytywanie, plik PCAP lub bardzo precyzyjny filtr CLI. Dzienniki usług i debugowanie pomagają wtedy, gdy problem dotyczy konkretnej usługi albo trzeba zebrać dane dla pomocy technicznej Sophos.

W przypadku pytań dotyczących wyłącznie osiągalności narzędzia Ping, Traceroute oraz wyszukiwanie DNS i tras w Diagnostics > Tools uzupełniają analizę dzienników. Ping sprawdza osiągalność, Traceroute — trasę, a wyszukiwanie — rozwiązywanie nazw lub trasę. Podstawowe polecenia diagnostyczne pomagają wybrać narzędzie; pomyślny test wykonany z zapory nie zastępuje testu z klienta, którego dotyczy problem.

Szybki wybór na podstawie objawów

Jeśli nie jest jasne, który dziennik jest istotny, pomocne może być rozpoczęcie od symptomu, a nie od nazwy usługi.

• Pojedyncze połączenie nie działa: najpierw sprawdzić w Log Viewer źródło, cel, usługę i czas. Następnie użyć Packet Capture, firewall_rule.log i nat_rule.log.
• Tunel VPN nie działa lub jest niestabilny: sprawdzić stan VPN, adres IP peer, czas i Log Viewer. Następnie przeanalizować strongswan.log, charon.log, sslvpn.log oraz dane diagnostyczne IPsec.
• WebAdmin, User Portal lub SSH są niedostępne: sprawdzić Device Access, Local Service ACL oraz odpowiednią strefę. Następnie użyć apache.log, tomcat.log, sshd.log i Packet Capture na porcie docelowym.
• Webfilter, TLS Inspection lub IPS nieoczekiwanie blokuje ruch: sprawdzić moduł w Log Viewer i Policy ID. Następnie porównać ips.log, awarrenhttp.log i Packet Capture.
• Zadanie Sophos Fusion utknęło: porównać kolejkę Central Task Queue ze stanem lokalnym. Następnie sprawdzić centralmanagement.log, sophos-central.log i fwcm-api-executor.log.
• HA zachowuje się inaczej w zależności od węzła: określić aktywny węzeł, węzeł Auxiliary i odpowiednią ścieżkę ruchu. Następnie zalogować się bezpośrednio do węzła, którego dotyczy problem, i sprawdzić dzienniki HA.
• Brakuje raportów lokalnych lub kończy się miejsce na dysku: sprawdzić ustawienia raportów, przestrzeń dyskową i Central Reporting. Następnie użyć reportdb.log, garner.log oraz analizy pamięci masowej.

Takie podejście pozwala uniknąć typowej pułapki: przeszukiwania dziennika usługi, mimo że najpierw należy sprawdzić dopasowanie reguły, Device Access, NAT lub routing.

Log Viewer czy plik dziennika?

Log Viewer otwiera się w prawym górnym rogu konsoli WebAdmin. Widok jest aktualizowany automatycznie, można go filtrować według modułu, czasu, wartości pól i dowolnego tekstu oraz eksportować wpisy w formacie CSV.

Aby chronić nazwy użytkowników oraz adresy IP, MAC i e-mail w codziennym widoku logów, można użyć Data Anonymization dla lokalnych logów i raportów. Działanie w Log viewer nie dowodzi automatycznie, że pliki w /log, CTR, Remote Syslog lub Central anonimizują te same tożsamości; każdą ścieżkę wyjściową sprawdza się oddzielnie.

Dzienniki diagnostyczne znajdują się w katalogu /log. Oficjalnie udokumentowana ścieżka prowadzi przez CLI: zalogować się, wybrać 5 Device Management, a następnie 3 Advanced Shell. SSH jest zwykle wygodniejsze podczas dłuższych sesji z tail, grep lub less. Bezpieczne przygotowanie opisano w Łączenie z Sophos Firewall przez SSH.

Przed dłuższą sesją powłoki trzeba ustalić, z której sieci administracyjnej następuje połączenie, czy zweryfikowano odcisk klucza SSH oraz czy Advanced Shell jest rzeczywiście potrzebny. Do wielu wstępnych testów wystarczą Log Viewer lub Packet Capture w WebAdmin.

Z reguły ta kolejność pomaga:

1. Problem dotyczy pojedynczego przepływu ruchu: filtrować Log Viewer według źródła, celu, usługi i czasu.
2. Log Viewer nie pokazuje żadnej decyzji: uruchomić Packet Capture z wąskim filtrem.
3. Packet Capture pokazuje Incoming, ale nie ma jasnej decyzji: sprawdzić Rule ID, NAT ID, Firewall ID 0, ścieżkę zwrotną i odpowiedni plik dziennika.
4. Określona usługa wydaje się niestabilna: obserwować odpowiedni plik w /log za pomocą tail -f.
5. Błąd występuje sporadycznie lub wymaga pomocy technicznej: przygotować okno czasowe, filtr, archiwum dzienników i w razie potrzeby tcpdump.
6. Zwykłe dzienniki nie wystarczą: włączyć debugowanie tylko dla usługi, której dotyczy problem, i tylko na krótko.

Dzięki temu zakres analizy pozostaje odpowiednio wąski. Najpierw zbiera się widoczne informacje, następnie przechodzi do przepływu pakietów, a dopiero później do dzienników usług lub debugowania. Zmniejsza to ryzyko zbyt wczesnego włączenia rozbudowanego debugowania albo analizy niewłaściwego pliku dziennika.

Odczytywanie plików dziennika w Advanced Shell

Przed wyszukiwaniem w /log należy możliwie najdokładniej udokumentować przypadek testowy: czas lokalny, źródłowy adres IP, którego dotyczy problem, docelowy adres IP, port, użytkownik, moduł i oczekiwane zachowanie. Ta informacja odróżnia użyteczną analizę dziennika od długiego przeszukiwania starych wpisów.

1. Zaloguj się do CLI, wybierz 5 Device Management, a następnie 3 Advanced Shell.
2. Przejdź do katalogu dziennika.

cd /log

Przydatne polecenia:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

Najważniejsze polecenia z Advanced Shell:

• Śledzenie na żywo: tail -f /log/<logfilename>.log, na przykład tail -f /log/ips.log.
• Odczyt statycznego pliku: less /log/<logfilename>.log, na przykład less /log/ips.log.
• Wyszukiwanie terminu: grep <keyword> /log/<logfilename>.log, na przykład grep error /log/ips.log.
• Odczyt stanu usługi: użyć service -S lub zawęzić wynik do nazwy, na przykład service -S | grep ips. Ta kontrola nie zmienia usługi.

Aby zawęzić filtrowanie na żywo, można dodać datę lub adres klienta:

tail -f /log/ips.log | grep 2026-10-10
tail -f /log/ips.log | grep 192.0.2.10
less /log/ips.log | grep error

Data i 192.0.2.10 to wartości przykładowe: należy je zastąpić datą widoczną w dzienniku lub adresem IP klienta, którego dotyczy problem. tail -f pokazuje tylko ostatnie istniejące wiersze i nowo dodawane wpisy, a nie automatycznie całą historię z danego dnia. Do wyszukiwania już zapisanych wpisów można użyć na przykład grep 2026-10-10 /log/ips.log. Jeśli filtr nie zwraca wyników, przed uznaniem, że rejestrowanie nie działa, należy sprawdzić format czasu, strefę czasową, adres IP i plik dziennika. W less /log/ips.log kombinacja Shift+G przenosi na koniec pliku, Enter przechodzi o jeden wiersz dalej, a q kończy wyświetlanie; Ctrl+C kończy bieżące śledzenie za pomocą tail -f. Potok z less zwraca przefiltrowany tekst, a nie interaktywny widok less. Te polecenia odczytują dzienniki, ale nie zmieniają reguł ani stanu debugowania.

Do zgłoszenia serwisowego lub późniejszej analizy nie wystarczy skopiować pojedynczych wierszy dziennika. Lepiej przygotować wyraźny zakres czasu, odtworzony test, odpowiednie zrzuty ekranu z Log Viewer lub Packet Capture oraz, jeśli to konieczne, pełny plik dziennika. Lokalne dzienniki są rotowane, dlatego ważne dane trzeba zabezpieczyć, dopóki zdarzenie znajduje się jeszcze w objętym analizą okresie. Procedurę opisano w artykule Zabezpieczanie dzienników Sophos Firewall do analizy zewnętrznej.

Pobieranie dzienników diagnostycznych w WebAdmin

Nie każdy zestaw dzienników trzeba składać ręcznie w Advanced Shell. WebAdmin zbiera pliki w Diagnostics > Tools.

W praktyce są dwa sposoby:

• Pojedyncze pliki dziennika: otworzyć Diagnostics > Tools > Troubleshooting logs, wybrać odpowiednie pliki dziennika i pobrać je jako archiwum.
• Consolidated Troubleshooting Report (CTR): użyć Diagnostics > Tools > Consolidated troubleshooting report, gdy pomoc techniczna potrzebuje wszystkich dzienników oraz danych o stanie systemu, procesach i zasobach w jednym pakiecie.

Jest to przydatne, gdy wystarczy jasno określony pakiet dzienników. CTR jest lepszym wyborem, gdy pomoc techniczna Sophos potrzebuje obszernej migawki systemu. Należy podać zrozumiały powód, na przykład numer zgłoszenia, przedział czasu lub objaw. Raport jest pobierany w postaci zaszyfrowanej; jego nazwa zawiera również numer seryjny zapory, więc nie powinna trafiać do publicznych załączników.

Domyślnie CTR zawiera 10 000 wierszy na każdy service subsystem log. W Device Console wartość można ustawić tylko w zakresie od 250 do 10 000, czyli jedynie zmniejszyć względem wartości domyślnej. Default subsystem logs zawierają wszystkie wiersze. Limit dotyczy wyłącznie CTR; pełne pojedyncze pliki pozostają dostępne przez Troubleshooting logs lub Advanced Shell.

Ważne: pobrany pakiet dzienników nie zastępuje danych kontekstowych. Pomoc techniczna nadal potrzebuje czasu ze strefą czasową, adresów IP, których dotyczy problem, użytkownika, nazwy tunelu, Rule ID, NAT ID i krótkiego opisu tego, co dokładnie zostało odtworzone.

W przypadku klastrów HA należy również pamiętać: dzienniki i raporty nie są po prostu synchronizowane między głównym i pomocniczym. Każdy węzeł zawiera dzienniki ruchu i usług, które sam przetworzył. W przypadku błędów specyficznych dla węzła należy zatem sprawdzić dany węzeł.

Rozumienie rotacji dzienników i danych ulotnych

Troubleshooting Logs są najpierw tworzone w pamięci, a następnie kopiowane przez zaporę do systemu plików. Jeśli zapora przestanie odpowiadać, wpisy, które nie zostały jeszcze skopiowane, mogą zostać utracone. Nieoczekiwany restart lub zawieszenie nie jest więc powodem, aby odkładać zabezpieczenie materiału; najpierw należy zapisać dostępne dane CTR, dzienniki i oś czasu.

Każdy podsystem ma własne limity rozmiaru i miejsca, zależne od jego krytyczności i modelu urządzenia. Gdy aktywny plik osiągnie limit, SFOS kompresuje go do .gz i kontynuuje zapis pod pierwotną nazwą. Jeśli także rotacje osiągną limit podsystemu, najstarszy skompresowany plik jest usuwany jako pierwszy. Liczba rotacji i głębokość historii nie są więc jednakowe dla wszystkich usług.

Plików dziennika ani rotacji .gz nie należy ręcznie zmieniać nazw ani usuwać. Do analizy miejsca, eksportu i udokumentowanych poleceń purge stosuje się procedurę Kontrolowane zarządzanie miejscem i raportami.

Advanced Shell czy Device Console?

Sophos Firewall ma dwa różne obszary konsoli, które często są mylone:

• Device Console: interfejs CLI Sophos do poleceń specyficznych dla zapory, na przykład priorytetu routingu, tras IPsec lub opcji systemowych.
• Advanced Shell: powłoka zbliżona do systemu Linux do obsługi systemu plików, dzienników i poleceń tylko do odczytu, takich jak tail, grep, less oraz service -S.

Nie każde polecenie działa w obu obszarach. /log, tail -f, grep i service -S należą do Advanced Shell. Udokumentowane polecenia system diagnostics ... dotyczące limitów CTR, czyszczenia dzienników i debugowania podsystemów należą do Device Console.

To rozróżnienie jest ważne, ponieważ wiele błędów wynika po prostu z wpisania prawidłowego polecenia w niewłaściwym miejscu.

Rejestrowanie musi być aktywne

Nie wszystkie oczekiwane informacje pojawiają się automatycznie.

• Log firewall traffic musi być aktywne w regułach zapory.
• Rejestrowanie musi być aktywne w regułach inspekcji SSL/TLS.
• System services > Log settings musi określić, które typy dzienników są wysyłane lokalnie, do Sophos Fusion lub do Syslog.

Do długoterminowego przechowywania przydatny jest serwer Syslog lub Sophos Central Firewall Reporting. Podłączenie zewnętrznych serwerów dzienników lub systemu SIEM opisano w artykule Wysyłanie danych Syslog z Sophos Firewall do SIEM. Dla Sophos Fusion właściwą procedurą jest Włączanie Central Firewall Reporting.

Debugowanie tylko w określonym celu

Rejestrowanie debugowania generuje znacznie więcej danych, zajmuje miejsce i może przechwytywać poufne treści. Nie jest więc rozsądnym pierwszym krokiem. Najpierw należy ustalić zwykły dziennik, przedział czasu i powtarzalny test; debugowania używa się tylko dla odpowiedniego podsystemu i tak krótko, jak to konieczne.

Sophos dokumentuje dwie różne metody. Forma Advanced Shell service <service>:debug -ds nosync przełącza stan i nie przyjmuje osobnego argumentu on ani off. Dla obsługiwanego podsystemu usługi należy preferować jawne polecenia Device Console udokumentowane przez Sophos: system diagnostics subsystems <subsystem> debug on, odtworzyć problem i zebrać dane, a następnie wykonać system diagnostics subsystems <subsystem> debug off. Na przykład nazwa podsystemu dla debugowania Packet Capture to Pktcapd. Debugowanie jest domyślnie wyłączone, ale przed zmianą trzeba sprawdzić, czy inny administrator lub Sophos Support nie zbiera już danych. Zmianę należy odnotować, a po zakończeniu potwierdzić wyłączenie debugowania.

Traktowanie debugowania kontrolera systemowego CSC jako osobnego przełącznika

SFOS 22 dokumentuje osobne polecenie Device Console dla kontrolera systemowego (CSC):

system diagnostics subsystems CSC debug

W odróżnieniu od powyższej składni podsystemu usługi to polecenie nie ma argumentu on ani off: każde wykonanie przełącza debugowanie CSC. Należy traktować je jako kontrolowaną zmianę, a nie zapytanie o stan:

1. Kontrola wstępna: Potwierdzić z innymi administratorami i Sophos Support, że debugowanie CSC nie jest już aktywne ani objęte trwającym zbieraniem danych. Zapisać firewall lub węzeł HA, czas, powód i planowane okno zbierania. Przed zmianą zachować kopię bazową odpowiedniego logu CSC. Nie uruchamiać przełącznika tylko po to, aby poznać jego stan.
2. Włączenie i odtworzenie: W Device Console wykonać polecenie dokładnie jeden raz. Odtworzyć wyłącznie zawężony problem i zapisać czas testu ze strefą czasową.
3. Zabezpieczenie dowodów: Przed rollbackiem pobrać odpowiedni pojedynczy log diagnostyczny albo wygenerować CTR i pobrać gotowy plik CTR. Ograniczyć dostęp do zaszyfrowanego CTR i archiwów logów, ponieważ mogą zawierać dane poufne; nie czyścić ani nie nadpisywać dowodów potrzebnych w sprawie.
4. Wyłączenie / rollback: Wrócić do Device Console i wykonać to samo polecenie dokładnie jeden raz. To drugie, zaplanowane wykonanie ponownie wyłącza debugowanie CSC.
5. Weryfikacja: Przeprowadzić krótki kontrolowany test i potwierdzić w nowych wierszach logu CSC, że dane poziomu debug przestały się pojawiać, a log rośnie znów w zwykłym tempie. Zapisać czas i wynik rollbacku. Jeśli stan początkowy lub kontrola końcowa są niejednoznaczne, nie powtarzać przełącznika; zatrzymać się i uzgodnić stan z Sophos Support.

⚠️ Debugowanie WAF i reverseproxy.log: w SFOS 22.0 MR2 Build 546 Sophos usunął błąd NC-177457, przez który przy włączonym debugowaniu WAF hasło było widoczne w reverseproxy.log. Sophos nie podaje ani początku zakresu wersji, których dotyczył błąd, ani rodzaju hasła. Dlatego wcześniej utworzone dzienniki debugowania WAF, archiwa diagnostyczne i pliki CTR ze starszych lub nieznanych kompilacji należy traktować jako potencjalnie zawierające dane logowania.

Jeśli zostaną znalezione dane logowania w postaci jawnego tekstu: ograniczyć dostęp, udokumentować incydent i zmienić dane logowania, których dotyczy problem. Nie usuwać logów bez rozróżnienia przed wyjaśnieniem wymagań pomocy technicznej, analizy śledczej i retencji.

Debugowanie i podstawowe polecenia CLI opisano szerzej w artykule Diagnostyka Sophos Firewall przez CLI: ważne polecenia. Przy ponownym uruchamianiu pojedynczych usług pomocny jest również artykuł Bezpieczne ponowne uruchamianie usług Sophos Firewall.

Typowe błędy wyszukiwania dzienników

Wiele analiz dzienników zajmuje dużo czasu nie z powodu brakujących danych, ale dlatego, że zbyt wcześnie przeszukano niewłaściwe narzędzie.

• Natychmiastowe włączenie debugowania: najpierw sprawdzić Log Viewer, odpowiedni plik dziennika i powtarzalny test.
• Wyszukiwanie tylko komunikatów o błędach: dodatkowo zawęzić źródło, cel, użytkownika, Rule ID, NAT Rule ID i czas.
• Ignorowanie Packet Capture: jeśli nie jest jasne, czy pakiety w ogóle docierają lub są przekazywane dalej, należy wcześnie użyć Packet Capture.
• Traktowanie Central Reporting jako debugowania na żywo: Central Reporting służy do historii i raportów, a lokalne dzienniki do szczegółowej analizy.
• Zabezpieczanie dzienników dopiero kilka dni później: dzienniki, czas i kroki odtwarzania trzeba zapisać, dopóki zdarzenie nadal można prześledzić.
• Pozostawienie debugowania po teście: ponownie wyłączyć debugowanie i sprawdzić dostępną przestrzeń dyskową.

Dobry przypadek rozwiązywania problemów zawsze składa się z trzech elementów: dokładnego testu, odpowiedniego źródła dziennika i udokumentowanego czasu. Bez tej podstawy można zobaczyć wiele linii logu, ale niekoniecznie przyczynę.

Pliki dziennika według obszaru funkcjonalnego

Poniższe listy mają służyć jako przewodnik referencyjny. Najlepiej najpierw wybrać obszar funkcjonalny, którego dotyczy problem, a następnie sprawdzić odpowiedni plik dziennika w wąskim oknie czasowym.

Podstawowe przypisania uwzględniają SFOS 22.0 i 23.0; pliki OAuth SSO różnią się między tymi wersjami, zgodnie z informacjami poniżej. W starszych instalacjach lub dawnych archiwach pomocy technicznej mogą dodatkowo występować wcześniej używane nazwy app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log i crreportdb.log. Sophos nie wymienia ich na uwzględnionych tutaj listach dzienników SFOS 22/23, dlatego nie należy zakładać ich obecności w aktualnej kompilacji.

Oprócz dzienników danego modułu sprawdza się także ogólne dzienniki systemowe i konfiguracyjne. Jeden plik może obsługiwać kilka funkcji: decydujące jest jego znaczenie w kontekście konkretnego problemu, a nie tylko nazwa usługi.

System, zarządzanie i usługi podstawowe

• Uruchamianie systemu: sysinit.log; sprawdzić w pierwszej kolejności przy problemach z rozruchem i trybem Failsafe.
• Komunikaty systemowe na poziomie jądra: syslog.log; dodatkowo sprawdzić czas, restart i zdarzenia interfejsów. Porównać także zdarzenia systemowe i zdarzenia wywołane przez administratora w Log Viewer.
• Serwer WWW Apache dla WebAdmin i User Portal: apache.log, apache_access.log i error_log.log; dodatkowo sprawdzić Device Access i Local Service ACL.
• Aplikacja WebAdmin i User Portal: serwer aplikacji internetowych Jetty, plik dziennika tomcat.log; dodatkowo sprawdzić błędy GUI, wysokie obciążenie i stan usługi. Nazwa pliku nie jest nazwą aktualnego serwera aplikacji internetowych.
• SSH: sshd.log; dodatkowo sprawdzić Device Access, sieć źródłową i logowanie kluczem publicznym.
• Błędy GUI/CLI: error_log.log; dodatkowo sprawdzić ostatnią zmianę, przeglądarkę i działanie administratora.
• Zmiany konfiguracji: applog.log, csc.log; dodatkowo sprawdzić Audit Trail i Config Studio.
• Baza danych konfiguracji: postgres.log; dodatkowo sprawdzić wolne miejsce, tworzenie/odtwarzanie kopii zapasowych i zgłoszenie do pomocy technicznej.
• Kanał komunikacji między określonymi komponentami a ich usługami: garner.log; w przypadku Central Management i raportowania dodatkowo sprawdzić wpisy odpowiednich wtyczek.
• API: apiparser.log; dodatkowo sprawdzić validation.log, ACL dla API, token i Central Task Queue.
• Walidacja: validation.log, validationError.log; dodatkowo sprawdzić nieprawidłowe obiekty lub importy.
• Licencjonowanie: licensing.log; dodatkowo sprawdzić stan licencji, synchronizację z Central i szczególny przypadek Air Gap.
• Aktualizacje systemu: u2d.log; dodatkowo sprawdzić stan sygnatur, DNS/HTTPS i wolne miejsce.

W przypadku problemów z zarządzaniem nie wystarczy sprawdzić pliku dziennika WebAdmin. Bardzo często to Device Access, reguła Local Service ACL Exception Rule lub nieprawidłowa sieć źródłowa decydują, czy WebAdmin, SSH, User Portal, VPN Portal, DNS lub SNMP są dostępne. W tej części lepiej zacząć od artykułu Bezpieczny dostęp do Sophos Firewall: prawidłowa konfiguracja Device Access.

Zapora sieciowa, NAT i Packet Capture

• Dopasowywanie reguł zapory: firewall_rule.log; dodatkowo sprawdzić moduł Firewall w Log Viewer.
• Dzienniki zapory dotyczące połączeń: fwlog.log; ich tworzenie zależy od rejestrowania w regule zapory i Log settings. Dodatkowo użyć Packet Capture.
• Reguły NAT: nat_rule.log; dodatkowo sprawdzić NAT Rule ID w Log Viewer.
• DNAT z równoważeniem obciążenia łączy: dodatkowo sprawdzić dgd.log, jeśli w grę wchodzi wybór bramy lub łącza.
• Packet Capture w WebAdmin: pktcapd.log; dodatkowo sprawdzić Diagnostics > Packet capture.
• Zarządzanie przepustowością / QoS: bwm.log; dodatkowo sprawdzić Traffic Shaping Policy.
• Virtual Host / starszy mechanizm publikowania serwerów: vhost.log; dodatkowo sprawdzić NAT i WAF.
• Web Server Protection / WAF: reverseproxy.log; niektóre szczegóły konfiguracji WAF znajdują się także w firewall_rule.log. Sprawdzić regułę WAF, Hosted address i osiągalność serwera backendowego.

NAT to nie tylko kwestia nat_rule.log: ustawienie NAT połączenia Site-to-Site IPsec sprawdza się w charon.log, a polecenie NAT wykonane przez CLI — w applog.log. Pozwala to odróżnić konfigurację tunelu od zwykłej reguły NAT.

W przypadku problemów z DNAT zawsze trzeba sprawdzić razem regułę zapory i regułę NAT. NAT jedynie tłumaczy adresy, ale nie zezwala na ruch. Więcej informacji: NAT w Sophos Firewall: SNAT, DNAT, MASQ i PAT.

Sophos Firewall używa między innymi IP tables, ARP table, IPset i conntrack do obsługi połączeń zapory. IMQ służy do zarządzania QoS lub przepustowością. Informacje te są przydatne, gdy komunikaty dziennika lub dane diagnostyczne od pomocy technicznej zawierają terminy techniczne ze ścieżki sieciowej systemu Linux.

IPS, Application Control i TLS Inspection

• Zapobieganie włamaniom: Usługa ips, plik dziennika ips.log.
• Application Control: Usługa ips / Application Filter, plik dziennika ips.log.
• DPI i TLS Inspection: Silnik DPI, plik dziennika ips.log.
• Antywirus w ścieżce sieciowej: Usługa avd, plik dziennika avd.log.
• Zero-Day Protection / Sandbox: usługa Sandbox, plik dziennika sandboxd.log.
• Active Threat Response / X-Ops Threat Feeds: ATR w ścieżce sieciowej; najpierw Log Viewer, a zależnie od modułu dodatkowo ips.log.
• MDR Threat Feeds: stan feedu ATR/MDR, plik dziennika atr.log; przewodnik operacyjny koreluje Audit ID, Task Queue i lokalny dowód ruchu.
• Aktualizacje sygnatur: Signature Updater, plik dziennika sig_upgrade.log.
• Migracja sygnatur: migracja sygnatur, plik dziennika sigmigration.log.

appcached.log zawiera także tymczasową pamięć podręczną skategoryzowanych aplikacji przed ich zapisaniem w bazie danych; jego zastosowanie w Application Based Routing opisano poniżej. W przypadku MDR i źródeł informacji o zagrożeniach od innych dostawców atr.log pokazuje stan licencji i konfiguracji; sam nie potwierdza decyzji dotyczącej ruchu. Dla IoC w postaci adresów IP dodatkowo sprawdza się firewall_rule.log. W przypadku IoC w postaci domen lub adresów URL należy analizować łącznie dzienniki zapory, DNS, inspekcji SSL/TLS i Web Proxy: firewall_rule.log, dnsd.log, ips.log, httplogd.log oraz, zależnie od ścieżki przetwarzania, awarrenhttp.log. Uczestniczące moduły realizują Active Threat Response zależnie od typu IoC.

Wiele nowoczesnych funkcji ochronnych uzyskuje wystarczającą ilość informacji dopiero po odszyfrowaniu HTTPS. Jeśli TLS Inspection nie jest stosowana, filtrowanie stron, Application Control, IPS i skanowanie złośliwego oprogramowania mogą być mniej miarodajne, zależnie od rodzaju ruchu.

Jeśli nie jest jasne, czy IPS jest aktywny, która polityka ma zastosowanie lub dlaczego sygnatura blokuje ruch, najpierw pomaga artykuł Konfiguracja i bezpieczne testowanie IPS w Sophos Firewall. Następnie można precyzyjniej skorelować ips.log, Log Viewer i Packet Capture.

W przypadku rozpoznawania aplikacji, Application Filter lub nieoczekiwanych blokad Application Control należy najpierw skorzystać z artykułu Konfiguracja i testowanie Application Control w Sophos Firewall.

W przypadku Zero-Day Protection trzeba również sprawdzić, czy Web Protection, TLS Inspection, typ i rozmiar pliku, polityka oraz działanie są odpowiednio skonfigurowane. Właściwy artykuł operacyjny to Zrozumienie i obsługa Zero-Day Protection w Sophos Firewall. Dla Threat Feeds odpowiedni jest artykuł Bezpieczna konfiguracja i obsługa Threat Feeds w Sophos Firewall. Więcej o TLS Inspection: Wdrażanie TLS Inspection w Sophos Firewall krok po kroku.

WWW, proxy, WAF i filtrowanie stron

• HTTP i HTTPS przez Web Proxy: usługa awarrenhttp, plik dziennika awarrenhttp.log.
• Dostęp przez proxy HTTPS: dziennik dostępu awarrenhttp, plik dziennika awarrenhttp_access.log. W SFOS 22/23 pojedyncze żądania Web Proxy pojawiają się tutaj tylko wtedy, gdy awarrenhttp działa z włączonym debugowaniem; należy przestrzegać opisanej poniżej procedury zbierania danych.
• Kategoryzacja i reputacja stron internetowych: usługa nSXLd, plik dziennika nSXLd.log.
• Aktualizacje kategorii (SFOS 22/23): plik dziennika catUpdateLog — należy zwrócić uwagę na wielkość liter; nazwa nie ma rozszerzenia .log.
• FTP przez proxy HTTP: usługa skein, plik dziennika skein.log.
• Proxy FTP: usługa ftpproxy, plik dziennika ftpproxy.log.
• Web Application Firewall: Reverse Proxy, plik dziennika reverseproxy.log.

Przed zebraniem tego dziennika dostępu określić właściwy węzeł zapory/HA, przypadek testowy, czas i krótki przedział zbierania danych, sprawdzić miejsce na dysku oraz potwierdzić z innymi administratorami lub pomocą techniczną, że debugowanie jest wyłączone. Nie używać polecenia przełączającego do sprawdzania stanu. Następnie wykonać service awarrenhttp:debug -ds nosync dokładnie raz w Advanced Shell, odtworzyć zawężony problem i bezpiecznie zapisać awarrenhttp_access.log. Potem wykonać to samo polecenie dokładnie raz, aby ponownie wyłączyć debugowanie. Krótkim, kontrolowanym testem sprawdzić, że nie pojawiają się nowe wpisy debugowania, a zwykły dziennik znów rośnie w normalnym tempie; udokumentować przywrócenie stanu i kontrolę miejsca na dysku. Jeśli stan początkowy lub wynik kontroli końcowej jest niejasny, nie przełączać dalej, lecz wyjaśnić to z pomocą techniczną. Ta metoda dotyczy tutaj awarrenhttp w SFOS 22/23, a nie ogólnie wszystkich usług lub wydań.

Przy podejrzeniu pętli proxy parametr block_proxy_loop wraz z krótko włączonym debugowaniem awarrenhttp może wygenerować Duplicate Via header values, proxy loop. Bezpieczne sprawdzanie ustawień HTTP Proxy opisuje warunek, globalne działanie i bezpieczne wycofanie. Debugowanie pozostaje aktywne tylko podczas odtwarzalnego testu, a następnie zostaje ponownie wyłączone.

Jeśli ruch internetowy jest blokowany w Log Viewer, przyczyna może leżeć w kilku modułach: Web Policy, inspekcji SSL/TLS, Application Control, IPS lub WAF. Dlatego zawsze trzeba wybrać konkretny moduł w Log Viewer i sprawdzić także odpowiedni plik dziennika.

Sophos zawsze blokuje strony internetowe z kategorii highly objectionable criminal activity i ukrywa nazwę domeny w dziennikach i raportach. Nie jest to domyślna akcja, którą można dowolnie wybrać. Jeśli wpis z tego obszaru wygląda na celowo zanonimizowany, może to więc być zamierzone.

Informacje o kategoriach internetowych, grupach URL, politykach WWW i Instant Alerts zawiera artykuł Używanie kategorii internetowych i Instant Alerts w Sophos Firewall.

VPN

• IPsec od SFOS v17+: usługi strongswan, charon; pliki dziennika strongswan.log, charon.log.
• IPsec dla konkretnego połączenia: pojedyncze połączenie IPsec, plik dziennika /log/ipsec_conn/ipsec_<connectionname>.log.
• IPsec w starszych wersjach: usługa IPsec, plik dziennika ipsec.log.
• Monitorowanie IPsec: IPsec Monitor, plik dziennika ipsec_monitor.log.
• XFRM / VPN oparty na trasach: Usługa xfrmi, plik dziennika xfrmi.log.
• SSL VPN: SSL VPN / OpenVPN, plik dziennika sslvpn.log.
• SSL VPN Status: Status OpenVPN, plik dziennika openvpn-status*.log.
• VPN Portal: Plik dziennika vpnportal.log.
• L2TP: Usługa l2tpd, plik dziennika l2tpd.log. L2TP Remote Access na Sophos Firewall opisuje konfigurację i diagnostykę.
• PPTP: PPTP VPN, plik dziennika pptpvpn.log.
• Certyfikaty VPN: usługi certyfikatów VPN, plik dziennika vpncertificate.log.
• Bez klienta SSL VPN: Dostęp bez klienta, plik dziennika clientless_access.log.

Sophos Firewall używa strongSwan dla IPsec VPN i OpenVPN dla SSL VPN. W przypadku problemów z IPsec kluczowe znaczenie mają czas, adres IP peera, Proposal, podsieci lokalne i zdalne, NAT-T, routing oraz reguły zapory.

Te implementacje dotyczą zarówno Site-to-Site, jak i Remote Access. /log/ipsec_conn/ipsec_<connectionname>.log zawiera przede wszystkim działania WebAdmin dotyczące konkretnego połączenia: włączanie, wyłączanie i zestawianie tunelu; <connectionname> należy zastąpić rzeczywistą nazwą połączenia. W przypadku uwierzytelniania użytkowników VPN dodatkowo sprawdzić access_server.log, a przy problemach z portalem — vpnportal.log. Przy problemach z klientem Sophos Connect do materiału diagnostycznego należy także dołączyć raport pomocy technicznej klienta: same dzienniki zapory nie pokazują pełnego stanu klienta. Procedura rozwiązywania problemów z IPsec pomaga zestawić wyniki diagnostyki klienta i zapory.

W przypadku problemów z IPsec lepszym przewodnikiem krok po kroku jest artykuł Rozwiązywanie problemów z IPsec w Sophos Firewall. W przypadku VPN opartej na trasach i ręcznych tras IPsec pomaga artykuł Tworzenie trasy IPsec w Sophos Firewall.

Uwierzytelnianie, User Portal i SSO

• Uwierzytelnianie, autoryzacja i rozliczanie użytkowników: Access Server / AAA, plik dziennika access_server.log.
• NTLM / NASM: usługa nasm, plik dziennika nasm.log.
• Chromebook SSO: backend Chromebook SSO, plik dziennika chromebook-sso-backend.log.
• Przebieg Chromebook SSO: csd.log; należy odróżnić go od dziennika backendu.
• OAuth SSO Captive Portal (SFOS 22): plik dziennika oauth_sso_captive.log.
• OAuth SSO WebAdmin (SFOS 22): plik dziennika oauth_sso_webadmin.log.
• OAuth SSO VPN (SFOS 22): plik dziennika oauth_sso_vpn.log.
• OAuth SSO (SFOS 23): oauth_sso_svc.log dla logowań SSO do WebAdmin, Captive Portal, VPN Portal, IPsec VPN i SSL VPN.
• RADIUS SSO: przypisanie użytkownika do adresu IP za pomocą Accounting w access_server.log. Konfigurację i weryfikację opisano w artykule RADIUS SSO z Accounting.
• STAS: kontekst STAS / Access Server, zależnie od kontekstu usługi, oraz access_server.log.

W przypadku reguł użytkowników zawsze najpierw trzeba sprawdzić, czy użytkownik jest w ogóle rozpoznawany. Jeśli Match known users jest aktywne, a uwierzytelnianie nie działa, reguła nie zostanie dopasowana. Dla klasycznych logowań w przeglądarce artykuł Konfiguracja i testowanie Captive Portal w Sophos Firewall łączy Device Access, regułę użytkownika, Live users, Log Viewer oraz access_server.log w kompletną procedurę sprawdzania.

Jeśli nadal nie wiadomo, czy zawodzi wybór usługi, tożsamość, Main Group, limit czy dopiero późniejsza ścieżka ruchu, artykuł Systematyczne rozwiązywanie błędów uwierzytelniania na Sophos Firewall łączy te warstwy w jedną procedurę diagnostyczną.

Gdy Captive Portal korzysta z Microsoft Entra ID SSO, artykuł Konfiguracja Microsoft Entra ID SSO dla Captive Portal w Sophos Firewall pomaga skorelować oauth_sso_captive.log (SFOS 22; w SFOS 23: oauth_sso_svc.log), Device Access, grupy i późniejsze dopasowanie reguł.

DNS, DHCP i sieć

• Usługa DNS: usługa dnsd, plik dziennika dnsd.log.
• Usługa Wildcard FQDN / DNS Grabber: usługa dnsgrabber, plik dziennika dnsgrabber.log.
• DNS Entity / pozostałe komponenty DNS: usługi entity, eacd; pliki dziennika entity.log, eacd.log.
• DHCP IPv4: usługa dhcpd, plik dziennika dhcpd.log.
• DHCP IPv6: plik dziennika dhcpd6.log.
• Interfejsy fizyczne i wirtualne: usługa networkd, plik dziennika networkd.log.
• Hosty FQDN: usługa fqdnd, plik dziennika fqdnd.log.
• Dead Gateway Detection i zarządzanie WAN/bramami: usługa dgd, plik dziennika dgd.log; sprawdzić także przełączanie awaryjne łączy i VPN oraz DNAT.
• Dynamiczny DNS: klient Dynamic DNS, plik dziennika ddc.log.
• Klient NTP: plik dziennika ntpclient.log.
• IPv6 Router Advertisement: usługa radvd, plik dziennika radvd.log.

Problemy DNS i DHCP często wyglądają jak problemy z zaporą ogniową. Dlatego też należy najpierw sprawdzić adres IP, bramę, serwer DNS oraz to, czy klienci powinni używać firewalla jako serwera DNS czy DHCP.

Jeśli domeny wewnętrzne nie są prawidłowo rozwiązywane, zwykle pomaga artykuł Konfiguracja tras żądań DNS w Sophos Firewall. Specjalne opcje DHCP opisano osobno w artykule Konfiguracja opcji DHCP w Sophos Firewall.

Komórkowy WAN

• WWAN / modem USB: sprawdzić podłączanie i odłączanie urządzeń USB w modemd.log.
• Konfiguracja sieci modemu: sprawdzić interfejsy związane z modemem i konfigurację IP w networkd.log.
• USB, modem i PPP: sprawdzić komunikaty Syslog dotyczące USB, modemu i protokołu Point-to-Point w syslog.log.

W przypadku problemów z komórkowym WAN należy także sprawdzić, czy modem został rozpoznany, czy ustawienia PIN, SIM i APN są prawidłowe oraz czy zapora tworzy odpowiednią bramę.

Trasowanie

• Statyczne trasy unicast: plik dziennika staticd.log. Konfigurację i sprawdzanie opisano w artykule Konfigurowanie trasy statycznej w Sophos Firewall.
• Instalowanie statycznych tras unicast IPv4: usługa zebra, plik dziennika zebra.log.
• Routing oparty na aplikacjach: usługa appcached, plik dziennika appcached.log.
• Routing multicast: plik dziennika mrouting.log.
• BGP i BGP-IPv6: usługa bgpd, plik dziennika bgpd.log. Konfigurację i weryfikację opisano w artykule Konfigurowanie BGP w Sophos Firewall; zebra.log dodatkowo pomaga sprawdzić, czy poznana dynamiczna trasa IPv4 lub IPv6 została zainstalowana w jądrze.
• OSPFv2 i OSPFv3: usługi ospfd i ospf6d, pliki dziennika ospfd.log i ospf6d.log. To, czy dynamiczna trasa została dodana do systemu, pokazuje dodatkowo zebra.log. Konfigurację i weryfikację opisano w artykule Konfigurowanie OSPF w Sophos Firewall.
• RIP: usługa ripd, plik dziennika ripd.log. Konfigurację i weryfikację opisano w artykule Konfigurowanie RIPv2 w Sophos Firewall; zebra.log dodatkowo pokazuje, czy poznana trasa została zainstalowana w stosie routingu.
• PIM-SM: usługa pimd, plik dziennika pimd.log. Konfigurację i weryfikację opisano w artykule Konfigurowanie PIM-SM w Sophos Firewall.

W przypadku problemów z routingiem trzeba również sprawdzić Routing > SD-WAN routes, bramy i Packet Capture. Policy Tester nie zastępuje rzeczywistego testu routingu.

W przypadku tras statycznych i dynamicznych csc.log dostarcza dodatkowo informacji o kodach operacji (Opcode) i restartach usług. W kontekście HA uzupełnia się analizę o ha.log, msync.log i applog.log. Przy trasach SD-WAN oprócz appcached.log sprawdza się także applog.log, csc.log i dgd.log; jeśli w grę wchodzi IPsec, dołącza się dzienniki IPsec.

Więcej informacji: Ustawianie priorytetu routingu w Sophos Firewall.

GUI, CLI i dostęp do systemu

W przypadku WebAdmin, SSH, API i lokalnych usług zarządzania podstawowa lista znajduje się powyżej w sekcji System, zarządzanie i usługi podstawowe. Jeśli WebAdmin lub SSH nie są dostępne, nie należy sprawdzać wyłącznie apache.log, tomcat.log lub sshd.log. Dostęp lokalny jest kontrolowany przez Administration > Device access i Local Service ACL.

Więcej informacji: Łączenie z Sophos Firewall przez SSH.

Sophos Fusion, Security Heartbeat i zarządzanie centralne

• Sophos Central Management: Central Management, pliki dziennika centralmanagement.log, sophos-central.log.
• CSC i usługi pomocnicze: usługi csc, cschelper, csd; pliki dziennika csc.log, cschelper.log, csd.log. cschelper.log dotyczy wiadomości e-mail generowanych przez system i narzędzi uwierzytelniania, a csd.log — przebiegu Chromebook SSO.
• Security Heartbeat i Synchronized Security: heartbeatd.log zawiera stan urządzeń końcowych i informacje o aplikacjach przesyłane do zapory; hbtrust.log — komunikację z Central. Usługi noszą nazwy heartbeatd i hbtrust; dodatkowo sprawdzić csc.log i applog.log.
• Synchronized Application Control: sprawdzić dane przesyłane do SophosLabs w sac-feedback.log.
• Optymalizacja bazy danych SAC (SFOS 22/23): sac-vacuum.log rejestruje cotygodniową optymalizację bazy danych Synchronized Application Control; sac-feedback.log pozostaje osobnym dziennikiem danych przesyłanych do SophosLabs.
• Zdarzenia Central, połączenie i przesyłanie konfiguracji: fwcm-eventd.log pokazuje przesyłane informacje o strefach/interfejsach dla obiektów dynamicznych, fwcm-heartbeatd.log — połączenie, a fwcm-updaterd.log — przesłaną konfigurację. Usługi noszą nazwy fwcm-eventd, fwcm-heartbeatd i fwcm-updaterd; nie wszystkie trzy są usługami Heartbeat.
• Central API Executor: usługa fwcm-api-executor, plik dziennika fwcm-api-executor.log.
• Active Threat Response: kontekst ATR; sprawdzić zależnie od wersji i modułu.

W przypadku problemów z Sophos Fusion najpierw trzeba sprawdzić, czy zapora jest zarejestrowana, usługi Central są aktywne oraz czy wychodzące połączenia DNS/HTTPS działają. Jeśli zmiana z Sophos Fusion nie dociera lokalnie, należy porównać kolejkę zadań zapory w Sophos Fusion z lokalnymi dziennikami. Sam zielony status w Sophos Fusion nie dowodzi, że konkretna polityka została przetworzona lokalnie.

Dla rejestracji i tokenów dostępu istotny jest sophos-central.log, a dla włączonego zarządzania i raportowania — centralmanagement.log. Rejestrację i wyrejestrowanie dodatkowo porównuje się z applog.log, a aktualizacje firmware — z csc.log. hbtrust.log pokazuje komunikację; w garner.log wpisy wtyczki SCM dotyczą Central Management, a wpisy wtyczki CR — Central Reporting. fwcm-api-executor.log zawiera także analizy MDR przesłane do zapory. Uwzględniona dokumentacja SFOS 22 nazywa platformę Sophos Fusion (dawniej Sophos Central), a dokumentacja SFOS 23 — Sophos Central; istniejące nazwy usług i plików pozostają bez zmian.

Wysoka dostępność

• Stan i konfiguracja HA: dziennik aplikacji HA, plik dziennika applog.log.
• Wykrywanie urządzenia partnerskiego HA w QuickHA: usługa ha_pair, plik dziennika ha_pair.log.
• Tunel SSH między urządzeniami HA przez dedykowane łącze: usługa ha_tunnel, plik dziennika ha_tunnel.log.
• Synchronizacja Conntrack: usługa ctsyncd, plik dziennika ctsyncd.log.
• Msync: usługa msync, plik dziennika msync.log.
• Zestawianie HA i zmiany stanu: ha.log.
• Synchronizacja plików wybranych usług z urządzeniem Auxiliary: filesync.log.

Dzienniki i raporty HA nie są synchronizowane między urządzeniami. Każdy węzeł przechowuje wyłącznie dane dotyczące ruchu, który sam przetworzył. Dlatego Log Viewer i Diagnostics > Tools > Troubleshooting logs trzeba sprawdzić na każdym urządzeniu, którego dotyczy problem. Aby pobrać dzienniki diagnostyczne urządzenia pomocniczego, należy zalogować się bezpośrednio do jego CLI przez adres IP lub FQDN interfejsu administracyjnego. Sophos Central Firewall Reporting może łączyć raporty obu urządzeń, ale nie zastępuje lokalnych plików diagnostycznych poszczególnych węzłów.

Poczta i ochrona przed spamem

• Ochrona antywirusowa: usługa AV, plik dziennika avd.log.
• Aktualizacje antywirusowe: Up2Date AV, plik dziennika up2date_av.log.
• Ochrona antyspamowa: usługa sasi, plik dziennika sasi.log.
• Sandbox: usługa sandboxd, plik dziennika sandboxd.log.
• SMTP MTA: usługa smtpd, plik dziennika smtpd_main.log.
• Błędy SMTP w trybie MTA: smtpd_error.log dla błędów skanowania poczty, smtpd_panic.log dla błędów wewnętrznych i smtpd_reject.log dla odrzuconych wiadomości e-mail; usługa to smtpd.
• Proxy SMTP/S w trybie Legacy: usługi awarrensmtp, awarrenmta; pliki dziennika awarrensmtp.log, awarrenmta.log. Konfigurację i test end-to-end opisano w artykule Mail Protection w trybie Legacy.
• Proxy POP/IMAP: usługa warren, plik dziennika warren.log. Konfigurację i test end-to-end opisano w artykule Skanowanie POP3 i IMAP w Sophos Firewall.

W przypadku problemów z pocztą zawsze trzeba sprawdzić, czy MTA Mode, reguła zapory, DNS, certyfikaty i ograniczenia dostawcy są ze sobą zgodne. Przepływ poczty, kolejkę, kwarantannę i przekazywanie opisano w artykule Konfiguracja Mail Protection w MTA Mode w Sophos Firewall.

Sophos Firewall korzysta z silników antywirusowych Avira i Sophos. Usługa antyspamowa uruchamia się tylko wtedy, gdy istnieje polityka spamu przychodzącego lub wychodzącego. Ta zależność jest istotna, jeśli plik sasi.log pozostaje pusty albo usługa antyspamowa nie działa.

Usługi bezprzewodowe, RED, hotspot i inne

• Kontroler sieci bezprzewodowej i komunikacja AP/APX z zaporą: usługa awed, plik dziennika awed.log.
• Klienci sieci bezprzewodowej: komunikacja między klientem a AP/APX w wc_remote.log.
• SSID LocalWifi: usługa hostapd, plik dziennika hostapd.log; nie należy mylić go ze zdarzeniami Hotspot.
• Zdarzenia Hotspot: usługa hotspotd, plik dziennika hotspotd.log.
• RED: red.log rejestruje wszystkie skonfigurowane urządzenia RED, w tym Site-to-Site RED i SD-RED. red-<serial ID of RED>.log dotyczy konkretnego urządzenia SD-RED, a red-<RED ID>.log — konkretnej konfiguracji Site-to-Site RED. RED ID można znaleźć w Network > Interfaces, otwierając odpowiedni Site-to-Site RED. Symbole zastępcze należy zastąpić jego rzeczywistym numerem seryjnym lub RED ID.
• SNMP: usługa snmpd, plik dziennika snmpd.log.
• Usługa Syslog: plik dziennika syslog.log.
• Licencjonowanie: usługa licencjonowania, plik dziennika licensing.log.
• Aktualizacje systemu: usługa u2d, plik dziennika u2d.log.
• VMware Tools: usługa vmtool, plik dziennika vmtool.log.

W przypadku problemów z licencją, Air-Gap lub sygnaturami pliki licensing.log i u2d.log są pierwszymi technicznymi punktami diagnostycznymi. Procedurę obsługi pliku licencji, 180-dniowego okresu oraz ręcznych aktualizacji sygnatur opisano w artykule Obsługa licencjonowania Air-Gap i aktualizacji sygnatur w Sophos Firewall.

Baza danych i raportowanie

• Baza danych konfiguracji: Config DB, plik dziennika postgres.log.
• Postgres: usługa postgres, plik dziennika postgres.log.
• Baza danych sygnatur: usługa sigdb, plik dziennika sigdb.log.
• Baza danych raportów: nowa baza danych raportów od SFOS 21.0, plik dziennika reportdb.log.
• Baza danych migracji: migracja raportów, plik dziennika reportmigration.log.
• Migracja konfiguracji (SFOS 22/23): plik dziennika migration.log; nie należy mylić go z reportmigration.log, który dotyczy migracji raportów.
• Garner: usługa garner, plik dziennika garner.log.
• Wizualizacja dzienników w WebAdmin: usługa iview, plik dziennika iview.log.

Jeśli brakuje raportów, działają one wolno lub występują problemy z miejscem na dysku, istotne są dzienniki raportowania i baz danych. Dodatkowo należy sprawdzić, czy raporty są zapisywane lokalnie, czy wysyłane do Sophos Fusion.

Dodatkowe pliki dziennika dla SFOS 22/23

Poniższe pliki są rzadziej potrzebne w codziennej diagnostyce ruchu, ale należą do zestawienia dla SFOS 22/23. Pogrupowano je według funkcji, aby nie wyciągać pochopnych wniosków o przyczynie problemu wyłącznie na podstawie nazwy pliku:

• Audyt, FIPS i dostęp pomocy technicznej: configuration-audit.log rejestruje zmianę konfiguracji, administratora i czas; fips.log — uruchomienie w trybie FIPS; uma.log — Support Access.
• Potok przetwarzania dzienników i utrzymanie danych lokalnych: syslog-ng.log pokazuje pomijanie kolejnych wpisów tego samego zdarzenia; reportdb_v9.log należy do starej bazy danych raportów. dbcleanup.log dotyczy czyszczenia bazy danych przy restarcie zapory, readobject.log — wewnętrznego odczytu obiektów, fstrim.log — operacji TRIM w systemie plików, a logrotate.log — rotacji do plików .gz.
• ATR, NDR Essentials i FastPath: atr-service.log pokazuje uruchomienie i zakończenie działania usługi ATR. ndr.log obejmuje licencję NDR, konfigurację i uruchomienie agenta; ndr_agent.log — uruchomienie usługi i przetwarzanie metadanych. vfpdf.log pokazuje metadane wysyłane przez FastPath do NDR Essentials wyłącznie na XGS 88/88w, 108/108w, 118/118w i 128/128w. setup_vf_dpdk.log rejestruje inicjalizację pamięci FastPath i nie dotyczy właśnie tych czterech serii modeli.
• TLS i SSL VPN: httplogd.log pokazuje nieodszyfrowane połączenia HTTPS w ścieżce DPI. peruser_cert_sslvpn.log rejestruje certyfikaty SSL VPN generowane dla poszczególnych użytkowników; openvpn-status0.log, openvpn-status1.log i kolejne numerowane pliki pokazują aktywne połączenia SSL VPN dla każdego procesu.
• Sieć i HA: dhcprelay.log dotyczy DHCP Relay. ha.log pokazuje powodzenie lub błędy przy zestawianiu HA oraz zmiany stanu; filesync.log — synchronizację plików wybranych usług z urządzeniem Auxiliary.
• Central, wdrażanie i ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log i fwcm-updaterd.log obejmują informacje o strefach/interfejsach, połączenie i przesyłanie konfiguracji. fwcm-frpcd.log dotyczy Fast Reverse Proxy przy jednoczesnym otwieraniu wielu zapór w Central. ssod.log zawiera informacje o aktualizacjach firmware przesyłane do Central oraz kopie zapasowe zapory utworzone w Central. W przypadku True/Controlled Zero Touch sprawdza się zt.log i fwcm-heartbeatd.log; w przypadku Zero Touch przez USB — zerotouch.log, a nie fwcm-heartbeatd.log. ztna-connector.log zawiera identyfikatory konta klienta i konektora, stan konektora, tunele ZTNA, wywoływane aplikacje i aktualizacje konfiguracji.
• Kopie zapasowe, firmware, Air Gap i certyfikaty: interfacemapping.log rejestruje przypisanie interfejsów podczas odtwarzania, legacyconversion.log — kopie zapasowe bez Secure Storage Master Key, a fwmgmt.log — instalowanie firmware i zarządzanie nim. u2d_airgap.log dotyczy aktualizacji Air Gap, cps_messages.log — błędów poprawek Hotfix, a letsencrypt.log wraz z applog.log — certyfikatów Let’s Encrypt.
• API, odtwarzanie i zarządzanie certyfikatami: apiparser.log dotyczy konwersji API między JSON i XML, a validation.log i validationError.log — walidacji API. Przy tworzeniu/odtwarzaniu kopii zapasowych dodatkowo sprawdzić applog.log i postgres.log. vpncertificate.log obejmuje nie tylko certyfikaty VPN, lecz także CA, CSR i CRL.
• Sprzęt i stan systemu: npu-startup.log pokazuje uruchomienie NPU, npu_syslog.log — dzienniki Syslog NPU, a xgs-host.log — sterowniki hosta podczas uruchamiania. xgs-npu-fw.log dotyczy sprawdzania zgodności NPU, aktualizacji i odzyskiwania, xgs-npu-serial.log — portu szeregowego NPU, a xgs-pport-wait.log — tworzenia interfejsów fizycznych podczas uruchamiania. xgs-healthmond.log obejmuje obciążenie CPU, temperaturę, prędkość obrotową wentylatorów i port zarządzania NPU. raid.log pokazuje programowy RAID, a lcd.log — wyświetlacz sprzętowy. Na zaporach sprzętowych, wirtualnych, chmurowych i programowych system-monitor/cpu_trigger.log oraz system-monitor/memory_trigger.log zapisują stan systemu odpowiednio przy wysokim obciążeniu CPU lub pamięci; oba są wymienione dla SFOS 22/23.
• Dzienniki Syslog FastPath: npu_syslog.log dotyczy FastPath opartego na NPU i nie ma zastosowania do XGS 88/88w, 108/108w, 118/118w i 128/128w. syslog.log pokazuje komunikację hosta z FastPath opartym na NPU oraz Virtual FastPath. W przypadku VMware oprócz dziennika VMware Tools vmtool.log należy sprawdzić także syslog.log.
• Usługi chmurowe i platformowe: iaasd.log rejestruje provisioning konfiguracji i sprawdzanie licencji w Azure, a waagent.log — provisioning na poziomie systemu operacyjnego i monitorowanie kondycji przez agenta provisioningu Azure; vmtool.log dotyczy VMware Tools.

Sama obecność pliku nie dowodzi błędu w tym module. Najpierw należy skorelować czas zdarzenia, właściwy węzeł, platformę, stan usługi i odtwarzalny objaw, a dopiero potem wyszukać informacje z wąskim filtrem we właściwym pliku.

Przebieg analizy

1. Dokładnie zanotować problem: czas ze strefą czasową, klienta, cel, port, użytkownika i działanie.
2. Ustalić, czy problem dotyczy ruchu, stanu usługi, zmiany konfiguracji czy synchronizacji z Sophos Fusion.
3. Filtrować Log Viewer według źródłowego adresu IP, docelowego adresu IP, modułu i czasu.
4. Sprawdzić widoczność Firewall Rule ID, NAT Rule ID, użytkownika, bramy i identyfikatorów polityk.
5. Użyć Packet Capture, jeśli przepływ pakietów, ścieżka zwrotna lub widok NAT są niejasne.
6. Sprawdzić odpowiedni plik dziennika za pomocą tail -f, less lub grep.
7. Odtworzyć problem i udokumentować dokładny czas testu.
8. W razie potrzeby włączyć debugowanie tylko dla usługi, której dotyczy problem, i tylko na krótko.
9. Ponownie wyłączyć debugowanie i sprawdzić dostępną przestrzeń dyskową.
10. Zapisać dzienniki bezpośrednio po odtworzeniu błędu.

W przypadku zgłoszeń do pomocy technicznej należy również udokumentować wszystkie komunikaty o błędach, kroki odtwarzania i wykonane czynności diagnostyczne. Te informacje znacznie przyspieszają obsługę zgłoszenia. Odpowiednią procedurę opisano w artykule Otwieranie zgłoszenia do pomocy technicznej Sophos: przygotowanie i portal.

Często zadawane pytania