Rozwiązywanie problemów z CLI Sophos Firewall: ważne polecenia

Podczas rozwiązywania problemów z Sophos Firewall Log Viewer często wystarcza do wstępnego zawężenia przyczyny. Gdy usługa nie uruchamia się prawidłowo, połączenia VPN są niestabilne, pojedyncze pakiety nie docierają lub dział wsparcia potrzebuje szczegółowych danych, istotne staje się użycie CLI.

Ten przegląd przedstawia najważniejsze polecenia do codziennej pracy: gdzie je wykonywać, co pokazują i kiedy lepiej skorzystać z wyspecjalizowanego artykułu. Przed uzyskaniem bezpiecznego dostępu przez SSH warto najpierw sprawdzić artykuł Łączenie z Sophos Firewall przez SSH. Klucz publiczny, weryfikacja klucza hosta i precyzyjnie ograniczony dostęp w Device Access są ważniejsze niż możliwość szybkiego logowania z dowolnego miejsca.

⚠️ Ważne: Polecenia CLI i Advanced Shell należy wykonywać wyłącznie z zaufanych sieci administracyjnych i w jasno określonym celu. Szczególnie debugowanie, tcpdump, operacje na plikach i polecenia dotyczące usług mogą wpływać na wolne miejsce, wydajność lub aktywne połączenia.

Najpierw WebAdmin, potem CLI

CLI nie zawsze jest najszybszym punktem wyjścia. W przypadku dopasowania reguł, NAT lub pojedynczych połączeń Log Viewer, Policy Test i Packet Capture w WebAdmin często szybciej dostarczają jednoznacznych informacji.

Dobre punkty wyjścia:

• Która reguła firewalla jest stosowana? Najpierw skorzystać z Log Viewer, Policy Test i Packet Capture. CLI jest potrzebne dopiero wtedy, gdy Log Viewer pokazuje zbyt mało szczegółów lub wymagane są logi na żywo.
• Czy pakiety docierają do firewalla? Najpierw użyć Packet Capture w WebAdmin. CLI jest przydatne, gdy potrzebne jest precyzyjne przechwytywanie albo plik PCAP dla działu wsparcia.
• Czy występuje problem z usługą? Najpierw sprawdzić dashboard, Log Viewer i logi usług. CLI staje się istotne, gdy trzeba bezpośrednio sprawdzić stan usługi, debugowanie lub pliki logów.
• Czy coś zostało zmienione? Najpierw sprawdzić Audit Trail Logs. Następnie CLI pomaga porównać różnicę konfiguracji z logami lub kopiami zapasowymi.

Celem nie jest jak najszybsze przejście do Advanced Shell. Lepszy jest powtarzalny proces: najpierw sprawdzenie widocznych zdarzeń, a następnie otwarcie odpowiedniego pliku logu lub przechwytywania.

Użyteczne dokumentowanie wyników z CLI

Wyniki z CLI są przydatne tylko wtedy, gdy później nadal wiadomo, którego testu dotyczą. Pojedyncze skopiowane komunikaty o błędach bez przedziału czasu, adresów IP lub funkcji, której dotyczy problem, często prowadzą do dodatkowych pytań i powtarzania analizy.

Zwykle wystarczy krótka notatka dla każdego testu:

• Przedział czasu: początek, koniec i strefa czasowa testu.
• Przepływ testowy: Source IP, Destination IP lub FQDN, port, użytkownik lub peer VPN.
• Narzędzie: Device Console, Advanced Shell, Log Viewer lub Packet Capture.
• Polecenie lub filtr: wykonane polecenie, używana fraza wyszukiwania grep lub filtr przechwytywania.
• Wynik: trafienie, komunikat o błędzie, brak wpisu w logu, pakiet widoczny lub niewidoczny.
• Następny wniosek: na przykład problem z regułą, DNS, trasą zwrotną, usługą lub zgłoszenie do wsparcia.

Przed przekazaniem danych do Sophos Support, Avanet lub zewnętrznego partnera należy sprawdzić, czy wyniki zawierają informacje wrażliwe: publiczne adresy IP, wewnętrzne nazwy hostów, nazwy użytkowników, parametry VPN, numery seryjne, tokeny, adresy e-mail lub nazwy klientów. Analiza techniczna nie wymaga nieograniczonego rozpowszechniania danych; istotny jest najmniejszy fragment potwierdzający wynik.

Przed pierwszym poleceniem

Rozwiązywanie problemów za pomocą CLI jest znacznie bardziej niezawodne, gdy kontekst zostanie ustalony przed pierwszym poleceniem. W przeciwnym razie szybko powstają fragmenty logów bez odniesienia do czasu, zbyt szerokie przechwytywania lub logi debugowania, których później nie można jednoznacznie przypisać.

Przed wykonaniem testów CLI w środowisku produkcyjnym należy zapisać:

• Czas wystąpienia problemu: pozwala przeszukiwać logi dokładnie w przedziale testowym.
• Source IP, Destination IP i port: grep, tcpdump i Packet Capture pozostają precyzyjne i czytelne.
• Użytkownik lub peer, którego dotyczy problem: ułatwia przypisanie uwierzytelniania, VPN i User Matching.
• Oczekiwany moduł: najpierw przeszukiwany jest właściwy plik logu, a nie wszystkie logi.
• Planowane działanie: debugowanie, sprawdzanie usługi lub przechwytywanie nie pozostaje przypadkowo aktywne.
• Kryterium wycofania lub przerwania: test zostaje zakończony w przypadku dużego obciążenia, zapełnienia pamięci lub efektów ubocznych.
• Aktualna kopia zapasowa przy planowanych zmianach: ułatwia zabezpieczenie restartów usług lub zmian konfiguracji.

Pierwszy krok powinien mieć w miarę możliwości charakter tylko do odczytu: sprawdzenie Log Viewer, wyświetlenie właściwego pliku logu, odczytanie service -S lub uruchomienie precyzyjnego przechwytywania. Restarty, tryb debugowania i szerokie przechwytywania należy wykonywać dopiero później, w świadomie zaplanowanym oknie testowym.

W klastrach HA trzeba dodatkowo ustalić, które urządzenie jest obecnie aktywne. Logi, debugowanie i przechwytywania należy sprawdzać na tym węźle, przez który rzeczywiście przechodzi analizowany ruch.

Device Console czy Advanced Shell?

Sophos Firewall udostępnia dwa różne obszary konsoli. Wiele błędów wynika z wprowadzenia polecenia w niewłaściwym obszarze.

Oba obszary mają różne zadania:

• Device Console: CLI Sophos do poleceń sieciowych, systemowych i diagnostycznych. Typowe polecenia to ping, dnslookup, traceroute, tcpdump, drop-packet-capture i show.
• Advanced Shell: powłoka podobna do systemu Linux, przeznaczona do plików, logów, procesów i kontroli usług. Typowe polecenia to nslookup, cd /log, tail -f, grep, less, df -kh, service -S i conntrack.

Po zalogowaniu przez SSH firewall najpierw wyświetla menu konsoli. Dla Device Console zwykle wybiera się 4. Device Console. Dla Advanced Shell używa się 5. Device Management > 3. Advanced Shell.

Test DNS szczególnie dobrze pokazuje tę różnicę. Tych poleceń nie można stosować zamiennie:

Device Console:

dnslookup host example.com

Advanced Shell:

nslookup example.com

Ten komunikat nie jest wynikiem testu DNS. Jeśli /bin/sh: dnslookup: not found pojawi się w Advanced Shell, polecenie dnslookup nie jest tam dostępne. Zamiast niego należy użyć nslookup; dopiero jego wynik pokaże, czy rozwiązywanie nazw DNS działa.

Oficjalna pomoc CLI Sophos obsługuje Tab i ? do sprawdzania składni. Jest to przydatne w Device Console, ponieważ nie każde polecenie ma taką samą strukturę.

Szczególnie w Device Console nie należy wykonywać niekompletnych ani odgadywanych poleceń. Sophos ostrzega, że niekompletne polecenie może zablokować access_server. Dlatego najpierw należy wyświetlić składnię za pomocą Tab lub ?, a następnie świadomie wykonać pełne polecenie.

Bezpośrednie zmiany konfiguracji wprowadzone w Advanced Shell nie są trwałe i nie są uwzględniane w kopiach zapasowych. Dlatego w tej instrukcji Advanced Shell służy wyłącznie do poleceń diagnostycznych.

Specjalnym poleceniem awaryjnym jest system appliance_access enable. Zastępuje ono konfigurację Device Access i zezwala na dostęp do wszystkich lokalnych usług firewalla, w tym starszych usług, takich jak Telnet. Ważne: dopóki ten tryb jest aktywny, firewall nie przekazuje ruchu wychodzącego do internetu. Nie jest to standardowy krok podczas rozwiązywania problemów, lecz rozwiązanie przeznaczone wyłącznie do krótkich sytuacji awaryjnych. Przed aktywacją należy sprawdzić stan:

system appliance_access show

Po teście należy wyłączyć tryb awaryjny i ponownie sprawdzić stan:

system appliance_access disable
system appliance_access show

Jeśli polecenie nie jest rozpoznawane, należy najpierw sprawdzić obszar konsoli. Użycie niewłaściwego obszaru jest bardziej prawdopodobne niż uszkodzenie polecenia.

Sprawdzanie logów w Advanced Shell

Najważniejsze pliki logów znajdują się w katalogu /log. Aby uzyskać wstępny przegląd, należy przejść do tego katalogu i wyświetlić listę plików.

cd /log
ls -lah

Przydatne polecenia podstawowe:

• Śledzenie logu na żywo: tail -f /log/strongswan.log. Przydatne w przypadku powtarzalnych błędów VPN.
• Odczyt pliku logu: less /log/ips.log. W programie less można wyszukiwać za pomocą /fraza.
• Wyszukiwanie błędów: grep -i "error" /log/ips.log. Opcja -i ignoruje wielkość liter.
• Wyświetlanie trafień z numerem wiersza: grep -n "192.0.2.10" /log/firewall_rule.log. Przydatne w dłuższych plikach.
• Wyświetlanie ostatnich wierszy: tail -n 100 /log/syslog.log. Szybki przegląd bez trybu na żywo.

Powiązanie plików logów z modułami opisano w artykule Sophos Firewall: usługi i logi podczas rozwiązywania problemów.

Podczas śledzenia logów na żywo okres testowy powinien być krótki, a jego czas należy zanotować. Jest to szczególnie ważne, jeśli archiwum logów ma zostać później przekazane do Sophos Support lub Avanet.

Device Console do szybkiej kontroli sieci

Device Console nadaje się do szybkich testów z perspektywy firewalla. Pozwala sprawdzić, czy DNS, routing lub osiągalność zasadniczo działają.

Szybkie kontrole:

• Sprawdzanie hosta: ping 192.0.2.10 count 4 sprawdza osiągalność ICMP.
• Sprawdzanie DNS w Device Console: dnslookup host example.com sprawdza rozpoznawanie nazw z perspektywy firewalla.
• Sprawdzanie trasy: traceroute 192.0.2.10 pokazuje drogę do celu.
• Wyświetlanie stanu interfejsu: show interfaces pokazuje informacje o interfejsach.
• Uruchamianie Drop Capture: drop-packet-capture 'host 192.0.2.10' pokazuje pakiety odrzucone przez reguły firewalla.
• Uruchamianie przechwytywania pakietów: tcpdump 'host 192.0.2.10 and port 443' sprawdza, czy pakiety są widoczne na firewallu.

Dla protokołu IPv6 dostępne są odpowiednie polecenia ping6, dnslookup6 i traceroute6.

drop-packet-capture jest szczególnie przydatne, gdy nie wiadomo, czy firewall aktywnie odrzuca pakiety. Nie zastępuje jednak analizy aplikacji. Jeśli serwer odpowiada, ale aplikacja nadal nie działa, należy dodatkowo sprawdzić Log Viewer, NAT, Packet Capture lub logi aplikacji.

W przypadku dłuższych przechwytywań i plików PCAP lepiej skorzystać z artykułu Sophos Firewall: zbieranie logów za pomocą TCPDump do analizy. Należy również zaplanować maksymalny rozmiar pliku, miejsce zapisu i bezpieczny sposób przesyłania.

Sprawdzanie połączeń i przepływu pakietów w Advanced Shell

Jeśli Log Viewer i Device Console nadal nie dają jednoznacznej odpowiedzi, niektóre polecenia Advanced Shell pomagają ocenić przepływ pakietów.

Sprawdzanie połączeń

Przed użyciem narzędzi Advanced Shell należy przefiltrować przepływ w Current activities > Live connections i Diagnostics > Connection list. Te udokumentowane widoki WebAdmin pokazują Rule ID, NAT ID, interfejsy, użytkownika, bramę i przetłumaczone adresy bez zmiany sesji.

W Device Console polecenie system diagnostics utilities connections jest oficjalnie udokumentowanym narzędziem diagnostycznym do połączeń. Dostępne opcje i dane wyjściowe należy wcześniej sprawdzić za pomocą ?.

conntrack jest narzędziem zbliżonym do narzędzi wsparcia w Advanced Shell i pokazuje aktywne połączenia znane ścieżce stateful firewalla. Dokładna dostępność może zależeć od wersji firmware.

conntrack -L | grep "192.0.2.10"

Brak trafienia jest tylko wskazówką, ponieważ na widoczność mogą wpływać czas, kierunek filtra lub FastPath. Dlatego wynik należy porównać z Log Viewer i Packet Capture. Jeśli wpis istnieje, ale aplikacja nie działa, należy dodatkowo sprawdzić, czy wracają pakiety odpowiedzi oraz czy NAT, reguła i aplikacja działają prawidłowo.

tcpdump w Advanced Shell

Do szybkich kontroli na żywo można używać tcpdump również w Advanced Shell.

tcpdump -i any -nn host 192.0.2.10

W analizach produkcyjnych filtr powinien być możliwie precyzyjny. Szerokie przechwytywania, takie jak tcpdump -i any bez hosta, portu lub limitu, szybko generują dużo danych i są niepraktyczne na obciążonych firewallach.

Bezpiecznym punktem wyjścia jest krótkie przechwytywanie z hostem, portem i limitem pakietów:

tcpdump -i any -nn -c 50 host 192.0.2.10 and port 443

Jeśli potrzeba więcej danych, należy najpierw sprawdzić wolne miejsce i świadomie wybrać lokalizację pliku PCAP.

Sprawdzanie wolnego miejsca i stanu systemu

Przed włączeniem debugowania, utworzeniem dużych archiwów logów lub rozpoczęciem dłuższych przechwytywań należy sprawdzić wolne miejsce.

Device Console udostępnia w tym celu następujące polecenia systemowe tylko do odczytu, oficjalnie opisane w dokumentacji:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

Do dodatkowej kontroli w Advanced Shell są dostępne poniższe narzędzia; ich dostępność może zależeć od wersji firmware:

df -kh
df -h /var

Inne szybkie kontrole:

uptime
top
service -S
service -S | grep strongswan

service -S pokazuje stan wielu usług. Nazwy poszczególnych usług nie zawsze są oczywiste. Dlatego przed restartem lub włączeniem debugowania usługę należy powiązać z odpowiednim plikiem logu.

Jeśli wolnego miejsca jest już mało, nie należy włączać debugowania ani rozpoczynać długiego przechwytywania pakietów. Najpierw trzeba ustalić, które logi lub raporty można bezpiecznie zapisać i usunąć.

Precyzyjne włączanie logowania debug

Logowanie debug może pomóc w przypadku złożonych błędów, ale powinno być aktywne tylko przez krótki czas i wyłącznie dla usługi, której dotyczy problem. Debugowanie generuje znacznie więcej danych i przy dłuższym działaniu może zużywać miejsce.

Aby uzyskać jednoznacznie kontrolowany proces włączania i wyłączania, należy użyć obsługiwanego podsystemu w Device Console. Dostępne nazwy można najpierw wyświetlić za pomocą system diagnostics subsystems ?. Sophos dokumentuje na przykład następujący proces dla Pktcapd:

system diagnostics subsystems Pktcapd debug on
system diagnostics subsystems Pktcapd debug off

Sophos dokumentuje również następujące polecenie debugowania IPS w Advanced Shell:

service ips:debug -ds nosync

Dla tego wariantu Advanced Shell nie udokumentowano oddzielnego polecenia z dodanym off. Dlatego należy go używać tylko wtedy, gdy Sophos Support potwierdził dokładny sposób wyłączenia dla zainstalowanego buildu.

Ilustracja pokazuje w SFOS 20.0.1, jak to samo polecenie przełącza tryb debugowania IPS oraz jak service -S | grep ips potwierdza stan przed testem i po nim. W aktualnych wersjach nie należy zakładać takiego działania przełącznika bez wcześniejszej weryfikacji.

Informacje o restartowaniu i identyfikacji usług zawiera także artykuł Ponowne uruchamianie usług Sophos Firewall. W zgłoszeniach do wsparcia należy dokumentować dokładny przedział czasu logu debugowania.

Przed restartem usługi należy sprawdzić, której funkcji dotyczy i czy aktualnie obsługuje ruch produkcyjny. Restart usług VPN, IPS, webowych lub uwierzytelniania może wpływać na aktywne sesje lub logowania użytkowników.

Bezpieczne przekazywanie logów

W złożonych przypadkach pojedyncze fragmenty logów często nie wystarczają. Pełne archiwum logów jest zazwyczaj bardziej przydatne dla Sophos Support, Avanet lub zewnętrznego zespołu analizującego problem.

Zamiast umieszczać dane logowania FTP w poleceniach, logi należy przesyłać w bezpieczny i identyfikowalny sposób, na przykład przez scp na własny serwer lub za pośrednictwem portalu wsparcia. Odpowiednią procedurę opisano w artykule Zapisywanie logów Sophos Firewall dla wsparcia i analizy.

Pliki logów mogą zawierać informacje wrażliwe: wewnętrzne i publiczne adresy IP, nazwy hostów, nazwy użytkowników, parametry VPN oraz komunikaty o błędach. Przed przekazaniem należy ustalić, kto otrzyma dane i jak długo będą przechowywane.

Typowe błędy podczas rozwiązywania problemów za pomocą CLI

• Polecenie w niewłaściwym obszarze konsoli: Device Console i Advanced Shell obsługują inną składnię. Najpierw sprawdzić obszar.
• Pozostawienie debugowania po analizie: Logi niepotrzebnie rosną i mogą zużywać wolne miejsce. Natychmiast wyłączyć debugowanie.
• Szerokie tcpdump bez filtra: Dużo danych, wysokie obciążenie i trudna analiza. Ograniczyć host, port, interfejs lub liczbę pakietów.
• Dane logowania FTP w historii powłoki: Dane mogą znaleźć się w logach, zrzutach ekranu lub historii. Używać bezpiecznego przesyłania i tymczasowych danych logowania.
• Sprawdzenie tylko jednego pliku logu: Wiele problemów dotyczy kilku modułów. Połączyć Log Viewer, odpowiednie logi usług i Packet Capture.
• Brak dokumentacji czasu: Wsparcie musi przeszukiwać niepotrzebnie duże zakresy logów. Zanotować czas, działanie testowe i używane adresy IP.
• Brak porządkowania po teście: Debugowanie, pliki tymczasowe lub szeroki dostęp pozostają aktywne. Wyłączyć debugowanie, sprawdzić pliki i usunąć tymczasowy dostęp SSH.

Lista kontrolna

• Dostęp SSH dozwolony tylko z zaufanych sieci administracyjnych.
• Fingerprint SSH i dostęp admin sprawdzone przed analizą.
• Wybrany właściwy obszar konsoli: Device Console lub Advanced Shell.
• Udokumentowany czas problemu, Source IP, Destination IP, port i użytkownik.
• Wynik CLI udokumentowany wraz z przedziałem czasu, poleceniem, filtrem i rezultatem.
• Najpierw użyte polecenia tylko do odczytu, przed włączeniem debugowania, restartem usług lub dłuższymi przechwytywaniami.
• Najpierw sprawdzony Log Viewer.
• Zidentyfikowany odpowiedni plik logu w /log.
• tail, grep lub less użyte z precyzyjną frazą wyszukiwania.
• Przy problemach sieciowych użyte dnslookup w Device Console lub nslookup w Advanced Shell, a także odpowiednio ping, traceroute, drop-packet-capture lub tcpdump.
• Debugowanie włączone tylko na krótko i wyłączone za pomocą udokumentowanego polecenia dla wybranego podsystemu.
• Wolne miejsce sprawdzone przed debugowaniem lub PCAP.
• Archiwum logów przesłane bezpiecznie, a pliki tymczasowe usunięte.
• Tymczasowe wyjątki Device Access lub SSH usunięte po zakończeniu zgłoszenia.

Często zadawane pytania