Prawidłowe korzystanie z Log Viewer na Sophos Firewall

W SFOS 22 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

1. W odpowiedniej regule zapory sprawdzić Log firewall traffic, a w regule SSL/TLS opcję Log connections.
2. W System services > Log settings upewnić się, że wymagany typ logu jest włączony w Local reporting.
3. Otworzyć Log viewer (SFOS 22) lub Logs and policy test (SFOS 23) w prawym górnym rogu WebAdmin, a następnie wybrać właściwy moduł logów.
4. 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.
5. Wygenerować nowy, krótki przepływ testowy i zanotować jego dokładny czas.
6. W Detailed view sprawdzić Rule ID, NAT ID, akcję, interfejsy, użytkownika i pola specyficzne dla modułu.
7. 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?

Event Logs rejestrują nie tylko ruch, lecz także uwierzytelnianie, zdarzenia systemowe i zmiany konfiguracji; domyślnie są przechowywane lokalnie. Troubleshooting Logs to szczegółowe logi usług dostępne w WebAdmin lub CLI. Procedura analizy logów usług wyjaśnia dostęp i zbieranie danych debug. Debug zajmuje dodatkowe miejsce i trzeba go wyłączyć po zebraniu potrzebnych danych; nie jest przełącznikiem przywracającym brakujące Event Logs.

Do centralnego przesyłania logów zapora musi być zarejestrowana w Sophos Central Firewall Management. Następnie włącza się usługi Central i Send reports and logs to Sophos Central oraz wybiera wymagane typy logów w System services > Log settings. Analizowana dokumentacja SFOS 22 nazywa cel Sophos Fusion, a dokumentacja SFOS 23 — Sophos Central; należy kierować się wskazanymi polami interfejsu. Procedura Central Reporting obejmuje konfigurację i kontrolę odbioru.

Prawidłowe odczytywanie wpisów logu

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 przepływu testowego na podstawie okresu testu i 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. Zdarzenia Web Policy wymagają także włączenia Log firewall traffic w powiązanej regule zapory. Logi Wireless nie są dostępne w Log Viewer; należy je wysyłać do Sophos Fusion (dawniej Sophos Central) lub serwera syslog.

Granica Web Proxy: Dokumentacja SFOS 22/23 dotycząca zachowania logów opisuje tę ścieżkę proxy dla HTTP/HTTPS na portach 80 i 443: pasująca reguła Drop przekazuje pakiety przychodzące do Web Proxy, które wysyła użytkownikowi stronę blokady; bez pasującego wyjątku Web Exception log Firewall pokazuje Allowed, a log Web filter Blocked. Web Exceptions nadal obowiązują i mogą zezwolić na żądania pomimo Drop. Udokumentowana ścieżka Reject kończy przepływ przed przetwarzaniem przez proxy. Sprawdzać wspólnie regułę zapory, Web Policy i Web Exceptions; to udokumentowany scenariusz, nie uniwersalna gwarancja strony blokady dla każdej kompilacji lub trybu inspekcji.

Nierozstrzygnięta sprzeczność w dokumentacji: Pomoc SFOS 22/23 dotycząca formularza reguł opisuje uwierzytelnianie nieznanych użytkowników web przy włączonej opcji Use web authentication for unknown users, zezwala na pasujące Web Exceptions i w pozostałych przypadkach opisuje stronę blokady HTML. Natomiast poradnik logowania odrzuconego ruchu opisuje ciche odrzucanie i wiąże stronę blokady web z tą opcją uwierzytelniania. Nie wyciągać wniosku, że sama opcja określa odpowiedź. Zanim uzna się Drop za podstawę blokowania web, uzyskać pisemne wyjaśnienie Sophos dla dokładnej wersji, kompilacji i ścieżki przetwarzania albo przeprowadzić wyraźnie autoryzowaną weryfikację w izolowanym środowisku. Zapisać aktualną regułę i ustawienia do wycofania zmian; osobno sprawdzić HTTP i HTTPS, znanych/nieznanych użytkowników, uwierzytelnianie włączone/wyłączone oraz obecność/brak pasujących wyjątków. Korelować nowe przepływy z Rule ID, logami, Packet Capture i wynikami przeglądarki. Ani strona blokady, ani timeout nie dowodzą same w sobie blokowania. Przy nieoczekiwanym dostępie lub niejasnym wyniku wycofać zmiany testowe i eskalować; nie wdrażać w produkcji.

Na portach innych niż 80 i 443 pasująca reguła Drop odrzuca pakiety bezpośrednio; log Firewall pokazuje dropped. Przy Reject log Firewall pokazuje rejected, zarówno na 80/443, jak i na innych portach. Te obserwacje wymagają Log firewall traffic w pasującej regule. Web Exception może na przykład dopuścić aktualizacje Windows od Microsoft pomimo reguły Drop; nie uzasadnia to rozszerzania reguły bez analizy.

Reguła Allow i brak heartbeat

Inny przypadek niż Drop występuje, gdy reguła zapory, która rzeczywiście pasuje, ma Action Allow, opcja Block clients with no Heartbeat jest włączona, a endpoint nie wysyła heartbeat. Aby zaobserwować opisane logi, w tej regule musi być włączone Log firewall traffic. Przed wyszukiwaniem należy również sprawdzić wymagane typy logów w System services > Log settings > Local reporting; samo włączenie zewnętrznego celu logowania nie wystarcza do wyświetlania lokalnego.

• Porty inne niż 80 i 443: Zapora odrzuca pakiety tego endpointu. Log Firewall pokazuje dropped.
• Porty 80 i 443 w udokumentowanej ścieżce Web Proxy: Zapora przyjmuje pakiety przychodzące i przekazuje je do Web Proxy. Ponieważ endpoint nie wysyła heartbeat, system heartbeat podejmuje decyzję o blokowaniu; proxy wysyła użytkownikowi stronę blokady. Log Firewall pokazuje allowed, inny log Firewall pokazuje Heartbeat blocked, a log Web filter pokazuje blocked. W tym przypadku Heartbeat blocked również należy do modułu Firewall, a nie do osobnego modułu logów heartbeat.

Samo Allowed nie dowodzi udanego dostępu. Przed zmianą reguły należy skorelować wpisy tego samego przepływu testowego: wspólnie sprawdzić okres testu, źródło, cel, porty i pasującą regułę. Wyszukać osobny wpis Heartbeat blocked oraz wpis Web filter z blocked. Nie wymaga to stałej kolejności zdarzeń, identycznych znaczników czasu ani uniwersalnej liczby wierszy; jeśli brakuje oczekiwanych wpisów, najpierw sprawdzić logowanie, lokalne cele i filtry, a w razie potrzeby użyć Packet Capture.

Ta interpretacja dotyczy dokładnie tej opcji reguły, endpointu bez heartbeat i opisanej ścieżki proxy. Nie jest ogólnym stwierdzeniem dotyczącym wszystkich reguł Allow, endpointów ze statusem czerwonym lub innym nieprawidłowym stanem ani innych trybów inspekcji. Nie wyłączać wymogu heartbeat jako ogólnej metody naprawy; najpierw ustalić dopasowanie reguły i przyczynę braku heartbeat.

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.

W Standard view najechanie na ikonę modułu również pokazuje szczegóły. Funkcja kopiowania umieszcza informacje logu w schowku. Viewer otwiera się w nowym pełnoekranowym oknie przeglądarki; jeśli się nie pojawi, najpierw sprawdzić blokowanie wyskakujących okien.

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.

Jeśli równocześnie w Diagnostics > Packet capture działa Packet Capture, opcja Open PCAP przy odpowiednim wpisie logu może otworzyć informacje o powiązanych pakietach. Łączy to zarejestrowaną decyzję ze szczegółami pakietów, ale nie zastępuje precyzyjnie ograniczonego filtra przechwytywania: źródło, cel, port i czas testu nadal muszą odpowiadać analizowanemu przepływowi.

Wyodrębnienie właściwego przepływu

Ustawianie filtrów tak, aby pozostał właściwy przepływ

Log Viewer oferuje cztery poziomy filtrowania:

1. Module: ogranicza widok do Firewall, Web, IPS, VPN lub innego obszaru.
2. Time / Timer filter: ogranicza zdarzenia do okresu testowego; kliknąć Timer filter i wybrać opcję czasu.
3. Add filter: łączy konkretne pole, warunek i wartość.
4. 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.

Lokalny limit Event Logs zależy od modelu appliance: dla modeli wyższej klasy Sophos podaje do 15 procent całej partycji /var lub 50 procent jej wolnego miejsca, zależnie od tego, która wartość jest mniejsza. Nie jest to gwarantowany okres retencji ani limit dla każdego modelu. Analiza pamięci dyskowej rozróżnia Event Logs, raporty i Troubleshooting Logs; nie należy usuwać plików na próbę.

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. Sophos zaleca co najmniej dwóch Authorizers: jeśli zalogowany administrator jest jednym z nich, deanonimizację musi zatwierdzić co najmniej jeszcze jedna uprawniona osoba. Zrzut ekranu lub eksport powinien mimo to zawierać tylko wiersze potrzebne do danego przypadku.

Wyświetlenie tożsamości za pomocą funkcji deanonimizacji wymaga uprawnień oraz podania danych uwierzytelniających. Skopiowanie wiersza nie zastępuje tej autoryzacji.

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

Bezpieczna interpretacja ustaleń

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

Logowanie Invalid traffic jest domyślnie włączone. Conntrack śledzi sesje TCP oraz określone sesje UDP i ICMP; pakiety inicjujące, takie jak TCP SYN lub żądanie ICMP Echo, tworzą powiązanie z połączeniem. Flagi TCP oznaczają:

• SYN: żądanie synchronizacji.
• SYN-ACK: jej potwierdzenie i uzgodnienie parametrów połączenia.
• ACK: potwierdzenie uzgodnienia; można rozpocząć przesyłanie danych.
• PSH: żądanie natychmiastowego przekazania danych.
• FIN: żądanie uporządkowanego zakończenia; obie strony potwierdzają zamknięcie.
• RST: zakończenie połączenia bez oczekiwania na odpowiedź, na przykład po nieoczekiwanym pakiecie.

Dodatkowe pakiety RST i FIN mogą zostać odrzucone i zapisane jako Invalid traffic. Pojedynczy wpis należy powiązać z rzeczywistym problemem połączenia, zamiast traktować go jako odrębny atak.

Polecenie tylko do odczytu show advanced-firewall w Device Console pokazuje aktualną wartość globalną; Sophos dokumentuje 10800 sekund, czyli trzy godziny, jako wartość domyślną. Zmiana wpływa na wszystkie odpowiadające sesje TCP na firewallu. Najpierw trzeba jednoznacznie powiązać daną aplikację, jej rzeczywisty czas bezczynności i zdarzenie Invalid traffic. Wyższy timeout jest wyłącznie uzasadnioną zmianą operacyjną, a nie naprawą routingu asymetrycznego lub utraty pakietów.

Pełny proces analizy odrzuceń z Reason, Rule ID i specjalnym Firewall ID 0 opisano w artykule Analiza odrzuconych pakietów na Sophos Firewall.

Źródło nazywa pole Tcp Connection Establishment Idle Timeout, ale opisuje wygasanie wpisów conntrack po bezczynności i używa parametru tcp-est-idle-timeout. Ta nazwa jest niejednoznaczna; nie dowodzi istnienia osobnego timeoutu handshake. Należy sprawdzić rzeczywisty wynik i pomoc CLI używanego buildu.

Dokumentacja CLI SFOS 22/23 jednoznacznie przypisuje tcp-est-idle-timeout do już zestawionych połączeń TCP i dopuszcza od 2700 do 432000 sekund. Odmienna nazwa pola nie stanowi więc zalecenia zmiany timeoutu zestawiania połączenia.

Tylko jeśli potwierdzony przypadek timeoutu bezczynności uzasadnia zmianę globalną, wybrać 4. Device Console w CLI, zapisać dotychczasową wartość z show advanced-firewall i uzgodnić okno serwisowe. Udokumentowany przykład zwiększa wartość do sześciu godzin; nie jest to ogólne zalecenie:

set advanced-firewall tcp-est-idle-timeout 21600
show advanced-firewall

Sprawdzić nową wartość i ponownie przetestować tę samą aplikację przez odpowiedni okres bezczynności. Mniejsza liczba wpisów Invalid traffic sama nie dowodzi naprawy. Aby cofnąć zmianę, użyć tego samego polecenia ustawiającego z wcześniej zapisaną liczbą sekund i sprawdzić wynik przez show advanced-firewall; 10800 jest właściwe tylko wtedy, gdy było wartością początkową. Przy niejasnym wyniku CLI lub dalszym problemie przerwać zmiany i zbadać ścieżkę pakietów albo skontaktować się ze wsparciem. Procedura została sprawdzona na podstawie dokumentacji, nie przetestowana na zaporze.

Kontrolowana zmiana reguł z poziomu Log Viewer

W zależności od zdarzenia Log Viewer może otwierać bezpośrednio polityki WWW oraz reguły NAT, zapory lub SSL/TLS. Kliknięcie Web Policy, reguły NAT lub reguły zapory udostępnia link do edycji w WebAdmin. 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, a także zapisać bieżące wartości zmienianych pól, aby można je było przywrócić.

Aby utworzyć wyjątek SSL/TLS, wybrać SSL/TLS inspection, przewinąć do Manage, wybrać Exclude, sprawdzić opcję w oknie dialogowym i dopiero wtedy potwierdzić przez Exclude. Domain i Subdomain są dodawane do grupy URL Local TLS exclusion list, widocznej w Categories and websites reguł SSL/TLS. Web category trafia do Exclusions by website or category, widocznych na stronie listy reguł SSL/TLS. Dla Other properties wybiera się regułę SSL/TLS i odpowiednie obiekty, takie jak użytkownicy lub adresy IP. Przed potwierdzeniem sprawdzić obiekt docelowy i zakres; wykluczenie domeny nie jest równoważne wyjątkowi dla jednego użytkownika. Log Viewer nie oferuje Exclude dla 19004 (ruch dozwolony) ani 19005 (zablokowany przez Web Policy).

Kliknięcie IPS Signature ID może udostępnić opcję Disable signature for this IPS policy. Zmienia ona aktywną IPS Policy, a nie tylko widok. Najpierw należy udokumentować regułę, politykę, sygnaturę, wpływ na ochronę i zakres wyjątku, a następnie ponownie przetestować dokładnie potwierdzony przepływ.

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. Jeśli test zakończy się niepowodzeniem lub wyjątek okaże się zbyt szeroki, należy przywrócić wcześniej zanotowany stan w powiązanym obiekcie reguły lub polityki i ponowić test z nowym przepływem.

Gdy logów brakuje lub znajdują się na drugim węźle HA

Gdy brakuje oczekiwanych logów

Pusty wynik sprawdza się w następującej kolejności:

1. Sprawdzić Pause, moduł, zakres czasu i filtry, a następnie użyć Reset oraz Refresh.
2. Sprawdzić logowanie reguły i Local reporting dla wymaganego typu logu.
3. Utworzyć nowe, świadomie zakończone połączenie ze znanym znacznikiem czasu.
4. Za pomocą Packet Capture potwierdzić, że ruch dociera do zapory i która Rule ID go obsługuje.
5. Sprawdzić pozostałe moduły pod kątem zdarzeń tego samego przepływu.
6. 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.