Prawidłowe odczytywanie Live Connections na Sophos Firewall

Live Connections pokazuje, które połączenia są obecnie aktywne na Sophos Firewall. Widok pozwala szybko ustalić, który klient, użytkownik lub aplikacja generuje ruch, jakie interfejsy biorą w nim udział oraz która reguła zapory lub NAT obsługuje sesję. Dla pojedynczego połączenia Diagnostics > Connection list udostępnia jeszcze więcej szczegółów technicznych.

Oba widoki są migawkami. Nie zastępują ani Log Viewer w przypadku zarejestrowanych decyzji, ani Packet Capture w przypadku rzeczywistego przepływu pakietów. Prawidłowo połączone znacznie przyspieszają pracę: najpierw znajduje się aktywną sesję, a następnie w razie potrzeby sprawdza logi i pakiety.

Live Connections w siedmiu krokach

1. Zdefiniować przepływ testowy: źródłowy adres IP, docelowy adres IP, protokół, port źródłowy, jeśli jest znany, port docelowy oraz dokładny czas.
2. Wygenerować nowe połączenie z klienta testowego, na przykład HTTPS z 192.0.2.25 do 198.51.100.50 przez TCP 443.
3. Otworzyć Current activities > Live connections i pogrupować według Source IP address.
4. Ustawić filtr na 192.0.2.25 i przez Total otworzyć poszczególne połączenia.
5. Zanotować Start time, In interface, Out interface, Source, Destination, porty, Firewall Rule ID oraz NAT Rule ID.
6. W Diagnostics > Connection list > Display filter możliwie precyzyjnie przefiltrować ten sam przepływ i porównać Translated source, Translated destination, Gateway ID, Policy IDs oraz RX/TX.
7. W razie rozbieżności skorelować przepływ w Log Viewer i Packet Capture przed zmianą reguł, NAT lub routingu.

Adresy 192.0.2.25 i 198.51.100.50 pochodzą z sieci dokumentacyjnych. W rzeczywistym teście należy je zastąpić faktycznymi adresami klienta i celu. TCP 443 pasuje tylko wtedy, gdy rzeczywiście testowane jest połączenie HTTPS.

⚠️ Widoki zawierają wewnętrzne adresy IP, nazwy użytkowników, aplikacje i relacje komunikacyjne. Filtry i zrzuty ekranu należy ograniczyć do niezbędnego minimum, a dane wsparcia udostępniać wyłącznie uprawnionym odbiorcom.

Rozróżnienie Live Connections i Connection List

Oba widoki korzystają z aktualnego stanu połączeń, ale odpowiadają na różne pytania.

Live Connections jako przegląd

W Current activities > Live connections aktywne połączenia można grupować według:

• Application
• Source IP address
• Username

Widok pokazuje upload, download, średnio wykorzystywaną przepustowość, właściwości i liczbę sesji. Pomaga odpowiedzieć na pytania takie jak: który klient generuje teraz dużo ruchu? Jaka aplikacja jest aktywna? Który użytkownik ma otwartych kilka połączeń?

Wyświetlane wartości transferu odnoszą się do czasu od zestawienia połączenia. Upstream bandwidth i Downstream bandwidth są obliczane na podstawie przesłanych bajtów i dotychczasowego czasu trwania połączenia. Nie są więc testem łącza wykonywanym sekunda po sekundzie. Do testowania wydajności lepiej nadaje się prawidłowe użycie iPerf3 z Sophos Firewall.

W Live Connections jednocześnie może być aktywny tylko jeden filtr. Najbardziej jednoznacznym punktem wyjścia jest zwykle źródłowy adres IP. Username lub Application są przydatne, gdy klient jest już poprawnie uwierzytelniony albo aplikacja została rozpoznana.

Connection List dla pojedynczej sesji

W Diagnostics > Connection list każde aktualne połączenie znajduje się w osobnym wierszu. Ten widok jest bardziej techniczny i pokazuje między innymi:

• In interface i Out interface
• Source i Destination wraz z portami
• Protocol i Application
• Rule ID i NAT ID
• User i User group
• Policy IDs dla Web, Application, IPS, Traffic Shaping i Remote Access
• Gateway ID
• Translated source i Translated destination
• Expiry, RX/TX bytes i RX/TX packets
• Connection served by

Display filter może zawierać kilka znanych cech przepływu testowego. Pozwala to ograniczyć dużą listę do niewielkiego zestawu pasujących sesji.

Czego nie dowodzi żaden z tych widoków

Widoczna sesja potwierdza istnienie aktualnego wpisu śledzenia połączenia. Nie dowodzi automatycznie:

• że każde żądanie i każda odpowiedź zostały przesłane w całości
• że serwer docelowy prawidłowo przetworzył aplikację
• że wcześniejszy błąd w tym samym przepływie jest nadal dostępny historycznie
• że wybrana reguła zapory lub NAT jest właściwa z punktu widzenia działania
• że zielony wpis nie zawiera utraty pakietów, retransmisji ani problemu MTU

Decyzje historyczne wymagają logowania. Ingress, egress, odpowiedzi i drops wymagają Packet Capture. Dla samej aplikacji nadal istotne są logi serwera, klienta lub usługi SaaS.

Przygotowanie kontrolowanego przepływu testowego

Użyteczny test nie zaczyna się od przypadkowego odświeżenia przeglądarki. Najpierw należy określić pięć elementów:

• źródłowy adres IP
• docelowy adres IP
• protokół
• port źródłowy
• port docelowy

Port źródłowy jest często dynamiczny w połączeniach klienckich. Jeśli nie jest jeszcze znany, do pierwszego filtra wystarczą źródłowy adres IP, docelowy adres IP, protokół i port docelowy. Po znalezieniu wpisu konkretny port źródłowy można odczytać z sesji.

Dodatkowo należy określić oczekiwane wartości:

• In interface i Out interface
• Firewall Rule ID oraz, w odpowiednich przypadkach, NAT Rule ID
• użytkownik lub grupa użytkowników, jeśli reguła korzysta z tożsamości
• Gateway lub ścieżka SD-WAN
• oczekiwane Source i Destination po NAT
• dokładny czas testu wraz ze strefą czasową

Po zmianach zawsze tworzyć nowe połączenie

Istniejące sesje zachowują stan ustalony przy ich zestawieniu. W szczególności decyzje NAT nie są podejmowane ponownie dla każdego kolejnego pakietu. Po zmianie reguły, NAT, routingu lub SD-WAN należy więc zakończyć sesję aplikacji i wygenerować nowy przepływ.

Odświeżenie przeglądarki może nadal korzystać z tego samego połączenia TCP, HTTP/2 lub HTTP/3. W wiarygodnym teście odbiorczym pomaga nowe prywatne okno przeglądarki, ponownie uruchomiony proces klienta lub inny kontrolowany test, który na pewno otwiera nowe połączenie. Metoda musi pasować do aplikacji i nie może przypadkowo przerwać sesji produkcyjnej.

Użycie Live Connections do znalezienia pierwszego wpisu

1. Otworzyć Current activities > Live connections.
2. Wybrać Automatic refresh interval odpowiedni do testu lub ręcznie odświeżać za pomocą Refresh.
3. Dla znanego klienta wybrać Source IP address.
4. Otworzyć filtr, wybrać odpowiedni modyfikator i wprowadzić źródłowy adres IP.
5. Sprawdzić Transfer, Bandwidth i Total w wierszu.
6. Kliknąć liczbę pod Total, aby otworzyć poszczególne połączenia na nowej karcie.
7. Zidentyfikować pasujący przepływ na podstawie Start time, interfejsów, adresów IP, portów i Protocol.

Bardzo krótkie żądanie DNS, ICMP lub Web może zniknąć przed odświeżeniem strony. W takim przypadku należy najpierw ustawić filtr, przygotować Refresh i dokładnie jeden raz ponownie wywołać test.

Prawidłowa interpretacja Other applications i DNS

Other applications zawiera nierozpoznane aplikacje oraz ruch generowany przez system, na przykład pobieranie sygnatur, dostęp do konsoli lub żądania DNS generowane przez samą zaporę. Nie jest to automatycznie kategoria błędu.

DNS wymaga dodatkowej uwagi: ruch między klientem wewnętrznym a zewnętrznym serwerem DNS podlega normalnym regułom zapory i jest wyświetlany jako DNS. Ruch DNS generowany przez zaporę może natomiast pojawiać się zarówno w DNS, jak i w Other applications.

Jeśli aplikacja nie zostanie rozpoznana, a Security Heartbeat jest aktywny, Connection List może zaproponować rozpoznanie Application Information dla połączonych endpointów. Bez połączonego Sophos Endpoint lub bez Heartbeat nadal możliwe jest No information available. Nieznana nazwa nie oznacza więc automatycznie złośliwego ruchu.

Firewall Rule ID 0 zależy od kontekstu

Ruch generowany przez system ma w Live Connections Firewall Rule ID 0, ponieważ normalne reguły zapory nie sterują tym ruchem. Dostęp do lokalnych usług zapory jest natomiast kontrolowany między innymi przez Administration > Device access i Local Service ACL. Device Access i Local Service ACL opisuje bezpieczną konfigurację.

Wartości 0 nie wolno interpretować bez kontekstu jako domyślnej reguły drop. Rule #0 w logu zapory lub Packet Capture może mieć inne znaczenie diagnostyczne. Decydujące są widok, Status, Reason oraz to, czy chodzi o ruch systemowy, czy przekazywany ruch klienta.

Ograniczenie Connection List do jednego przepływu

1. Otworzyć Diagnostics > Connection list.
2. Wybrać Display filter.
3. Ustawić Network protocol na IPv4 lub IPv6 zgodnie z testem.
4. Wprowadzić źródłowy i docelowy adres IP.
5. Dodać Packet type oraz port źródłowy lub docelowy, jeśli są znane.
6. Wprowadzić oczekiwaną Rule ID, gdy wyszukiwane są konkretnie aktywne sesje tej reguły.
7. Zastosować filtr za pomocą OK i porównać wyniki z czasem testu.

Pusty wynik nie dowodzi, że zapora blokuje ruch. Sesja mogła już się zakończyć, klient może używać innego adresu docelowego uzyskanego przez DNS lub CDN, NAT może zmieniać widoczny adres albo test mógł zostać obsłużony przez drugi węzeł HA. Najpierw należy sprawdzić przepływ testowy i kierunek obserwacji, a nie rozszerzać regułę zapory.

Wspólne odczytywanie najważniejszych pól

• Time: czas rozpoczęcia połączenia. Musi odpowiadać kontrolowanemu testowi.
• In interface / Out interface: pokazują ścieżkę wejściową i wyjściową używaną przez sesję.
• Source / Destination / Ports: definiują widoczny przepływ przed szczegółową interpretacją.
• Rule ID: pokazuje regułę zapory zezwalającą na sesję.
• NAT ID: pokazuje używaną regułę NAT.
• Translated source / Translated destination: uwidaczniają SNAT, MASQ, DNAT lub PAT.
• Gateway ID: przypisuje sesję do bramy i jest szczególnie ważne w przypadku pytań dotyczących WAN lub SD-WAN.
• Username / User group: pokazują, czy z sesją powiązany jest oczekiwany kontekst użytkownika.
• Policy IDs: pokazują przypisane polityki Web, Application, IPS, Traffic Shaping lub Remote Access.
• Expiry: pokazuje, po ilu sekundach nieaktywna sesja wygasa.
• RX/TX bytes i packets: pomagają ustalić, czy tylko jeden kierunek przesyła dane, czy oba są aktywne.
• Connection served by: pokazuje, która zapora obsługuje połączenie w środowisku HA.

Rule ID i NAT ID należy zawsze odczytywać razem z interfejsami, adresami i portami. Oczekiwana Rule ID wraz z nieoczekiwaną NAT ID wskazuje na problem dopasowania NAT. Jeśli oba identyfikatory są poprawne, ale Out interface lub Gateway nie, następnie należy sprawdzić routing lub SD-WAN. NAT na Sophos Firewall wyjaśnia podstawy.

Nie przeceniać Related Connections

Kliknięcie Connection ID może pokazać połączenia zależne, na przykład w przypadku Web Proxy, FTP, SIP lub innych protokołów tworzących powiązane sesje. Jeśli nie istnieje zależny przepływ, widok pozostaje pusty. Pusty widok Related Connections nie stanowi więc dowodu błędu.

Korelacja aktywnej sesji, Log Viewer i Packet Capture

Te trzy narzędzia odpowiadają kolejno na trzy różne pytania:

1. Live Connections lub Connection List: jaka sesja jest obecnie dostępna oraz jakie ID, interfejsy, adresy, polityki i przypisania bramy zawiera?
2. Log Viewer: jaka decyzja zapory, NAT lub zabezpieczeń została zarejestrowana?
3. Packet Capture: czy pakiety docierają, są przekazywane i czy odpowiedzi wracają?

Aby uzyskać wiarygodne porównanie:

1. Zanotować czas testu i pięć elementów przepływu.
2. Zanotować aktywną sesję i Connection ID.
3. Udokumentować Rule ID, NAT ID, In/Out interface, Gateway i przetłumaczone adresy.
4. Przefiltrować Log Viewer według źródła, celu, portu i czasu.
5. Przy braku odpowiedzi lub niejasnej ścieżce uruchomić Packet Capture z wąskim filtrem BPF.
6. Udokumentować wynik przed zmianą konfiguracji.

Jeśli Live Connections pokazuje sesję, ale w Log Viewer nie ma pasującego zdarzenia zapory, najpierw należy sprawdzić Log firewall traffic, Local reporting i filtry. Procedura znajduje się w Log Viewer nie pokazuje nowych logów.

Device Console udostępnia również system diagnostics utilities connections. Aktualna pomoc publiczna dokumentuje narzędzie, ale nie wszystkie opcje zależne od buildu. Przed użyciem należy więc sprawdzić dostępną składnię za pomocą ? i korzystać z danych wyjściowych wyłącznie w trybie odczytu. Rozwiązywanie problemów z CLI Sophos Firewall opisuje bezpieczne granice.

Typowe objawy

Oczekiwana sesja nie pojawia się

Najpierw należy sprawdzić, czy przepływ jest nadal aktywny oraz czy źródło, cel i wersja IP są poprawne. W przypadku DNS, CDN, proxy, NAT lub IPv6 rzeczywisty adres docelowy może różnić się od zakładanego. Należy wygenerować nowy test i równolegle uruchomić Packet Capture, jeśli nie wiadomo, czy zapora w ogóle odbiera pakiety.

Widoczna jest niewłaściwa Rule ID lub NAT ID

Bardziej ogólna reguła wyżej na liście może mieć pierwszeństwo. Należy porównać kolejność reguł zapory i NAT, strefy, źródło, cel, usługę, użytkownika i harmonogram. Nie wolno przesuwać kilku reguł jednocześnie. Instrukcja znajduje się w Prawidłowe testowanie reguły Sophos Firewall.

Tylko jeden kierunek zwiększa RX lub TX

Może to wskazywać na brakującą ścieżkę powrotną, nieprawidłową translację NAT, problem systemu docelowego lub lokalną zaporę serwera. Należy sprawdzić interfejsy, przetłumaczone adresy i bramę, a następnie poszukać obu kierunków w Packet Capture. Sam licznik nie dowodzi przyczyny.

Wartości nie zmieniają się po zmianie konfiguracji

Prawdopodobnie nadal obserwowana jest istniejąca sesja. Należy prawidłowo zakończyć połączenie klienta, wygenerować nowy przepływ i ponownie sprawdzić Start time oraz Connection ID. Globalne czyszczenie sesji ani restart usługi nie powinny być standardowym pierwszym testem.

W HA brakuje sesji lub odpowiedniego wpisu logu

Należy zanotować Connection served by i uwzględnić węzeł, który przetwarzał ruch w chwili zdarzenia. Logi są przechowywane lokalnie na każdym węźle HA i nie są w pełni synchronizowane między węzłami. Z widocznej Connection List nie należy wnioskować o nieprzerwanym utrzymaniu sesji. Konfiguracja HA na Sophos Firewall wyjaśnia ograniczenia.

Other applications jest nietypowo duże

Najpierw należy pogrupować według źródłowego adresu IP i otworzyć poszczególne sesje. W tej grupie mogą znajdować się nierozpoznane aplikacje, ruch systemowy i kilka różnych przyczyn. Przed uznaniem tego za incydent bezpieczeństwa należy sprawdzić Rule ID, cele, porty, użytkownika i kontekst aplikacji.

Lista kontrolna

• Źródło, cel, protokół, porty i czas testu są znane.
• Do testu wygenerowano nowe połączenie.
• Live Connections zostało sensownie pogrupowane według źródłowego IP, użytkownika lub aplikacji.
• Start time, In/Out interface, Rule ID i NAT ID odpowiadają oczekiwaniom.
• Translated source/destination i Gateway ID odpowiadają planowanej ścieżce.
• User i Policy IDs były oczekiwane tylko wtedy, gdy odpowiednie rozpoznawanie było aktywne.
• Rule ID 0 odczytano we właściwym kontekście ruchu systemowego.
• W środowisku HA udokumentowano Connection served by.
• Log Viewer i w razie potrzeby Packet Capture potwierdzają sesję.
• Globalnego czyszczenia sesji ani restartu usługi nie użyto jako pierwszej próby diagnostycznej.

Często zadawane pytania