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

W przypadku rozwiązywania problemów z Sophos Firewall, Log Viewer często wystarcza do wstępnej izolacji. Gdy tylko usługa nie uruchomi się płynnie, połączenia VPN są niestabilne, poszczególne pakiety nie docierają lub wsparcie potrzebuje szczegółowych danych, CLI staje się ważne.

W tym przeglądzie przedstawiono najważniejsze polecenia w życiu codziennym: gdzie je wykonać, co pokazują i kiedy lepiej przejść na artykuł specjalistyczny. Aby uzyskać bezpieczny dostęp przez SSH, należy najpierw zaznaczyć opcję Połącz Sophos Firewall przez SSH. Klucze publiczne, sprawdzanie kluczy hosta i ścisłe zatwierdzanie dostępu do urządzeń są ważniejsze niż szybkie logowanie z dowolnego miejsca.

⚠️ Ważne: Polecenia CLI i Advanced Shell powinny być wykonywane wyłącznie z zaufanych sieci administracyjnych i z jasnym celem. W szczególności debugowanie, tcpdump, operacje na plikach i polecenia usług mogą mieć wpływ na miejsce w pamięci, wydajność lub działające połączenia.

Najpierw WebAdmin, potem CLI

Interfejs CLI nie zawsze jest najszybszym sposobem na rozpoczęcie pracy. Jeśli chodzi o dopasowywanie reguł, NAT lub pojedyncze połączenia, Log Viewer, Policy Test i Packet Capture w WebAdmin często zapewniają czysty wynik szybciej.

Dobre wstępy:

• Która reguła zapory ma zastosowanie? Pierwsze użycie Log Viewer, Policy Test i Packet Capture. Interfejs CLI staje się konieczny tylko wtedy, gdy Log Viewer pokazuje zbyt mało szczegółów lub wymagane są dzienniki na żywo.
• Czy pakiety docierają do zapory ogniowej? Pierwsze użycie Packet Capture w WebAdmin. Interfejs CLI jest przydatny, gdy do obsługi potrzebne jest ścisłe przechwytywanie lub plik PCAP.
• Czy wystąpił problem z usługą? Najpierw sprawdź pulpit nawigacyjny, Log Viewer i logi serwisowe. Interfejs CLI staje się ważny, gdy konieczne jest bezpośrednie sprawdzenie stanu usługi, plików debugowania lub dziennika.
• Czy coś się zmieniło? Najpierw sprawdź Audit Trail Logs. Interfejs CLI pomaga wówczas w porównywaniu różnic konfiguracyjnych z dziennikami lub kopiami zapasowymi.

Celem nie jest jak najszybsze wskoczenie do Advanced Shell. Lepiej mieć zrozumiały proces: najpierw sprawdź widoczne zdarzenia, a następnie otwórz odpowiedni plik dziennika lub przechwyć.

Dokumentuj ustalenia CLI w użyteczny sposób

Dane wyjściowe CLI są przydatne tylko wtedy, gdy później będzie jasne, do którego testu należy. Pojedyncze skopiowane komunikaty o błędach bez okna czasowego, adresów IP lub funkcji, których dotyczy problem, często prowadzą do zapytań i podwójnej analizy.

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

• Okno czasowe: Początek, koniec i strefa czasowa testu.
• Przepływ testu: Źródło IP, miejsce docelowe IP lub FQDN, port, użytkownik lub element równorzędny VPN.
• Narzędzie: Device Console, Advanced Shell, Log Viewer lub Packet Capture.
• Polecenie lub filtr: polecenie wykonane, grep wyszukiwane hasło lub używany filtr przechwytywania.
• Wynik: Trafienie, komunikat o błędzie, brak wpisu w dzienniku, pakiet widoczny lub pakiet niewidoczny.
• Następny wniosek: na przykład problem z regułami, problem z DNS, ścieżką zwrotną, błąd usługi lub zgłoszenie do pomocy technicznej.

Przed udostępnieniem pomocy technicznej, Avanet lub partnerom zewnętrznym sprawdź, czy dane wyjściowe zawierają wrażliwe dane: publiczne adresy IP, wewnętrzne nazwy hostów, nazwy użytkowników, parametry VPN, numery seryjne, tokeny, adresy e-mail lub identyfikatory klientów. W przypadku analizy technicznej dane nie muszą być dowolnie szeroko rozpowszechniane; Ważny jest najmniejszy fragment potwierdzający stwierdzenie.

Przed pierwszym poleceniem

Rozwiązywanie problemów za pomocą interfejsu CLI staje się znacznie bardziej niezawodne, jeśli ramka zostanie naprawiona przed pierwszym poleceniem. W przeciwnym razie szybko powstają fragmenty dziennika bez odniesienia do czasu, zbyt obszerne przechwyty lub dzienniki debugowania, których nikt nie będzie mógł później jednoznacznie przypisać. Przed produktywnym testowaniem CLI powinieneś pamiętać:

• Czas wystąpienia problemu: Logi można przeszukiwać specjalnie dla okna testowego.
• Źródło IP, miejsce docelowe IP i port: grep, tcpdump i Packet Capture pozostają wąskie i czytelne.
• Dotknięty użytkownik lub użytkownik równorzędny: Uwierzytelnianie, VPN i dopasowanie użytkownika można lepiej przypisać.
• Oczekiwany moduł: Najpierw przeszukujesz odpowiedni plik dziennika, a nie wszystkie dzienniki.
• Planowane działanie: Debugowanie, kontrola serwisowa lub przechwytywanie nie staną się przypadkowo trwałe.
• Kryteria wycofania lub zakończenia: Test zostaje zakończony w przypadku obciążenia, zapełnienia pamięci lub wystąpienia skutków ubocznych.
• Bieżąca kopia zapasowa na potrzeby zmian: Ponowne uruchomienie usługi lub zmiany konfiguracji można wykonać w bardziej przejrzysty sposób. Pierwszym krokiem powinno być odczytanie, jeśli to możliwe: sprawdź Log Viewer, wyświetl odpowiedni plik dziennika, przeczytaj service -S lub rozpocznij dokładne przechwytywanie. Ponowne uruchomienie, tryb debugowania i wszechstronne nagrania należą później tylko do świadomego okna testowego.

W przypadku klastrów HA powinno być również jasne, które urządzenie jest aktualnie aktywne. Dzienniki, debugowanie i przechwytywanie należy sprawdzić w węźle, przez który faktycznie przebiega odpowiedni ruch.

Device Console czy Advanced Shell?

Sophos Firewall ma dwa różne obszary konsoli. Wiele błędów występuje, ponieważ polecenie zostało wprowadzone w niewłaściwym obszarze.

Obszary mają różne zadania:

• Device Console: Sophos CLI do poleceń sieciowych, systemowych i diagnostycznych. Typowe polecenia to ping, dnslookup, traceroute, tcpdump, drop-packet-capture i show.
• Advanced Shell: Powłoka przypominająca Linuksa dla plików, dzienników, procesów i kontroli usług. Typowe polecenia to cd /log, tail -f, grep, less, df -kh, service -S i conntrack.

Po zalogowaniu się poprzez SSH, zapora sieciowa najpierw wyświetli menu konsoli. W przypadku Device Console zwykle wybierasz 4. Device Console. W przypadku Advanced Shell użyj 5. Device Management > Advanced Shell.

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

Szczególnie w Device Console nie należy uruchamiać poleceń na podstawie domysłów. Sophos wskazuje, że niekompletne polecenia mogą mieć skutki uboczne. Najpierw należy wyświetlić składnię, a dopiero potem świadomie uruchomić kompletne polecenie.

Specjalnym poleceniem awaryjnym jest system appliance_access enable. Nadpisuje ono konfigurację Device Access i zezwala na dostęp do wszystkich lokalnych usług zapory, w tym starszych usług takich jak Telnet. Ważne: dopóki ten tryb jest aktywny, zapora przestaje przekazywać ruch wychodzący do internetu. Nie jest to normalny krok troubleshootingowy, lecz rozwiązanie tylko na krótkie sytuacje awaryjne. Po przywróceniu dostępu trzeba cofnąć ten stan:

system appliance_access disable

Jeśli polecenie nie zostanie rozpoznane, sprawdź najpierw obszar konsoli. Błędny zakres jest bardziej prawdopodobny niż natychmiastowe przerwanie polecenia.

Sprawdź dzienniki w Advanced Shell

Najważniejsze pliki dziennika znajdują się w /log. Aby uzyskać wstępną orientację, przejdź do tego katalogu i wyświetl listę plików.

cd /log
ls -lah

• Zapis trasy na żywo: tail -f /log/strongswan.log. Dobre w przypadku powtarzalnych błędów VPN.
• Przeczytaj plik dziennika: less /log/ips.log. W less możesz wyszukiwać za pomocą /Suchbegriff.
• Sprawdź błędy: grep -i "error" /log/ips.log. W -i nie jest rozróżniana wielkość liter.
• Wpisz numer linii: grep -n "192.0.2.10" /log/firewall_rule.log. Przydatne w przypadku dłuższych plików.
• Pokaż ostatnie linie: tail -n 100 /log/syslog.log. Szybki przegląd bez trybu na żywo.

Który plik dziennika należy do którego modułu, podsumowano w Sophos Firewall Rozwiązywanie problemów: Services i dzienniki.

W przypadku dzienników bieżących okres testowy powinien być krótki i zanotowany. Jest to szczególnie ważne, jeśli archiwum logów zostanie później przekazane firmie Sophos Support lub Avanet.

Device Console do szybkiego sprawdzania sieci

Device Console nadaje się do szybkich testów z punktu widzenia zapory ogniowej. Dzięki temu możesz sprawdzić, czy DNS, routing lub dostępność w zasadzie działają.

Szybkie kontrole:

• Dotrzyj do hosta: ping 192.0.2.10 count 4 sprawdza osiągalność ICMP.
• Sprawdź DNS: dnslookup example.com sprawdza rozpoznawanie nazw z perspektywy zapory ogniowej.
• Sprawdź trasę: traceroute 192.0.2.10 pokazuje ścieżkę do celu.
• Wyświetl stan interfejsu: show interfaces wyświetla informacje o interfejsie.
• Rozpocznij przechwytywanie: drop-packet-capture 'host 192.0.2.10' pokazuje pakiety odrzucone przez reguły zapory sieciowej.
• Rozpocznij przechwytywanie pakietów: tcpdump 'host 192.0.2.10 and port 443' sprawdza, czy pakiety są widoczne na zaporze. drop-packet-capture jest szczególnie przydatny, gdy nie jest jasne, czy zapora aktywnie odrzuca pakiety. Nie zastępuje jednak analizy aplikacji. Jeśli serwer odpowiada, ale aplikacja nadal nie działa, wymaga również sprawdzenia Log Viewer, NAT, Packet Capture lub dzienników aplikacji.

W przypadku dłuższych nagrań pakietów i plików PCAP bardziej odpowiedni jest oddzielny artykuł Sophos Firewall: Zbieranie dzienników za pomocą TCPDump do analizy. Należy także zaplanować, jak duży może być plik, gdzie będzie przechowywany i w jaki sposób będzie bezpiecznie przesyłany.

Sprawdź połączenia i przepływ pakietów w Advanced Shell

Jeśli Log Viewer i Device Console nie dają jasnej odpowiedzi, niektóre zaawansowane polecenia powłoki pomogą ci zrozumieć przepływ pakietów.

Conntrack

conntrack pokazuje aktywne połączenia, o których wie ścieżka zapory stanowej. Jest to przydatne, jeśli chcesz sprawdzić, czy połączenie w ogóle pojawia się w śledzeniu połączenia.

conntrack -L | grep "192.0.2.10"

Jeśli brakuje wpisu, może to wskazywać na routing, NAT, nieprawidłowe źródło, brakującą regułę zapory lub testowanie na niewłaściwej ścieżce. Jeśli wpis istnieje, ale aplikacja nie działa, należy przeprowadzić dodatkowe sprawdzenie, czy zwracane są pakiety odpowiedzi i czy NAT, polityka lub aplikacja działają poprawnie.

tcpdump w pliku Advanced Shell

Do szybkich testów na żywo tcpdump można również zastosować w Advanced Shell.

tcpdump -i any -nn host 192.0.2.10

W przypadku analiz produktywnych filtr powinien być tak wąski, jak to możliwe. Szerokie nagrania, takie jak tcpdump -i any, bez hosta, portu i licznika, szybko generują dużo danych wyjściowych i są niepraktyczne w przypadku obciążonych zapór sieciowych.

Bezpieczny start to krótkie nagranie 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 wcześniej sprawdzić miejsce do przechowywania i świadomie wybrać miejsce przechowywania PCAP.

Sprawdź miejsce na dysku i stan systemu

Przed rejestrowaniem debugowania, dużymi archiwami logów lub dłuższymi nagraniami pakietów należy sprawdzić wolną przestrzeń dyskową.

df -kh
df -h /var

Inne szybkie kontrole:

uptime
top
service -S
service -S | grep strongswan

service -S pokazuje stan wielu usług. Poszczególne nazwy usług nie zawsze są oczywiste. Dlatego przed aktywacją ponownego uruchomienia lub debugowania należy porównać usługę z odpowiednim plikiem dziennika.

Jeśli miejsce w pamięci jest już ograniczone, nie należy rozpoczynać rejestrowania debugowania ani nagrywania długich pakietów. Najpierw wyjaśnij, dla których dzienników lub raportów można bezpiecznie utworzyć kopię zapasową i wyczyścić.

Aktywuj specjalnie dziennik debugowania

Rejestrowanie debugowania może pomóc w przypadku złożonych błędów, ale powinno być aktywne tylko przez krótki czas i tylko dla danej usługi. Debugowanie generuje znacznie więcej danych dziennika i może zająć miejsce w pamięci, jeśli działa przez długi czas.

Przykład debugowania IPS:

service ips:debug -ds nosync

Odtwórz problem, zanotuj odpowiedni czas i ponownie dezaktywuj debugowanie:

service ips:debug -ds nosync off

Przed ponownym uruchomieniem usługi należy sprawdzić, której funkcji to dotyczy i czy aktualnie odbywa się przez nią ruch produktywny. Ponowne uruchomienie VPN, IPS, usług internetowych lub uwierzytelniających może mieć wpływ na aktywne sesje lub logowania użytkowników.

Bezpiecznie dostarczaj dzienniki

W przypadku skomplikowanych przypadków pojedyncze fragmenty dziennika często nie wystarczą. W przypadku wsparcia Sophos, Avanet lub analizy zewnętrznej zwykle bardziej przydatne jest pełne archiwum logów. Zamiast zapisywać dane dostępowe FTP w poleceniach, należy przesyłać logi w bezpieczny i identyfikowalny sposób, na przykład za pośrednictwem scp na własny serwer lub za pośrednictwem portalu wsparcia. Odpowiednie instrukcje są dostępne pod adresem Sophos Firewall Tworzenie kopii zapasowych dzienników w celu wsparcia i analizy.

Pliki dziennika mogą zawierać poufne informacje: wewnętrzne adresy IP, publiczne adresy IP, nazwy hostów, nazwy użytkowników, parametry VPN i komunikaty o błędach. Przed udostępnieniem powinno być jasne, kto otrzyma dane i jak długo będą one przechowywane.

Typowe błędy rozwiązywania problemów z CLI

• Polecenie w złym obszarze konsoli: Device Console i Advanced Shell obsługują inną składnię. Najpierw sprawdź obszar.
• Po analizie pozostaw debugowanie aktywne: Dzienniki powiększają się niepotrzebnie i mogą zajmować miejsce w pamięci. Natychmiast ponownie dezaktywuj debugowanie.
• Szeroki tcpdump bez filtra: Dużo danych wyjściowych, duże obciążenie i dane, które są trudne do oceny. Ogranicz hosta, port, interfejs lub liczbę.
• Poświadczenia FTP w historii powłoki: Poświadczenia mogą znaleźć się w logach, zrzutach ekranu lub historii. Użyj bezpiecznego transferu i tymczasowych danych uwierzytelniających.
• Sprawdź tylko jeden plik dziennika: Wiele problemów dotyczy wielu modułów. Połącz Log Viewer, pasujące dzienniki serwisowe i Packet Capture.
• Nie dokumentuj czasu: Wsparcie musi przeszukiwać niepotrzebnie duże obszary logów. Zanotuj czas, działanie testowe i zaangażowane adresy IP.
• Nie czyść po testowaniu: Debugowanie, pliki tymczasowe lub szeroki dostęp pozostają aktywne. Wyłącz debugowanie, sprawdź pliki i usuń tymczasowe udziały SSH.

Lista kontrolna

• Dostęp SSH dozwolony tylko z zaufanych sieci administracyjnych.
• Przed analizą sprawdzono odcisk palca SSH i dostęp admin.
• Wybrano prawidłowy zakres konsoli: Device Console lub Advanced Shell.
• Czas wystąpienia problemu, źródło IP, miejsce docelowe IP, port i użytkownik udokumentowane.
• Wyniki CLI udokumentowane za pomocą okna czasowego, polecenia, filtra i wyniku.
• Przeczytaj polecenia użyte jako pierwsze przed debugowaniem, ponownym uruchomieniem usługi lub rozpoczęciem dłuższych przechwytywania.
• Najpierw sprawdzono Log Viewer.
• Pasujący plik dziennika zidentyfikowany pod /log.
• tail, grep lub less użyte z wąskim wyszukiwanym hasłem.
• Używane specjalnie do problemów z siecią ping, dnslookup, traceroute, drop-packet-capture lub tcpdump.
• Debugowanie było aktywowane tylko na krótko i ponownie dezaktywowane. — Miejsce na dysku sprawdzane przed debugowaniem lub PCAP.
• Bezpiecznie przesyłaj archiwum dzienników i usuwaj pliki tymczasowe. — Usunięto wyjątki dotyczące tymczasowego dostępu do urządzenia lub SSH po zgłoszeniu do pomocy technicznej.

Często zadawane pytania