Sophos Firewall Reports planen und per E-Mail versenden

Sophos Firewall kann lokale Reports täglich oder wöchentlich als PDF versenden. Damit der Empfänger nicht nur irgendeine Datei, sondern eine brauchbare Auswertung erhält, wird der Report zuerst manuell geprüft und erst danach geplant.

Der zuverlässige Ablauf ist kurz:

1. Den gewünschten Report mit Zeitraum und Filter manuell erzeugen.
2. Die Auswahl bei Bedarf als Bookmark speichern.
3. Unter Reports > Show report settings > Report scheduling einen Zeitplan anlegen.
4. Mit Send test mail den Mailweg prüfen.
5. Mit Generate now den Report sofort erzeugen und versenden.
6. Das empfangene PDF auf Inhalt, Zeitraum, Sprache und sensible Daten kontrollieren.

Send test mail und Generate now prüfen nicht dasselbe: Die Testmail bestätigt den Mailtransport. Erst Generate now prüft zusätzlich, ob die Firewall den gewählten Report erzeugt und als PDF versendet.

⚠️ Die Modelle XGS 87/87w und XGS 88/88w unterstützen kein On-appliance Reporting. Für diese Modelle oder eine zentrale Auswertung mehrerer Firewalls passt Sophos Central Firewall Reporting in Sophos Fusion.

Voraussetzungen prüfen

Vor dem Zeitplan werden sechs Grundlagen geklärt:

• Lokale Reports funktionieren: Unter Reports enthält der gewünschte Zeitraum bereits plausible Daten. Ein Zeitplan kann fehlendes Logging oder eine leere Reportdatenbank nicht reparieren.
• E-Mail-Versand funktioniert: Der integrierte oder externe Mailserver sowie die dafür benötigten Einstellungen für Authentifizierung, Verbindungssicherheit, Absender und Empfänger sind unter Administration > Notification settings eingerichtet. Der vollständige Ablauf steht unter Sophos Firewall E-Mail-Benachrichtigungen einrichten und testen.
• Zeit und Zeitzone stimmen: Falsche Systemzeit erschwert die Auswahl und Kontrolle des Zeitraums. Die Einrichtung erklärt Datum, Uhrzeit und NTP konfigurieren.
• Lokaler Speicher ist verfügbar: On-box-Reportdaten liegen unter /var. Bei erreichtem Stop-Schwellwert setzt die Firewall das Reporting aus. Status, Warnschwellen und Aufbewahrung erklärt Sophos Firewall Speicherplatz prüfen und Reports verwalten.
• Die lokale Aufbewahrung passt zum Zweck: Unter Reports > Show report settings > Data management lässt sich die Aufbewahrung von Reports auf höchstens ein Jahr setzen. Der gewählte Zeitraum zählt vom Vormonat zurück und eine Änderung wird um 00:00 Uhr wirksam. Die Einstellung gilt nur für Reports, nicht für Logs oder bereits versendete PDF-Dateien im Postfach. Ältere Reports löscht die Firewall automatisch. Vor einer Änderung der Aufbewahrungsdauer werden deshalb die Compliance- und Aufbewahrungsanforderungen der Organisation geprüft.
• Empfänger und Zweck sind festgelegt: Ein Funktionspostfach wie firewall-reports@example.net ist meist besser als eine persönliche Adresse. Es braucht einen Owner, der die Reports tatsächlich prüft.

Ein PDF kann Benutzer, IP-Adressen, MAC-Adressen, E-Mail-Adressen, URLs und Sicherheitsereignisse enthalten. Deshalb den Empfängerkreis klein halten, den Mailtransport verschlüsseln und die Aufbewahrung im Postfach berücksichtigen. Wird Data Anonymization für Logs und Reports verwendet, muss am tatsächlich empfangenen PDF geprüft werden, ob die erwarteten Daten anonymisiert sind.

Bei einem speicherbedingten Reporting-Stopp genügt es nicht, /var nur knapp unter 80 Prozent zu bringen. Die Nutzung muss unter die Warnschwelle sinken, standardmässig 70 Prozent; erst dann beginnt die Firewall wieder Reports zu erzeugen. Die Warnschwelle ist von 50 bis 75 Prozent einstellbar, die Stoppgrenze von 80 Prozent dagegen fest. Control Center zeigt Warnung und Alarm, Log Viewer auch das Unterschreiten der Warnschwelle. E-Mail- und SNMP-Meldungen am höheren Schwellwert sind standardmässig ausgeschaltet: Unter System services > Notification list > Disk/Memory wird Reports disk usage exceeded threshold für die benötigten Ziele aktiviert und mit Save gespeichert. Anschliessend Status und neue Reportdaten prüfen; eine gesendete alte PDF-Datei beweist keine wieder laufende Reporterzeugung. Die sichere Ursachenanalyse und Bereinigung bleiben im verlinkten Speicherartikel.

Top Users in PDF-Reports global steuern

Der wenig sprechende Device-Console-Befehl system custom-feature steuert, ob erzeugte PDF-Reports zusätzlich Top Users enthalten. Der Schalter ist systemweit und hat keinen Report- oder Empfängerparameter. Da die aktuelle SFOS-22-Hilfe keinen Default nennt, wird zuerst der Ist-Zustand gelesen:

system custom-feature show

Die angezeigte Einstellung vor jeder Änderung als freigegebenen Ausgangszustand festhalten; sie bestimmt später den Rückweg.

Top Users lassen sich mit enable ergänzen und mit disable wieder aus den erzeugten PDFs entfernen:

system custom-feature enable
system custom-feature disable

Vor enable werden Empfängerkreis, Aufbewahrung und Data Anonymization geprüft. Danach mit Generate now ein reales PDF erzeugen und kontrollieren, ob die erwarteten Benutzer erscheinen und sensible Identitäten wie vorgesehen geschützt sind. Der Schalter erzeugt keine fehlende Benutzerzuordnung und repariert kein Authentication- oder Logging-Problem. Für den Rückbau wird genau der festgehaltene Ausgangszustand wiederhergestellt: system custom-feature enable bei ursprünglich aktivierter Funktion, system custom-feature disable bei ursprünglich deaktivierter Funktion. War die Funktion bereits aktiviert, ist ein erneutes enable keine Änderung; als vermeintlicher Rückbau darf sie nicht deaktiviert werden. Anschliessend mit system custom-feature show den Ausgangszustand bestätigen und mit Generate now ein neues PDF prüfen: Top Users sollen entsprechend dem gespeicherten Zustand enthalten oder nicht enthalten sein. Der Rückbau verspricht weder eine Nachverarbeitung fehlender Daten noch die Wiederherstellung verlorener Reporthistorie.

Reportinhalt vorbereiten

Als Beispiel soll ein wöchentlicher IPS-Report zeigen, welche Angriffe am häufigsten erkannt wurden. Die Namen und Werte werden an die eigene Umgebung angepasst.

1. Reports > Network & threats > Intrusion attacks öffnen.
2. Den gewünschten Datumsbereich wählen.
3. Mit Filter die Auswertung bei Bedarf auf relevante Systeme, Regeln oder Ereignisse begrenzen.
4. Generate auswählen.
5. Prüfen, ob Zeitraum, Treffer und Sortierung zur beabsichtigten Frage passen.

Der fachliche Zweck sollte in einem Satz erklärbar sein, zum Beispiel: „Das Security-Team prüft jeden Montag die häufigsten IPS-Treffer der Vorwoche.“ Diese Aussage hilft bei der Entscheidung, welcher Report, Filter und Empfänger wirklich nötig ist.

Für erzeugte Reports lässt sich optional ein eigenes Logo auswählen (Custom logo), das auf den Reports angezeigt wird.

Die passende Reportgruppe auswählen

Unter Reports wählt man mit Show die Reportgruppe beziehungsweise Auswertung und danach den Datumsbereich. Generate aktualisiert die Daten, Filter grenzt sie ein; Schedule führt zur Zeitplanung direkt aus der Reportansicht. Für die Auswahl hilft die Betriebsfrage, nicht allein der Name des Reports:

• Dashboards: Traffic dashboard zeigt Traffic nach Anwendungen, Webkategorien und Benutzern. Security dashboard zeigt verweigerte Aktivitäten, Malware, Spam sowie häufige Quell- und Zielländer. Executive report bündelt häufig benötigte Traffic- und Bedrohungsinformationen. User threat quotient ordnet Benutzer nach Threat Score ein.
• Network & threats: Intrusion attacks zeigt Angriffsversuche. Active threat response zeigt Threat Events und kompromittierte Hosts auf Basis von MDR- und Sophos-X-Ops-Feeds. Wireless betrifft Access-Point-Nutzung und konfigurierte SSIDs, Security Heartbeat den gemeldeten Endpoint-Zustand und Zero-day protection die Aktivität des erweiterten Schutzes gegen fortgeschrittene und gezielte Angriffe.
• Email: Email usage beantwortet Fragen zum Mailtraffic; Email protection betrifft mit Viren oder Spam belasteten Mailtraffic. Mailzustellung und Schutzereignisse sind unterschiedliche Review-Fragen.
• VPN: VPN betrifft Remote-Access-Traffic, SSL VPN den Traffic von SSL-VPN-Clients und Clientless access browserbasierten Zugriff. Die Reportbeschreibung nennt für VPN auch IPsec, L2TP und PPTP. Diese historisch formulierte Einteilung ist keine Zusage, dass jedes dort genannte Verfahren im eingesetzten Build verfügbar oder sicher einzurichten ist; für einen Report werden keine veralteten Zugriffsverfahren aktiviert.
• Compliance: Die angebotenen Sichten heissen HIPAA, GLBA, SOX, FISMA, PCI, NERC CIP v3 und CIPA; Events zeigt Netzwerkereignisse mit Schweregrad. Diese Reports unterstützen die Auswertung, bestätigen aber allein weder die vollständige Erfüllung einer Vorschrift noch deren Aktualität für die eigene Organisation.
• Applications & web: User app risks & usage, Cloud application usage und Web risks & usage dienen der Nutzungs- und Risikoanalyse. Cloud-Nutzung lässt sich nach Klassifikation, Kategorie, Nutzung, Inhalt, Quellzonen und Zielländern betrachten. Blocked user apps und Blocked web attempts zeigen blockierte Versuche; Web policy overrides zeigt autorisierte Policy-Ausnahmen. Synchronized applications betrifft über Security Heartbeat erkannte Endpoint-Anwendungen, Search engine Suchmuster und Web content Content-Filter-Treffer. Web server usage, Web server protection, User data transfer, FTP usage und FTP protection decken Servertraffic, Webserver-Angriffe und deren Quellen, Benutzertraffic sowie normale beziehungsweise schädliche FTP-Aktivität ab.

Der Application risk meter bildet einen Durchschnittsscore aus Risikostufe und Hits der einzelnen Anwendungen. Rot steht für mehr risikoreiche, Grün für mehr risikoarme Anwendungskommunikation. Der Durchschnitt ist eine Orientierung, kein Nachweis einer konkreten Kompromittierung; für die Bewertung werden die einzelnen Anwendungen, deren Risikostufe und Hits geöffnet. Bei Web content ist eine Datenschutzgrenze wichtig: Als highly objectionable criminal activity kategorisierte Seiten werden immer blockiert, und der Domainname wird in Logs und Reports verborgen. Ein fehlender Domainname ist dort daher nicht automatisch ein Exportfehler und wird nicht durch das Abschalten von Schutzfunktionen untersucht.

Bei Web policy overrides werden die zum Überschreiben berechtigten Benutzer sowie die betroffenen blockierten Websites und Webkategorien betrachtet. Web server usage umfasst laut Reportbeschreibung Anwendungs-, Web-, Internet- und FTP-Traffic; die Auswahl ist daher nicht auf Webserver-Angriffe begrenzt. Dafür ist Web server protection zuständig.

Custom Report, Custom View und Bookmark unterscheiden

Ein Custom Report unter Reports > Custom grenzt einen einzelnen Datenbereich mit detaillierten Kriterien ein. Verfügbar sind Web-, Mail-, FTP-, User- und Webserver-Auswertungen. Wichtig ist die Grenze bei Web-Reports: Die benutzerdefinierte Suche zeigt nur erlaubte Domains, URLs, Kategorien und IP-Adressen. Blockierte Webzugriffe werden stattdessen unter Reports > Applications & web > Blocked web attempts geprüft.

Für die Kriterienwahl gilt: Ein Web-Report sucht Surfaktivität oder Viren etwa nach Benutzer und Domain; ein Mail-Report Mailnutzung, Spam und Viren etwa nach Protokoll und Benutzer. Ein FTP-Report kann nach Transfertyp, Benutzer, Datei oder Quell-IP suchen. Ein User-Report ordnet risikoreiche Anwendungen, unproduktive Webdomains und erkannte Viren einem Benutzernamen oder Quellhost zu. Ein Webserver-Report untersucht Zeitpunkt, Benutzer, URI und Schutzaktivität. Diese Kriterien werden passend zur Frage gewählt und nicht als Garantie verstanden, dass ohne entsprechendes Logging bereits Daten vorliegen.

Eine Custom View kombiniert mehrere Reportgruppen in einer gemeinsamen Sicht, etwa Zero-day-Protection-Aktivität und Webbenutzer. Sie wird unter Reports > Show report settings > Custom view > Add mit einem Namen und den benötigten Reportgruppen angelegt und erscheint danach unter Reports > Custom. Mit Save speichern, dann die neue Sicht zuerst manuell erzeugen und prüfen, bevor sie geplant oder weitergegeben wird.

Ein Bookmark speichert dagegen eine bereits gefilterte, wiederkehrende Auswahl. Beim Zeitplan kann eine Standard- oder benutzerdefinierte Reportgruppe oder ein Bookmark gewählt werden. Für den Admin ist nicht der technisch grösste Report der beste, sondern die kleinste Auswahl, die die konkrete Betriebsfrage beantwortet.

Wiederkehrende Auswahl als Bookmark speichern

Ein Bookmark ist sinnvoll, wenn nicht nur eine ganze Reportgruppe, sondern eine wiederverwendbare Auswahl mit Filter geplant werden soll.

1. Den fertig vorbereiteten Report öffnen.
2. Bookmark auswählen.
3. Einen verständlichen Namen wie Weekly-IPS-Review eintragen.
4. Eine passende Bookmark-Gruppe auswählen und mit Save speichern.

Fehlt eine geeignete Gruppe, wird sie unter Reports > Show report settings > Bookmark management > Add bookmark group angelegt. Ein Name wie Weekly-IPS-Review beschreibt Zweck und Rhythmus besser als Report1.

Nach dem Speichern den Bookmark erneut öffnen und den Report nochmals erzeugen. Damit wird geprüft, ob tatsächlich die beabsichtigte Auswahl wiederverwendet wird. Die genaue Zuordnung des späteren PDF-Zeitraums sollte nicht nur aus dem Namen abgeleitet, sondern im erzeugten PDF kontrolliert werden.

Wenn noch keine eigene Bookmark-Gruppe existiert, lässt sich der Bookmark der Default-Gruppe zuordnen. Für eine neue Gruppe einen Namen eingeben und mit Save speichern; die Gruppe organisiert zusammengehörige Bookmarks, etwa für Anwendungen und Bedrohungen. Zum erneuten Öffnen unter Show die Gruppe und danach den einzelnen Bookmark wählen. Eine Gruppe erscheint in dieser Auswahl erst, wenn sie mindestens einen Bookmark enthält. Fehlt sie, daher zuerst ihren Inhalt prüfen statt den Zeitplan mehrfach anzulegen.

Einen Vergleichsexport herunterladen

Für einen unabhängig vom Mailweg prüfbaren Vergleich werden Reports in WebAdmin heruntergeladen, nicht über die CLI:

1. Reports > Applications & web öffnen.
2. Unter Show die Reportkriterien und danach den Datumsbereich wählen.
3. Mit Generate die Daten erzeugen und prüfen.
4. Eines der angebotenen Dateiformate auswählen und die heruntergeladene Datei öffnen.

Unter Reports > Show report settings > Data management heisst das Aufbewahrungsfeld Log retention report period, obwohl es nur Reports betrifft. Export customization steuert dagegen die Reportauswahl und Datensatzanzahl pro Report beim Export. Den Umfang vor dem Download passend zum Review wählen und in der Datei kontrollieren. Die Exportanpassung ist weder eine Änderung der Aufbewahrung noch eine dokumentierte Aufhebung der 50-Datensatz-Grenze geplanter E-Mail-Reports. Die vollständige Speicher- und Exportverwaltung ist im bereits verlinkten Speicherartikel beschrieben.

Zeitplan erstellen

1. Reports > Show report settings > Report scheduling öffnen.
2. Add auswählen.
3. Als Typ Report wählen.
4. Unter To email address die Empfänger eintragen. Mehrere Adressen werden kommagetrennt angegeben.
5. Unter Report type eine Reportgruppe oder den vorbereiteten Bookmark auswählen.
6. Falls angeboten, die Sortierung nach Hits oder Bytes passend zum Zweck festlegen.
7. Unter Email frequency Daily oder Weekly wählen.
8. Mit Save speichern.

Das zugehörige Sortierfeld heisst Sorting criteria; Hits priorisiert häufige Treffer, Bytes das Datenvolumen. Die Option gilt nur für Reports, die diese Sortierung anbieten.

Für das Beispiel werden diese Werte verwendet:

• Empfänger: firewall-reports@example.net
• Report type: Bookmark Weekly-IPS-Review
• Sortierung: Hits
• Häufigkeit: Weekly

Die Werte sind kein allgemeiner Standard. Ein Bandbreitenreport kann nach Bytes sinnvoller sein, ein täglicher Betriebsreport benötigt Daily, und ein anderer Standort braucht einen eigenen Empfänger oder Bookmark.

Geplante On-box-Reports werden als PDF versendet und enthalten maximal 50 Datensätze. Diese Grenze gilt für den E-Mail-Report; sie sollte nicht als vollständiges Archiv oder Export aller lokalen Daten verstanden werden. Für mehrere Firewalls, konsolidierte HA-Daten oder längere zentrale Auswertungen ist Sophos Central Firewall Reporting in Sophos Fusion die passendere Ebene.

Seit SFOS 21.5 MR1 verwendet ein geplanter PDF-Report die WebAdmin-Sprache des Administrators, der den Zeitplan angelegt hat. Soll der Empfänger den Report auf Deutsch erhalten, wird der Zeitplan daher mit einer deutschen WebAdmin-Sitzung erstellt und das Ergebnis mit Generate now kontrolliert.

Neben normalen Reports bietet die Zeitplanung auch Security audit report und bei eingerichteter Integration ConnectWise. Der Security Audit Report ist insbesondere für eine passive Discover-Mode-Analyse mit TAP und SPAN vorgesehen. Diese Typen erfüllen andere Zwecke und sollten nicht gewählt werden, nur weil ein normaler Report leer bleibt.

Security-Audit- und ConnectWise-Zeitpläne gezielt konfigurieren

Ein Security audit report ist ein vordefinierter Report zu sicherheitsrelevanten Aktivitäten. Sein Zeitplan enthält diese Felder: Organization name für den im Report angezeigten Organisationsnamen, To email address für kommagetrennte Empfänger, Report type für Daten einer Reportgruppe oder eines Bookmarks und Email frequency für den Versand Daily oder Weekly.

Ein ConnectWise schedule steht erst nach der Integration von ConnectWise mit Sophos Firewall zur Verfügung. Unter Reports > Show report settings > ConnectWise muss ConnectWise aktiviert sein; Server-URL und Benutzerzugangsdaten müssen zur eigenen Integration passen. Zugangsdaten werden nicht in PDF-Beispielen oder Supportbelegen offengelegt. Seine exakten Zeitplanfelder werden so konfiguriert:

• Report: Einen der vorkonfigurierten ConnectWise-Reports Top sites, Filtered sites, Bandwidth usage oder Top attacks wählen.
• Number of records: Festlegen, wie viele Datensätze der Report erzeugt. Die Anzahl wird passend zum Review-Zweck gewählt; die allgemeine Obergrenze von 50 Datensätzen für E-Mail-Reports ist nicht automatisch der gewünschte ConnectWise-Wert.
• Frequency: Den Report täglich im angegebenen Intervall planen.

Nach dem Speichern eines spezialisierten Zeitplans wird Generate now ausgeführt und der zugestellte Report geprüft. Eine aktive Integration oder ein sichtbarer Zeitplan beweist allein noch nicht, dass der vordefinierte Report die erwarteten Datensätze enthält.

Versand und PDF kontrollieren

Nach dem Speichern wird nicht bis zum ersten regulären Termin gewartet.

1. Mailtransport mit Send test mail prüfen

In der Liste den Zeitplan auswählen, Send test mail ausführen, eine Testadresse eintragen und Send wählen. Diese Adresse wird für den Test separat eingegeben; sie muss nicht mit To email address des Zeitplans übereinstimmen. Für einen aussagekräftigen ersten Test wird dasselbe Funktionspostfach verwendet. Danach im Zielpostfach, Spamfilter oder Mailserver-Tracking prüfen, ob die Nachricht angenommen und zugestellt wurde.

Eine erfolgreiche Testmail bestätigt die konfigurierte Mailserver-Verbindung und die grundsätzliche Zustellung. Sie bestätigt noch nicht, dass der gewählte Report Daten enthält oder als korrektes PDF erzeugt wird.

2. Gesamtpfad mit Generate now prüfen

Danach Generate now ausführen. Die Firewall erzeugt den geplanten Report unmittelbar und versendet ihn an die eingetragenen Empfänger.

Am empfangenen PDF werden geprüft:

• richtige Firewall beziehungsweise richtiger Standort;
• beabsichtigte Reportgruppe oder Bookmark-Auswahl;
• plausibler Zeitraum und Zeitstempel;
• sinnvolle Sortierung und Datenmenge;
• erwartete Sprache;
• lesbare Darstellung von Tabellen und Diagrammen;
• falls ein eigenes Logo ausgewählt wurde: vor der Weitergabe am neu erzeugten Report visuell prüfen, ob das erwartete Logo angezeigt wird;
• keine unnötig offengelegten Benutzer-, Netzwerk- oder Sicherheitsdaten.

⚠️ Beim Upgrade von SFOS 20.0 oder früher auf SFOS 21.0 oder später liegen Reports vor und nach dem Upgrade in getrennten Datenbanken. Wird nur der Migrationstag ausgewählt, müssen Data before migration und Data after migration einzeln gewählt werden, um den ganzen Tag auszuwerten. Ein Datumsbereich, der den Migrationstag umfasst, muss dagegen in Bereiche vor und nach diesem Tag aufgeteilt werden. Bei einem Rollback auf die frühere Version gehen alle seit dem Upgrade erzeugten Reports verloren, auch nach einem erneuten Upgrade. Bei der Kontrolle geplanter PDFs diese Datenbankgrenze berücksichtigen: Erfolgreicher Mailversand allein belegt keine lückenlose Auswertung über die Migration hinweg.

Nach einer Unterbrechung die Datumszuordnung prüfen: Beim Herunterfahren können Daten unverarbeitet bleiben. Nach dem Neustart können die darin enthaltenen Ereignisse dem Tag vor dem Neustart statt ihrem tatsächlichen Ereignistag zugeordnet werden, sogar einem Tag, an dem die Firewall ausgeschaltet war. Das betrifft verbliebene unverarbeitete Daten, nicht pauschal alle Ereignisse. Deshalb nach einer Unterbrechung mit Generate now ein neues PDF erzeugen und Zeitraum sowie Ereignisdatierung besonders prüfen.

Für möglichst konsistente Reportdaten empfiehlt sich ein kontinuierlicher Betrieb der Firewall; ein Neustart ist keine Korrekturmassnahme für abweichende Ereignisdatierungen.

Erst danach wird der nächste reguläre Lauf beobachtet. Die aktuelle Hilfe beschreibt die genaue Bindung von Ausführungszeit, Zeitzone und Reportzeitraum nicht detailliert genug, um sie pauschal vorauszusetzen. Der erzeugte Report ist deshalb der Funktionsnachweis.

Betrieb in einem HA-Cluster

Lokale Reportdaten werden zwischen den HA-Nodes nicht synchronisiert. Jeder Node enthält nur Reports zu dem Traffic, den er verarbeitet. Die Hilfe zu Report scheduling vom 19. Dezember 2025 beschreibt den Versand von beiden Appliances, sobald der Report einer Appliance mindestens eine Datenzeile in einer Tabelle enthält; ohne Datenzeile beschreibt sie keinen Versand. Die HA-Übersicht vom 13. August 2025 beschreibt dagegen einen datenabhängigen Versand der Auxiliary Appliance und nennt Security Dashboard und Security Audit als Beispiele ohne Versand. Diese Beschreibungen sind nicht vollständig deckungsgleich; die Zeitplanhilfe ist die neuere und für diesen Ablauf spezifischere Dokumentation, aber keine Garantie für jedes Report-/Build-Szenario. Deshalb können zwei E-Mails eintreffen. Mit Generate now das Verhalten des gewählten Reports auf dem eingesetzten Build prüfen und Absender, Appliance, Zeitraum sowie Inhalt vergleichen, bevor ein vermeintlich doppelter Zeitplan gelöscht wird. Aus einer fehlenden zweiten E-Mail allein lässt sich weder ein Fehler noch ein Defekt der HA-Funktion ableiten.

Auch eine ansonsten inaktive Appliance kann einen Executive report mit Systemnutzung und Reportdaten erzeugen. Deshalb ist „kein Nutzertraffic“ nicht gleichbedeutend mit „keine Datenzeile“ und verhindert den Versand von beiden Appliances nicht zwingend.

Diese Zustellung ist nicht automatisch ein Fehler. Zuerst Absender, Appliance-Identität, Zeitraum und Inhalt beider PDFs vergleichen. Für eine konsolidierte Sicht über beide Nodes eignet sich Central Reporting besser als zwei lokale E-Mail-Reports.

Nach einem HA-Failover, Appliance-Tausch oder Firmwareupdate wird Generate now erneut geprüft. So fällt auf, wenn ein Zeitplan zwar noch sichtbar ist, aber Daten, Sprache oder Mailzustellung nicht mehr der Erwartung entsprechen.

Fehler systematisch eingrenzen

Send test mail schlägt fehl

Dann liegt das Problem im Mailweg und noch nicht im Reportinhalt. Unter Administration > Notification settings werden DNS, Route, Port, Authentifizierung, OAuth, TLS, Zertifikat, Absender und Empfänger geprüft. Mailserver-Tracking oder Quarantäne zeigen, ob die Nachricht angenommen oder abgewiesen wurde.

Den Zeitplan nicht mehrfach neu anlegen. Zuerst muss eine Testmail zuverlässig ankommen. Die Fehlerbilder und sicheren Prüfungen stehen im Artikel zu E-Mail-Benachrichtigungen.

Testmail kommt an, aber Generate now liefert keinen Report

Jetzt ist der SMTP-Weg grundsätzlich bestätigt. Danach werden geprüft:

1. Ist die richtige Reportgruppe oder der richtige Bookmark im Zeitplan ausgewählt?
2. Enthält derselbe Report bei manueller Ausführung Daten?
3. Ist On-box Reporting aktiv und wird vom Appliance-Modell unterstützt?
4. Liegt /var unter dem Stop-Schwellwert für Reports und nach einem speicherbedingten Stopp wieder unter der Warnschwelle?
5. Sind Logging und benötigte Schutzfunktionen für die erwarteten Daten aktiv?
6. Taucht die Nachricht in Mailserver-Tracking, Spam oder Quarantäne auf?

In der Device Console liefern zwei lesende Befehle den aktuellen On-box-Status und die Report-Speicherschwellen:

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

Die Befehle ändern nichts. Weitere Speicherdiagnose und die Bedeutung der Ausgabe stehen unter Speicherplatz und Reports verwalten.

PDF ist leer, unvollständig oder falsch dargestellt

Zuerst denselben Report manuell mit identischem Zeitraum und Filter erzeugen. Ist schon die WebAdmin-Auswertung leer, fehlen Reportdaten, Logging oder passende Ereignisse. Enthält nur das PDF falsche oder unvollständige Daten, werden SFOS-Version, Build, Browser, Zeitplan, Generate now-Zeitpunkt und ein Beispiel-PDF dokumentiert.

SFOS 22.0 MR2 Build 546 behebt unter anderem bekannte Fehler mit einem leeren täglichen Traffic-Dashboard-PDF ohne On-box Reporting und falsch dargestellten Tabellen oder Diagrammen in On-demand-PDFs, die in Chrome erzeugt wurden. Ein ähnliches Symptom auf einem anderen Build ist nicht automatisch derselbe Fehler. Vor Änderungen wird deshalb der exakte Build geprüft und mit einem manuell erzeugten Report verglichen.

Für eine tiefere Analyse werden der Testzeitpunkt und die Dateien cschelper.log, reportdb.log, garner.log sowie bei Bedarf postgres.log korreliert. Der Zugriff ist unter Sophos Firewall Troubleshooting: Services und Logs beschrieben. Ein einzelner Logeintrag ist kein ausreichender Grund, Reporting-Dienste neu zu starten oder Reportdaten zu löschen.

Executive Report mit 1 month lässt sich nicht als PDF laden

Für SFOS 22.0 MR1 Build 490 dokumentierte Sophos unter NC-182976 ein eng begrenztes Fehlerbild: Unter Reports > Dashboards > Executive report konnte der PDF-Download fehlschlagen, wenn der Zeitraum 1 month gewählt war. Zuerst werden deshalb der genaue Firmware-Build, der Reporttyp, der Zeitraum und das Ausgabeformat kontrolliert. Andere PDF-Reports oder geplante E-Mail-Reports sind damit nicht automatisch betroffen.

Im damaligen Beschreibungstext nannte Sophos einen CSV-Download mit einem eintägigen Zeitraum; die separate KIL-Spalte Workaround lautete jedoch None. Deshalb ist dieser Export nur eine begrenzte Ausweichprüfung. Er ersetzt keinen vollständigen Monatsreport und bestätigt weder den Monatsreport noch den PDF-Erzeugungspfad. Scheitern auch andere Reports, Zeiträume oder Formate, ist das Fehlerbild breiter als NC-182976; dann werden Zeitpunkt und Browser dokumentiert und die oben genannten Logs gesichert, statt Reporting-Dienste neu zu starten oder Reportdaten zu löschen.

Der früher dokumentierte Eintrag zu NC-182976 nannte SFOS 23.0 EAP0 Build 275 im Feld Fix versions und beschrieb die Korrekturen für SFOS 23 und SFOS 22.0 MR3 als bevorstehend. Diese historischen Felder belegen weder den aktuellen Release- noch den Fehlerstatus. Vor einem Upgrade werden die aktuelle Known Issues List und die Release Notes der freigegebenen Zielversion sowie deren Unterstützung für das eigene Modell geprüft. Fehlt der Eintrag in der aktuellen Known Issues List, ist das kein Nachweis, dass der Fehler behoben ist. Tritt dasselbe Symptom auf MR2 oder einem anderen Build auf, wird es nicht automatisch NC-182976 zugeordnet, sondern mit den gesicherten Daten geprüft.

E-Mail enthält nur 50 Einträge

Das ist bei geplanten E-Mail-Reports die dokumentierte Obergrenze. Filter und Reportzweck werden so gewählt, dass die wichtigsten 50 Datensätze die konkrete Betriebsfrage beantworten. Wenn vollständige Rohdaten, längere Historie oder Auswertungen über mehrere Firewalls benötigt werden, ist ein zentraler Reporting- oder SIEM-Workflow geeigneter.

Derselbe Report kommt zweimal

Bei einem HA-Cluster können zwei E-Mails zu erwarten sein; die offiziellen Beschreibungen des datenabhängigen Versands der Auxiliary Appliance unterscheiden sich, wie im Abschnitt zum HA-Betrieb erläutert. Den gewählten Report auf dem eingesetzten Build mit Generate now prüfen und Absender, Appliance, Zeitraum sowie Inhalt vergleichen, bevor ein vermeintlich doppelter Zeitplan gelöscht wird. Eine fehlende zweite E-Mail allein belegt keinen HA-Fehler. Bei einer einzelnen Firewall wird dagegen geprüft, ob zwei Zeitpläne dieselbe Reportauswahl und denselben Empfänger verwenden.