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

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. Die aktuellen Schritte führt Sophos unter Configure OAuth 2.0 on Gmail.

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

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.