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.

Oficjalna procedura pobierania i diagnostyki dotyczy SFOS 22 i SFOS 23. Dodatkowe archiwa tworzone ręcznie pozostają odrębną metodą analizy, a nie potwierdzonym standardowym eksportem dla obu wersji. 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:

• Sprawdź konkretną próbę połączenia: Przetestuj regułę zapory sieciowej za pomocą Log Viewer, Policy Test i Packet Capture, jeśli reguła, reguła NAT lub trasa są niejasne.
• Dobierz lokalne pliki logów: Rozwiązywanie problemów z Sophos Firewall: usługi i logi, jeśli najpierw trzeba ustalić, który log dotyczy VPN, WWW, IPS, interfejsu administracyjnego lub usług systemowych.
• Problem jest znany, a dane trzeba przekazać: wykonaj kroki z tego artykułu, aby utworzyć CTR, wybrane logi lub archiwum surowych logów.

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 zestawia się lub zrywa połączenie: zwykłe archiwum logów, dane diagnostyczne IPsec, adres IP drugiej strony, 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.

Logi diagnostyczne są przechowywane na partycji /var i odczytywane przez /log. Krytyczne komponenty otrzymują więcej miejsca; zależnie od podsystemu zachowywane są co najmniej dwie skompresowane rotacje. Po rotacji zapora kontynuuje zapis pod pierwotną nazwą pliku. Na urządzeniu XGS Appliance dostępna historia zależy więc również od modelu i usługi, a nie od jednego stałego okresu przechowywania.

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

W wielu zgłoszeniach warto najpierw wygenerować Consolidated Troubleshooting Report. CTR zawiera migawkę systemu i pliki logów w zaszyfrowanym archiwum. Sophos Support może przeanalizować je bezpośrednio w ramach zgłoszenia.

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. Wpisz krótki powód, na przykład numer zgłoszenia, objawy i przedział czasu.
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.

System snapshot nie wymaga trybu debug i zapisuje bieżący stan systemu, w tym aktywne procesy i wykorzystanie zasobów. Udokumentowana nazwa pliku to CTR_<APPKEY>_<MM_DD_YY>_<HH_MM_SS>: APPKEY jest numerem seryjnym zapory; kolejne pola oznaczają datę utworzenia w formacie miesiąc/dzień/rok i czas w formacie godzina/minuta/sekunda. Sama nazwa pliku jest więc także poufna. Jest to przydatne, gdy dane z wielu zapór lub kilku prób trafiają do tego samego zgłoszenia serwisowego.

Limit wierszy dotyczy tylko Service subsystem logs; Default subsystem logs są dołączane w całości, o ile dane są nadal dostępne. Zaszyfrowanego CTR nie sprawdza się poleceniem tar -tzf pokazanym dalej: sprawdź zakończenie pobierania, wiarygodny rozmiar, urządzenie i czas testu, a następnie bezpiecznie dołącz plik do zgłoszenia. Jeśli generowanie lub pobieranie się nie powiedzie, udokumentuj błąd i najpierw zapisz odpowiednie pojedyncze logi, zamiast usuwać logi.

⚠️ 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 i SFOS 23 dopuszczają od 250 do 10000 wierszy i domyślnie używają 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.

Zapisz krótki fragment logu na żywo

W Advanced Shell można śledzić nowe wpisy podczas ograniczonego testu:

cd /log
tail -f /log/charon.log

charon.log jest konkretnym przykładem dla IPsec; przy innych problemach wybierz odpowiedni istniejący plik z zestawienia logów usług. Zanotuj początek, koniec i strefę czasową testu, odtwórz problem i skopiuj wynik do chronionego pliku tekstowego na komputerze administratora. Ctrl+C zatrzymuje wyświetlanie, nie usługę zapory. tail -f pokazuje ostatnie istniejące wiersze i nowe wpisy, a nie pełny eksport. Jeśli brakuje wpisów, sprawdź najpierw węzeł, nazwę pliku, czas i usługę; w razie potrzeby pobierz pełny pojedynczy plik. Prześlij fragment i jego kontekst do zgłoszenia.

Zbierz wybrane dzienniki przed utworzeniem kopii zapasowej

Jeśli problem można odtworzyć, zrób to w miarę możliwości bezpośrednio przed archiwizacją logów. Dzięki temu istotne wpisy będą możliwie aktualne.

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.

Zbieraj debug z kontrolowaną drogą powrotu

Debug jest domyślnie wyłączony. Przed zmianą mimo to ustal z administratorami i wsparciem, czy zbieranie danych już trwa; udokumentuj węzeł, wolne miejsce i krótkie okno testowe. Pracuj z jednym obsługiwanym podsystemem naraz. Dane debug są dostępne przez pobranie pojedynczych plików, CTR i CLI. Dla udokumentowanego przykładu usługi wykonaj w 4. Device Console:

Dla innych obsługiwanych usług składnia to system diagnostics subsystems <subsystem> debug on i system diagnostics subsystems <subsystem> debug off. Zastąp <subsystem> nazwą CLI potwierdzoną w konkretnym buildzie, a nie nazwą pliku logu. Jeśli zbieranie debug już trwa dla innego zgłoszenia, nie zmieniaj tego stanu bez uzgodnienia.

system diagnostics subsystems Pktcapd debug on

Wykonaj tylko zaplanowany test, pobierz log lub gotowy CTR, a następnie wyłącz debug w tej samej Device Console:

system diagnostics subsystems Pktcapd debug off

Zapisz wyniki włączenia i wyłączenia oraz ich czas; krótkim testem kontrolnym sprawdź, czy nie powstają nowe wpisy debug, a wzrost logów i zużycie miejsca wróciły do normy. Jeśli polecenie zostanie odrzucone, nie zgaduj nazw: sprawdź składnię builda i skontaktuj się ze wsparciem. Wyłączenie nie usuwa zebranych plików.

Dla kontrolera systemu przewodnik logów podaje to samo polecenie, system diagnostics subsystems CSC debug, przy włączaniu i wyłączaniu, bez on ani off. Nie używaj tego przełącznika do sprawdzania stanu ani nie wykonuj go dwukrotnie w ciemno. Jeśli stan początkowy lub droga powrotu są niejasne, nie zmieniaj debug CSC; zastosuj kontrolowaną procedurę CSC ze wsparciem. Nazwy plików logów nie są nazwami podsystemów CLI.

Zestawienie diagnostyczne SFOS 22/23 wymienia następujące Default logs dla debug; ta grupa jest także wyłączona z limitu wierszy CTR:

syslog.log, postgres.log, reportdb.log, applog.log, access_server.log, awarrenhttp.log, awed.log, charon.log, csc.log, garner.log, heartbeatd.log, ips.log, iview.log, msync.log, nSXLd.log, networkd.log, red.log, reverseproxy.log, smtpd_main.log, sslvpn.log, tomcat.log, u2d.log, up2date_av.log, npu-startup.log.prev, npu_syslog.log, syslog-ng.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-pport-wait.log.

Wymienione Service logs to:

awarrenhttp_access.log, httplogd.log, bwm.log, awarrensmtp.log, pktcapd.log, warren.log.

Lista opisuje pliki obsługujące debug, a nie wszystkie logi ani ich gwarantowaną obecność na każdej platformie. Pliki NPU i XGS sprawdzaj w kontekście konkretnego urządzenia XGS Appliance. Zachowaj wielkość liter: pktcapd.log nie jest parametrem polecenia Pktcapd.

Zabezpiecz dowody przed czyszczeniem logów

Czyszczenie poleceniem purge nie jest wymagane do utworzenia CTR ani pobrania pojedynczych plików. Przewodnik diagnostyczny wymienia opróżnienie podsystemu przed odtworzeniem problemu tylko jako opcjonalne. Najpierw ustal wymagania dotyczące dowodów, wsparcia i przechowywania, a potrzebne pliki zapisz poza zaporą. W przeciwieństwie do późniejszego usuwania własnych archiwów purge usuwa historię diagnostyczną; nie można tego cofnąć.

Globalne polecenia Device Console to system diagnostics purge-old-logs dla wszystkich skompresowanych logów .gz i system diagnostics purge-all-logs dla całej zawartości logów. Według pomocy CLI po pełnym czyszczeniu pozostają puste pliki. Globalne operacje wpływają także na inne podsystemy i trwające zgłoszenia.

Konflikt składni dla pojedynczego podsystemu: Pomoc administratora SFOS 22/23 podaje system diagnostics <subsystem> purge-log i system diagnostics <subsystem> purge-old-log; pomoc CLI dokumentuje natomiast system diagnostics subsystems <subsystem> purge-log i system diagnostics subsystems <subsystem> purge-old-log. Przed zatwierdzonym czyszczeniem w 4. Device Console sprawdź pełną składnię i nazwy w pomocy CLI lub przez uzupełnianie klawiszem Tab oraz wyjaśnij konflikt ze wsparciem. Nie próbuj obu wariantów.

Przerwij przy niejasnej składni, pochodzeniu plików lub trwającym zbieraniu danych i skorzystaj z procedury analizy miejsca i kontrolowanego czyszczenia. Po uzgodnionej operacji sprawdź wolne miejsce, nowe normalne wpisy i stan usług; mniejsze zużycie miejsca nie dowodzi usunięcia przyczyny. Nie usuwaj ręcznie logów systemowych za pomocą rm ani symboli wieloznacznych.

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:

Przed użyciem tej dodatkowej metody w shellu sprawdź istniejące katalogi i wolne miejsce. Jeśli /log jest dowiązaniem symbolicznym, poniższe polecenie tar może zapisać tylko dowiązanie zamiast plików logów: nie kontynuuj z pozornie gotowym archiwum; użyj oficjalnego pobierania pojedynczych plików albo uzgodnij metodę ze wsparciem. Katalog, do którego nadal trwa zapis, również nie jest spójną kopią zapasową. Najpierw wyjaśnij brakujące ścieżki, błędy odczytu lub problemy z miejscem; nie usuwaj logów systemowych, aby zwolnić miejsce.

ls -ld /log
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 także dane połączeń z /tmp/ipsec/connections/. Przejrzane instrukcje SFOS 22/23 nie opisują tej ręcznej metody jako standardowego eksportu. Używaj jej wyłącznie do analizy wewnętrznej lub na wyraźną prośbę wsparcia i najpierw sprawdź, czy katalog istnieje.

Utwórz w tym celu osobne archiwum:

ls -ld /tmp/ipsec/connections
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. Tylko w razie potrzeby wykonaj przechwycenie tcpdump z wąskim filtrem i zapisz je 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
• Nazwy użytkowników
• 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 Sophos Support potrzebuje danych lub wymagana jest migawka systemu.
• 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.
• Sprawdzono rzeczywiste logi poleceniem tar -tzf tylko w ręcznych archiwach gzip; dla zaszyfrowanego CTR sprawdzono pobranie, urządzenie i czas.
• 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