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.

Voraussetzungen prüfen

Vor dem Zeitplan werden fünf 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: Mailserver, Authentifizierung, TLS, 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.
• 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.

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.

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 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.

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. Speichern.

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 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.

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 und Send test mail ausführen. Danach im Zielpostfach, Spamfilter oder Mailserver-Tracking prüfen, ob die Nachricht angenommen und zugestellt wurde.

Eine erfolgreiche Testmail bestätigt SMTP, Authentifizierung und 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;
• keine unnötig offengelegten Benutzer-, Netzwerk- oder Sicherheitsdaten.

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. Beide Nodes verarbeiten die Daten des Traffics, der über sie läuft. Enthält der Report eines Nodes Daten, kann dieser Node die geplante Nachricht versenden. Dadurch können bei einem HA-Cluster zwei E-Mails zum selben Zeitplan eintreffen.

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?
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 dokumentiert Sophos unter NC-182976 ein eng begrenztes Fehlerbild: Unter Reports > Dashboards > Executive report kann der PDF-Download fehlschlagen, wenn der Zeitraum 1 month gewählt ist. 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 Beschreibungstext nennt Sophos einen CSV-Download mit einem eintägigen Zeitraum; die separate KIL-Spalte Workaround lautet jedoch weiterhin 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.

Die aktuelle Known Issues List führt nur SFOS 23.0 EAP0 Build 253 im Feld Fix versions und kündigt im Beschreibungstext zusätzlich eine Korrektur für SFOS 22.0 MR3 an. Stand 10. August 2026 ist MR3 noch nicht veröffentlicht und deshalb keine verfügbare Lösung. 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 beide Nodes eine Nachricht versenden, wenn ihr lokaler Report Daten enthält. Absender, Appliance und Inhalt vergleichen, bevor ein vermeintlich doppelter Zeitplan gelöscht wird. Bei einer einzelnen Firewall wird dagegen geprüft, ob zwei Zeitpläne dieselbe Reportauswahl und denselben Empfänger verwenden.