Zum Inhalt springen
Avanet

Sophos Firewall E-Mail-Benachrichtigungen einrichten und testen

Sophos Firewall

Für funktionierende E-Mail-Benachrichtigungen braucht die Sophos Firewall zwei getrennte Konfigurationen: Unter Administration > Notification settings wird der Mailtransport eingerichtet. Unter System services > Notification list wird festgelegt, welche Ereignisse tatsächlich per E-Mail gemeldet werden.

Der Mailtransport wird auch vom Quarantäne-Digest für Benutzer verwendet; dessen Zeitplan, Portal-Link und Benutzerzuweisung sind jedoch separate Einstellungen.

Die sichtbaren Authentication-, SMTP-, Admin- und SMS-Texte unter Administration > Messages sind eine dritte, davon getrennte Ebene. Sophos Firewall Login-Disclaimer und Messages konfigurieren erklärt deren Inhalt und Tests; eine geänderte Message richtet weder SMTP-Transport noch Ereignisauswahl ein.

Der schnelle Weg:

  1. Mailserver, Port, Authentifizierung, Verschlüsselung, Absender und Empfänger unter Administration > Notification settings konfigurieren.
  2. Eine Testmail senden und die Zustellung im Zielpostfach oder Mailserver-Tracking bestätigen.
  3. Unter System services > Notification list den globalen Schalter Email notifications aktivieren.
  4. Nur die Ereignisse auswählen, für die ein verantwortlicher Empfänger reagieren kann.
  5. Zusätzlich zur Testmail ein echtes ausgewähltes Ereignis kontrolliert auslösen und dessen Zustellung prüfen.

Eine erfolgreiche Testmail beweist nur, dass der SMTP-Weg grundsätzlich funktioniert. Sie beweist noch nicht, dass der globale E-Mail-Schalter und die richtigen Ereignisse aktiviert sind. Umgekehrt versendet eine ausgewählte Ereigniszeile keine Nachricht, solange der Mailtransport nicht funktioniert. Genau diese Trennung erklärt auch, warum ein konfigurierter SMTP-Server allein den Punkt Notification Emails im Sophos Firewall Health Check betrieblich noch nicht erfüllt.

Empfängeradresse über die Device Console ändern

Ist der WebAdmin nicht verfügbar oder soll die Empfängeradresse über einen kontrollierten Console-Zugang korrigiert werden, steht dafür 2. System Configuration > 3. Set Email ID for system notification zur Verfügung. Diese Option ändert nur die Administrator-E-Mail-Adresse für System-Alerts. Sie konfiguriert weder Mailserver, Absender, Authentifizierung und TLS noch den globalen Schalter und die Ereignisse in der Notification list.

Die bisherige Adresse zuerst dokumentieren. Danach die Änderung mit y bestätigen, die neue Adresse eingeben und die von SFOS angezeigte Adresse auf Tippfehler prüfen. Mit Enter geht es zurück ins Menü. Anschliessend müssen eine Testmail und ein kontrolliertes echtes Ereignis den neuen Empfänger erreichen; die Konsolenausgabe allein beweist keine Zustellung.

Mailversand vorbereiten

Vor der Konfiguration werden Mailserver, Port und Authentifizierungsverfahren beim zuständigen Mailadministrator geklärt. Wird ein FQDN wie smtp.example.net verwendet, muss die Firewall diesen auflösen und den Server über den vorgesehenen Routingpfad erreichen können. Eine allgemeine Internetverbindung ist nur nötig, wenn der gewählte Mailserver oder OAuth-Provider im Internet liegt. Ein internes SMTP-Relay kann auch ohne direkten Internetzugang der Firewall funktionieren.

Ein realistisches Beispiel:

  • Mailserver: smtp.example.net
  • Port: 587
  • Authentication: Basic
  • Connection security: STARTTLS
  • Sender: fw-zrh-01@example.net
  • Recipient: firewall-alerts@example.net
  • Management interface IP address: internes Management-Interface der Firewall

Alle Werte mit example.net werden durch die eigene Domain und die vom Mailadministrator freigegebenen Adressen ersetzt. Eine Verteileradresse ist meist besser als ein persönliches Postfach: Verantwortlichkeiten lassen sich ändern, ohne jede Firewall neu zu konfigurieren.

Die Management interface IP address steuert nicht, über welches Interface die SMTP-Verbindung die Firewall verlässt. Die ausgewählte IP-Adresse wird in die Benachrichtigung aufgenommen und hilft, die sendende Firewall zu identifizieren. Bei mehreren Standorten sollte deshalb eine dauerhaft verständliche Management-IP gewählt werden; bei nur einer Firewall kann auch None genügen.

Mailserver konfigurieren

Built-in oder External email server wählen

Sophos Firewall kann den Built-in email server oder einen External email server verwenden. Der integrierte Versand ist für einen einfachen Start praktisch. In produktiven Umgebungen ist ein eigener Relay- oder Cloud-Mailserver häufig besser nachvollziehbar, weil Authentifizierung, Mail-Tracking, Absenderfreigaben und Zustellfehler an einer zentralen Stelle sichtbar sind.

Wir empfehlen deshalb den External email server, wenn bereits ein verlässlich betriebener SMTP-Dienst vorhanden ist.

Für den integrierten Versand genügt dieser kurze Zweig:

  1. Unter Administration > Notification settings den Built-in email server aktivieren.
  2. Absender, Empfänger und optional Management interface IP address eintragen.
  3. Speichern und die Testmail senden.

Beim Built-in email server gibt es kein eigenes Relay-Tracking, an dem der Admin Annahme und Weiterleitung nachvollziehen kann. Deshalb die tatsächliche Zustellung besonders sorgfältig prüfen. Scheitert sie wiederholt oder verlangen Empfängerdomain und Sicherheitsvorgaben einen kontrollierten SMTP-Pfad, ist ein External email server die besser betreibbare Variante.

External email server einrichten

  1. Administration > Notification settings öffnen.
  2. External email server auswählen.
  3. IPv4-Adresse oder FQDN des Mailservers und den vorgegebenen Port eintragen.
  4. Unter Authentication None, Basic oder OAuth 2.0 passend zum Server wählen.
  5. Unter Connection security die vom Mailserver geforderte Transportverschlüsselung einstellen.
  6. Absender, Empfänger und optional Management interface IP address eintragen.
  7. Speichern und die Testmail-Funktion ausführen.

Der Standardport in SFOS ist 25, er ist aber keine Empfehlung für jede Umgebung. Entscheidend ist der Listener des eigenen Relays. Typisch sind 25 für ein internes, nach Quell-IP freigegebenes Relay, 587 für authentifizierte Übermittlung mit STARTTLS oder 465 für direktes SSL/TLS. Port, Authentifizierung und Verschlüsselungsmodus müssen als Kombination zum Mailserver passen.

None bedeutet in den beiden Auswahlfeldern nicht dasselbe: Unter Authentication deaktiviert es die Anmeldung am Mailserver. Das kann bei einem internen Relay korrekt sein, das ausschliesslich die Quell-IP der Firewall freigibt. Unter Connection security bedeutet None dagegen unverschlüsselte SMTP-Übertragung. Diese Einstellung ist für Internetpfade ungeeignet und sollte auch intern nur verwendet werden, wenn das Sicherheitsmodell dies ausdrücklich erlaubt.

Bei Basic verwendet die Firewall Benutzername und Passwort. Der Benutzername ist laut Sophos case-sensitive. Das Relay muss das verwendete Anmeldeverfahren unterstützen; eine Fehlermeldung zur Authentication method weist insbesondere auf einen Unterschied bei LOGIN oder PLAIN hin.

STARTTLS wird leicht missverstanden: Die Firewall folgt der Fähigkeit des Mailservers. Bietet der Server STARTTLS an, wird die Verbindung verschlüsselt; bietet er es nicht an, kann die Nachricht unverschlüsselt übertragen werden. Wer Verschlüsselung erzwingen muss, verwendet SSL/TLS mit dem dazu passenden Port und Server-Listener.

⚠️ Allow invalid certificate unter Email > General settings sollte nicht als schneller Workaround aktiviert werden. Ein abgelaufenes, nicht vertrauenswürdiges oder zum Servernamen unpassendes Zertifikat wird besser am Mailserver beziehungsweise an der Vertrauenskette korrigiert.

Wenn die Firewall Mail Protection im MTA Mode verwendet, hängt das für den E-Mail-Versand verwendete Zertifikat zusätzlich von der Konfiguration unter Email > General settings ab. Eine Änderung sollte deshalb nicht isoliert vorgenommen werden, ohne den produktiven Mailflow zu berücksichtigen.

Gmail und Microsoft 365 mit OAuth 2.0

Für Gmail und Microsoft 365 verlangt die aktuelle SFOS-22-Hilfe OAuth 2.0. In Notification settings werden dafür Provider, Client ID, Client secret und Refresh token hinterlegt. Die allgemeine Sophos-Hilfe bezeichnet das Client secret für Microsoft 365 zwar als optional; der von Sophos dokumentierte Microsoft-365-Ablauf erstellt und verwendet jedoch ausdrücklich eines. Für diesen Ablauf wird es deshalb mitkonfiguriert.

Bei Gmail müssen in Google Cloud ein Projekt und die Gmail API eingerichtet sowie OAuth-Client und Refresh Token erzeugt werden. Der folgende Ablauf entspricht der aktuellen Sophos-Anleitung Configure OAuth 2.0 on Gmail.

Gmail OAuth 2.0 Schritt für Schritt einrichten

  1. In der Google Cloud Console mit dem vorgesehenen Google-Konto anmelden, ein neues Projekt erstellen und dieses auswählen.
  2. APIs & Services > Library öffnen, nach Gmail API suchen und die API aktivieren.
  3. Unter APIs & Services > Credentials auf Create credentials > OAuth client ID klicken.
  4. Falls zuerst der Consent Screen verlangt wird, Configure the OAuth consent screen > Get started öffnen. App-Name und E-Mail-Adresse eintragen, User type: External wählen, die Entwickler-Kontaktadresse ergänzen und die Konfiguration erstellen.
  5. Create OAuth client wählen, Application type: Web application setzen und einen eindeutigen Namen vergeben.
  6. Unter Authorized redirect URIs exakt https://developers.google.com/oauthplayground hinzufügen.
  7. Den OAuth-Client erstellen und Client ID sowie Client secret sofort sicher dokumentieren.
  8. Unter Audience > Add users das Google-Konto hinzufügen, das später die Benachrichtigungen sendet.
  9. Den Google OAuth 2.0 Playground öffnen. Über das Zahnradsymbol Use your own OAuth credentials aktivieren und Client ID sowie Client secret einfügen.
  10. Unter Step 1 Select & authorize APIs die Gmail API v1 aufklappen, den Scope https://mail.google.com auswählen und Authorize APIs starten. Dabei das vorgesehene Sendekonto verwenden.
  11. Unter Step 2 Exchange authorization code for tokens den Code gegen Tokens tauschen und den Refresh token sicher kopieren.
  12. Auf der Firewall unter Administration > Notification settings den External email server mit Authentication: OAuth 2.0 und Provider: Gmail konfigurieren. Client ID, Client secret und Refresh token einfügen, speichern und eine Testmail senden.

Google behandelt ein OAuth-Projekt mit User type External und Publishing status Testing nicht als dauerhafte Produktionskonfiguration: Bei Verwendung des Gmail-Scopes läuft der Refresh Token laut Google OAuth 2.0 nach sieben Tagen ab. Der von Sophos verwendete Gmail-Scope https://mail.google.com erlaubt ausser dem Senden auch das Lesen, Erstellen und dauerhafte Löschen von E-Mails. OAuth-App, Zugangsdaten und ein möglichst dediziertes Sendekonto müssen deshalb genauso geschützt und betrieben werden wie ein Mailserver-Kennwort.

Bei Microsoft 365 braucht die App die delegierten Berechtigungen SMTP.Send und offline_access; für das sendende Konto muss Authenticated SMTP aktiviert sein. Der dokumentierte Standardweg verwendet smtp.office365.com, Port 587 und STARTTLS. Weicht die Absenderadresse vom angemeldeten Postfach ab, benötigt das Konto zusätzlich Send As. Die aktuellen Entra-Schritte stehen unter Configure OAuth 2.0 on Microsoft 365.

Microsoft 365 OAuth 2.0 Schritt für Schritt einrichten

  1. Im Microsoft Entra admin center unter Identity > Applications > App registrations eine New registration erstellen.
  2. Einen eindeutigen Namen vergeben. Für den von Sophos dokumentierten Ablauf Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) auswählen und unter Redirect URI die Plattform Web mit https://outlook.office365.com/ eintragen. Diese URI muss später exakt wiederverwendet werden.
  3. Die App registrieren und die Application (client) ID sicher dokumentieren.
  4. Unter API permissions > Add a permission > Microsoft Graph > Delegated permissions die Berechtigungen SMTP.Send und offline_access hinzufügen. Danach Grant admin consent ausführen.
  5. Für das Sendekonto unter Users > Active users > Mail > Email apps > Manage email apps die Option Authenticated SMTP aktivieren.
  6. Unter Certificates & secrets > Client secrets > New client secret ein Secret mit einem überwachten Ablaufdatum erstellen. Den angezeigten Value sofort sicher kopieren; nach dem Neuladen zeigt Entra ihn nicht mehr an.
  7. Im Browser die folgende URL öffnen. YOUR_CLIENT_ID durch die Application ID ersetzen; die redirect_uri muss mit der App-Registrierung übereinstimmen.
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=https://outlook.office365.com/&response_mode=query&scope=https://outlook.office365.com/.default+offline_access&state=12345
  1. Mit dem vorgesehenen Sendekonto anmelden und den kurzlebigen Authorization Code aus der weitergeleiteten URL kopieren.
  2. Den Code mit einem API-Client als application/x-www-form-urlencoded an den Token-Endpunkt senden. Alle Platzhalter werden durch die Werte dieser App ersetzt.
POST https://login.microsoftonline.com/common/oauth2/v2.0/token

client_id=YOUR_CLIENT_ID
&scope=https://outlook.office365.com/.default offline_access
&code=YOUR_AUTHORIZATION_CODE
&redirect_uri=https://outlook.office365.com/
&grant_type=authorization_code
&client_secret=YOUR_CLIENT_SECRET
  1. Den zurückgegebenen Refresh token sofort sicher speichern. Authorization Code, Client secret, Access token und Refresh token gehören weder in Tickets noch in ungeschützte Screenshots oder Logs.
  2. Auf der Firewall unter Administration > Notification settings den External email server mit Authentication: OAuth 2.0 und Provider: Microsoft 365 konfigurieren. smtp.office365.com, Port 587, STARTTLS, Client ID, Client secret und Refresh token eintragen, speichern und eine Testmail senden.

Sophos verlangt für die Token-Erzeugung, dass das System mit dem API-Client und die Firewall in derselben Zeitzone arbeiten. Systemzeit und Zeitzone deshalb vor dem Ablauf prüfen. Eine Änderung der Firewall-Zeitzone nicht spontan im Produktivbetrieb vornehmen; Sophos verlangt danach einen Neustart, der in ein Wartungsfenster gehört.

Microsoft Security Defaults deaktivieren SMTP AUTH. Diese Schutzvorgabe sollte nicht pauschal für den gesamten Tenant abgeschaltet werden, nur damit eine Firewall Nachrichten senden kann. Wenn die gezielte Freigabe für das Sendekonto nicht zum Sicherheitsmodell passt, ist ein dafür vorgesehenes internes oder externes Relay der sauberere Weg.

⚠️ Sophos führt in der aktuellen Known Issues list weiterhin NC-166854: Microsoft-365-OAuth für Notifications funktioniert auf den dort genannten Builds 22.0.0.274, 22.0.0.323, 21.0.2.349 und 21.5.1.261 nicht. Eine Fix-Version ist dort nicht ausgewiesen. Deshalb den exakten SFOS-Build prüfen und die erfolgreiche Testmail verlangen. Gespeicherte Client-ID-, Secret- und Token-Felder sind noch kein Funktionsbeweis.

Ist ein aufgeführter Build betroffen, wird ein unterstütztes SMTP-Relay oder ein anderer verifizierter Mailweg verwendet, bis ein korrigierter Firmwarestand belastbar bestätigt ist. Unsichere TLS-Ausnahmen oder ungeprüfte Basic-Authentication sind kein guter Ersatz für einen funktionierenden Alarmweg.

Ereignisse in der Notification list auswählen

Nach erfolgreichem Mailtest wird System services > Notification list geöffnet. Dort zuerst Email notifications aktivieren, anschliessend die Checkboxen in der Spalte Email für die benötigten Ereignisse setzen und mit Save speichern.

Nicht jede Firewall braucht dieselbe Auswahl. Eine sinnvolle Basis orientiert sich an den Risiken und den tatsächlich genutzten Funktionen:

  • Admin: fehlgeschlagene Anmeldungen und zu viele fehlgeschlagene Anmeldeversuche.
  • HA: getrennte überwachte Ports oder Interfaces, wenn ein HA-Cluster betrieben wird.
  • Disk/Memory: Speicherwarnungen, damit ein voller Report- oder Systembereich nicht erst im Wartungsfenster auffällt. Die Schwellen und Folgen erklärt Speicher und Reports auf Sophos Firewall prüfen.
  • Firmware: neue Firmware und vor allem fehlgeschlagene Installationen passend zum eigenen Updateprozess.
  • System: fehlgeschlagene Signatur- oder Datenbankupdates, Systemstart, hohe CPU-Auslastung und Gateway status.
  • IPS und Active threat response: zunächst kritische oder blockierende Ereignisse, wenn dafür ein Triage-Prozess besteht.
  • RED, AP und VPN: nur für tatsächlich eingesetzte Geräte und wichtige Verbindungen.
  • Web - Instant alerts: bewusst ausgewählte Web-Kategorien. Diese Meldungen werden in Fünf-Minuten-Batches versendet und benötigen eine separate Kategorieaktivierung, wie unter Web Categories und Instant Alerts beschrieben.

Alle Ereignisse pauschal zu aktivieren erzeugt schnell Alarmmüdigkeit. Besonders VPN-Meldungen können ungefähr alle 60 Sekunden wiederholt werden, bis die Ursache behoben ist; bei mehreren lokalen und entfernten Netzen kann zudem eine Meldung pro Subnetzpaar entstehen. Besser ist eine kleine Auswahl mit klarer Reaktion: Wer erhält den Alert, wie dringend ist er und welcher erste Prüfschritt folgt?

Einige Default Notifications sendet die Firewall automatisch und lässt sie nicht abwählen. Dazu gehören bestimmte HA-Rollen- und Statusänderungen, der Status virtueller Hosts sowie Neustart oder Shutdown über den WebAdmin. Auch für diese Meldungen muss der konfigurierte Mailweg erreichbar sein.

Testmail und echtes Ereignis prüfen

Die Prüfung besteht aus zwei Stufen.

1. SMTP-Zustellung mit einer Testmail bestätigen

Die Testmail unter Administration > Notification settings senden. Die Erfolgsmeldung der Firewall reicht noch nicht: Im Zielpostfach, Spamfilter oder Mailserver-Tracking muss erkennbar sein, dass die Nachricht wirklich angenommen und zugestellt wurde.

Dabei werden kontrolliert:

  • Absender und Empfänger stimmen.
  • Die erwartete Firewall ist anhand von Betreff, Inhalt oder Management-IP erkennbar.
  • Die Nachricht landet nicht dauerhaft in Spam oder Quarantäne.
  • Der Verteiler nimmt Nachrichten des konfigurierten Absenders an.

2. Die vollständige Ereigniskette testen

Danach ein ausgewähltes Ereignis kontrolliert auslösen. Geeignet sind beispielsweise:

  • ein einzelner fehlgeschlagener Login mit einem Testkonto, nachdem Login-Sperren und Schwellen geprüft wurden;
  • Up/Down eines ausdrücklich dafür vorgesehenen VPN-Testtunnels;
  • Gateway status während eines geplanten WAN-Failover-Tests.

Ein produktives Gateway, einen HA-Port oder die Firewall selbst nur für eine E-Mail-Prüfung neu zu starten beziehungsweise zu trennen, wäre unverhältnismässig. Ein ohnehin geplantes Wartungs- oder Failover-Szenario ist der bessere Test.

Erst wenn das Ereignis in der erwarteten Zeit beim richtigen Empfänger ankommt, ist die gesamte Kette bestätigt: Event-Erkennung, Event-Auswahl, globaler E-Mail-Schalter, SMTP-Transport und Zustellung.

Fehler systematisch eingrenzen

Die Testmail schlägt bereits fehl

Die SFOS-22-API unterscheidet mehrere Fehlerklassen:

  • Failed to connect oder SMTP server failed to respond: FQDN-Auflösung, Route, Port, vorgeschaltete Firewall und Listener des Mailservers prüfen.
  • Password mismatch: Benutzername, Gross-/Kleinschreibung, Passwort und gegebenenfalls gesperrtes Konto kontrollieren.
  • Authentication method mismatch: Prüfen, ob Relay und SFOS bei Basic Authentication LOGIN oder PLAIN gemeinsam unterstützen.
  • STARTTLS not supported: Port und Connection security passen nicht zum Server-Listener.
  • Mail server refused to communicate: Relay-Freigabe, Absenderadresse, erlaubte Quell-IP und Mailserver-Logs prüfen.
  • Couldn’t generate the OAuth 2.0 access token: Provider, Client ID, Secret, Refresh Token, Berechtigungen und Systemzeit kontrollieren.

Von einem Administrationssystem auf einem vergleichbaren Netzpfad lassen sich DNS und STARTTLS ohne Änderung am Mailserver vorprüfen:

nslookup smtp.example.net
openssl s_client -starttls smtp -connect smtp.example.net:587 -servername smtp.example.net

smtp.example.net und 587 werden durch den eigenen Server und Port ersetzt. nslookup bestätigt nur die Namensauflösung des Administrationssystems. openssl s_client zeigt SMTP-Erreichbarkeit, TLS-Handshake und Zertifikatskette, prüft aber weder die Route aus Sicht der Firewall noch deren Anmeldung oder die spätere Zustellung.

Im Log Viewer und bei einer tieferen Analyse in cschelper.log lässt sich der Testzeitpunkt mit der systemgenerierten E-Mail korrelieren. Der Zugriff auf Service-Logs und die Abgrenzung zur Advanced Shell stehen unter Sophos Firewall Services und Logs. MTA-Logs wie smtpd_main.log gehören primär zur Mail Protection und sind nicht pauschal das Notification-Log.

Die Testmail kommt an, aber Ereignismails fehlen

Dann funktioniert der Transport, und die Suche beginnt in System services > Notification list:

  1. Ist Email notifications global aktiv?
  2. Ist das konkrete Ereignis in der Spalte Email ausgewählt?
  3. Ist das erwartete Ereignis wirklich eingetreten und passt es zur richtigen Kategorie?
  4. Gibt es eine bekannte Verzögerung oder Bündelung, beispielsweise bei Web Instant Alerts?
  5. Zeigen Spamfilter, Quarantäne oder Mailserver-Tracking eine Annahme oder Ablehnung?

Bei einem einzelnen Spezialereignis sollte zusätzlich dessen fachliche Bedingung geprüft werden. Ein IPS-Alert entsteht beispielsweise nicht nur durch eine aktivierte Checkbox, sondern erst, wenn eine passende IPS-Regel das Ereignis protokolliert und verwirft. Eine VPN-Meldung hängt vom Tunneltyp und vom tatsächlichen Up-/Down-Zustand ab.

Microsoft-365-OAuth speichert, aber sendet nicht

Zuerst SFOS-Version und Build mit NC-166854 vergleichen. Danach Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP für das Sendekonto und die korrekte Systemzeit prüfen.

Bleibt die Testmail auf einem nicht als betroffen gelisteten Build erfolglos, ist das nicht automatisch derselbe Fehler. Die genaue Meldung, der SFOS-Build und die Provider-Anmeldelogs gehören dann in die weitere Analyse oder ein Supportticket.

Benachrichtigungen betreiben

  • Empfänger als funktionalen Verteiler mit verantwortlichem Owner führen.
  • Testmail und ein echtes Ereignis nach Änderungen an Mailserver, DNS, Routing, Zertifikat, Zugangsdaten, OAuth-App oder Firmware erneut prüfen.
  • Den vollständigen Alarmweg mindestens quartalsweise testen, wenn kein zentrales Monitoring ihn laufend überwacht.
  • Ablauf und Rotation von Passwörtern, Client Secrets und Tokens dokumentieren.
  • Ereignisauswahl regelmässig an neue Funktionen und abgeschaltete Dienste anpassen.
  • Für jeden wichtigen Alert einen ersten Prüfschritt und einen Eskalationsweg festlegen.

Welche Status-, Security- und Adminsignale im laufenden Betrieb zusätzlich aktiv kontrolliert werden, bündelt die tägliche Sophos Firewall Admin-Checkliste.

E-Mail ist ein guter direkter Alarmkanal, ersetzt aber keine zentrale Logaufbewahrung oder Korrelation. Für längere Historie und Security-Auswertung passt Sophos Firewall Syslog an ein SIEM senden. Für klassische Zustandsüberwachung und Traps ist SNMP Hardware Monitoring die passende Ergänzung.

Für täglich oder wöchentlich versendete PDF-Auswertungen wird nicht die Notification list, sondern ein eigener Report-Zeitplan verwendet. Sophos Firewall Reports planen und per E-Mail versenden erklärt Reportauswahl, Bookmark, Transporttest und Inhaltskontrolle.