Sophos Firewall Log Viewer nie pokazuje nowych logów

Jeśli Log Viewer w SFOS 22 nie pokazuje nowych zdarzeń, nie należy ponownie uruchamiać usługi wyłącznie na podstawie podejrzenia. Najpierw trzeba ustalić, czy brakuje tylko oczekiwanego wpisu, czy lokalny widok dzienników całkowicie przestał się aktualizować. W zakresie zwykłej obsługi, filtrów i interpretacji pól należy najpierw skorzystać z artykułu Prawidłowe korzystanie z Log Viewer na Sophos Firewall. Bezpieczna, szybka procedura dla zatrzymanego widoku wygląda następująco:

W Log Viewer sprawdzić Pause, moduł, zakres czasu i ustawione filtry, a następnie wykonać Reset i Refresh.
W odpowiedniej regule zapory sprawdzić Log firewall traffic, a w sekcji System services > Log settings typ dziennika Firewall w kolumnie Local reporting.
Z dobrze znanego klienta testowego nawiązać krótkie połączenie i zanotować czas.
W sekcji Diagnostics > Packet capture > Configure ustawić wąski filtr BPF, włączyć przechwytywanie i sprawdzić, czy ruch dociera do zapory oraz która Rule ID jest przetwarzana.
Po teście wyłączyć przechwytywanie. Tylko jeśli nie pojawiają się również inne oczekiwane zdarzenia, zapisać wersję SFOS, pełną kompilację i czas ostatniego widocznego wpisu.
W SFOS 22 nie stosować workaroundów Garner ani bazy danych ze starszej wersji. Sprawdzić bieżącą wersję serwisową i przekazać dane diagnostyczne do Sophos Support, jeśli wszystkie lokalne dzienniki się zatrzymały.
Zachowany poniżej workaround z Garner dotyczy wyłącznie SFOS 21.5.1 MR1 Build 261 i dokładnie udokumentowanego symptomu.

Dzięki temu diagnostyka pozostaje przejrzysta: błędny filtr lub reguła, która nie rejestruje ruchu, nie zostaną pomylone z awarią bazy danych systemu logowania.

Dlaczego może brakować pojedynczego wpisu

Log Viewer zwykle aktualizuje się automatycznie. Pokazuje jednak tylko zdarzenia, które wybrany moduł zapisuje lokalnie i których nie ukrywa bieżący widok.

Typowe przyczyny, które nie oznaczają technicznej awarii Log Viewer:

Włączono Pause: nowe zdarzenia pojawiają się dopiero po wznowieniu widoku lub ręcznym odświeżeniu.
Nieprawidłowy moduł, zakres czasu lub filtry: Reset usuwa wszystkie filtry; następnie ponownie wybiera się właściwy moduł.
Rule Logging jest wyłączony: sesje zapory pojawiają się tylko wtedy, gdy w faktycznie dopasowanej regule włączono Log firewall traffic.
Local reporting jest wyłączony: w sekcji System services > Log settings wymagany typ dziennika musi być wybrany w kolumnie Local reporting.
Połączenie jest nadal otwarte: sesje zapory są zwykle rejestrowane przy zdarzeniu Destroy, gdy połączenie się kończy. Wpis może więc pojawić się później niż pierwsze nawiązanie połączenia.
Sesja kończy się bez zdarzenia Destroy: na przykład po utracie połączenia z Internetem sesja może zostać zamknięta bez utworzenia wpisu w dzienniku. Wpis nie jest wtedy tylko opóźniony — nie powstaje wcale.
Ruch nie dociera do zapory: brak wpisu nie dowodzi, że zapora odrzuciła pakiet. Połączenie może zostać wcześniej zatrzymane przez klienta, router poprzedzający zaporę, DNS lub inną ścieżkę.
Firewall Log suppression agreguje powtórzenia: kolejne zdarzenia zapory objęte mechanizmem suppression mogą zostać zebrane w Log occurrence, zamiast pojawiać się jako wiele osobnych wierszy.

Jeśli podczas innych testów Log Viewer nadal pokazuje nowe zdarzenia systemowe lub zapory, sam widok zasadniczo działa. Przyczyny należy wtedy szukać raczej w Rule Logging, wyborze modułu, filtrach, zakończeniu sesji lub rzeczywistej ścieżce pakietów. Do takiego rozgraniczenia lepiej nadaje się procedura Sprawdzanie reguły zapory za pomocą Log Viewer, Policy Tester i Packet Capture.

Generowanie kontrolowanego przepływu testowego

Powtarzalny test jest bardziej wiarygodny niż czekanie na losowy ruch użytkowników. W poniższym przykładzie klient testowy ma możliwy do zmiany adres IP 10.20.30.25. Na kliencie – nie w powłoce zapory – nawiązuje się krótkie połączenie HTTPS:

curl -I https://example.com/

example.com jest zarezerwowaną domeną przykładową. Do testu można też użyć własnej, znanej i dozwolonej usługi HTTPS. Ważne, aby proces ponownie zakończył połączenie oraz aby znane były czas, adres IP klienta i cel.

Następnie sprawdza się kolejno:

W sekcji Rules and policies > Firewall rules sprawdzić, czy w oczekiwanej regule włączono Log firewall traffic.
W Log Viewer wykonać Reset, wybrać moduł Firewall i odpowiedni zakres czasu, a następnie filtrować według 10.20.30.25.
Odczekać kilka sekund i raz ręcznie odświeżyć widok, ponieważ zdarzenie zapory może pojawić się dopiero po zakończeniu sesji.
Jeśli wpisu nadal nie ma, otworzyć Diagnostics > Packet capture, kliknąć Configure, w polu Enter BPF string wpisać wąski filtr host 10.20.30.25 i zapisać. Adres IP należy zastąpić rzeczywistym adresem klienta testowego.
Włączyć Packet capture, powtórzyć test jeden raz, a następnie wyłączyć przechwytywanie. Dzięki temu zapis jest ograniczony do znanego klienta i krótkiego przedziału czasu.

Obserwacja wyznacza kolejny krok:

Packet Capture nie widzi ruchu testowego: szukać przyczyny przed zaporą lub na kliencie.
Packet Capture pokazuje inną Rule ID: sprawdzić faktycznie dopasowaną regułę i jej ustawienia rejestrowania.
Pojawiają się inne nowe zdarzenia Log Viewer: widok nie zatrzymał się całkowicie; dalej sprawdzać filtry, typ dziennika i konkretną regułę.
Packet Capture potwierdza przepływ, Rule Logging i Local reporting są prawidłowe, ale wszystkie nowe zdarzenia nadal się nie pojawiają: sprawdzić kompilację i lokalne przetwarzanie dzienników.

Packet Capture pokazuje przepływ pakietów, ale nie naprawia widoku dzienników. Jeśli bufor jest pełny i nie wybrano Wrap capture buffer once full, SFOS automatycznie zatrzymuje przechwytywanie; Clear zwalnia bufor na kolejny test. Sposób obsługi i wartości stanu opisano w artykule Packet Capture w WebAdmin Sophos Firewall.

Klasyfikacja awarii w SFOS 22

Sophos Known Issues List ogranicza NC-175936 do SFOS 21.5.1 MR1 Build 261 i wyraźnie stwierdza, że problem rozwiązano w wersji 22. Powiązany restart Garner nie jest więc procedurą naprawczą dla SFOS 22.

Informacje o wydaniu SFOS 22 wymieniają dalsze zmiany w Logging Framework. SFOS 22.0 GA Build 411 naprawił NC-169237, w którym uszkodzenie bazy danych powodowało utratę zdarzeń Log Viewer. SFOS 22.0 MR1 Build 490 naprawił NC-152553, czyli nieudany mechanizm odzyskiwania active.db. Najnowsza wymieniona tam wersja, SFOS 22.0 MR2 Build 546, poprawia wydajność Log Viewer w ramach NC-181520.

Wpisy te potwierdzają usunięte błędy, ale nie wskazują przyczyny bieżącej awarii. W SFOS 22 należy zapisać dokładną wersję i kompilację, sprawdzić obsługiwaną ścieżkę aktualizacji do bieżącej wersji serwisowej oraz nie zmieniać plików bazy danych ani nie uruchamiać ponownie usługi rejestrowania z powłoki, jeśli zdarzeń nadal brakuje.

Sprawdzanie `NC-175936` na SFOS 21.5.1 MR1 Build 261

Sophos dokumentuje błąd NC-175936 dla SFOS 21.5.1 MR1 Build 261: może brakować pliku /tmp/eventlogs/active.db, przez co Log Viewer przestaje pokazywać nowe dane. Według Sophos zapora nadal przetwarza ruch i realizuje funkcje bezpieczeństwa. To stwierdzenie opisuje znany błąd i nie stanowi ogólnego potwierdzenia prawidłowego stanu zapory bez logów.

Sophos wyraźnie stwierdza również, że problem rozwiązano w wersji 22. Dlatego poniższego historycznego workaroundu nie stosuje się w SFOS 22 ani na innej kompilacji wyłącznie na podstawie podobnego symptomu.

Kontrole tylko do odczytu w Advanced Shell

Najpierw zapisuje się pełną kompilację, czas, ostatnie widoczne zdarzenie oraz – w przypadku HA – węzeł, którego dotyczy problem. Jeśli WebAdmin nadal działa, przed zmianą należy zabezpieczyć garner.log oraz, jeśli to możliwe, Consolidated Troubleshooting Report.

Następnie łączy się przez udokumentowany dostęp SSH do Sophos Firewall i otwiera Advanced Shell. Poniższe polecenia tylko odczytują stan pamięci masowej, plik i dziennik:

df -kh /tmp
ls -l /tmp/eventlogs/active.db
tail -n 200 /log/garner.log

df -kh /tmp pokazuje, czy w systemie plików jest jeszcze wolne miejsce. ls -l potwierdza, czy istnieje active.db; jeśli pliku brakuje, w zależności od kompilacji powłoka może wyświetlić komunikat taki jak No such file or directory. W garner.log sprawdza się błędy występujące w udokumentowanym czasie testu. Inne nazwy usług i pliki dzienników opisano w artykule Przypisywanie dzienników usług Sophos Firewall.

Jeśli /tmp jest pełny, plik istnieje, kompilacja jest inna lub symptom nie jest jednoznaczny, nie wykonuje się poniższego ponownego uruchomienia. Plików w /tmp/eventlogs nie należy usuwać, kopiować ani tworzyć ręcznie.

Jednorazowe, kontrolowane ponowne uruchomienie Garner

⚠️ Polecenie zmieniające stan: ten workaround dotyczy wyłącznie potwierdzonego symptomu na SFOS 21.5.1 MR1 Build 261. Wcześniej należy zabezpieczyć dzienniki i stan systemu. W klastrze HA nie należy bez weryfikacji wykonywać polecenia na obu węzłach. Nie należy wielokrotnie restartować Garner ani ręcznie naprawiać lub usuwać active.db.

Dla NC-175936 Sophos podaje w Advanced Shell dokładnie to polecenie:

service garner:restart -ds nosync

Polecenie zostało przejęte do tego artykułu z aktualnej Sophos Known Issues List, ale nie przetestowano go laboratoryjnie na appliance. Ponownego uruchomienia usługi nie można cofnąć; jeśli pliku nadal nie ma lub zdarzenia wciąż się nie pojawiają, należy przerwać działania i przekazać Sophos Support zapisany stan sprzed zmiany. Po jednorazowym restarcie plik oraz najnowsze komunikaty Garner ponownie sprawdza się tylko do odczytu:

ls -l /tmp/eventlogs/active.db
tail -n 50 /log/garner.log

Następnie w Log Viewer wykonać Reset i Refresh oraz powtórzyć ten sam krótki przepływ testowy. Działanie można uznać za skuteczne dopiero wtedy, gdy pojawi się nowe zdarzenie z właściwym znacznikiem czasu. Sama obecność active.db nie dowodzi jeszcze, że cała ścieżka logowania ponownie działa.

Gdy SFOS 22 nadal nie pokazuje nowych zdarzeń

Jeśli Packet Capture pokazuje kontrolowany przepływ testowy w SFOS 22, Rule Logging i Local reporting są prawidłowe, a nowych zdarzeń nadal brakuje we wszystkich modułach, najpierw planuje się obsługiwaną ścieżkę aktualizacji firmware SFOS do bieżącej wersji serwisowej. Jeśli problem pozostaje w aktualnej kompilacji, nie ingeruje się w bazę danych ani usługi.

Dla zgłoszenia do pomocy technicznej należy zabezpieczyć co najmniej:

model appliance, wersję SFOS i pełną kompilację;
w przypadku HA węzeł, którego dotyczy problem, oraz jego rolę;
ostatni widoczny znacznik czasu w Log Viewer i czas przepływu testowego;
moduł, filtry, Rule ID, Source, Destination i Service testu;
stan Log firewall traffic i Local reporting;
wynik Packet Capture;
dla dokładnie pasującego błędu 21.5.1 MR1 wyniki df -kh /tmp i ls -l /tmp/eventlogs/active.db;
garner.log, w razie potrzeby fwlog.log i iview.log, a jeśli to możliwe, także CTR przed kolejnymi zmianami;
informację, czy restart Garner wykonano jeden raz i co się po nim zmieniło.

Dzięki temu Sophos może odróżnić błędy wyświetlania, bazy danych, pamięci masowej, usługi i wersji bez zaciemniania pierwotnej przyczyny przez powtarzane próby naprawy.