Przejdz do tresci
Avanet

Przypisywanie dzienników usług Sophos Firewall

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:

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

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

  • Uruchamianie systemu: sysinit.log; sprawdzić w pierwszej kolejności przy problemach z uruchamianiem i Failsafe.
  • 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.
  • Kanał komunikacji między określonymi komponentami i ich usługami: garner.log; w przypadku Central Management i reporting sprawdzić również odpowiednie wpisy pluginó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 Fusion 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; 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.

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. W SFOS 22/23 pojedyncze żądania proxy WWW pojawiają się tutaj tylko wtedy, gdy awarrenhttp działa z włączonym debugowaniem; zastosować procedurę zbierania danych opisaną poniżej.
  • Kategoryzacja/reputacja stron: usługa nSXLd, plik dziennika nSXLd.log.
  • Aktualizacje kategorii (SFOS 22/23): plik dziennika catUpdateLog – zachować wielkość liter, bez końcówki .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.

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.

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

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 (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 logowania SSO do WebAdmin, Captive Portal, VPN Portal, IPsec VPN i SSL VPN.
  • RADIUS SSO: Mapowanie użytkownik-IP przez accounting w access_server.log. RADIUS SSO z accountingiem opisuje konfigurację i odbiór.
  • 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. 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.
  • 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

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 Fusion, 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.
  • 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 wysyłanych do SophosLabs.
  • Heartbeat do Sophos Fusion: 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 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.

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.
  • Nawiązywanie 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

  • 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. Mail Protection w Legacy mode opisuje konfigurację i test end-to-end.
  • POP/IMAP Proxy: Usługa warren, plik dziennika warren.log. Skanowanie POP3 i IMAP na Sophos Firewall opisuje konfigurację i test end-to-end.

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.
  • Hotspot: usługi hostapd, hotspotd; pliki dziennika hostapd.log, hotspotd.log.
  • RED: usługa RED, plik dziennika red.log. Zależnie od typu i instancji RED mogą również występować red-<serial ID of RED>.log i red-<RED ID>.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.
  • Migracja konfiguracji (SFOS 22/23): plik dziennika migration.log; nie mylić go z reportmigration.log, który dotyczy migracji raportów.
  • 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 Fusion.

Inne aktualne pliki dziennika SFOS 22

Poniższe pliki są rzadziej potrzebne w codziennym rozwiązywaniu problemów z ruchem, ale należą do aktualnej mapy SFOS 22. Zostały pogrupowane według funkcji, aby nie wyciągać pochopnych wniosków o przyczynie tylko 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 dzienników i utrzymanie danych lokalnych: syslog-ng.log pokazuje tłumienie kolejnych zdarzeń; reportdb_v9.log należy do starej bazy raportów. dbcleanup.log, readobject.log, fstrim.log i logrotate.log dotyczą czyszczenia bazy danych, wewnętrznego odczytu obiektów, operacji trim systemu plików i rotacji dzienników.
  • ATR, NDR i FastPath: atr-service.log pokazuje uruchamianie i zatrzymywanie usługi ATR. ndr.log i ndr_agent.log obejmują licencję NDR, konfigurację, start agenta i przetwarzanie metadanych; vfpdf.log dotyczy metadanych NDR 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 użytkowników; openvpn-status0.log, openvpn-status1.log i dalsze numerowane pliki pokazują aktywne połączenia SSL VPN dla poszczególnych procesów.
  • Sieć i HA: dhcprelay.log dotyczy DHCP Relay. ha.log pokazuje powodzenie lub błąd zestawienia HA oraz zmiany stanu; filesync.log synchronizację plików wybranych usług do urządzenia Auxiliary.
  • Central, wdrażanie i ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log i fwcm-frpcd.log obejmują informacje o strefach i interfejsach wysyłane do Central, połączenie, przesyłaną konfigurację oraz Fast Reverse Proxy. ssod.log zawiera informacje o firmware i kopiach Central, zt.log i zerotouch.log warianty Zero Touch, a ztna-connector.log lokalny ZTNA Connector.
  • Kopia zapasowa, firmware, Air Gap i certyfikaty: interfacemapping.log rejestruje mapowanie interfejsów podczas odtwarzania, legacyconversion.log kopie bez Secure Storage Master Key, a fwmgmt.log instalację i zarządzanie firmware. u2d_airgap.log dotyczy aktualizacji Air Gap, cps_messages.log błędów hotfixów, a letsencrypt.log wraz z applog.log certyfikatów Let’s Encrypt.
  • Sprzęt i stan systemu: npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log i xgs-pport-wait.log obejmują start, komunikację, firmware, port szeregowy, stan NPU i tworzenie interfejsów fizycznych. raid.log pokazuje programowy RAID, lcd.log wyświetlacz sprzętowy. system-monitor/cpu_trigger.log zapisuje stan systemu przy wysokim obciążeniu CPU; system-monitor/memory_trigger.log dotyczy w SFOS 22 wysokiego obciążenia pamięci.
  • Usługi chmurowe i platformowe: iaasd.log rejestruje provisioning i sprawdzanie licencji w Azure, waagent.log agenta Azure i jego Health Monitoring; vmtool.log należy do 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

Który plik dziennika jest najważniejszy dla Sophos Firewall?

To zależy od problemu. W przypadku reguł zapory ważny jest firewall_rule.log, dla NAT nat_rule.log, dla IPsec strongswan.log, dla SSL VPN sslvpn.log, a dla IPS i Application Control często ips.log. Log Viewer pozostaje jednak najlepszym pierwszym punktem analizy pojedynczych połączeń.

Co to jest CTR w dziennikach Sophos Firewall?

W wielu kontekstach Sophos skrót CTR oznacza Consolidated Troubleshooting Report. Dla administratorów ważne jest, że CTR lub pakiet dzienników diagnostycznych pomaga pomocy technicznej, ale nie zastępuje precyzyjnego opisu błędu z czasem, adresami IP, użytkownikiem, nazwą tunelu, Rule ID i krokami odtwarzania.

Kiedy potrzebny jest Advanced Shell?

Advanced Shell jest przydatny, gdy trzeba sprawdzić lokalne pliki dziennika za pomocą tail, grep lub less, skontrolować stan usługi albo gdy pomoc techniczna Sophos potrzebuje szczegółowych danych. Do wielu testów wstępnych wystarczą Log Viewer, Policy Test i Packet Capture w WebAdmin.

Czy rejestrowanie debugowania powinno pozostać na stałe aktywne?

Nie. Debugowanie generuje dużo danych i może zużywać przestrzeń dyskową. Powinno być używane tylko dla usługi, której dotyczy problem, na czas krótkiego, powtarzalnego testu, a następnie wyłączone.

Dlaczego w Log Viewer nie widać oczekiwanych zdarzeń zapory?

Często w danej regule nie jest aktywna opcja Log firewall traffic, wybrano niewłaściwy okres lub filtr albo ruch nie dociera do zapory. Jeśli przepływ pakietów jest niejasny, należy użyć łącznie Log Viewer i Packet Capture.

Czy dzienniki lokalne są lepsze niż Central Reporting lub Syslog?

Są to różne narzędzia. Lokalne dzienniki pomagają w szczegółowej analizie bezpośrednio na zaporze. Central Reporting nadaje się do raportów i historii w Sophos Fusion. Syslog jest lepszy dla własnego SIEM, SOC lub długoterminowego przechowywania.