Przejdz do tresci
Avanet

Zapisywanie logów Sophos Firewall na potrzeby wsparcia i analizy

W przypadku awarii, problemów z VPN lub niejasnych zdarzeń firewalla pojedyncze zrzuty ekranu z interfejsu webowego często nie wystarczają. Aby analiza była oparta na solidnych podstawach, zgłoszenie do pomocy technicznej wymaga zrozumiałych informacji czasowych, odpowiednich plików logów, a czasem także zapisu pakietów.

Ten przewodnik dotyczy SFOS 22. Opisuje oficjalną ścieżkę Diagnostics > Tools i odróżnia ją od dodatkowego sposobu pobierania surowych logów przez Advanced Shell. Dla Sophos Support najlepszym punktem wyjścia jest zwykle Consolidated Troubleshooting Report (CTR), który łączy pliki logów i migawkę systemu w zaszyfrowanym archiwum. Ręcznie utworzone archiwum /log przydaje się do zebrania pełnych surowych logów, dodatkowych danych IPsec lub analizy wewnętrznej. Nie jest jednak zaszyfrowanym CTR ani standardowym eksportem opisanym przez Sophos.

Ten proces nie zastępuje wstępnego zawężenia problemu w Log Viewer. Jeśli nadal nie wiadomo, którego modułu dotyczy problem, warto najpierw skorzystać z artykułu Rozwiązywanie problemów z Sophos Firewall: usługi i logi.

Najpierw zawęź zgłoszenie do pomocy technicznej

Duże archiwum nie jest automatycznie dobrym pakietem diagnostycznym. Najpierw trzeba ustalić, który test się nie powiódł, kiedy został wykonany i który komponent jest prawdopodobnie zaangażowany.

Najpierw analizować czy od razu zbierać dane?

W zależności od wzoru błędu inne podejście jest szybsze:

Do raportów historycznych lub powtarzających się zdarzeń służy Central Firewall Reporting. Długoterminowe przechowywanie i korelacja wymagają Syslog lub SIEM. Doraźne archiwum dla supportu nie zastępuje żadnego z tych rozwiązań.

Wybierz pakiet danych odpowiedni do problemu

Nie każdy problem wymaga natychmiastowego utworzenia pełnego archiwum dziennika. Im wyraźniej wyodrębniony zostanie błąd, tym mniejsze i bardziej przydatne stają się dane.

  • Reguła zapory sieciowej lub reguła NAT zostaje zastosowana nieoczekiwanie: Czas, źródłowy adres IP, docelowy adres IP, Rule ID, NAT ID, eksport przeglądarki logów i, jeśli to konieczne, Packet Capture.
  • Usługa nie uruchamia się lub WebAdmin wyświetla błąd: Skonsolidowany raport dotyczący rozwiązywania problemów, usługa, której dotyczy problem, godzina i ostatni krok konfiguracji.
  • Tunel IPsec nie ustanawia lub kończy się niepowodzeniem: normalne archiwum logów, dane diagnostyczne IPsec, adres IP partnera, sieci lokalne i zdalne, czas próby połączenia.
  • Ruch nie dociera do miejsca docelowego: Log Viewer, Packet Capture lub w przypadku dłuższych analiz tcpdump-PCAP.
  • Problem po zmianie konfiguracji: Ścieżka audytu, przybliżony czas zmiany, udział administratora, dotknięte obiekty i, jeśli to konieczne, CTR.

W przypadku wielu zgłoszeń połączenie czasu wystąpienia problemu, krótkiego opisu błędu, archiwum logów i ukierunkowanych dodatkowych dowodów jest lepsze niż bardzo szeroki pakiet danych bez kontekstu. Jeśli zostanie utworzone oficjalne zgłoszenie Sophos, obowiązuje również Otwórz zgłoszenie do pomocy Sophos: przygotowanie i portal.

Wymagania wstępne

Do tego przewodnika potrzebujesz:

  • Dostęp administracyjny do Sophos Firewall
  • Dostęp do Diagnostics > Tools w WebAdmin
  • W przypadku nieprzetworzonych archiwów logów dodatkowy dostęp do Advanced Shell
  • Serwer docelowy, portal pomocy technicznej lub inny bezpieczny sposób przesyłania archiwów
  • Wystarczająca ilość wolnego miejsca na zaporze ogniowej na archiwa tymczasowe

Polecenia CLI są wykonywane bezpośrednio na zaporze. Dlatego należy pracować ostrożnie i nie usuwać plików, jeśli nie jest jasne, do czego służą.

Jeśli dostęp do powłoki nie jest jeszcze skonfigurowany, instrukcje Sophos Firewall połącz przez SSH wyjaśniają, jak ustanowić połączenie SSH z zaporą ogniową.

⚠️ Archiwa dzienników i pliki PCAP mogą zawierać poufne informacje. Takie pliki powinny znajdować się na zaporze sieciowej tylko przez krótki czas, zostać bezpiecznie przesłane, a następnie ponownie usunięte po pomyślnym przesłaniu.

Zbierz dzienniki

W zależności od przypadku wystarczające jest ukierunkowane pobranie WebAdmin, CTR lub nieprzetworzone archiwum logów z Advanced Shell. Proces należy rozpocząć od najmniejszego zestawu danych, który jasno wyjaśnia błąd.

Lokalne przechowywanie logów jest ograniczone przez miejsce przydzielone każdemu podsystemowi i model zapory. Gdy plik logu osiągnie limit rozmiaru, jest kompresowany za pomocą gzip; gdy podsystem osiągnie limit miejsca, najstarsze pliki rotacji .gz są usuwane jako pierwsze. Jeśli zapora przestanie odpowiadać, mogą również zostać utracone dane logów, które nadal znajdują się w pamięci RAM i nie zostały jeszcze zapisane w systemie plików. Dlatego istotne logi należy zapisać jak najszybciej: eksport zawiera tylko nadal dostępne dane i nie odzyska utraconych wpisów.

Ścieżka domyślna: Utwórz CTR w WebAdmin

W przypadku wielu przypadków pomocy technicznej należy najpierw wygenerować Skonsolidowany raport dotyczący rozwiązywania problemów. CTR zawiera migawkę System i pliki dziennika w zaszyfrowanym archiwum. Wsparcie Sophos może ocenić to archiwum bezpośrednio w sprawach wsparcia.

Jak utworzyć CTR:

  1. Jeśli to możliwe, odtwórz błąd i zanotuj dokładny czas.
  2. Otwórz w WebAdmin Diagnostics > Tools.
  3. Wybierz wymagane opcje w obszarze Consolidated troubleshooting report.
  4. W przypadku zgłoszenia o szerokim zakresie włącz System snapshot i All log files.
  5. Wprowadź krótki powód, na przykład numer biletu, wzór błędu i okno czasowe.
  6. Wybierz Generate.
  7. Po utworzeniu wybierz Download.
  8. Udostępnij plik za pośrednictwem portalu wsparcia, uzgodnionego bezpiecznego przesyłania lub ścieżki analizy wewnętrznej.

Nazwa pliku zazwyczaj zaczyna się od CTR_ i zawiera numer seryjny lub identyfikator urządzenia, a także datę i godzinę utworzenia. Jest to przydatne, gdy wiele zapór sieciowych lub wiele prób kończy się jednym biletem.

⚠️ CTR nie jest pełnym zrzutem surowych danych. Logi podsystemów usług zawierają domyślnie najwyżej 10 000 wierszy; limit dotyczy tylko CTR. Jeśli potrzebne są starsze lub kompletne logi, należy pobrać osobno odpowiednie Troubleshooting Logs albo zapisać pliki przez Advanced Shell.

Sprawdzanie limitu wierszy CTR w Device Console

Limit wierszy logów podsystemów usług w CTR można wyświetlać i ustawiać niezależnie od surowych logów. W menu głównym CLI otwórz 4. Device Console. SFOS 22 dopuszcza od 250 do 10000 wierszy i domyślnie używa 10000:

system diagnostics show ctr-log-lines
system diagnostics ctr-log-lines 5000

Zwykle nie trzeba zmieniać wartości domyślnej. 5000 pokazuje jedynie składnię celowego zmniejszenia CTR: zakres jest stały, a wartość zależy od zgłoszenia. Przed zmianą zapisz bieżącą wartość za pomocą show; po wygenerowaniu CTR przywróć ją tym samym poleceniem ustawiającym. Zmiana dotyczy wyłącznie przyszłych plików CTR, nie pełnych surowych logów, i nie odzyska danych już usuniętych lub nadpisanych.

Pobierz indywidualne dzienniki rozwiązywania problemów

Jeśli moduł jest już znany, ukierunkowany eksport dziennika jest często lepszy niż bardzo szeroki zestaw danych.

  1. Otwórz Diagnostics > Tools.
  2. Wybierz odpowiednie pliki logów w obszarze Troubleshooting logs.
  3. Wybierz Download.
  4. Roześlij wygenerowany skompresowany plik wraz z czasem wystąpienia błędu, przypadkiem testowym i zaporą, której dotyczy problem.

Ta ścieżka jest odpowiednia, jeśli potrzebny jest na przykład tylko strongswan.log, charon.log, sslvpn.log, reverseproxy.log, applog.log lub log innej wyraźnie wskazanej usługi. W przeciwieństwie do CTR te osobne pliki nie podlegają limitowi wierszy. Przypisanie plików do modułów opisano w Sophos Firewall Rozwiązywanie problemów: Services i logi.

Otwórz Advanced Shell

Zaloguj się do Sophos Firewall i otwórz Advanced Shell:

  1. W menu głównym CLI wybierz 5. Device Management.
  2. Następnie otwórz 3. Advanced Shell.
  3. Potwierdź dostęp, jeśli zapora wyświetli dodatkowe zapytanie.

Po zalogowaniu znajdujesz się w powłoce zapory sieciowej. Stamtąd można archiwizować pliki dziennika.

Zbierz wybrane dzienniki przed utworzeniem kopii zapasowej

Jeśli problem można odtworzyć, jeśli to możliwe, należy go ponownie wywołać bezpośrednio przed archiwizacją dzienników. Oznacza to, że odpowiednie wpisy trafiają do plików dziennika możliwie najpóźniej.

Przy bardziej złożonych problemach zwykłe logi mogą nie wystarczyć. Przed utworzeniem archiwum można wtedy włączyć debugowanie wyłącznie dla usługi, której dotyczy problem. Tryb debugowania powinien działać krótko i zostać wyłączony zaraz po zebraniu danych, ponieważ pliki logów mogą szybko rosnąć. Procedurę opisano w sekcji Włączanie ukierunkowanego debugowania.

Przyporządkowanie plików logów do modułów zapory opisano w artykule Rozwiązywanie problemów z Sophos Firewall: usługi i logi. Zestawienie pomaga ustalić, czy dla danego problemu istotniejsze są logi VPN, IPS, WWW, poczty, interfejsu administracyjnego czy systemu.

Jeśli nie jest to problem z usługą, lecz niejasny przepływ pakietów, samo archiwum logów często nie wystarczy. Do krótkich testów nadaje się Packet Capture w WebAdmin. Do tworzenia plików PCAP, dłuższych przechwyceń lub analiz dla wsparcia właściwym narzędziem jest tcpdump na Sophos Firewall.

Zapisz surowe logi za pomocą Advanced Shell

Jeśli CTR nie wystarczy lub do analizy wewnętrznej potrzebne są wszystkie aktualnie dostępne surowe logi, można ręcznie zarchiwizować katalog /log. Ten sposób w powłoce nie zastępuje oficjalnego CTR ani pobierania pojedynczych plików w Troubleshooting logs. Przed archiwizacją sprawdź, czy w /var jest wystarczająco dużo wolnego miejsca:

df -h /var

Następnie utwórz skompresowane archiwum z plikami z katalogu /log:

tar -cvzf /var/Sophos-Firewall-Logs.tar.gz -C / log

Polecenie tworzy plik:

/var/Sophos-Firewall-Logs.tar.gz

Najważniejsze części polecenia:

  • tar tworzy archiwum.
  • -c tworzy nowe archiwum.
  • -v wyświetla przetworzone pliki.
  • -z kompresuje archiwum za pomocą programu gzip.
  • -f określa nazwę pliku archiwum.
  • -C / zmienia katalog główny na potrzeby operacji archiwizacji.
  • log to katalog zawierający pliki dziennika Sophos Firewall.

Zaletą -C / jest to, że polecenie działa niezależnie od bieżącego katalogu roboczego. Dlatego wcześniejsze cd / nie jest konieczne. Jeśli plik już istnieje, polecenie go nadpisze.

W zależności od rozmiaru i obciążenia zapory proces archiwizacji może zająć trochę czasu. Tymczasem wynik tar pokazuje, które pliki są zapisywane w archiwum.

Następnie można sprawdzić rozmiar archiwum:

ls -lh /var/Sophos-Firewall-Logs.tar.gz

Ponadto należy krótko sprawdzić, czy archiwum jest czytelne i czy rzeczywiście zawiera katalog dziennika:

tar -tzf /var/Sophos-Firewall-Logs.tar.gz

Wynik powinien pokazywać ścieżki pod log/. Jeśli polecenie zgłosi błąd albo archiwum jest nietypowo małe, nie należy go przekazywać dalej. Najpierw trzeba sprawdzić wolne miejsce, uprawnienia zapisu i poprzednie uruchomienie tar.

Skopiuj archiwum dzienników na serwer Linux

Jeśli do serwera Linux można dotrzeć poprzez SSH, archiwum można przesłać poprzez scp.

Przykład:

scp /var/Sophos-Firewall-Logs.tar.gz root@192.0.2.10:/root/

Adres IP, użytkownik i ścieżka docelowa muszą być dostosowane do Twojego środowiska.

Po przesłaniu archiwum znajduje się na serwerze docelowym pod adresem:

/root/Sophos-Firewall-Logs.tar.gz

Stamtąd można go przekazać wewnętrznie lub udostępnić wsparciu Sophos lub Avanet.

Zapisz oddzielnie dane diagnostyczne IPsec

Przy problemach z VPN lub IPsec mogą być pomocne dane połączeń IPsec z /tmp/ipsec/connections/. Sophos nie opisuje tego ręcznego archiwum jako standardowego eksportu SFOS 22, dlatego należy go używać wyłącznie do analizy wewnętrznej lub na wyraźną prośbę wsparcia.

Utwórz w tym celu osobne archiwum:

tar -cvzf /var/Sophos-Firewall-IPsec-Connections.tar.gz -C /tmp/ipsec connections

Również tutaj można krótko sprawdzić wygenerowany plik:

ls -lh /var/Sophos-Firewall-IPsec-Connections.tar.gz

To archiwum można również skopiować na serwer docelowy poprzez scp:

scp /var/Sophos-Firewall-IPsec-Connections.tar.gz root@192.0.2.10:/root/

Zwłaszcza w przypadku błędów IPsec sensowne jest udostępnienie tego archiwum razem ze zwykłymi dziennikami zapory ogniowej, aby można było wspólnie ocenić stan tunelu, informacje o połączeniu i wpisy dziennika.

Czego nie zastępuje archiwum dla supportu

CTR i archiwum /log są migawkami lokalnej zapory. Pomagają przy błędach usług i systemu, ale nie zapewniają automatycznie długiej historii ani nie dowodzą, że konkretny pakiet przeszedł przez zaporę. Do historii i wyszukiwania służą Central Firewall Reporting oraz Syslog i SIEM. Zmiany konfiguracji można śledzić dokładniej za pomocą Audit Trail Logs.

Oddzielnie obsługuj nagrania pakietowe

Archiwa dzienników i przechwycone pakiety są różnymi rodzajami materiału diagnostycznego. Archiwum logów pokazuje komunikaty usług, błędy, stany VPN i zdarzenia systemowe. Packet Capture lub tcpdump pokazuje natomiast, czy pakiety rzeczywiście docierają, są przekazywane dalej i czy wracają odpowiedzi.

W przypadkach pomocy technicznej nagrania pakietów nie powinny być wysyłane bez filtrowania. Jest lepiej:

  1. Zanotuj przypadek testowy ze źródłowym adresem IP, docelowym adresem IP, portem, protokołem i czasem.
  2. Najpierw sprawdź Log Viewer i WebAdmin Packet Capture, jeśli to wystarczy.
  3. W razie potrzeby utwórz bliskie nagranie tcpdump jako PCAP.
  4. Bezpiecznie przesyłaj plik PCAP.
  5. Po pomyślnym przesłaniu usuń plik PCAP z zapory sieciowej.

Plik PCAP nie należy do archiwum /log, ale jest tworzony i przesyłany osobno. Dzięki temu wiadomo, który plik zawiera dzienniki usług, a który pakiety sieciowe.

Bezpieczeństwo, prywatność i porządek

Pliki logów mogą zawierać dane wrażliwe, na przykład:

  • Publiczne i wewnętrzne adresy IP
  • Nazwa użytkownika
  • Nazwy hostów
  • Informacje o VPN
  • Komunikaty o błędach ze szczegółami technicznymi
  • Odniesienia do wewnętrznych struktur sieciowych

Dlatego archiwa dzienników powinny być przesyłane wyłącznie bezpiecznymi kanałami i udostępniane wyłącznie osobom lub organizacjom zaangażowanym w analizę. Jeżeli logi przesyłane są do partnera zewnętrznego, należy wcześniej wyjaśnić wewnętrznie, czy transfer jest dozwolony zgodnie z Twoimi własnymi wytycznymi dotyczącymi ochrony danych i bezpieczeństwa.

W klastrach HA logi i raporty nie są automatycznie synchronizowane między urządzeniami Primary i Auxiliary. Każde urządzenie zawiera logi i raporty dotyczące przetwarzanego przez nie ruchu. Przy problemach z HA lub w okresie obejmującym przełączenie awaryjne należy zanotować, z którego węzła pochodzi archiwum i czy potrzebne są także logi z drugiego węzła.

Usuń ponownie archiwa tymczasowe

Po przesłaniu sprawdź archiwum w systemie docelowym, a następnie usuń je z firewalla, aby zwolnić miejsce tymczasowe. Poniższe polecenia usuwają wyłącznie archiwa o stałych nazwach utworzone w tym przewodniku:

rm /var/Sophos-Firewall-Logs.tar.gz

Jeśli utworzono również osobne archiwum IPsec, należy je również usunąć:

rm /var/Sophos-Firewall-IPsec-Connections.tar.gz

Przed usunięciem należy sprawdzić, czy pliki pomyślnie dotarły do systemu docelowego.

Lista kontrolna zgłoszeń do pomocy technicznej

  • Krótko opisano problem: Co nie działa, od kiedy i jak często?
  • Dokładny czas podany ze strefą czasową.
  • Zanotowano dotknięty źródłowy adres IP, docelowy adres IP, użytkownika, usługę lub nazwę tunelu.
  • Odpowiedni moduł sprawdzony w Log Viewer.
  • W razie potrzeby: Debugowanie tylko na krótko aktywowane i ponownie dezaktywowane.
  • CTR utworzony w Diagnostics > Tools, gdy wymagana jest obsługa Sophos lub migawka System.
  • Utworzono indywidualne dzienniki rozwiązywania problemów lub, jeśli to konieczne, kompletne archiwa /log.
  • W przypadku problemów IPsec zapisano dodatkowe dane diagnostyczne IPsec.
  • Packet Capture lub tcpdump utworzony oddzielnie w przypadku problemów z przepływem pakietów.
  • Archiwum z tar -tzf zostało krótko sprawdzone pod kątem czytelności.
  • Sprawdzono w HA, z którego węzła pochodzą dzienniki.
  • Archiwum i PCAP przesyłane są wyłącznie bezpiecznymi kanałami.
  • Pliki tymczasowe z zapory zostały usunięte po pomyślnym transferze.

Często zadawane pytania

Czy zrzut ekranu z Log Viewer wystarczy do obsługi Sophos?

Zrzut ekranu może pomóc w prostych przypadkach. W przypadku złożonych błędów znacznie bardziej znaczące są pliki dziennika, dokładne informacje o czasie i, w zależności od problemu, nagranie Packet Capture lub tcpdump.

Czy zawsze należy tworzyć kopie zapasowe wszystkich dzienników Sophos Firewall?

Nie zawsze. Jeśli problem jest dobrze zawężony, często wystarczą odpowiednie logi i dokładny przedział czasu. Pełne archiwum /log bywa jednak przydatne w zgłoszeniach serwisowych, ponieważ problem może obejmować kilka powiązanych usług.

Kiedy sporządzany jest skonsolidowany raport dotyczący rozwiązywania problemów?

CTR jest przydatny, gdy Sophos Support potrzebuje migawki systemu i wielu plików logów w jednym uporządkowanym archiwum. Gdy potrzebne są pełne lub starsze surowe logi albo szczegółowa analiza wewnętrzna, może być konieczne dodatkowe pobranie pojedynczych logów w Troubleshooting logs lub utworzenie archiwum /log.

Czy plik PCAP należy do archiwum dziennika?

Nie. Pliki PCAP są tworzone oddzielnie przy użyciu Packet Capture lub tcpdump i przesyłane osobno. Oznacza to, że dzienniki usług i nagrania pakietów pozostają wyraźnie oddzielone.

Czy Central Reporting zastępuje lokalne archiwum dzienników?

Nie. Central Reporting jest przydatny do historii, wyszukiwania i raportów w Sophos Fusion (dawniej Sophos Central). W przypadku problemów związanych z pomocą techniczną lub analizą usług często nadal potrzebne są lokalne pliki dziennika z /log, ponieważ znajdują się tam szczegółowe informacje o modułach i usługach.

Jak sprawdzić, czy utworzono archiwum logów?

Najpierw sprawdź za pomocą ls -lh /var/Sophos-Firewall-Logs.tar.gz, czy plik istnieje i czy ma akceptowalny rozmiar. Następnie możesz użyć tar -tzf /var/Sophos-Firewall-Logs.tar.gz, aby sprawdzić, czy archiwum jest czytelne i zawiera pliki w log/.