Rozwiązywanie problemów z Sophos Firewall: Usługi i logi

W Sophos Firewall istnieją trzy ważne poziomy troubleshooting: Event Logs w Log viewer, narzędzia diagnostyczne w WebAdmin oraz usługi i pliki logów na firewallu. Log Viewer jest idealny 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, filtr sieciowy działa nieoczekiwanie lub support wymaga szczegółowych danych.

Ten artykuł klasyfikuje najważniejsze usługi i pliki dziennika według typowych problemów administratora. Pomaga również, gdy na pulpicie nawigacyjnym, w Advanced Shell lub w przypadku wsparcia pojawia się techniczna nazwa usługi i nie jest od razu jasne, jaka funkcja zapory za nią stoi. Nazwy takie jak zebra, warren, awed, garner czy strongswan nie są oczywiste na co dzień.

Wybór narzędzia i wymagania wstępne

Zanim zacznie się szukać w plikach logów, powinno być jasne, które narzędzie najszybciej da odpowiedź. Wiele przypadków można zawęzić już przez Log Viewer albo Packet Capture. Shell staje się naprawdę pomocna dopiero wtedy, gdy trzeba sprawdzić samą usługę albo support potrzebuje szczegółowych danych logów.

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

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

Kolejność jest ważna. Log Viewer często szybciej pokazuje, która reguła lub moduł podjął decyzję. Packet Capture dowodzi przepływu pakietów w WebAdmin. tcpdump jest przydatny, gdy potrzebne jest dłuższe przechwytywanie, plik PCAP lub bardzo dokładny filtr CLI. Logi usług i debugowanie pomagają, gdy problem dotyczy samej usługi lub gdy trzeba zebrać dane dla wsparcia Sophos.

Szybki start według symptomu

Jeśli nie wiadomo, który log jest istotny, pomaga start według symptomu zamiast według nazwy usługi.

• Pojedyncze połączenie nie działa: najpierw sprawdzić Log Viewer z Source, Destination, Service i godziną. Następnie użyć Packet Capture, firewall_rule.log i nat_rule.log.
• Tunel VPN jest down albo niestabilny: sprawdzić status VPN, Peer-IP, godzinę i Log Viewer. Następnie przejrzeć strongswan.log, charon.log, sslvpn.log i dane diagnostyczne IPsec.
• WebAdmin, User Portal albo SSH nie jest osiągalny: sprawdzić Device Access, Local Service ACL i dotkniętą strefę. Następnie użyć apache.log, tomcat.log, sshd.log i Packet Capture na port docelowy.
• Webfilter, TLS Inspection albo IPS blokuje nieoczekiwanie: sprawdzić moduł Log Viewer i Policy-ID. Następnie porównać ips.log, webproxy.log, awarrenhttp.log i Packet Capture.
• Zadanie Sophos Central pozostaje zawieszone: porównać Central Task Queue i lokalny status. Następnie sprawdzić centralmanagement.log, sophos-central.log i fwcm-api-executor.log.
• HA zachowuje się inaczej na poszczególnych node: określić Active Node, Auxiliary Node i dotkniętą ścieżkę ruchu. Następnie zalogować się bezpośrednio na dotkniętym node i sprawdzić logi HA.
• Brakuje lokalnych raportów albo kończy się miejsce: sprawdzić ustawienia raportów, miejsce na dysku i Central Reporting. Następnie użyć reportdb.log, garner.log i analizy miejsca.

Takie spojrzenie zapobiega typowej pułapce: szukaniu w logu usługi, mimo że najpierw trzeba udowodnić Rule Matching, Device Access, NAT albo routing.

Log Viewer czy plik dziennika?

Log viewer otwiera się w konsoli WebAdmin w prawym górnym rogu. Aktualizuje się automatycznie, można go filtrować według modułu, czasu, wartości pól i tekstu dowolnego oraz eksportować logi jako CSV.

Logi do rozwiązywania problemów znajdują się na zaporze w katalogu /log. Dostęp uzyskuje się przez konsolę WebAdmin lub SSH. Do krótkich kontroli działa Device Management > Advanced Shell w przeglądarce, ale w praktyce SSH jest zazwyczaj wygodniejsze, stabilniejsze i lepsze do dłuższych sesji tail, grep lub less. Jak bezpiecznie przygotować SSH, opisano w instrukcji Łączenie się z Sophos Firewall przez SSH.

Przed dłuższymi sesjami powłoki powinno być jasne, z której sieci administracyjnej się łączy, czy odcisk palca SSH został sprawdzony i czy naprawdę potrzebna jest Advanced Shell. Do wielu pierwszych kontroli wystarczy Log Viewer lub Packet Capture w WebAdmin.

Jako zasada kciuka pomaga ta kolejność:

Dzięki temu analiza pozostaje wystarczająco mała. Najpierw zbiera się widoczny wynik, następnie przechodzi do przepływu pakietów, a dopiero potem do logów usług lub debugowania. To zmniejsza ryzyko zbyt wczesnego aktywowania szerokich logów debugowania lub analizowania niewłaściwego pliku dziennika.

Czytanie plików dziennika w Advanced Shell

Zanim zacznie się szukać w /log, przypadek testowy powinien być jak najdokładniej udokumentowany: lokalny czas, dotknięty adres IP źródła, adres IP celu, port, użytkownik, moduł i oczekiwane zachowanie. Te informacje robią różnicę między użyteczną analizą logów a długim przeszukiwaniem starych wpisów.

1. Połącz się przez SSH lub otwórz Device Management > Advanced Shell w konsoli WebAdmin.
2. Przejdź do katalogu logów.

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:

Dla wsparcia lub późniejszej analizy nie należy kopiować tylko pojedynczych linii logów. Lepiej jest mieć wyraźny zakres czasowy, odtworzony test, odpowiednie zrzuty ekranu z Log Viewer lub Packet Capture i w razie potrzeby pełne archiwum logów. Lokalne logi rotują; dlatego ważne dane powinny być zabezpieczone, dopóki zdarzenie jest jeszcze w odpowiednim okresie. Procedura jest opisana w Zabezpieczanie logów Sophos Firewall dla analizy zewnętrznej.

Pobieranie logów troubleshooting w WebAdmin

Nie każdą kolekcję logów trzeba budować ręcznie przez tar w Advanced Shell. W przypadkach supportowych WebAdmin ma dodatkowo obszar Diagnostics > Tools > Log file details albo wybór Troubleshooting Logs. Tam można wybrać pliki logów według modułu i je pobrać.

W praktyce istnieją dwie drogi:

• Pojedyncze pliki logów: otworzyć Diagnostics > Tools > Troubleshooting logs, wybrać odpowiednie pliki logów i pobrać je jako plik skompresowany.
• Consolidated Troubleshooting Report (CTR): użyć Diagnostics > Tools > Consolidated troubleshooting report, gdy support potrzebuje wszystkich logów wraz ze stanem systemu, procesami i danymi zasobów w jednym pakiecie.

Jest to praktyczne, gdy admin nie chce otwierać dłuższej sesji shell albo potrzebny jest tylko jasno ograniczony pakiet logów. CTR jest lepszy, gdy Sophos Support potrzebuje szerokiego zrzutu stanu systemu. Podczas tworzenia CTR należy wpisać krótki i jasny powód, na przykład numer ticketu, zakres czasu albo objaw. Raport jest pobierany w postaci zaszyfrowanej i dla logów podsystemów usług zwykle zawiera tylko ograniczoną liczbę linii. Pełne pojedyncze pliki logów uzyskuje się bardziej niezawodnie przez Troubleshooting logs albo bezpośrednio z /log.

Ważne: pobrany pakiet logów nie zastępuje danych kontekstowych. Support nadal potrzebuje godziny ze strefą czasową, dotkniętych IP, użytkownika, nazwy tunelu, Rule ID, NAT ID i krótkiego opisu tego, co dokładnie odtworzono.

W klastrach HA trzeba dodatkowo pamiętać: logi i raporty nie są po prostu synchronizowane między Primary i Auxiliary. Każdy node zawiera logi ruchu i usług, które sam przetworzył. Przy błędach specyficznych dla noda należy więc sprawdzić dotknięty node.

Advanced Shell czy Device Console?

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

Nie każde polecenie działa w obu obszarach. Jeśli artykuł wyraźnie wspomina Device Console, polecenie powinno być tam wykonane. Jeśli chodzi o /log, tail -f, grep, service -S lub debugowanie logów, zazwyczaj chodzi o Advanced Shell.

To rozróżnienie jest ważne, ponieważ wiele błędów wynika tylko z tego, że poprawne polecenie jest wprowadzane w niewłaściwym miejscu.

Logowanie musi być aktywne

Nie każda oczekiwana informacja pojawia się automatycznie.

• W regułach zapory musi być aktywne Log firewall traffic.
• W regułach inspekcji SSL/TLS musi być aktywne logowanie.
• W System services > Log settings musi być zdefiniowane, jakie typy logów są wysyłane lokalnie, do Sophos Central lub do Syslog.

Dla długoterminowego przechowywania serwer Syslog lub Sophos Central Firewall Reporting są sensowne. Jak można podłączyć zewnętrzne serwery logów lub SIEM, opisano w Wysyłanie dzienników Syslog z Sophos Firewall do SIEM. Dla Sophos Central odpowiednia procedura to Aktywowanie raportowania centralnego Sophos Firewall.

Debugowanie tylko celowo aktywować

Debugowanie logów jest bardzo pomocne, ale generuje wiele danych i może zużywać miejsce na dysku. Debugowanie powinno być aktywowane tylko dla odpowiedniej usługi. Następnie odtwarza się problem i wyłącza debugowanie.

Przykład:

service ips:debug -ds nosync
service ips:debug -ds nosync off

Dokładna składnia zależy od usługi. Jeśli dotknięta usługa jest niejasna, najpierw należy sprawdzić odpowiedni normalny plik dziennika.

Sophos rozróżnia tu dwie ścieżki obsługi. W Advanced Shell używa się poleceń usług, takich jak service ips:debug -ds nosync. W Device Console dla obsługiwanych podsystemów dostępne są dodatkowo polecenia system diagnostics subsystems <subsystem> debug on i system diagnostics subsystems <subsystem> debug off. Tych wariantów nie należy mieszać: najpierw ustalić, w której konsoli się pracuje, a potem użyć pasującego polecenia.

Temat debugowania logów i podstawowych poleceń CLI jest bardziej szczegółowo opisany w artykule Rozwiązywanie problemów z Sophos Firewall CLI: ważne polecenia. Dla restartu pojedynczych usług pomocny jest również Bezpieczne ponowne uruchamianie usług Sophos Firewall.

Typowe błędy przy wyszukiwaniu logów

Wiele analiz logów trwa długo nie z powodu braku danych, ale dlatego, że zbyt wcześnie szuka się w niewłaściwym narzędziu.

Dobry przypadek rozwiązywania problemów zawsze ma trzy rzeczy: dokładny test, odpowiednie źródło logów i udokumentowany czas. Bez tej podstawy można zobaczyć wiele linii logów, ale niekoniecznie przyczynę.

Pliki logów według obszaru funkcjonalnego

Poniższe listy służą jako materiał referencyjny. Najlepiej najpierw wybrać dotknięty obszar funkcjonalny, a potem sprawdzić pasujący plik logu z wąskim oknem czasowym.

System, Management i usługi podstawowe

• Komunikaty systemowe: syslog.log; dodatkowo sprawdzić czas, reboot i zdarzenia interfejsów.
• WebAdmin Webserver: apache.log, apache_access.log; dodatkowo sprawdzić Device Access i Local Service ACL.
• Aplikacja WebAdmin: tomcat.log; dodatkowo sprawdzić błędy GUI, wysokie obciążenie i status usługi.
• SSH: sshd.log; dodatkowo sprawdzić Device Access, sieć źródłową i Public-Key-Login.
• Błędy GUI/CLI: error_log.log; dodatkowo sprawdzić aktualną zmianę, przeglądarkę i akcję admina.
• Zmiany konfiguracji: applog.log, csc.log; dodatkowo sprawdzić Audit Trail i Config Studio.
• Baza konfiguracji: postgres.log; dodatkowo sprawdzić miejsce, backup/restore i sprawę supportową.
• Komunikacja między komponentami: garner.log; dodatkowo sprawdzić reporting, Central Reporting i przetwarzanie logów.
• API: apiparser.log, app-feedback.log; dodatkowo sprawdzić API-ACL, token i Central Task Queue.
• Walidacja: validation.log, validationError.log; dodatkowo sprawdzić błędne obiekty albo importy.
• Licencjonowanie: licensing.log; dodatkowo sprawdzić status licencji, Central Sync i specjalny przypadek Air-Gap.
• System Updates: u2d.log, sig_update.log; dodatkowo sprawdzić status pattern, DNS/HTTPS i miejsce na dysku.

Przy problemach z zarządzaniem nie należy sprawdzać tylko pliku logu WebAdmin. Bardzo często Device Access, Local Service ACL Exception Rule albo błędna sieć źródłowa decyduje o tym, czy WebAdmin, SSH, User Portal, VPN Portal, DNS albo SNMP są osiągalne. Do tej części lepszym wejściem jest Zabezpieczanie dostępu do Sophos Firewall: prawidłowa konfiguracja Device Access.

Zapora, NAT i Packet Capture

W przypadku problemów z DNAT zawsze sprawdzaj regułę zapory i regułę NAT razem. NAT tylko tłumaczy, ale nie pozwala na ruch. Więcej na ten temat: Zrozumienie NAT na Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Sophos Firewall używa między innymi IP tables, ARP table, IPset i conntrack do połączeń zapory. Do QoS lub zarządzania przepustowością używa się IMQ. Ta informacja jest pomocna, gdy widzi się komunikaty logów lub dane wsparcia z technicznymi terminami z ścieżki sieciowej Linuxa.

IPS, Application Control i TLS Inspection

Wiele nowoczesnych funkcji ochrony widzi wystarczająco dużo szczegółów dopiero, gdy HTTPS jest odszyfrowane. Jeśli TLS Inspection nie działa, filtry sieciowe, Application Control, IPS i skanowanie złośliwego oprogramowania są mniej znaczące w zależności od ruchu.

Jeśli nie jest jasne, czy IPS jest w ogóle aktywny, jaka polityka działa lub dlaczego sygnatura blokuje, najpierw pomaga Konfigurowanie i bezpieczne testowanie IPS na Sophos Firewall. Następnie można bardziej celowo połączyć ips.log, Log Viewer i Packet Capture.

Jeśli chodzi o wykrywanie aplikacji, Application Filter lub nieoczekiwane blokady App-Control, najpierw pasuje Konfigurowanie i testowanie Application Control na Sophos Firewall.

Przy Zero-Day Protection należy dodatkowo sprawdzić, czy Web Protection, TLS Inspection, typ pliku, rozmiar pliku, Policy i akcja do siebie pasują. Odpowiedni artykuł operacyjny to Zrozumienie i obsługa Sophos Firewall Zero-Day Protection. Dla Threat Feeds pasuje Konfiguracja i bezpieczna obsługa Sophos Firewall Threat Feeds. Więcej o TLS Inspection: Stopniowe wdrażanie TLS Inspection na Sophos Firewall.

Sieć Web, Proxy, WAF i Webfilter

Jeśli ruch sieciowy w Log Viewer jest oznaczony jako zablokowany, przyczyna może leżeć w kilku modułach: Web Policy, SSL/TLS inspection, Application Control, IPS lub WAF. Dlatego zawsze wybieraj konkretny moduł w Log Viewer i dodatkowo sprawdzaj odpowiedni plik dziennika.

Sophos blokuje strony internetowe kategorii highly objectionable criminal activity zasadniczo i ukrywa nazwę domeny w logach i raportach. Jeśli wpis w tym obszarze wydaje się celowo zanonimizowany, może to być zamierzone.

Dla kategorii sieci Web, grup URL, polityk sieci Web i natychmiastowych alertów pasuje Wykorzystanie kategorii sieci Web i natychmiastowych alertów na Sophos Firewall.

VPN

Sophos Firewall używa strongSwan dla IPsec VPN i OpenVPN dla SSL VPN. W przypadku problemów z IPsec kluczowe są czas, IP partnera, propozycja, lokalne/zdalne podsieci, NAT-T, routing i reguły zapory.

Dla problemów z IPsec artykuł Rozwiązywanie problemów z IPsec na Sophos Firewall jest lepszym przewodnikiem krok po kroku. Jeśli chodzi o VPN oparty na trasach i ręczne trasy IPsec, pomocne jest Tworzenie trasy IPsec na Sophos Firewall.

Uwierzytelnianie, User Portal i SSO

W przypadku reguł użytkowników zawsze najpierw sprawdź, czy użytkownik jest w ogóle znany. Jeśli Match known users jest aktywne i uwierzytelnianie nie działa, reguła nie pasuje.

Jeśli Captive Portal jest używany z Microsoft Entra ID SSO, pomocne jest Konfigurowanie Microsoft Entra ID SSO dla Captive Portal Sophos Firewall przy porównywaniu oauth_sso_captive.log, Device Access, grup i późniejszego dopasowania reguł.

DNS, DHCP i sieć

Problemy z DNS i DHCP często wyglądają jak problemy z zaporą. Dlatego najpierw należy sprawdzić adres IP, bramę, serwer DNS i pytanie, czy klienci mają używać zapory jako serwera DNS lub DHCP.

Jeśli wewnętrzne domeny nie są poprawnie rozwiązywane, zazwyczaj istotne jest Konfigurowanie tras żądań DNS na Sophos Firewall. Dla specjalnych opcji DHCP istnieje osobny artykuł Konfigurowanie opcji DHCP na Sophos Firewall.

Cellular WAN

W przypadku problemów z Cellular WAN należy dodatkowo sprawdzić, czy modem jest rozpoznawany, czy PIN/SIM/APN są poprawne i czy zapora tworzy odpowiednią bramę.

Routing

W przypadku problemów z routingiem dodatkowo sprawdź Routing > SD-WAN routes, bramy i Packet Capture. Tester polityki nie zastępuje prawdziwego testu routingu.

Więcej na ten temat: Dostosowywanie priorytetu routingu na Sophos Firewall.

GUI, CLI i dostęp do systemu

Jeśli WebAdmin lub SSH nie są dostępne, nie tylko te logi należy sprawdzić. Lokalny dostęp jest kontrolowany przez Administration > Device access i Local Service ACL.

Więcej na ten temat: Łączenie się z Sophos Firewall przez SSH.

Sophos Central, Heartbeat i Central Management

W przypadku problemów z Central najpierw sprawdź, czy zapora jest zarejestrowana, usługi Central są aktywne i czy DNS/HTTPS wychodzący działa. Jeśli zmiana z Central nie dociera lokalnie, należy porównać Sophos Central Firewall Management Task Queue z lokalnymi logami. Zielony status Central sam w sobie nie dowodzi, że konkretna Policy została lokalnie przetworzona.

High Availability

Logi HA znajdują się na urządzeniu, na którym zostały wygenerowane. Dla surowych logów urządzenia pomocniczego trzeba połączyć się bezpośrednio z tym urządzeniem, na przykład przez jego port administracyjny za pomocą SSH. Dla skonsolidowanych raportów bardziej praktyczne jest Sophos Central Firewall Reporting.

Poczta i Anti-Spam

W przypadku problemów z pocztą zawsze sprawdzaj, czy tryb MTA, reguła zapory, DNS, certyfikaty i ograniczenia dostawcy są zgodne. Procedura dla przepływu poczty, bufora, kwarantanny i przekazywania jest opisana w Konfigurowanie ochrony poczty na Sophos Firewall w trybie MTA.

Sophos Firewall używa Avira i Sophos Antivirus. Usługa Anti-Spam uruchamia się tylko wtedy, gdy istnieje polityka antyspamowa przychodząca lub wychodząca. Ta zależność jest ważna, jeśli sasi.log pozostaje pusty lub usługa Anti-Spam nie działa.

Sieć bezprzewodowa, RED, Hotspot i inne usługi

W przypadku problemów z licencjonowaniem, Air-Gap lub wzorcami, licensing.log i u2d.log są pierwszymi technicznymi punktami kontaktowymi. Dla procedury operacyjnej z plikiem licencji, oknem 180-dniowym i ręcznymi aktualizacjami wzorców pasuje Obsługa licencjonowania Air-Gap i aktualizacji wzorców na Sophos Firewall.

Baza danych i raportowanie

Jeśli brakuje raportów, są wolne lub występują problemy z miejscem na dysku, istotne są logi raportowania i bazy danych. Dodatkowo należy sprawdzić, czy raporty są przechowywane lokalnie czy wysyłane do Sophos Central.

Przebieg analizy

1. Dokładnie zanotować problem: godzina ze strefą czasową, klient, cel, port, użytkownik, akcja.
2. Zdecydować, czy chodzi o traffic, status usługi, zmianę konfiguracji czy synchronizację Central.
3. W Log Viewer filtrować po Source IP, Destination IP, module i godzinie.
4. Sprawdzić widoczność Firewall Rule ID, NAT Rule ID, User, Gateway i Policy IDs.
5. Użyć Packet Capture, jeśli przepływ pakietów, droga powrotna albo widok NAT są niejasne.
6. Sprawdzić pasujący plik logu przez tail -f, less albo grep.
7. Odtworzyć problem i udokumentować dokładny czas testu.
8. Jeśli trzeba, aktywować Debug tylko dla dotkniętej usługi i tylko na krótko.
9. Ponownie wyłączyć Debug i sprawdzić miejsce na dysku.
10. Zabezpieczyć logi, dopóki błąd został świeżo odtworzony.

Dla przypadków wsparcia należy również udokumentować wszystkie komunikaty o błędach, kroki reprodukcji i już wykonane kroki rozwiązywania problemów. Dokładnie te informacje znacznie przyspieszają przypadki wsparcia. Odpowiednia procedura jest opisana w Otwieranie zgłoszenia do wsparcia Sophos: Przygotowanie i portal.

FAQ