Przejdz do tresci
Avanet

Sophos Firewall Log Viewer nie pokazuje nowych logów

Sophos Firewall

Jeśli Log Viewer nie pokazuje nowych zdarzeń, nie należy od razu ponownie uruchamiać usługi. 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:

  1. W Log Viewer sprawdzić Pause, moduł, zakres czasu i ustawione filtry, a następnie wykonać Reset i Refresh.
  2. W odpowiedniej regule zapory sprawdzić Log firewall traffic, a w sekcji System services > Log settings typ dziennika Firewall w kolumnie Local reporting.
  3. Z dobrze znanego klienta testowego nawiązać krótkie połączenie i zanotować czas.
  4. Za pomocą Packet capture sprawdzić, czy ruch dociera do zapory i która Rule ID jest przetwarzana.
  5. Tylko jeśli nie pojawiają się również inne oczekiwane zdarzenia, zapisać wersję SFOS, pełną kompilację i czas ostatniego widocznego wpisu.
  6. Workaround z Garner stosować wyłącznie na SFOS 21.5 MR1 Build 261 i tylko w przypadku opisanego poniżej 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.
  • 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:

  1. W sekcji Rules and policies > Firewall rules sprawdzić, czy w oczekiwanej regule włączono Log firewall traffic.
  2. W Log Viewer wykonać Reset, wybrać moduł Firewall i odpowiedni zakres czasu, a następnie filtrować według 10.20.30.25.
  3. Odczekać kilka sekund i raz ręcznie odświeżyć widok, ponieważ zdarzenie zapory może pojawić się dopiero po zakończeniu sesji.
  4. Jeśli wpisu nadal nie ma, w sekcji Diagnostics > Packet capture ustawić wąski filtr, na przykład host 10.20.30.25, i powtórzyć ten sam test.

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. Sposób obsługi i wartości stanu opisano w artykule Packet Capture w WebAdmin Sophos Firewall.

Sprawdzanie NC-175936 na SFOS 21.5 MR1 Build 261

Sophos dokumentuje błąd NC-175936 dla SFOS 21.5 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.

Aktualna Sophos Known Issues List nie podaje jednoznacznego pola z wersją zawierającą poprawkę dla 21.5 MR2. Dlatego poniższego workaroundu nie stosuje się na innych kompilacjach 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 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. 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.

Inne kompilacje i powtarzające się awarie

Sophos naprawił inne, ale nie identyczne błędy związane z bazą danych Log Viewer. SFOS 22.0 MR1 Build 490 zawiera w ramach NC-152553 poprawkę nieudanego mechanizmu odzyskiwania active.db; NC-169237, dotyczący utraty zdarzeń Log Viewer wskutek uszkodzenia bazy danych, jest wymieniony dla SFOS 21.5 MR2 Build 323 i SFOS 22.0 GA Build 411. Te identyfikatory nie potwierdzają poprawki dla NC-175936 ani nie wskazują automatycznie przyczyny bieżącej awarii.

W przypadku starszej kompilacji najpierw planuje się obsługiwaną ścieżkę aktualizacji firmware SFOS. Na aktualnej kompilacji lub po nieskutecznym restarcie Garner nie podejmuje się dalszych ingerencji 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;
  • 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łąd widoku, bazy danych, pamięci masowej, usługi i błąd specyficzny dla wersji, bez zacierania pierwotnej przyczyny przez kolejne próby naprawy.