Planowanie i wysyłanie raportów Sophos Firewall e-mailem

Sophos Firewall może wysyłać lokalne raporty codziennie lub co tydzień w formacie PDF. Aby odbiorca otrzymał użyteczną analizę, a nie dowolny plik, raport najpierw sprawdza się ręcznie, a dopiero potem tworzy harmonogram.

Niezawodny proces jest krótki:

1. Ręcznie wygenerować żądany raport z odpowiednim okresem i filtrem.
2. W razie potrzeby zapisać wybór jako bookmark.
3. Utworzyć harmonogram w Reports > Show report settings > Report scheduling.
4. Sprawdzić tor pocztowy za pomocą Send test mail.
5. Za pomocą Generate now natychmiast wygenerować i wysłać raport.
6. Sprawdzić otrzymany PDF pod kątem treści, okresu, języka i danych wrażliwych.

Send test mail i Generate now nie sprawdzają tego samego. Wiadomość testowa potwierdza transport poczty. Dopiero Generate now sprawdza również, czy zapora generuje wybrany raport i wysyła go jako PDF.

⚠️ Modele XGS 87/87w i XGS 88/88w nie obsługują On-appliance Reporting. Dla tych modeli lub do centralnej analizy wielu zapór lepiej nadaje się Sophos Central Firewall Reporting w Sophos Fusion.

Sprawdzanie wymagań wstępnych

Przed utworzeniem harmonogramu sprawdza się sześć podstawowych elementów:

• Lokalne raporty działają: W Reports wybrany okres zawiera już wiarygodne dane. Harmonogram nie naprawi braku logowania ani pustej bazy raportów.
• Wysyłanie wiadomości działa: Wbudowany lub zewnętrzny serwer pocztowy oraz wymagane ustawienia uwierzytelniania, zabezpieczeń połączenia, nadawcy i odbiorcy są skonfigurowane w Administration > Notification settings. Pełny proces opisano w artykule Konfiguracja i test powiadomień e-mail Sophos Firewall.
• Czas i strefa czasowa są prawidłowe: Błędny czas systemowy utrudnia wybór i kontrolę okresu. Konfigurację opisano w artykule Konfiguracja daty, czasu i NTP.
• Dostępna jest lokalna przestrzeń: Dane On-box Reports znajdują się w /var. Po osiągnięciu progu zatrzymania zapora wstrzymuje raportowanie. Status, progi ostrzegawcze i retencję wyjaśnia artykuł Sprawdzanie miejsca i zarządzanie raportami Sophos Firewall.
• Lokalna retencja odpowiada celowi: W Reports > Show report settings > Data management raporty można przechowywać maksymalnie przez rok. Wybrany okres jest liczony wstecz od poprzedniego miesiąca, a zmiana zaczyna obowiązywać o 00:00. Ustawienie dotyczy tylko raportów, a nie logów ani plików PDF już dostarczonych do skrzynki pocztowej. Zapora automatycznie usuwa starsze raporty. Przed zmianą okresu przechowywania należy więc sprawdzić wymagania organizacji dotyczące zgodności i retencji.
• Określono odbiorcę i cel: Funkcyjna skrzynka, taka jak firewall-reports@example.net, jest zazwyczaj lepsza niż adres osobisty. Potrzebny jest Owner, który rzeczywiście sprawdza raporty.

PDF może zawierać użytkowników, adresy IP, adresy MAC, adresy e-mail, adresy URL i zdarzenia bezpieczeństwa. Dlatego grono odbiorców powinno być małe, transport poczty szyfrowany, a retencja w skrzynce uwzględniona. Jeśli używana jest funkcja Data Anonymization dla logów i raportów, w faktycznie odebranym PDF należy sprawdzić, czy oczekiwane dane zostały zanonimizowane.

Jeśli raportowanie zatrzymało się z powodu braku miejsca, obniżenie użycia /var tuż poniżej 80 procent nie wystarczy. Musi ono spaść poniżej progu ostrzegawczego, domyślnie 70 procent, aby zapora wznowiła generowanie raportów. Próg ostrzegawczy można ustawić od 50 do 75 procent; próg zatrzymania wynoszący 80 procent jest stały. Control Center pokazuje ostrzeżenia i alarmy, a Log Viewer rejestruje także spadek poniżej progu ostrzegawczego. Powiadomienia e-mail i SNMP przy wyższym progu są domyślnie wyłączone: w System services > Notification list > Disk/Memory włączyć Reports disk usage exceeded threshold dla potrzebnych miejsc docelowych i zapisać przez Save. Następnie sprawdzić stan i nowe dane raportów; otrzymanie starego PDF nie dowodzi wznowienia generowania. Bezpieczna diagnostyka i zwalnianie miejsca pozostają opisane w podlinkowanym artykule o przestrzeni dyskowej.

Globalne sterowanie Top Users w raportach PDF

Mało opisowe polecenie Device Console system custom-feature decyduje, czy generowane raporty PDF zawierają również Top Users. Przełącznik działa globalnie i nie ma parametru raportu ani odbiorcy. Ponieważ aktualna pomoc SFOS 22 nie podaje wartości domyślnej, najpierw należy odczytać istniejący stan:

system custom-feature show

Przed każdą zmianą zapisać wyświetlone ustawienie jako zatwierdzony stan początkowy; to on określa sposób wycofania zmiany.

enable dodaje Top Users, a disable ponownie usuwa ich z generowanych plików PDF:

system custom-feature enable
system custom-feature disable

Przed enable należy sprawdzić odbiorców, okres przechowywania i Data Anonymization. Następnie za pomocą Generate now trzeba utworzyć rzeczywisty PDF i potwierdzić, że pojawiają się oczekiwani użytkownicy, a wrażliwe tożsamości są chronione zgodnie z założeniem. Przełącznik nie tworzy brakującego przypisania użytkownika i nie naprawia problemu uwierzytelniania ani logowania. Przy wycofywaniu zmiany przywrócić dokładnie zapisany stan początkowy: system custom-feature enable, jeśli funkcja była włączona, albo system custom-feature disable, jeśli była wyłączona. Jeśli była już włączona, ponowne enable niczego nie zmienia; nie wyłączać jej w ramach pozornego rollbacku. Następnie potwierdzić stan początkowy poleceniem system custom-feature show i sprawdzić nowy PDF za pomocą Generate now: Top Users ma być obecne lub nieobecne zgodnie z zapisanym ustawieniem. Wycofanie zmiany nie obiecuje uzupełnienia brakujących danych ani odzyskania utraconej historii raportów.

Przygotowanie treści raportu

W przykładzie tygodniowy raport IPS ma pokazywać najczęściej wykrywane ataki. Nazwy i wartości należy dostosować do własnego środowiska.

1. Otworzyć Reports > Network & threats > Intrusion attacks.
2. Wybrać żądany zakres dat.
3. W razie potrzeby użyć Filter, aby ograniczyć analizę do odpowiednich systemów, reguł lub zdarzeń.
4. Wybrać Generate.
5. Sprawdzić, czy okres, trafienia i sortowanie odpowiadają pytaniu, na które raport ma odpowiedzieć.

Cel merytoryczny powinien dać się wyjaśnić jednym zdaniem, na przykład: „Zespół bezpieczeństwa w każdy poniedziałek sprawdza najczęstsze trafienia IPS z poprzedniego tygodnia”. Takie stwierdzenie ułatwia wybór naprawdę potrzebnego raportu, filtra i odbiorcy.

Dla generowanych raportów można opcjonalnie wybrać własne logo (Custom logo), które będzie wyświetlane w raportach.

Wybór odpowiedniej grupy raportów

W Reports wybrać grupę raportów lub analizę przez Show, a następnie zakres dat. Generate odświeża dane, Filter je zawęża, a Schedule otwiera harmonogram bezpośrednio z widoku raportu. Wybór powinien wynikać z pytania operacyjnego, nie tylko z nazwy:

• Dashboards: Traffic dashboard pokazuje ruch według aplikacji, kategorii WWW i użytkowników. Security dashboard pokazuje odrzuconą aktywność, malware, spam oraz najczęstsze kraje źródłowe i docelowe. Executive report łączy często potrzebne informacje o ruchu i zagrożeniach. User threat quotient szereguje użytkowników według punktowej oceny zagrożenia.
• Network & threats: Intrusion attacks pokazuje próby ataków. Active threat response pokazuje zdarzenia zagrożeń i przejęte hosty na podstawie feedów MDR i Sophos X-Ops. Wireless dotyczy wykorzystania punktów dostępowych i skonfigurowanych SSID, Security Heartbeat zgłaszanego stanu endpointów, a Zero-day protection aktywności rozszerzonej ochrony przed zaawansowanymi i ukierunkowanymi atakami.
• Email: Email usage odpowiada na pytania o ruch pocztowy; Email protection dotyczy ruchu zawierającego wirusy lub spam. Dostarczanie poczty i zdarzenia ochronne to różne zagadnienia przeglądu.
• VPN: VPN dotyczy ruchu dostępu zdalnego, SSL VPN ruchu klientów SSL VPN, a Clientless access dostępu przez przeglądarkę. Opis VPN wymienia także IPsec, L2TP i PPTP. Ta historyczna klasyfikacja nie gwarantuje, że każda wymieniona metoda jest dostępna lub bezpieczna do konfiguracji w zainstalowanym buildzie; nie włącza się przestarzałych metod dostępu na potrzeby raportu.
• Compliance: Dostępne widoki mają nazwy HIPAA, GLBA, SOX, FISMA, PCI, NERC CIP v3 i CIPA; Events pokazuje zdarzenia sieciowe i ich wagę. Raporty wspierają analizę, ale same nie potwierdzają pełnej zgodności ani aktualności danego wymagania dla organizacji.
• Applications & web: User app risks & usage, Cloud application usage i Web risks & usage służą analizie wykorzystania i ryzyka. Wykorzystanie chmury można przeglądać według klasyfikacji, kategorii, wykorzystania, treści, stref źródłowych i krajów docelowych. Blocked user apps i Blocked web attempts pokazują zablokowane próby; Web policy overrides pokazuje autoryzowane wyjątki od polityk. Synchronized applications dotyczy aplikacji endpointów wykrytych przez Security Heartbeat, Search engine wzorców wyszukiwania, a Web content dopasowań filtrów treści. Web server usage, Web server protection, User data transfer, FTP usage i FTP protection obejmują ruch serwerów, ataki na serwery WWW i ich źródła, ruch użytkowników oraz normalną lub szkodliwą aktywność FTP.

Application risk meter przedstawia średni wynik oparty na poziomie ryzyka i trafieniach poszczególnych aplikacji. Czerwień oznacza więcej ruchu aplikacji wysokiego ryzyka, zieleń więcej ruchu niskiego ryzyka. Średnia jest wskazówką, nie dowodem konkretnego przejęcia; przy ocenie należy sprawdzić poszczególne aplikacje, poziomy ryzyka i trafienia. W Web content obowiązuje istotne ograniczenie związane z prywatnością: strony sklasyfikowane jako highly objectionable criminal activity są zawsze blokowane, a nazwa domeny jest ukrywana w logach i raportach. Brak domeny nie oznacza więc automatycznie błędu eksportu i nie uzasadnia wyłączania ochrony w celu diagnostyki.

W Web policy overrides sprawdzić użytkowników uprawnionych do nadpisywania polityk oraz objęte tym zablokowane witryny i kategorie WWW. Opis Web server usage obejmuje ruch aplikacji, WWW, internetowy i FTP; ten wybór nie ogranicza się więc do ataków na serwery WWW. Te należą do Web server protection.

Rozróżnienie Custom report, Custom view i bookmark

Custom report w Reports > Custom zawęża jeden obszar danych za pomocą szczegółowych kryteriów. Dostępne są raporty dotyczące WWW, poczty, FTP, użytkowników i serwerów WWW. Ważne jest ograniczenie raportów WWW: wyszukiwanie niestandardowe pokazuje tylko dozwolone domeny, adresy URL, kategorie i adresy IP. Zablokowany dostęp do stron należy sprawdzać w Reports > Applications & web > Blocked web attempts.

Custom view łączy kilka grup raportów w jednym widoku, na przykład aktywność Zero-day protection i użytkowników WWW. Tworzy się go w Reports > Show report settings > Custom view > Add, podając nazwę i wymagane grupy raportów; następnie jest dostępny w Reports > Custom. Nowy widok należy najpierw wygenerować i sprawdzić ręcznie, zanim zostanie zaplanowany lub udostępniony.

Przy wyborze kryteriów: raport WWW wyszukuje aktywność przeglądania lub wirusy, na przykład według użytkownika i domeny; raport poczty wyszukuje wykorzystanie, spam i wirusy według protokołu lub użytkownika. Raport FTP może wyszukiwać według typu transferu, użytkownika, pliku lub źródłowego IP. Raport użytkownika przypisuje aplikacje wysokiego ryzyka, nieproduktywne domeny i wykryte wirusy do nazwy użytkownika lub hosta źródłowego. Raport serwera WWW analizuje czas, użytkownika, URI i aktywność ochronną. Kryteria dobiera się do pytania; nie gwarantują one danych bez odpowiedniego logowania.

Nowy widok Custom view zapisać przez Save przed ręcznym wygenerowaniem.

Bookmark zapisuje natomiast już przefiltrowany, powtarzalny wybór. Harmonogram może wybrać domyślną lub niestandardową grupę raportów albo bookmark. Dla administratora najlepszy nie jest technicznie największy raport, lecz najmniejszy wybór, który odpowiada na konkretną potrzebę operacyjną.

Zapisywanie powtarzalnego wyboru jako bookmark

Bookmark jest przydatny, gdy harmonogram ma obejmować nie całą grupę raportów, lecz wielokrotnie używany wybór z filtrem.

1. Otworzyć przygotowany raport.
2. Wybrać Bookmark.
3. Wprowadzić zrozumiałą nazwę, na przykład Weekly-IPS-Review.
4. Wybrać odpowiednią grupę bookmarków i zapisać przez Save.

Jeśli nie ma odpowiedniej grupy, tworzy się ją w Reports > Show report settings > Bookmark management > Add bookmark group. Nazwa taka jak Weekly-IPS-Review lepiej opisuje cel i cykl niż Report1.

Po zapisaniu ponownie otworzyć bookmark i jeszcze raz wygenerować raport. W ten sposób sprawdza się, czy rzeczywiście ponownie używany jest zamierzony wybór. Dokładnego okresu późniejszego PDF nie należy wywodzić wyłącznie z nazwy; trzeba go sprawdzić w wygenerowanym pliku.

Jeśli nie istnieje jeszcze własna grupa bookmarków, bookmark można przypisać do grupy domyślnej. Dla nowej grupy wprowadzić nazwę i zapisać przez Save; grupa porządkuje powiązane bookmarki, na przykład dotyczące aplikacji i zagrożeń. Aby ponownie otworzyć bookmark, wybrać grupę w Show, a następnie pojedynczy bookmark. Grupa pojawia się w tym wyborze tylko wtedy, gdy zawiera co najmniej jeden bookmark. Jeśli jej brakuje, najpierw sprawdzić zawartość zamiast wielokrotnie tworzyć harmonogram.

Pobieranie eksportu do porównania

Na potrzeby porównania niezależnego od toru pocztowego raporty pobiera się w WebAdmin, nie przez CLI:

1. Otworzyć Reports > Applications & web.
2. Wybrać kryteria w Show, a następnie zakres dat.
3. Wygenerować i sprawdzić dane przez Generate.
4. Wybrać jeden z dostępnych formatów i otworzyć pobrany plik.

W Reports > Show report settings > Data management pole retencji nazywa się Log retention report period, choć dotyczy tylko raportów. Export customization określa natomiast wybór raportów i liczbę rekordów na raport w eksporcie. Przed pobraniem dobrać zakres do celu przeglądu i sprawdzić go w pliku. Dostosowanie eksportu nie zmienia retencji ani nie jest udokumentowaną metodą zniesienia limitu 50 rekordów zaplanowanych raportów e-mail. Pełne zarządzanie przestrzenią i eksportami opisano w już podlinkowanym artykule.

Tworzenie harmonogramu

1. Otworzyć Reports > Show report settings > Report scheduling.
2. Wybrać Add.
3. Jako typ wybrać Report.
4. W To email address wprowadzić odbiorców. Wiele adresów rozdziela się przecinkami.
5. W Report type wybrać grupę raportów lub przygotowany bookmark.
6. Jeśli opcja jest dostępna, ustawić sortowanie według Hits albo Bytes odpowiednio do celu.
7. W Email frequency wybrać Daily lub Weekly.
8. Zapisać przez Save.

Pole sortowania nazywa się Sorting criteria; Hits priorytetyzuje częste trafienia, a Bytes ilość danych. Opcja dotyczy tylko raportów oferujących takie sortowanie.

W przykładzie używane są następujące wartości:

• Odbiorca: firewall-reports@example.net
• Report type: Bookmark Weekly-IPS-Review
• Sortowanie: Hits
• Częstotliwość: Weekly

Wartości te nie są uniwersalnym standardem. W raporcie o przepustowości przydatniejsze może być sortowanie według Bytes, codzienny raport operacyjny wymaga Daily, a inna lokalizacja może potrzebować własnego odbiorcy lub bookmarku.

Zaplanowane On-box Reports są wysyłane jako PDF i zawierają maksymalnie 50 rekordów. Limit ten dotyczy raportu w wiadomości e-mail i nie należy go traktować jako pełnego archiwum ani eksportu wszystkich lokalnych danych. Dla wielu zapór, skonsolidowanych danych HA lub dłuższych analiz centralnych lepszą warstwą jest Sophos Central Firewall Reporting w Sophos Fusion.

Od SFOS 21.5 MR1 zaplanowany raport PDF używa języka WebAdmin administratora, który utworzył harmonogram. Jeśli odbiorca ma otrzymać raport po niemiecku, harmonogram tworzy się w niemieckojęzycznej sesji WebAdmin, a wynik sprawdza za pomocą Generate now.

Oprócz zwykłych raportów harmonogram obsługuje również Security audit report oraz, po skonfigurowaniu integracji, ConnectWise. Security Audit Report jest przeznaczony w szczególności do pasywnej analizy Discover Mode z TAP i SPAN. Typy te służą innym celom i nie należy ich wybierać tylko dlatego, że zwykły raport pozostaje pusty.

Kontrolowana konfiguracja harmonogramów Security audit i ConnectWise

Security audit report to predefiniowany raport dotyczący aktywności związanej z bezpieczeństwem. Jego harmonogram zawiera pola: Organization name dla nazwy wyświetlanej w raporcie, To email address dla adresów odbiorców rozdzielonych przecinkami, Report type dla danych grupy raportów lub zakładki oraz Email frequency dla wysyłki Daily lub Weekly.

ConnectWise schedule jest dostępny dopiero po zintegrowaniu ConnectWise z Sophos Firewall. ConnectWise musi być włączony w Reports > Show report settings > ConnectWise, z adresem URL serwera i danymi logowania użytkownika właściwymi dla integracji organizacji. Nie ujawniać danych logowania w przykładowych PDF ani materiałach dla wsparcia. Skonfiguruj jego dokładne pola harmonogramu następująco:

• Report: Wybierz jeden z wstępnie skonfigurowanych raportów ConnectWise: Top sites, Filtered sites, Bandwidth usage lub Top attacks.
• Number of records: Ustaw liczbę rekordów tworzonych w raporcie. Dobierz ją do celu przeglądu, zamiast zakładać, że ogólny limit 50 rekordów w raportach e-mail jest właściwą wartością dla ConnectWise.
• Frequency: Zaplanuj raport codziennie w określonym interwale.

Po zapisaniu jednego z tych specjalistycznych harmonogramów użyj Generate now i sprawdź dostarczony raport. Aktywna integracja lub widoczność harmonogramu na liście nie dowodzi jeszcze, że predefiniowany raport zawiera oczekiwane rekordy.

Kontrola wysyłki i pliku PDF

Po zapisaniu nie czeka się do pierwszego regularnego terminu.

1. Sprawdzanie transportu poczty za pomocą Send test mail

Na liście wybrać harmonogram, uruchomić Send test mail, wprowadzić adres testowy i wybrać Send. Adres ten podaje się osobno na potrzeby testu i nie musi być zgodny z To email address harmonogramu. Aby pierwszy test był miarodajny, należy użyć tej samej skrzynki funkcyjnej. Następnie w tej skrzynce, filtrze spamu lub śledzeniu serwera pocztowego sprawdzić, czy wiadomość została przyjęta i dostarczona.

Pomyślna wiadomość testowa potwierdza połączenie ze skonfigurowanym serwerem pocztowym i podstawowe dostarczanie. Nie potwierdza jeszcze, że wybrany raport zawiera dane ani że zostanie wygenerowany jako prawidłowy PDF.

2. Sprawdzanie całego toru za pomocą Generate now

Następnie uruchomić Generate now. Zapora natychmiast generuje zaplanowany raport i wysyła go do podanych odbiorców.

W otrzymanym PDF sprawdza się:

• właściwą zaporę lub lokalizację;
• zamierzoną grupę raportów lub wybór bookmarku;
• wiarygodny okres i znacznik czasu;
• sensowne sortowanie i ilość danych;
• oczekiwany język;
• czytelną prezentację tabel i wykresów;
• jeśli wybrano własne logo: przed udostępnieniem nowo wygenerowanego raportu sprawdzić wzrokowo, czy wyświetla się w nim oczekiwane logo;
• brak zbędnego ujawnienia danych użytkowników, sieci lub bezpieczeństwa.

⚠️ Przy aktualizacji z SFOS 20.0 lub wcześniejszego do SFOS 21.0 lub nowszego raporty sprzed aktualizacji i po niej są przechowywane w oddzielnych bazach danych. Jeśli wybrano tylko dzień migracji, trzeba osobno wybrać Data before migration i Data after migration, aby przeanalizować cały dzień. Zakres dat obejmujący dzień migracji należy natomiast podzielić na zakresy przed tym dniem i po nim. Powrót do wcześniejszej wersji powoduje utratę wszystkich raportów wygenerowanych od aktualizacji, również po ponownej aktualizacji. Podczas kontroli zaplanowanych plików PDF należy uwzględnić ten podział baz danych: skuteczne dostarczenie wiadomości nie dowodzi samo w sobie ciągłości danych obejmujących migrację.

Sprawdzić przypisanie dat po przerwie: Przy wyłączaniu zapory część danych może pozostać nieprzetworzona. Po ponownym uruchomieniu zdarzenia w tych danych mogą zostać przypisane do dnia poprzedzającego ponowne uruchomienie zamiast do faktycznego dnia zdarzenia, nawet do dnia, w którym zapora była wyłączona. Dotyczy to pozostałych nieprzetworzonych danych, a nie wszystkich zdarzeń. Po przerwie należy więc wygenerować nowy PDF za pomocą Generate now i szczególnie dokładnie sprawdzić okres oraz daty zdarzeń.

Dla spójności danych raportowych zaleca się ciągłą pracę zapory; ponowne uruchomienie nie jest sposobem na naprawę rozbieżności w datach zdarzeń.

Dopiero potem obserwuje się następne regularne wykonanie. Aktualna pomoc nie opisuje powiązania czasu wykonania, strefy czasowej i okresu raportu na tyle szczegółowo, aby można było przyjąć je ogólnie. Dlatego wygenerowany raport jest dowodem działania funkcji.

Obsługa w klastrze HA

Lokalne dane raportów nie są synchronizowane między węzłami HA. Każdy węzeł zawiera tylko raporty dotyczące przetwarzanego przez niego ruchu. Pomoc dotycząca Report scheduling z 19 grudnia 2025 r. opisuje wysyłanie raportów przez oba urządzenia, gdy raport danego urządzenia zawiera co najmniej jeden wiersz danych w tabeli; nie opisuje wysyłania raportu bez wiersza danych. Natomiast przegląd HA z 13 sierpnia 2025 r. opisuje wysyłanie raportów przez urządzenie pomocnicze w zależności od danych i podaje Security Dashboard oraz Security Audit jako przykłady raportów, które nie są wysyłane. Opisy te nie są w pełni zgodne; pomoc dotycząca harmonogramów jest nowszą dokumentacją, bardziej szczegółowo opisującą ten proces, ale nie stanowi gwarancji dla każdego scenariusza raportu i buildu. Dlatego mogą nadejść dwie wiadomości e-mail. Przed usunięciem rzekomo zduplikowanego harmonogramu należy sprawdzić działanie wybranego raportu na używanym buildzie za pomocą Generate now oraz porównać nadawcę, urządzenie, okres i treść. Sam brak drugiej wiadomości e-mail nie pozwala stwierdzić ani błędu, ani usterki funkcji HA.

Nawet nieaktywna poza tym zapora może wygenerować Executive report z wykorzystaniem systemu i danymi raportów. „Brak ruchu użytkowników” nie oznacza więc „braku wierszy danych” i nie musi zapobiegać wysyłce z obu zapór.

Takie dostarczenie nie jest automatycznie błędem. Najpierw należy porównać nadawcę, tożsamość appliance, okres i treść obu plików PDF. Do skonsolidowanego widoku obu węzłów lepiej nadaje się Central Reporting niż dwa lokalne raporty e-mail.

Po przełączeniu awaryjnym HA, wymianie appliance lub aktualizacji firmware ponownie sprawdza się Generate now. Pozwala to wykryć sytuację, w której harmonogram jest nadal widoczny, ale dane, język albo dostarczanie poczty nie są już zgodne z oczekiwaniami.

Systematyczne ustalanie przyczyny błędów

Send test mail nie działa

Problem dotyczy wtedy toru pocztowego, a nie treści raportu. W Administration > Notification settings sprawdza się DNS, trasę, port, uwierzytelnianie, OAuth, TLS, certyfikat, nadawcę i odbiorcę. Śledzenie serwera pocztowego lub kwarantanna pokazują, czy wiadomość została przyjęta, czy odrzucona.

Nie należy wielokrotnie tworzyć harmonogramu od nowa. Najpierw wiadomość testowa musi niezawodnie docierać. Typowe błędy i bezpieczne testy opisano w artykule o powiadomieniach e-mail.

Wiadomość testowa dociera, ale Generate now nie dostarcza raportu

Tor SMTP jest wtedy zasadniczo potwierdzony. Następnie sprawdza się:

1. Czy w harmonogramie wybrano właściwą grupę raportów lub bookmark?
2. Czy ten sam raport zawiera dane przy ręcznym uruchomieniu?
3. Czy On-box Reporting jest aktywny i obsługiwany przez dany model appliance?
4. Czy użycie /var jest poniżej progu zatrzymania raportów, a po zatrzymaniu z powodu braku miejsca ponownie poniżej progu ostrzegawczego?
5. Czy logowanie i wymagane funkcje ochronne są aktywne dla oczekiwanych danych?
6. Czy wiadomość pojawia się w śledzeniu serwera pocztowego, spamie lub kwarantannie?

W Device Console dwie komendy tylko do odczytu pokazują bieżący status On-box i progi przestrzeni na raporty:

show on-box-reports
show report-disk-usage watermark

Komendy niczego nie zmieniają. Dalszą diagnostykę przestrzeni i znaczenie wyników opisano w artykule Zarządzanie miejscem i raportami.

PDF jest pusty, niepełny lub błędnie wyświetlany

Najpierw ręcznie generuje się ten sam raport z identycznym okresem i filtrem. Jeśli już analiza w WebAdmin jest pusta, brakuje danych raportowych, logowania lub odpowiednich zdarzeń. Jeśli tylko PDF zawiera błędne albo niepełne dane, należy udokumentować wersję SFOS, build, przeglądarkę, harmonogram, czas użycia Generate now i przykładowy PDF.

SFOS 22.0 MR2 Build 546 usuwa między innymi znane błędy pustego codziennego pliku Traffic dashboard PDF bez On-box Reporting oraz nieprawidłowo wyświetlanych tabel lub wykresów w plikach On-demand PDF wygenerowanych w Chrome. Podobny objaw w innym buildzie nie oznacza automatycznie tego samego błędu. Przed zmianami należy więc sprawdzić dokładny build i porównać go z ręcznie wygenerowanym raportem.

Do głębszej analizy koreluje się czas testu oraz pliki cschelper.log, reportdb.log, garner.log i w razie potrzeby postgres.log. Dostęp opisano w artykule Rozwiązywanie problemów z usługami i logami Sophos Firewall. Pojedynczy wpis w logu nie jest wystarczającym powodem do ponownego uruchamiania usług raportowania ani usuwania danych raportowych.

Executive report z okresem 1 month nie daje się pobrać jako PDF

Dla SFOS 22.0 MR1 Build 490 Sophos udokumentował pod identyfikatorem NC-182976 precyzyjnie ograniczony problem: w Reports > Dashboards > Executive report pobieranie pliku PDF mogło się nie powieść po wybraniu okresu 1 month. Dlatego najpierw sprawdza się dokładny build firmware’u, typ raportu, okres i format wyjściowy. Nie oznacza to automatycznie, że problem dotyczy innych raportów PDF ani zaplanowanych raportów e-mail.

W ówczesnym tekście opisu Sophos wskazywał pobranie pliku CSV z okresem jednego dnia; w oddzielnej kolumnie KIL Workaround widniało jednak None. Dlatego ten eksport jest tylko ograniczonym testem zastępczym. Nie zastępuje pełnego raportu miesięcznego i nie potwierdza ani poprawnego działania raportu miesięcznego, ani ścieżki generowania plików PDF. Jeśli nie działają także inne raporty, okresy lub formaty, zakres problemu jest szerszy niż NC-182976; należy wtedy udokumentować czas i przeglądarkę oraz zabezpieczyć wymienione wyżej logi, zamiast ponownie uruchamiać usługi raportowania lub usuwać dane raportowe.

Wcześniej udokumentowany wpis dotyczący NC-182976 wymieniał SFOS 23.0 EAP0 Build 275 w polu Fix versions i opisywał poprawki dla SFOS 23 i SFOS 22.0 MR3 jako nadchodzące. Te historyczne pola nie potwierdzają ani aktualnego statusu wydania, ani statusu błędu. Przed aktualizacją należy sprawdzić aktualną Known Issues List i Release Notes udostępnionej wersji docelowej oraz jej obsługę używanego modelu. Brak wpisu w aktualnej Known Issues List nie jest dowodem, że błąd został naprawiony. Jeśli ten sam objaw występuje w MR2 lub innym buildzie, nie przypisuje się go automatycznie do NC-182976, lecz sprawdza na podstawie zabezpieczonych danych.

Wiadomość e-mail zawiera tylko 50 rekordów

Jest to udokumentowany górny limit zaplanowanych raportów e-mail. Filtr i cel raportu należy dobrać tak, aby 50 najważniejszych rekordów odpowiadało na konkretne pytanie operacyjne. Jeśli potrzebne są pełne dane surowe, dłuższa historia lub analizy wielu zapór, lepiej sprawdzi się centralny proces raportowania lub SIEM.

Ten sam raport przychodzi dwa razy

W klastrze HA można spodziewać się dwóch wiadomości e-mail; oficjalne opisy wysyłania raportów przez urządzenie pomocnicze w zależności od danych różnią się, jak wyjaśniono w sekcji dotyczącej pracy w trybie HA. Przed usunięciem rzekomo zduplikowanego harmonogramu należy sprawdzić działanie wybranego raportu na używanym buildzie za pomocą Generate now oraz porównać nadawcę, urządzenie, okres i treść. Sam brak drugiej wiadomości e-mail nie dowodzi błędu HA. W przypadku pojedynczej zapory sprawdza się natomiast, czy dwa harmonogramy używają tego samego wyboru raportu i tego samego odbiorcy.