Sophos Firewall E-Mail-Benachrichtigungen einrichten und testen

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:

Mailserver, Port, Authentifizierung, Verschlüsselung, Absender und Empfänger unter Administration > Notification settings konfigurieren.
Eine Testmail senden und die Zustellung im Zielpostfach oder Mailserver-Tracking bestätigen.
Unter System services > Notification list den globalen Schalter Email notifications aktivieren.
Nur die Ereignisse auswählen, für die ein verantwortlicher Empfänger reagieren kann.
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.

Ist der WebAdmin nicht verfügbar oder soll die Empfängeradresse über einen kontrollierten CLI-Zugang korrigiert werden, im Main Menu der CLI 2. System Configuration > 3. Set Email ID for system notification öffnen. System Configuration ist Option 2 des Main Menu, kein Untermenü der Device Console (Option 4). Befindet man sich bereits in Option 4, zuerst zum Main Menu zurückkehren und dort Option 2 wählen. 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.

Vor einer Änderung werden die gewählte Mailserver-Option, Mailserver, Port, Authentication, Connection security, Absender, Empfänger, Management-Interface und die ausgewählten Ereignisse dokumentiert. Sind Zertifikatseinstellungen Teil der Umstellung, gehört auch die bisherige Auswahl unter Administration > Notification settings beziehungsweise Email > General settings in diese Bestandsaufnahme. Die dafür benötigten Zugangsdaten und OAuth-Tokens müssen sicher in einem Passwort- oder Secrets-Manager verfügbar sein; in ungeschützte Screenshots gehören sie nicht. Nur mit diesen Angaben lässt sich die bisherige Konfiguration wiederherstellen, falls der neue Mailweg den Zustellungstest nicht besteht.

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.

Im Dropdown erscheinen physische Interfaces, Bridge-Interfaces und LAG-Interfaces nur, wenn ihnen eine IP-Adresse zugewiesen ist. Fehlt ein Interface, erklärt diese Voraussetzung die fehlende Auswahl; nur für die Identifikation in einer Nachricht sollte man weder IP-Adressen zuweisen noch Interfaces oder Routing ändern.

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:

Unter Administration > Notification settings den Built-in email server aktivieren.
Absender, Empfänger und optional Management interface IP address eintragen.
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

Administration > Notification settings öffnen.
External email server auswählen.
IPv4-Adresse oder FQDN des Mailservers und den vorgegebenen Port eintragen.
Unter Authentication None, Basic oder OAuth 2.0 passend zum Server wählen.
Unter Connection security die vom Mailserver geforderte Transportverschlüsselung einstellen.
Absender, Empfänger und optional Management interface IP address eintragen.
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. Beim Benutzernamen ist die Gross-/Kleinschreibung zu beachten. 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.

Welches Zertifikat SFOS verwendet, hängt auch vom E-Mail-Modus ab. Bei STARTTLS verwendet die Firewall im MTA Mode das Zertifikat unter Email > General settings. Im Legacy Mode kann für STARTTLS ein Zertifikat direkt unter Administration > Notification settings gewählt werden; ohne Auswahl greift SFOS ebenfalls auf das Zertifikat unter Email > General settings zurück. Bei SSL/TLS kommt das Zertifikat unter Email > General settings zum Einsatz. Eine Zertifikatsä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 ist in SFOS 22 und 23 OAuth 2.0 zu wählen. In Notification settings werden dafür Provider, Client ID, Client secret und Refresh token hinterlegt. Das Feld Client secret ist für Microsoft 365 optional; der hier beschriebene Microsoft-365-Ablauf erstellt und verwendet jedoch ausdrücklich ein Secret. 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 beschreibt diese Schritte. Google und Microsoft ändern ihre Portale und Vorgaben unabhängig von SFOS; vor einer produktiven Einrichtung werden deshalb die aktuellen Provider-Vorgaben und die Berechtigungen des vorgesehenen Sendekontos geprüft.

Gmail OAuth 2.0 Schritt für Schritt einrichten

Vor dem Erzeugen des Refresh Tokens werden das vorgesehene Sendekonto, der OAuth-Client, die Redirect URI und der unten beschriebene weitreichende Gmail-Scope geprüft. Für den folgenden Ablauf mit User type: External muss auch die Freigabe für den Produktionsbetrieb der OAuth-App geklärt sein. Publish App ersetzt weder eine erforderliche Provider-Verifizierung noch die Zustimmung des zuständigen Google-Workspace- oder Sicherheitsadministrators. Ist die Veröffentlichung nach den aktuellen Google-Vorgaben oder den eigenen Richtlinien nicht zulässig, nicht einfach Schutzvorgaben umgehen: Für einen dauerhaften Alarmweg wird stattdessen ein freigegebenes SMTP-Relay verwendet.

In der Google Cloud Console mit dem vorgesehenen Google-Konto anmelden, ein neues Projekt erstellen und dieses auswählen.
APIs & Services > Library öffnen, nach Gmail API suchen und die API aktivieren.
Unter APIs & Services > Credentials auf Create credentials > OAuth client ID klicken.
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.
Create OAuth client wählen, Application type: Web application setzen und einen eindeutigen Namen vergeben.
Unter Authorized redirect URIs exakt https://developers.google.com/oauthplayground hinzufügen.
Den OAuth-Client erstellen und Client ID sowie Client secret sofort sicher dokumentieren.
Unter Audience das vorgesehene Sendekonto und den aktuellen Veröffentlichungsstatus prüfen. Solange die App auf Testing steht, wird das Konto unter Add users als Testbenutzer hinzugefügt. Diese Testbenutzerliste ist keine Zugriffsbeschränkung für eine später veröffentlichte externe App.
Nach der erforderlichen Freigabe Publish App ausführen und kontrollieren, dass der Publishing status von Testing auf In production gewechselt hat. Eine externe App steht dann grundsätzlich Google-Konten ausserhalb der Testbenutzerliste zur Autorisierung offen; die geltenden Konto- und Organisationsrichtlinien bleiben zu beachten. Erst danach den Refresh Token erzeugen. Ein bereits vor der Veröffentlichung erzeugter Token läuft in diesem Gmail-Ablauf nach sieben Tagen ab; für den dauerhaften Betrieb deshalb nach der Veröffentlichung einen neuen Refresh Token erzeugen, statt den bisherigen weiterzuverwenden.
Den Google OAuth 2.0 Playground öffnen. Über das Zahnradsymbol Use your own OAuth credentials aktivieren und Client ID sowie Client secret einfügen.
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 und vor der Zustimmung die angezeigte App und deren Berechtigungen mit der freigegebenen Konfiguration vergleichen. Bei Abweichungen abbrechen und die Konfiguration prüfen.
Unter Step 2 Exchange authorization code for tokens den Code gegen Tokens tauschen und den Refresh token sicher kopieren. Client secret, Authorization Code, Access token und Refresh token gehören weder in Tickets noch in ungeschützte Screenshots oder Logs.
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. Die tatsächliche Zustellung im Zielpostfach oder Mailserver-Tracking bestätigen; gespeicherte OAuth-Felder allein beweisen keinen funktionierenden Mailweg.

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 hier 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 vollständigen Entra-Schritte folgen direkt darunter.

Microsoft 365 OAuth 2.0 Schritt für Schritt einrichten

Im Microsoft Entra admin center unter Identity > Applications > App registrations eine New registration erstellen.
Einen eindeutigen Namen vergeben. Für diesen Ablauf Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) auswählen. Unter Redirect URI die Plattform Web wählen und https://outlook.office365.com/ als URI eintragen. Alternativ ist http://localhost/ vorgesehen. Die registrierte URI muss in der Autorisierungsanfrage und beim Token-Austausch exakt wiederverwendet werden; bei Verwendung von localhost sind beide folgenden Beispiele entsprechend anzupassen.
Die App registrieren und die Application (client) ID sicher dokumentieren.
Unter API permissions > Add a permission die delegierte SMTP-Berechtigung für die Outlook-/Exchange-Ressource konfigurieren und den erforderlichen Consent erteilen. Microsoft dokumentiert dafür den Scope https://outlook.office.com/SMTP.Send; zusätzlich wird offline_access für den Refresh Token angefordert. Entscheidend ist die SMTP-Berechtigung, nicht eine Graph-Berechtigung wie Mail.Send. Die Ressourcenauswahl und die angezeigten Berechtigungen anhand der Microsoft-Anleitung für SMTP mit OAuth prüfen, bevor der Token erstellt wird. Fehlt die passende Berechtigung, nicht mit einer vermeintlich ähnlichen fortfahren.
Im Microsoft 365 admin center für das Sendekonto unter Users > Active users > Mail > Email apps > Manage email apps die Option Authenticated SMTP prüfen und, sofern die Sicherheitsrichtlinien dies erlauben, aktivieren und speichern. Dieser Postfachschalter ist nicht die App-Registrierung im Entra admin center.
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.
Im Browser die folgende URL öffnen. YOUR_CLIENT_ID durch die Application ID und YOUR_RANDOM_STATE durch einen zufälligen, nur für diesen Vorgang erzeugten Wert ersetzen; die redirect_uri muss mit der App-Registrierung übereinstimmen. Parameterwerte korrekt URL-kodieren. Der State-Wert muss in der Antwort unverändert zurückkommen; ein fester Beispielwert schützt den Vorgang nicht. Die Microsoft-Anleitung zum Authorization-Code-Flow erklärt State-Prüfung und PKCE für geeignete Clients.

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=YOUR_RANDOM_STATE

Mit dem vorgesehenen Sendekonto anmelden, den zurückgegebenen State-Wert mit dem gespeicherten Wert vergleichen und erst bei Übereinstimmung den kurzlebigen Authorization Code aus der weitergeleiteten URL übernehmen. Bei einer Abweichung abbrechen und den Vorgang neu beginnen.
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. Der folgende Block zeigt die Felder lesbar auf mehreren Zeilen; im API-Client werden sie als einzelne Formularfelder erfasst, damit Leerzeichen und Sonderzeichen in Code, Secret und Redirect URI korrekt kodiert werden. Es ist kein unverändert kopierbarer Shell-Befehl.

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

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

Für diesen Token-Erzeugungsablauf müssen das System mit dem API-Client und die Firewall in derselben Zeitzone arbeiten. Systemzeit und Zeitzone deshalb vorher prüfen. Eine Änderung der Firewall-Zeitzone nicht spontan im Produktivbetrieb vornehmen; der danach erforderliche Neustart gehört in ein Wartungsfenster.

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.

⚠️ Der bekannte Fehler NC-166854 betrifft Microsoft-365-OAuth für Notifications auf den SFOS-Builds 22.0.0.274, 22.0.0.323, 21.0.2.349 und 21.5.1.261. Daraus lässt sich weder ableiten, dass jeder andere Build funktioniert, noch dass inzwischen keine Korrektur verfügbar ist. Vor der Inbetriebnahme den exakten SFOS-Build und den für ihn geltenden Fehler-/Fix-Status prüfen und eine 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.

E-Mail und SNMP sind getrennte Ausgabekanäle. Für Traps müssen unter Administration > SNMP zusätzlich der SNMP-Agent und die passenden Communities oder Benutzer eingerichtet sein. Danach in der Notification list den globalen Schalter SNMP traps und die verfügbaren Ereignis-Checkboxen für SNMP aktivieren und speichern. Eine E-Mail-Auswahl aktiviert keine Traps; je Ereignis kann man E-Mail, SNMP oder beide verfügbaren Kanäle wählen. Die Einrichtung und Prüfung des SNMP-Managers erklärt der unten verlinkte SNMP-Artikel.

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 bereit zur Installation, erfolgreich installierte Firmware und fehlgeschlagene Installationen passend zum eigenen Updateprozess.
Nur SFOS 23 – Firmware > Security updates: Unter System services > Notification list die Spalte Email für Security updates aktivieren. Der globale Schalter Email notifications und ein funktionierender SMTP-Pfad bleiben Voraussetzung. Für Hotfix-Sicherheitsupdates gibt es keine SNMP-Benachrichtigungen; diese Einschränkung gilt nicht pauschal für alle Hotfixes oder Firmware-Ereignisse. Eine sofortige Zustellung ist nicht zugesichert, und fehlende E-Mail beweist weder Erfolg noch Fehlschlag. Angewendete Updates anhand des SFOS-23-Hotfix-Nachweises prüfen.
System: fehlgeschlagene WebCat-Datenbank-, IPS-Signatur- und Antivirus-Definitionsupdates, Systemstart beziehungsweise Neustart, hohe CPU-Auslastung und Gateway status.
IPS: die Stufen Critical, Major, Moderate, Minor und Warning sind auswählbar. Der Alert setzt voraus, dass die Firewall das IPS-Ereignis protokolliert und das Paket verwirft. Für den Einstieg eignen sich kritische Ereignisse mit einem definierten Triage-Prozess.
Active threat response: Log- und Drop-Ereignisse für MDR, NDR Essentials, Sophos X-Ops und Drittanbieter-Threat-Feeds werden getrennt ausgewählt. Die Match-Arten und Einschränkungen stehen im nächsten Abschnitt.
RED: Verbindung ausgefallen, Firmwareupdate fehlgeschlagen, Gerät automatisch deautorisiert oder neuer Unlock Code. AP: Access Point offline oder Firmwareupdate fehlgeschlagen. Nur Meldungen tatsächlich eingesetzter Geräte auswählen und einen zuständigen Empfänger festlegen.
VPN: IPsec-Tunnel up, down sowie failover/failback und etablierte beziehungsweise getrennte SSL-VPN-Verbindungen. Die unten erläuterten IPsec-Auslösebedingungen sind enger als diese allgemeine Liste; die Auswahl ist keine Zusage für jeden manuellen Tunnelwechsel.
Virus: Alerts für HTTP, FTP, SMTP, POP3 und IMAP4 nach den tatsächlich verwendeten Schutzfunktionen auswählen. Die Checkbox ersetzt weder die entsprechende Prüfung noch deren Ereigniserkennung.
Web - Instant alerts: bewusst ausgewählte Web-Kategorien. Diese Meldungen werden in festen, nicht änderbaren 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: HA-Rollenänderungen von Standalone, Primary oder Auxiliary, HA-Gerätestatus faulty, virtuelle Hosts up/down sowie Neustart oder Shutdown über den WebAdmin. Auch für diese Meldungen muss der konfigurierte Mailweg erreichbar sein. Die nicht abwählbare Ereigniskategorie ist keine Garantie, dass eine Nachricht ein unerreichbares Postfach erreicht.

Active threat response: Match und Kanal unterscheiden

Für jede der folgenden Match-Arten gibt es ein Log event und ein Drop event:

Destination match for all traffic: die Zieladresse stimmt mit einem Threat-Feed-Eintrag überein.
Remote source match for inbound traffic: die entfernte Quelladresse eingehenden Verkehrs stimmt überein.
Local source match for outbound traffic: die lokale Quelladresse ausgehenden Verkehrs stimmt überein.

Ein Log-Alert allein belegt keine Blockierung. Umgekehrt ist ein Drop-Ereignis vom tatsächlichen Match und der entsprechenden Active-threat-response-Konfiguration abhängig; die E-Mail-Checkbox erzeugt weder einen Match noch eine neue Schutzregel.

Die Sophos-Benachrichtigungshilfe nennt lokale und entfernte Quellmatches für Sophos X-Ops als nicht unterstützt. Dazu besteht jedoch der im NDR-/ATR-Artikel dokumentierte Widerspruch zur SVG-Traffic-Matrix, insbesondere beim lokalen Quellabgleich. Die E-Mail-Option belegt deshalb weder eine bestimmte X-Ops-Matchwirkung noch die Auflösung dieses Widerspruchs; strittige Fälle vor dem Einplanen als Schutzvoraussetzung gesondert klären. Remote-source-match-Alerts werden nicht an den zentralen Sophos-Dienst weitergeleitet, ihre Logs sind jedoch in Central Firewall Reporting (CFR) sichtbar. Die Bezeichnung des zentralen Diensts variiert zwischen den Versionen (Sophos Central beziehungsweise Sophos Fusion); daraus folgt keine Erweiterung der Alert-Weiterleitung. Für diese Ereignisse wird deshalb der lokale E-Mail-/Logweg geprüft und nicht allein auf eine zentrale Alert-Anzeige vertraut.

Auslösebedingungen und Wiederholungen richtig einordnen

Eine aktivierte Checkbox bedeutet nicht, dass jede kurze Zustandsänderung eine E-Mail erzeugt. Für SFOS 22.0 und 23.0 gelten bei den folgenden Ereignissen diese Bedingungen:

Admin: Sign-in failed umfasst falsche Zugangsdaten oder ein falsches Einmalpasswort (OTP). Too many failed sign-in attempts wird beim Erreichen der unter Administration > Admin and user settings > Login security konfigurierten Anzahl erfolgloser Anmeldeversuche ausgelöst. Diese Schwelle erklärt den Alert; sie ist keine Aufforderung, eine Kontosperre zu provozieren.
High CPU usage: Erst wenn die CPU-Auslastung 95 % erreicht und mindestens 25 Minuten durchgehend bei 95 % oder darüber bleibt, entsteht der erste Benachrichtigungs-Logeintrag. Weitere Einträge entstehen alle 25 Minuten, bis die Auslastung unter 95 % fällt. Ein kurzer CPU-Spike ohne Ereignismail belegt daher keinen SMTP-Fehler.
Gateway status: Die Ereignisauswahl ist standardmässig eingeschaltet. Zum Versand muss trotzdem der separate globale Schalter Email notifications aktiv sein.

Bei Disk-Ereignissen muss die Auslastung mindestens 50 Sekunden durchgehend an oder über der jeweiligen Schwelle liegen. Danach werden Logs und Benachrichtigungen mit der folgenden Standardfrequenz wiederholt, bis die Auslastung unter die Schwelle fällt:

Bereich	Benachrichtigungsschwelle	Wiederholung
Konfigurationsspeicher	≥80 %	alle 50 Sekunden
Signaturspeicher	≥90 %	alle 50 Sekunden
`/var`	≥80 %	alle 12 Stunden

Bei /var erzeugt bereits die niedrigere Schwelle Logs; Benachrichtigungen beginnen erst an der höheren Schwelle von 80 %. Fällt die Auslastung nach Überschreiten der höheren Schwelle wieder unter die niedrigere, wird die Erholung protokolliert, aber keine Erholungsbenachrichtigung versendet. Das ist vom Warn- und Stop-Verhalten der Reports im oben verlinkten Speicherartikel zu unterscheiden; eine ausbleibende Erholungsmail ist hier kein Zustellfehler.

Für IPsec ist der dokumentierte Geltungsbereich enger als ein beliebiger VPN-Up-/Down-Wechsel: Benachrichtigungen gelten nur für Host-to-Host- und Site-to-Site-Tunnel mit den beschriebenen Trennungsbedingungen:

Dead peer detection (DPD).
Fehlgeschlagener Wiederaufbau nach DPD.
Die IPsec Security Association (SA) ist abgelaufen und muss neu aufgebaut werden.
In dieser Aufzählung ist auch enthalten, dass der Tunnel nach einem Verbindungsverlust ohne Eingriff des Administrators wieder hochkommt.

Ist in den IPsec-Verbindungseinstellungen eine Beschreibung hinterlegt, enthält die Benachrichtigung diese ebenfalls. Daraus folgt keine Zusage für jede manuelle Trennung oder für Remote-Access- beziehungsweise SSL-VPN-Tunnel.

Die CPU-Zeiten beschreiben die Erzeugung von Benachrichtigungs-Logs, die Disk-Intervalle die dokumentierte Wiederholung – keine garantierte Ankunftszeit im Postfach. Bei fehlender Mail zuerst Ereignisbedingung, Logzeitpunkt und Mailserver-Tracking vergleichen. CPU- oder Disk-Sättigung, Login-Sperren, HA-Unterbrechungen oder produktive VPN-Ausfälle sollten nicht eigens für einen Alert-Test erzeugt werden.

Testmail und echtes Ereignis prüfen

Die Prüfung besteht aus zwei Stufen.

1. SMTP-Zustellung mit einer Testmail bestätigen

Zuerst die unter Administration > Notification settings gespeicherte Mailkonfiguration prüfen und die im verwendeten SFOS-Build verfügbare Testmail-Funktion ausführen. Der Report-Testweg ist Reports > Show report settings > Report scheduling: einen Report auswählen, Send test mail öffnen, die Testempfängeradresse eingeben und Send klicken. Dieser Report-Test prüft den Mailtransport, nicht die Ereignisauswahl; sein Empfänger ist nicht automatisch der gespeicherte Empfänger für System-Alerts. Die Erfolgsmeldung der Firewall reicht noch nicht: Im Zielpostfach, Spamfilter oder Mailserver-Tracking muss erkennbar sein, dass die Nachricht wirklich angenommen und zugestellt wurde. Reportinhalt und Zeitplan werden separat geprüft, wie im unten verlinkten Report-Artikel beschrieben.

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;
ein dokumentiertes VPN-Ereignis an einem ausdrücklich vorgesehenen Testtunnel, sofern Tunneltyp und Auslösebedingung zur ausgewählten Benachrichtigung passen; ein manueller IPsec-Up-/Down-Wechsel allein ist kein verlässlicher Alert-Test;
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:

Ist Email notifications global aktiv?
Ist das konkrete Ereignis in der Spalte Email ausgewählt?
Ist das erwartete Ereignis wirklich eingetreten und passt es zur richtigen Kategorie?
Gibt es eine bekannte Verzögerung oder Bündelung, beispielsweise bei Web Instant Alerts?
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 das Paket verwirft. Eine VPN-Meldung hängt vom Tunneltyp und vom tatsächlichen Up-/Down-Zustand ab.

Gmail-OAuth fällt nach einem Passwortwechsel aus

Beim hier beschriebenen Gmail-Benachrichtigungsablauf mit dem Scope https://mail.google.com wird der Refresh Token ungültig, wenn das Passwort des verwendeten Gmail-Sendekontos geändert wird. Die Firewall kann dann mit diesem Token keinen neuen Access Token mehr beziehen. Das ist keine Aussage über sämtliche Google-OAuth-Tokens oder über Microsoft 365.

Prüfen, ob das Passwort genau dieses Sendekontos geändert wurde. OAuth-Client, Konto, freigegebene Berechtigungen und Publishing status: In production mit der dokumentierten Konfiguration vergleichen. Auch ein noch vor Publish App erzeugter Token ist nach sieben Tagen keine dauerhafte Grundlage; die beiden Ursachen werden getrennt geprüft.
Mit dem aktuellen Kontozugang und den eigenen OAuth-Client-Zugangsdaten den Gmail-Autorisierungs- und Token-Austausch im oben beschriebenen Playground-Ablauf erneut durchführen. Die App und die angeforderten Berechtigungen vor der Zustimmung prüfen und den neuen Refresh Token sicher speichern.
Unter Administration > Notification settings bei Provider: Gmail den ungültigen Refresh token durch den neuen ersetzen und speichern. Client ID und Client secret müssen zum verwendeten OAuth-Client passen; SMTP-, TLS-, Absender-, Empfänger- und Ereigniseinstellungen werden nicht ohne Anlass geändert.
Eine Testmail senden und deren tatsächliche Zustellung im Zielpostfach oder Mailserver-Tracking bestätigen. Anschliessend ein kontrolliertes ausgewähltes Ereignis wie im Abschnitt zur vollständigen Ereigniskette prüfen.

Das erneute Eintragen des alten Tokens macht ihn nicht wieder gültig. Das Kontopasswort wird nicht zurückgesetzt, nur um den bisherigen Mailweg wiederherzustellen. Bleibt der Versand nach der erneuten Autorisierung erfolglos, die genaue Fehlermeldung, den SFOS-Build und die Provider-Konfiguration ohne Secrets oder Tokens für die weitere Analyse festhalten. Bis zur bestätigten Wiederherstellung wird ein freigegebener alternativer Alarmweg beziehungsweise das dokumentierte SMTP-Relay verwendet.

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

Schlägt die Zustellung nach einer Umstellung fehl, wird zuerst die dokumentierte Mailkonfiguration wiederhergestellt: Mailserver-Option, Server, Port, Authentication, Connection security, Absender, Empfänger und Management-Interface sowie, falls geändert, die vorherige Zertifikatsauswahl. Die Ereignisauswahl bleibt unverändert, sofern sie nicht Teil der Änderung war. Nach dem Speichern bestätigen erneut eine Testmail und ein kontrolliertes ausgewähltes Ereignis den bisherigen Alarmweg. Der Rückweg ist erst abgeschlossen, wenn beide Nachrichten tatsächlich angekommen sind.

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.

Empfängeradresse über CLI Main Menu > 2. System Configuration ändern