Prawidłowe korzystanie z Log Viewer na Sophos Firewall
Log Viewer jest często najszybszym punktem wyjścia podczas analizy usterki: która reguła zapory obsłużyła ruch, która reguła NAT została użyta, który użytkownik został rozpoznany i który moduł bezpieczeństwa zablokował połączenie? Aby odpowiedź była prawidłowa, muszą pasować moduł, zakres czasu, filtry oraz moment utworzenia wpisu.
Log Viewer pokazuje zarejestrowane zdarzenia. Nie jest Packet Capture ani kompletną historią połączeń. Brak wpisu nie dowodzi więc ani odrzucenia pakietu, ani tego, że pakiet dotarł do zapory.
Aby analiza była wiarygodna, należy zawsze zanotować źródło, cel, usługę, dokładny czas testu i oczekiwany kierunek. Następnie generuje się dokładnie jeden nowy przepływ testowy i wyszukuje go w odpowiednich modułach.
Analiza testu w siedmiu krokach
- W odpowiedniej regule zapory sprawdzić Log firewall traffic, a w regule SSL/TLS opcję Log connections.
- W System services > Log settings upewnić się, że wymagany typ logu jest włączony w Local reporting.
- Otworzyć Log viewer w prawym górnym rogu WebAdmin i wybrać właściwy moduł.
- Ustawić filtr czasu, a następnie za pomocą Add filter zawęzić widok najpierw do źródłowego adresu IP, docelowego adresu IP i usługi.
- Wygenerować nowy, krótki przepływ testowy i zanotować jego dokładny czas.
- W Detailed view sprawdzić Rule ID, NAT ID, akcję, interfejsy, użytkownika i pola specyficzne dla modułu.
- Jeśli wpis nie odpowiada obserwowanemu zachowaniu, przed zmianą reguły skorelować ten sam test z Packet Capture.
Ta kolejność rozdziela trzy często mylone pytania: czy log w ogóle został utworzony? Która polityka podjęła decyzję? Czy pakiety rzeczywiście weszły i ponownie wyszły?
Dlaczego wpisy nie zawsze pojawiają się od razu
Log Viewer aktualizuje widok automatycznie. Sesja zapory jest jednak zwykle rejestrowana dopiero wtedy, gdy zapora otrzyma zdarzenie Destroy i zamknie połączenie. Przy długiej sesji wpis może więc pojawić się później niż pierwsze żądanie.
Jeśli połączenie zostanie przerwane bez otrzymania przez zaporę zdarzenia Destroy, na przykład przy utracie połączenia internetowego, oczekiwanego logu sesji może w ogóle nie być. Połączenia SSL/TLS są rejestrowane po udanym handshake i podczas zamykania. Do krótkiego testu lepsze jest więc świadomie zakończone połączenie niż stale otwarta sesja przeglądarki, strumieniowania lub HTTP/2.
Odświeżenie strony w przeglądarce nie musi tworzyć nowego połączenia. W zależności od aplikacji do powtarzalnego testu nadaje się prywatne okno przeglądarki, ponownie uruchomiony proces klienta lub krótkie wywołanie:
curl -I https://example.com/
Polecenie uruchamia się na kliencie testowym, nie w powłoce zapory. example.com jest zarezerwowaną domeną przykładową i można ją zastąpić znaną, dozwoloną usługą.
Wybór właściwego modułu
Jeden przepływ ruchu może dotyczyć kilku modułów logowania. Moduł Firewall może na przykład pokazać, że reguła LAN-to-WAN zezwoliła na połączenie, podczas gdy Web filter, Application filter, IPS lub SSL/TLS inspection później blokuje ten sam przepływ albo obsługuje go w inny sposób.
Dlatego pojedynczy zielony wpis zapory nie wystarcza przy problemach z WWW lub bezpieczeństwem. Moduły należy skorelować dla tego samego znacznika czasu i tych samych adresów:
- Firewall: decyzja reguły, NAT, interfejsy, porty i podstawowy stan połączenia.
- Web filter: decyzje dotyczące adresu URL, kategorii i polityki WWW.
- SSL/TLS inspection: decyzje dotyczące certyfikatu, handshake i deszyfrowania.
- Application filter: rozpoznana aplikacja i akcja Application Control.
- IPS: zdarzenia sygnatur lub anomalii.
- VPN: zestawienie i stan odpowiedniego komponentu VPN.
- Authentication: rozpoznany użytkownik oraz udane lub nieudane uwierzytelnienie.
- System: zdarzenia systemowe i wywołane przez administratora.
- SD-WAN: profil SD-WAN, SLA i użycie trasy.
To, które typy logów pojawiają się lokalnie, ustala się w System services > Log settings w sekcji Local reporting. Te Event Logs nie są tym samym co On-box Reports. Central reporting i syslog są osobnymi celami i muszą zostać włączone niezależnie.
Różnica między Standard view i Detailed view
Standard view nadaje się do szybkiego odczytu. Kolumny można wyświetlać i ukrywać, a kliknięcie wartości może od razu użyć jej jako filtra. W technicznej weryfikacji ważniejsza jest Detailed view, ponieważ pokazuje źródłowe nazwy pól i dodatkowe wartości.
Istotny szczegół NAT: jeśli używany jest przetłumaczony adres źródłowy inny niż domyślny adres MASQ, Standard view może mimo to pokazać adres MASQ jako adres wychodzący. Rzeczywisty przetłumaczony adres źródłowy znajduje się w Detailed view w polu src_trans_ip.
Typowe pola testu zapory to:
- źródłowy i docelowy adres IP oraz port źródłowy i docelowy
- In interface i Out interface
- Firewall Rule ID i NAT Rule ID
- Action lub status
- nazwa użytkownika, jeśli rozpoznano tożsamość
- przetłumaczone źródło i cel
- Log component i Log subtype
Nazwa pola lub identyfikator nie wyjaśnia automatycznie przyczyny. Rule ID należy porównać z aktualną bazą reguł, NAT ID z odpowiednią regułą NAT, a identyfikator polityki bezpieczeństwa z właściwym modułem.
Ustawianie filtrów tak, aby pozostał właściwy przepływ
Log Viewer oferuje cztery poziomy filtrowania:
- Module: ogranicza widok do Firewall, Web, IPS, VPN lub innego obszaru.
- Time: ogranicza zdarzenia do okresu testowego.
- Add filter: łączy konkretne pole, warunek i wartość.
- Free text search: wyszukuje na przykład port, adres IP, użytkownika lub nazwę reguły i działa również z zanonimizowanymi informacjami.
Zwykły test połączenia zaczyna się od źródłowego adresu IP, docelowego adresu IP i portu docelowego. Następnie widok zawęża się za pomocą Rule ID, użytkownika lub Action. Reset usuwa wszystkie filtry. Jest to ważne, ponieważ stary filtr czasu lub pola może łatwo sprawić wrażenie, że viewer nie otrzymuje nowych zdarzeń.
Liczba dostępnych wpisów zależy od wielkości dysku i lokalnej retencji. Log Viewer nie zastępuje więc długoterminowego, zabezpieczonego przed manipulacją przechowywania. Do tego służy Central Firewall Reporting lub wysyłanie syslog do SIEM.
Prawidłowe użycie Pause, Refresh i eksportu CSV
Pause zatrzymuje automatyczne odświeżanie widoku. Pomaga to spokojnie odczytać lub skopiować wiersz. Nie zatrzymuje rejestrowania na zaporze. Refresh ręcznie przeładowuje widok, a Export pobiera aktualnie dostępne logi jako CSV.
Przed eksportem należy udokumentować moduł, zakres czasu i filtry. CSV może zawierać wewnętrzne adresy IP, nazwy użytkowników, adresy URL i relacje komunikacyjne, dlatego powinien trafić do chronionego procesu wsparcia lub analizy.
Jeśli włączona jest Data anonymization, wartości identyfikujące, takie jak nazwa użytkownika, adres IP, MAC i e-mail, są wyświetlane w chronionej postaci. Deanonimizacja wymaga uprawnionej osoby i jej danych logowania. Zrzut ekranu lub eksport powinien mimo to zawierać tylko wiersze potrzebne do danego przypadku.
Log suppression i Log occurrence
W System services > Log settings zapora może tłumić następujące po sobie identyczne zdarzenia Firewall. Oszczędza to pamięć i przetwarzanie. Tłumienie wpływa nie tylko na logi lokalne, lecz także na Sophos Central i skonfigurowane cele syslog.
W Log Viewer pole Log occurrence pokazuje, ile razy wystąpiło zgrupowane zdarzenie. Jeden wiersz może więc reprezentować wiele powtórzeń. Nie wolno automatycznie liczyć go jako jednego pakietu lub jednego połączenia.
Przed zmianą Log suppression należy sprawdzić, czy obecna ilość logów rzeczywiście powoduje problem. Przy krótkiej diagnostyce zwykle wystarczy świadomie odczytać Log occurrence. Zmiana globalna wpływa także na zewnętrzne cele logowania i nie powinna być wykonywana tylko po to, aby uzyskać zrzut ekranu.
Prawidłowa interpretacja Invalid traffic
Invalid traffic oznacza, że conntrack nie mógł przypisać pakietu do bieżącego połączenia. Może to wystąpić przy asymetrycznej ścieżce, wygasłej sesji, nieoczekiwanych flagach TCP lub dodatkowych pakietach RST i FIN. Nie oznacza automatycznie ataku ani usterki zapory.
Jeśli równocześnie występuje problem z połączeniem, za pomocą Packet Capture należy sprawdzić oba kierunki. Źródło, cel, flagi TCP, interfejsy i znaczniki czasu muszą należeć do tego samego przepływu. Zwiększenie Tcp Connection Establishment Idle Timeout może zmniejszyć liczbę takich logów, ale nie usuwa podstawowej przyczyny związanej ze ścieżką lub sesją. Dlatego nie należy zmieniać tej wartości na próbę.
Pełny proces analizy odrzuceń z Reason, Rule ID i specjalnym Firewall ID 0 opisano w artykule Analiza odrzuconych pakietów na Sophos Firewall.
Kontrolowana zmiana reguł z poziomu Log Viewer
W zależności od zdarzenia Log Viewer może otwierać bezpośrednio polityki WWW, reguły zapory lub reguły SSL/TLS. Jest to wygodne, ale nie skraca kontroli technicznej. Przed edycją należy sprawdzić Rule ID, nazwę i pozycję reguły, strefy, obiekty, usługę, przypisanie użytkownika oraz istniejące sesje.
Szeroka reguła zezwalająca, globalny wyjątek WWW lub wyłączona SSL/TLS inspection mogą ukryć objaw, a jednocześnie stworzyć nową lukę bezpieczeństwa. Zmiany ogranicza się więc do potwierdzonego przepływu, testuje w oknie serwisowym, a następnie ponownie weryfikuje nowy przepływ w Log Viewer i w razie potrzeby w Packet Capture.
Gdy brakuje oczekiwanych logów
Pusty wynik sprawdza się w następującej kolejności:
- Sprawdzić Pause, moduł, zakres czasu i filtry, a następnie użyć Reset oraz Refresh.
- Sprawdzić logowanie reguły i Local reporting dla wymaganego typu logu.
- Utworzyć nowe, świadomie zakończone połączenie ze znanym znacznikiem czasu.
- Za pomocą Packet Capture potwierdzić, że ruch dociera do zapory i która Rule ID go obsługuje.
- Sprawdzić pozostałe moduły pod kątem zdarzeń tego samego przepływu.
- Dopiero jeśli cały lokalny widok nie otrzymuje nowych zdarzeń, zbadać ścieżkę viewer lub usługi logowania.
Wersyjny proces diagnostyczny dla całkowicie zatrzymanego viewer opisuje artykuł Log Viewer nie pokazuje nowych logów. Restart usługi ani ingerencja w lokalną bazę logów nie należą do zwykłych czynności obsługowych.
Log Viewer w środowiskach HA
Każdy węzeł HA przechowuje tylko logi i raporty ruchu, który sam obsłużył. Szczególnie w trybie active-active lub po failover oczekiwany wpis może więc znajdować się na drugim węźle. Należy wspólnie udokumentować czas, rolę węzła i Connection served by.
Central Firewall Reporting lub syslog mogą zapewnić widok centralny. Nie zastępują jednak kontroli konkretnego węzła podczas analizy określonej zmiany roli HA, lokalnego błędu usługi lub ścieżki ruchu w chwili zdarzenia.
Dlaczego dozwolone połączenie pojawia się później w Log Viewer?
Destroy, gdy połączenie się kończy. Długa lub ponownie używana sesja może więc pojawić się z opóźnieniem. Do testu należy utworzyć nowe, krótkie i świadomie zakończone połączenie.