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.
• 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 Central utknęła? Sprawdzanie kolejki zadań Sophos Central Firewall Management.
• Potrzebne są raporty lub historia w Sophos Central? 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.

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 Central 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.

Dzienniki diagnostyczne znajdują się na zaporze w katalogu /log. Dostęp do nich jest możliwy przez konsolę WebAdmin lub SSH. Do krótkich kontroli można użyć w przeglądarce Device Management > Advanced Shell, jednak w praktyce SSH jest zwykle wygodniejsze, stabilniejsze i lepiej nadaje się do dłuższych sesji z tail, grep lub less. Bezpieczne przygotowanie SSH opisano w instrukcji Łą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. Połącz się przez SSH lub otwórz Device Management > Advanced Shell w konsoli WebAdmin.
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.
• Sterowanie usługą lub włączenie debugowania: service <service>:<start/restart/stop/debug> -ds nosync, na przykład service ips:debug -ds nosync. Polecenia start, restart i stop wpływają na działanie systemu i należy je wykonywać w oknie serwisowym lub zgodnie z instrukcją pomocy technicznej.

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 tworzyć ręcznie za pomocą tar w Advanced Shell. Na potrzeby pomocy technicznej WebAdmin udostępnia również Diagnostics > Tools > Log file details oraz wybór dzienników diagnostycznych. Można tam wybierać i pobierać pliki dziennika według modułów.

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 administrator nie chce otwierać długiej sesji powłoki lub potrzebny jest tylko jasno określony pakiet dzienników. CTR jest lepszym wyborem, gdy pomoc techniczna Sophos potrzebuje obszernej migawki systemu. Podczas tworzenia CTR należy podać krótki i zrozumiały powód, na przykład numer zgłoszenia, przedział czasu lub objaw. Raport jest pobierany w postaci zaszyfrowanej, a w przypadku dzienników podsystemów usług domyślnie zawiera tylko ograniczoną liczbę wierszy. Pełne pojedyncze pliki dziennika można uzyskać niezawodniej przez Troubleshooting logs lub bezpośrednio z /log.

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ł.

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, służąca do obsługi systemu plików, dzienników, tail, grep, less, service -S, restartów usług i poleceń debugowania.

Nie każde polecenie działa w obu obszarach. Jeśli w artykule wyraźnie wspomniano o Device Console, polecenie należy wykonać właśnie tam. W przypadku /log, tail -f, grep, service -S lub rejestrowania debugowania zwykle chodzi o Advanced Shell.

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 Central 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 Central właściwą procedurą jest Włączanie Central Firewall Reporting.

Debugowanie tylko w określonym celu

Rejestrowanie debugowania jest bardzo przydatne, ale generuje dużo danych i może zużywać miejsce na dysku. Debugowanie należy włączyć tylko dla odpowiedniej usługi. Następnie odtwarza się problem i ponownie wyłącza debugowanie. Dzienniki debugowania mogą zawierać dane logowania i inne poufne treści; przed pobraniem lub przekazaniem trzeba je sprawdzić i przesłać bezpiecznym kanałem.

Przykład dla IPS w Advanced Shell:

service ips:debug -ds nosync

Polecenie przełącza stan debugowania usługi i po zebraniu danych wykonuje się je ponownie, aby wyłączyć debugowanie. Dodanie off do tego polecenia Advanced Shell nie jest udokumentowane. Dokładna składnia zależy od usługi. Jeśli nie jest jasne, której usługi dotyczy problem, najpierw należy sprawdzić odpowiedni zwykły plik dziennika.

⚠️ 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.

Sophos rozróżnia dwa sposoby obsługi. W Advanced Shell używa się poleceń usług, takich jak service ips:debug -ds nosync. W Device Console dostępne są dodatkowo polecenia system diagnostics subsystems <subsystem> debug on i system diagnostics subsystems <subsystem> debug off dla obsługiwanych podsystemów. Nie należy mieszać tych wariantów: najpierw trzeba ustalić, w której konsoli wykonywana jest praca, a następnie użyć właściwego polecenia.

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 są zgodne z aktualną dokumentacją SFOS 22.0. 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 już na aktualnej liście dzienników SFOS 22.0, dlatego nie należy zakładać ich obecności w bieżącej kompilacji.

System, zarządzanie i usługi podstawowe

• Komunikaty systemowe: syslog.log; dodatkowo sprawdzić czas, ponowne uruchomienie i zdarzenia interfejsu.
• Serwer WWW WebAdmin: 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 stan usługi.
• SSH: sshd.log; dodatkowo sprawdzić Device Access, sieć źródłową i logowanie za pomocą klucza publicznego.
• Błędy GUI/CLI: error_log.log; dodatkowo sprawdzić ostatnie zmiany, przeglądarkę i działania administratora.
• Zmiany konfiguracji: applog.log, csc.log; dodatkowo sprawdzić Audit Trail i Config Studio.
• Baza danych konfiguracji: postgres.log; dodatkowo sprawdzić miejsce na dysku, kopię zapasową/przywracanie i zgłoszenie do pomocy technicznej.
• Komunikacja pomiędzy komponentami: garner.log; dodatkowo sprawdzić raportowanie, Central Reporting i przetwarzanie dzienników.
• API: apiparser.log; dodatkowo sprawdzić validation.log, API-ACL, 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 Sophos Central i szczególny przypadek Air-Gap.
• Aktualizacje systemowe: u2d.log; dodatkowo sprawdzić stan wzorców, DNS/HTTPS i wolne miejsce na dysku.

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

• Dopasowanie reguły zapory: firewall_rule.log; dodatkowo sprawdzić moduł Firewall w Log Viewer.
• Ogólne przetwarzanie zapory: fwlog.log; dodatkowo użyć Packet Capture.
• Reguły NAT: nat_rule.log; dodatkowo sprawdzić NAT Rule ID w Log Viewer.
• DNAT z Link Load Balancing: dodatkowo sprawdzić dgd.log, jeśli problem dotyczy wyboru bramy lub łącza.
• Packet Capture w WebAdmin: pktcapd.log; dodatkowo sprawdzić Diagnostics > Packet capture.
• Zarządzanie przepustowością / QoS: bwm.log; dodatkowo sprawdzić politykę kształtowania ruchu.
• Virtual Host / starsza publikacja serwera: vhost.log; dodatkowo sprawdzić NAT i WAF.
• Web Server Protection / WAF: reverseproxy.log; dodatkowo sprawdzić regułę WAF, Hosted address i dostępność backendu.

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 tablic IP, tabeli ARP, IPset i conntrack do połączeń z zaporą ogniową. IMQ służy do zarządzania QoS lub przepustowością. Informacje te są przydatne, gdy wyświetlane są komunikaty dziennika lub problemy dotyczące pomocy technicznej zawierające 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.
• Aktualizacje sygnatur: Signature Updater, plik dziennika sig_upgrade.log.
• Migracja sygnatur: migracja sygnatur, plik dziennika sigmigration.log.

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

• HTTPS Proxy: Usługa awarrenhttp, plik dziennika awarrenhttp.log.
• Dostęp przez proxy HTTPS: dziennik dostępu awarrenhttp, plik awarrenhttp_access.log.
• Kategoryzacja/reputacja stron: usługa nSXLd, plik dziennika nSXLd.log.
• Starsza wersja HTTP/FTP Proxy: Usługa skein, plik dziennika skein.log.
• FTP Proxy: Usługa ftpproxy, plik dziennika ftpproxy.log.
• Web Application Firewall: Reverse Proxy, plik dziennika reverseproxy.log.

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 domyślnie blokuje strony z kategorii highly objectionable criminal activity i ukrywa nazwę domeny w dziennikach oraz raportach. Jeśli wpis w tym obszarze wygląda na celowo zanonimizowany, może to być działanie 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.
• 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.

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 użytkownika: Serwer dostępu / AAA, plik dziennika access_server.log.
• NTLM / NASM: Usługa nasm, plik dziennika nasm.log.
• Chromebook SSO: Zaplecze Chromebook SSO, plik dziennika chromebook-sso-backend.log.
• Portal przechwytujący OAuth SSO: Plik dziennika oauth_sso_captive.log.
• OAuth SSO WebAdmin: Plik dziennika oauth_sso_webadmin.log.
• OAuth SSO VPN: Plik dziennika oauth_sso_vpn.log.
• STAS: Kontekst STAS / serwera dostępu, w zależności od kontekstu usługi i 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.

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, Device Access, grupy i późniejsze dopasowanie reguł.

DNS, DHCP i sieć

• Usługa DNS: usługa dnsd, plik dziennika dnsd.log.
• DNS Grabber: Usługa dnsgrabber, plik dziennika dnsgrabber.log.
• DNS Entity / inne 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.
• Usługa sieciowa: usługa networkd, plik dziennika networkd.log.
• Hosty FQDN: usługa fqdnd, plik dziennika fqdnd.log.
• Wykrywanie martwej bramy: Usługa dgd, plik dziennika dgd.log.
• Dynamiczny DNS: Dynamiczny klient 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

• Routing statyczny: Usługa zebra, plik dziennika zebra.log.
• Routing oparty na aplikacji: Usługa appcached, plik dziennika appcached.log.
• Routing multiemisji: Plik dziennika mrouting.log.
• BGP: Usługa bgpd, plik dziennika bgpd.log.
• OSPF: Usługa ospfd, plik dziennika ospfd.log.
• RIP: Usługa ripd, plik dziennika ripd.log.
• PIM-SM: Usługa pimd, plik dziennika pimd.log.

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.

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 Central, Security Heartbeat i zarządzanie centralne

• Sophos Central Management: zarządzanie centralne, pliki dziennika centralmanagement.log, sophos-central.log.
• CSC: usługi csc, cschelper, csd; pliki dziennika csc.log, cschelper.log, csd.log.
• Security Heartbeat: usługi heartbeatd, hbtrust; pliki dziennika heartbeatd.log, hbtrust.log.
• Synchronized Application Control: sprawdzić dane wysyłane do SophosLabs w sac-feedback.log.
• Heartbeat do Sophos Central: usługi fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; sprawdzić odpowiednie dzienniki usług.
• 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 Central 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 Central nie dociera lokalnie, należy porównać kolejkę zadań Sophos Central Firewall Management z lokalnymi dziennikami. Sam zielony status w Central nie dowodzi, że konkretna polityka została przetworzona lokalnie.

Wysoka dostępność

• Stan i konfiguracja HA: dziennik aplikacji HA, plik applog.log.
• Usługa pary HA: usługa ha_pair, plik dziennika ha_pair.log.
• Tunel HA: usługa ha_tunnel, plik dziennika ha_tunnel.log.
• Conntrack Sync: usługa ctsyncd, plik dziennika ctsyncd.log.
• Msync: usługa msync, plik dziennika msync.log.

Dzienniki HA znajdują się na urządzeniu, na którym zostały utworzone. Aby uzyskać surowe dzienniki urządzenia Auxiliary, trzeba połączyć się bezpośrednio z tym urządzeniem, na przykład przez jego port administracyjny za pomocą SSH. W przypadku raportów skonsolidowanych praktyczniejsze jest Sophos Central Firewall Reporting.

Poczta i ochrona przed spamem

• Antywirus: usługa AV, plik dziennika avd.log.
• Aktualizacje antywirusowe: Up2Date AV, plik dziennika up2date_av.log.
• Antyspam: 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: błędy, awarie krytyczne i odrzucenia smtpd; pliki dziennika smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Starszy serwer proxy SMTP/S: usługi awarrensmtp, awarrenmta; pliki dziennika awarrensmtp.log, awarrenmta.log.
• POP/IMAP Proxy: Usługa warren, plik dziennika warren.log.

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 bezprzewodowy: Usługa awed, plik dziennika awed.log.
• Klienci bezprzewodowi: sprawdzić komunikację między klientem a AP/APX w wc_remote.log.
• Uwierzytelnianie Wi-Fi: usługa wifiauth, plik dziennika wifiauth.log.
• Hotspot: usługi hostapd, hotspotd; pliki dziennika hostapd.log, hotspotd.log.
• RED: usługa RED, plik dziennika red.log.
• SNMP: Usługa snmpd, plik dziennika snmpd.log.
• Usługa Syslog: plik dziennika syslog.log.
• Licencja: Usługa licencjonowania, plik dziennika licensing.log.
• Aktualizacje systemowe: usługa u2d, plik dziennika u2d.log.
• Narzędzia VMware: Usługa vmtool, plik dziennika vmtool.log.

W przypadku problemów z licencją, Air-Gap lub wzorcami pliki licensing.log i u2d.log są pierwszymi technicznymi punktami diagnostycznymi. Procedurę obsługi pliku licencji, 180-dniowego okresu oraz ręcznych aktualizacji wzorców opisano w artykule Obsługa licencjonowania Air-Gap i aktualizacji wzorców 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 sygnatur: Usługa sigdb, plik dziennika sigdb.log.
• Baza danych raportów: kontekst Report DB, plik dziennika reportdb.log.
• Baza danych migracji: Report Migration, plik dziennika reportmigration.log.
• Garner: Usługa garner, plik dziennika garner.log.
• iView: 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 Central.

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 Central.
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