Sophos Firewall Quarantäne-Digest einrichten und testen

Der Quarantäne-Digest informiert Benutzer per E-Mail über Spam-Nachrichten, die Sophos Firewall zurückgehalten hat. Der Digest ist aber nicht einfach nur eine weitere Systembenachrichtigung: Versandweg, Benutzerzuweisung, Release-Link und User Portal müssen gemeinsam funktionieren.

Der wichtigste Punkt für die Abnahme ist deshalb der vollständige Benutzerweg. Eine erfolgreiche Testmail bestätigt noch nicht, dass ein echter Benutzer seinen Digest erhält, sich am richtigen Portal anmelden und eine zulässige Nachricht freigeben kann.

⚠️ Der Release-Link gibt eine Nachricht nicht direkt frei. Er führt zum User Portal, wo sich der Benutzer anmelden und die Nachricht selbst auswählen muss. Die gewählte Portaladresse muss deshalb für den vorgesehenen Empfängerkreis erreichbar sein, darf die Oberfläche aber nicht unkontrolliert für weitere Netze öffnen.

Quarantäne-Digest in sieben Schritten

1. Unter Administration > Notification settings den Mailtransport einrichten.
2. Portaladresse, DNS, Zertifikat und erlaubte Quellnetze für den vorgesehenen Benutzerkreis festlegen.
3. Unter Email > Quarantine settings den Digest aktivieren und Versandzeit, Absender sowie Anzeigenamen setzen.
4. Unter Release link settings die richtige User-Portal-Adresse auswählen, mit Send test email prüfen und mit Apply speichern.
5. Nur im MTA Mode: Quarantänebereich und bewusst auszuschliessende Adressmuster festlegen.
6. Den Digest unter Authentication > Groups oder Authentication > Users den vorgesehenen Konten zuweisen.
7. Mit einer echten quarantänisierten Spam-Testmail den Digest, die Portal-Anmeldung und die Freigabe end-to-end prüfen.

Was der Digest kann und was nicht

Der Digest enthält eine Liste quarantänisierter Spam-Nachrichten mit Empfangszeit, Absender, Empfänger und Betreff. Er ist damit eine komfortable Benutzersicht, ersetzt aber weder die administrative Quarantäne unter Email > SMTP quarantine noch die technische Analyse von Policy, Mail logs und MTA-Logs.

Die allgemeinen Digest-Einstellungen stehen im MTA Mode und im Legacy Mode zur Verfügung. Quarantine area und Skip address patterns zeigt SFOS dagegen nur im MTA Mode. Legacy-Admins konfigurieren deshalb nur Versand, Release-Link und Benutzerzuweisung.

Nur Benutzer, die mindestens einmal an der Firewall authentifiziert wurden, erhalten einen Quarantäne-Digest. Das wird häufig übersehen, wenn Konten zwar aus Active Directory importiert sind, sich aber noch nie an User Portal, Captive Portal oder einem anderen passenden Dienst angemeldet haben.

Auf XGS 87 und XGS 87w ist der Quarantäne-Digest laut SFOS-22/23-Hilfe nicht verfügbar. Diese Modellgrenze betrifft den Digest und darf nicht mit der separaten MTA-Mode-Grenze verwechselt werden. Den Mailflow, die SMTP-Policy und die administrative Quarantäne erklärt Mail Protection im MTA Mode einrichten.

Mailversand und Portaladresse vorbereiten

Der Versand verwendet die Einstellungen unter Administration > Notification settings. Mailserver, Absender, Empfänger, DNS, Route, Authentifizierung und TLS müssen dort zuerst funktionieren. Der vollständige Transporttest steht unter Sophos Firewall E-Mail-Benachrichtigungen einrichten.

Für den Release-Link gibt es zwei Wege:

• Reference user portal IP: SFOS verwendet die Adresse des ausgewählten Interfaces zusammen mit dem User-Portal-Port.
• IP address or hostname: SFOS verwendet die unter Administration > Admin and user settings > Admin console and end-user interaction konfigurierte Adresse.

Die Quarantäne-Hilfe für SFOS 22/23 nennt diesen Bereich abweichend Administration > Admin settings. Entscheidend ist das Feld unter Admin console and end-user interaction, nicht allein der Menüname. Die tatsächliche Oberfläche und den Link in der empfangenen Digest-Mail abgleichen; aus unterschiedlichen Bezeichnungen folgt keine zusätzliche Freigabefunktion.

Ein FQDN ist meist verständlicher und lässt sich mit einem passenden Zertifikat sauber absichern. Er muss aber aus den Netzen der Empfänger auf die richtige Firewall-Adresse auflösbar und erreichbar sein. Eine private Interface-IP im Digest ist für externe oder mobile Benutzer normalerweise unbrauchbar. Umgekehrt ist eine öffentliche Adresse kein Grund, das User Portal pauschal für jedes WAN-Netz freizugeben. Portalzweck und Device Access werden unter Sophos Firewall Portale im Überblick getrennt erklärt.

Sophos warnt vor einer Freigabe des User Portals aus der WAN-Zone. Externe Benutzer greifen deshalb zuerst über eine sichere Anbindung wie VPN zu; der Digest allein rechtfertigt keine WAN-Freigabe. Bei extern authentifizierten Konten gehört zudem die einmalige Anmeldung am Captive Portal vor der ersten User-Portal-Nutzung zum Pilotversuch.

Das User Portal ist ein lokaler Dienst. Sein Zugriff wird unter Administration > Device access und nicht mit einer normalen Firewallregel gesteuert. Für einen engeren Zugriff auf bestimmte Hosts oder Netze werden Local service ACL exception rules verwendet. Prüfen muss man zusätzlich den Webproxy: HTTP- und HTTPS-Anfragen über den Proxy der Firewall behandelt SFOS als intern. Dadurch kann das User Portal trotz deaktivierter Freigabe für die Ursprungszone erreichbar sein. Proxy-Nutzung und Proxy-Regeln gehören daher in denselben Zugriffstest.

Digest konfigurieren

Unter Email > Quarantine settings wird Enable quarantine digest aktiviert. Danach werden die gewünschte Versandfrequenz, der Zeitpunkt und gegebenenfalls der Wochentag festgelegt. Als From email address gehört eine gültige Absenderadresse hinein; Display name sollte den Absender für Benutzer eindeutig als Firewall-Quarantäne kennzeichnen.

Unter Release link settings wird anschliessend die vorbereitete Portaladresse gewählt. Mit Send test email wird eine Testnachricht gesendet; nach deren Empfang werden die Einstellungen mit Apply gespeichert. Für die Benutzerabnahme reicht diese Nachricht nicht: Erst der vollständige Weg mit einem zugewiesenen Pilotbenutzer bestätigt Zeitplan, Zuordnung, Portal-Anmeldung und Freigabe.

Pilotbeispiel mit anpassbaren Werten

Ein anpassbares Pilotbeispiel ist Email frequency: Daily um 10:00, From email address: firewall@example.com und Display name: Firewall Quarantine. Daily und die Feldnamen sind UI-Werte; Uhrzeit, Absender und Anzeigename werden für die eigene Umgebung gewählt. 10:00 erlaubt eine Prüfung während der Arbeitszeit, ist aber keine Produktvorgabe. Die Beispieldomain durch eine zulässige eigene Absenderdomain ersetzen. Für Skip address patterns kann man im MTA Mode beispielsweise sales@example.com mit + hinzufügen, wenn dieser gemeinsame Alias bewusst nicht im Digest erscheinen soll. Danach prüfen, dass seine Nachrichten weiterhin in SMTP quarantine, aber nicht im Digest stehen.

XML-Zeitplan und Benutzerlisten richtig lesen

Bei XML-Automatisierung trennt AntiSpamQuarantineDigestSettings die globale Konfiguration in SpamDigestSettings von den Benutzerzuweisungen in SpamDigestUsers. EmailFrequency verwendet Hourly, Day oder Week; das UI-Beispiel Daily entspricht dabei Day. Die Felder unter SpamDigestSettings > SendEmailAt hängen von dieser Wahl ab:

• Hourly: Hour beschreibt laut Referenz das Intervall in Stunden, nicht eine tägliche Versandzeit.
• Day: Hour und Minute bestimmen die tägliche Versandzeit. Das Pilotbeispiel 10:00 entspricht Hour = 10 und Minute = 0.
• Week: Hour und Minute bestimmen die Versandzeit, wiederholte Days-Einträge die ausgewählten Wochentage.

Die Referenz nennt den Bereich 0–23 für Hour und 0–59 für Minute. Ihre wiederholten, als Pflichtfeld markierten Hour-/Minute-Zeilen beschreiben unterschiedliche Frequenzkontexte: Sie sind keine Aufforderung, alle Varianten gleichzeitig einzutragen. Aus dem dokumentierten Bereich allein folgt auch keine verifizierte Bedeutung eines stündlichen Intervalls von 0.

⚠️ Die XML-Referenzen für SFOS 22/23 widersprechen sich beim Samstag innerhalb derselben Seite: Das Beispiel enthält Saturday, die Liste erlaubter Days-Werte lässt ihn aus. Das belegt weder Unterstützung noch ein Verbot von Samstag. Für einen benötigten Samstagslauf die Unterstützung auf dem installierten SFOS-Build mit Sophos Support klären, statt den Beispielwert ungeprüft zu übernehmen oder einen numerischen Ersatz zu erraten. Bis zur Klärung keinen produktiven Samstags-Zeitplan per XML ausrollen.

Unter SpamDigestUsers enthält EnableUsers wiederholte EnableUser-Einträge zum Aktivieren und DisableUsers wiederholte DisableUser-Einträge zum Deaktivieren des Digests für benannte Benutzerkonten. Die Werte sind Benutzernamen, keine Empfängeradressmuster; diese Listen sind daher nicht Skip address patterns. Für den Pilotversuch die vorhandenen Zuweisungen dokumentieren, widersprüchliche Einträge desselben Kontos vermeiden und danach die gespeicherten Benutzer- und Zeitplaneinstellungen sowie den tatsächlichen Digest-Lauf prüfen. Die Referenz klärt nicht alle Details zur Verarbeitung überlappender oder ausgelassener Listen; aus dem Beispiel keine Prioritäts- oder Ersetzungsregel ableiten. Diese Feldzuordnung ist noch kein vollständiger XML-Request.

Quarantänebereich und automatische Bereinigung

Im MTA Mode wird unter Quarantine area die Grösse des lokalen Quarantänebereichs gewählt. SFOS kontrolliert die Belegung alle fünf Minuten. Erreicht sie mindestens 90 Prozent der gewählten Grösse, werden ältere Nachrichten gelöscht, bis die Belegung auf 60 Prozent sinkt.

Diese automatische Bereinigung ist kein Archiv. Ein zu kleiner Bereich kann die verfügbare Zeit für Prüfung und Freigabe verkürzen; ein grosser Bereich verbraucht lokalen Speicher. Die Belegung zeigt Total utilization unter Email > SMTP quarantine. Den übrigen Speicherstatus ordnet Speicherplatz und Reports auf Sophos Firewall prüfen ein.

10 GB ist ein mögliches Konfigurationsbeispiel, kein Standardwert oder zugesicherter Aufbewahrungszeitraum. Die Grösse anhand von Mailvolumen, freiem Speicher und benötigter Prüfzeit wählen und die Belegung im Pilotbetrieb beobachten. Bereits automatisch bereinigte oder mit Delete entfernte Nachrichten kommen durch eine spätere Vergrösserung nicht zurück.

Skip address patterns im MTA Mode

Im MTA Mode unter Skip address patterns jede Empfänger-E-Mail-Adresse eingeben, deren quarantänisierte Nachrichten aus dem Quarantäne-Digest ausgeschlossen werden sollen, und anschliessend auf die Plus-Schaltfläche + klicken, um die jeweilige Adresse zur Liste hinzuzufügen. Adressen unter Skip address patterns werden aus dem Quarantäne-Digest ausgeschlossen. Das ist beispielsweise für gemeinsam genutzte Aliasse sinnvoll, deren Spam nicht an viele Benutzer verteilt werden soll. Die Einstellung löscht jedoch keine Nachricht und ist keine Ausnahme von Spam-, Malware- oder Data-Protection-Prüfungen.

Benutzern und Gruppen zuweisen

Die globale Digest-Konfiguration allein aktiviert den Versand noch nicht für alle Benutzer. Unter Authentication > Groups oder Authentication > Users wird Quarantine digest für die vorgesehenen Konten auf Enable gesetzt und mit Save gespeichert. Alternativ lässt sich die Zuweisung direkt unter Email > Quarantine settings > Change user’s quarantine digest settings vornehmen. Eine Einstellung am einzelnen Benutzer hat Vorrang vor der Gruppenebene; bei einem unerwarteten Ergebnis werden daher beide Ebenen geprüft.

Für eine gebündelte Zuweisung öffnet man Email > Quarantine settings > Change user’s quarantine digest settings, filtert bei Bedarf nach Group und wählt die vorgesehenen Benutzer aus. Muss dort die E-Mail-Adresse eines einzelnen Benutzers korrigiert werden, wird sie über Edit geändert und mit Save gespeichert. Anschliessend wird die Zuweisung mit Apply abgeschlossen. Primäradresse und bewusst zugewiesene Aliasse werden danach mit dem betroffenen Benutzerkonto abgeglichen.

Bei Alias-Adressen sind zwei Grenzen wichtig. Standardmässig wendet SFOS die Digest-Einstellung nicht automatisch auf Aliasse an; sie müssen zusammen mit der primären E-Mail-Adresse am Benutzer hinterlegt oder gezielt zugewiesen werden. Der Digest kann dann Spam für primäre und Alias-Adressen aufführen. Im User Portal werden quarantänisierte Nachrichten an Alias-Adressen laut Sophos trotzdem nicht angezeigt. Für solche Adressen braucht es deshalb einen klaren administrativen Freigabeprozess unter Email > SMTP quarantine.

Nachrichten im User Portal bearbeiten

Nach dem Digest-Link meldet sich der Benutzer am User Portal an und öffnet Quarantine mit der SMTP-Quarantäne. Der Link selbst gibt nichts frei. Dort sind nur Nachrichten an die eigene primäre E-Mail-Adresse sichtbar, nicht an Aliasse oder fremde Postfächer.

1. Die gesuchte Nachricht anhand von Datumsbereich, Absender und Betreff eingrenzen und bei Bedarf die angebotenen Filter verwenden.
2. Für eine einzelne Spam-Nachricht Release an der Nachricht wählen. Für mehrere Nachrichten die gewünschten Zeilen auswählen, Release aus den Aktionen wählen und Go anklicken.
3. Bei einem bestätigten False Positive der Einstufung Spam oder Probable Spam mit Release and report freigeben und an SophosLabs melden. Eine unerwünschte Nachricht lässt sich stattdessen mit Delete löschen. Vor beiden Aktionen Empfänger und Nachricht kontrollieren.

Nur quarantänisierter Spam kann vom Benutzer freigegeben werden. Virusinfizierte Nachrichten können weder freigegeben noch heruntergeladen werden. Die Firewall scannt freigegebene Nachrichten erneut und stellt sie anschliessend zu; für Alias-Nachrichten und andere Quarantänegründe bleibt der unten beschriebene administrative Prüfweg zuständig.

Benutzer-Ausnahmen für Absender kontrollieren

Im User Portal unter Exception kann ein berechtigter Benutzer einzelne Absenderadressen oder Wildcards wie *@example.com erlauben oder blockieren. Erlaubte Absender werden nicht als Spam markiert oder in die Spam-Quarantäne verschoben, die Antivirus-Prüfung bleibt jedoch aktiv. Steht dieselbe Adresse in beiden Listen, hat die Blockliste Vorrang und die Nachricht wird quarantänisiert. Diese benutzerspezifischen Ausnahmen gehören deshalb in den Pilot- und Supporttest und dürfen nicht mit den globalen Skip address patterns des Digests verwechselt werden.

Eine einzelne Absenderadresse ist enger als *@example.com. Vor einer Ausnahme die bisherigen Listeneinträge dokumentieren und den False Positive prüfen. Danach eine passende und eine nicht passende Testnachricht kontrollieren. Für den Rückweg die Listen auf den dokumentierten Stand zurücksetzen und die erwartete Spam-Einstufung erneut prüfen; bereits zugestellte Nachrichten werden dadurch nicht zurückgeholt.

Den vollständigen Freigabeweg testen

Für die Abnahme wird ein Pilotbenutzer verwendet, der sich bereits einmal an der Firewall authentifiziert hat. Eine kontrollierte Nachricht muss durch die erwartete SMTP-Policy als Spam quarantänisiert werden. Danach werden folgende Zustände geprüft:

1. Die Nachricht erscheint unter Email > SMTP quarantine mit erwartetem Empfänger, Betreff und Grund.
2. Der Pilotbenutzer erhält den Digest zur konfigurierten Zeit.
3. Absender, Anzeigename, Betreff und Metadaten entsprechen dem Datenschutz- und Betriebskonzept.
4. Der Release-Link öffnet den vorgesehenen User-Portal-FQDN mit gültiger Zertifikatskette.
5. Die Anmeldung funktioniert aus einem erlaubten Netz und scheitert aus einem nicht vorgesehenen Netz. Wird ein expliziter Webproxy eingesetzt, wird der Negativtest einmal ohne und einmal mit Proxy wiederholt.
6. Die zulässige Testnachricht lässt sich nach der Anmeldung freigeben und wird tatsächlich zugestellt.
7. Ein Benutzer ohne Digest-Zuweisung erhält keinen Bericht.

Im User Portal sieht ein Benutzer die quarantänisierten Nachrichten an seine primäre E-Mail-Adresse, kann dort aber nur Spam freigeben. SFOS scannt eine freigegebene Nachricht erneut und stellt sie anschliessend zu. Für Alias-Adressen und andere Quarantänegründe wird der administrative Weg unter Email > SMTP quarantine verwendet. Dort kann man gefilterte Nachrichten freigeben oder löschen und bei Spam beziehungsweise Probable spam mit Release and report einen False Positive an SophosLabs melden. Virusinfizierte Nachrichten und E-Mails, die Zero-Day Protection als bösartig bewertet hat, lassen sich auch administrativ nicht freigeben.

Fehler systematisch eingrenzen

Administrative Quarantäne gezielt filtern

Für Alias-Nachrichten oder eine administrative Prüfung Email > SMTP quarantine öffnen. Mit Start and end dates den Verarbeitungszeitraum eingrenzen und unter Sender/Recipient/Subject passende Suchbegriffe setzen. Zuerst Empfänger, Betreff und Quarantänegrund prüfen, bevor Release, Release and report oder Delete auf die gefilterten Nachrichten angewendet werden. Ein zu breiter Filter kann ungewollt andere Nachrichten einschliessen.

Filter by unterscheidet sich nach Mailmodus:

• MTA Mode: Blocked by RBL, Spam, Analyzed by Zero-day protection, Infected, Unscannable content or protected attachment, DKIM verification, Other.
• Legacy Mode: Blocked source IP, Blocked destination IP, Unscannable content or protected attachment, Oversized message, Blocked header, Blocked by RBL, Blocked by data protection, Spam, Infected, Other.

Der Filtergrund ist keine Freigabeerlaubnis: Virusinfizierte oder von Zero-Day Protection als bösartig bewertete Nachrichten bleiben nicht freigebbar. Zum Löschen von Nachrichten aus der Zero-Day-Protection-Analyse benötigt das Adminprofil Lese- und Schreibrechte für Zero-day protection activity. Bei fehlender Aktion zuerst Grund und Profil prüfen, statt Schutzfunktionen zu deaktivieren. Nach einer zulässigen Freigabe die tatsächliche Zustellung kontrollieren; Delete ist kein rückgängig machbarer Test.

Die Testmail kommt nicht an

Zuerst Administration > Notification settings prüfen. Send test email scheitert vor der eigentlichen Quarantänefunktion, wenn DNS, Route, Mailserver, Authentifizierung, TLS, Absender oder Empfänger nicht stimmen. Es ist nicht sinnvoll, Benutzerzuweisungen oder Quarantänegrösse zu ändern, solange der Mailtransport selbst nicht funktioniert.

Die Testmail kommt an, aber kein Benutzerdigest

Prüfen, ob Enable quarantine digest aktiv ist, die Änderung mit Apply gespeichert wurde, Zeitplan und Zeitzone stimmen und das betroffene Konto unter Groups, Users oder Change user’s quarantine digest settings aktiviert wurde. Eine Benutzereinstellung kann die Gruppenwahl übersteuern. Der Benutzer muss sich mindestens einmal an der Firewall authentifiziert haben. Ausserdem muss im gewählten Zeitraum tatsächlich eine passende Spam-Nachricht für diesen Empfänger in der Quarantäne liegen.

Der Release-Link zeigt auf die falsche Adresse

Release link settings, das ausgewählte Interface, User-Portal-Port sowie Admin console and end-user interaction abgleichen. Danach DNS-Auflösung, Zertifikatsname und Erreichbarkeit aus dem echten Benutzernetz testen. Die Adresse wird nicht durch wiederholtes Senden der Testmail korrigiert; zuerst muss die zugrunde liegende Portalreferenz stimmen.

Freigegebene Nachrichten bleiben im Mail-Spool

Eine Freigabe ist noch kein Zustellnachweis. Unter Email > Mail spool und Email > Mail logs Nachricht und Zeitpunkt abgleichen. Matcht eine neue Regel oberhalb der vorgesehenen SMTP-Regel bereits den SMTP-Verkehr, wertet SFOS die darunterliegende Regel nicht mehr aus. Das betrifft etwa automatisch erstellte IPsec- oder Hotspot-Regeln und manuelle Regeln mit Rule position: Top.

Vor einer Änderung die Regelreihenfolge und betroffenen Verbindungen sichern. Unter Rules and policies > Firewall rules nur die als Ursache bestätigte neue überlagernde Regel so weit nach unten verschieben, dass die vorgesehene SMTP-Regel wieder ausgewertet wird; die automatische MTA-Regel nicht editieren. Danach eine kontrollierte Nachricht bis zur tatsächlichen Zustellung verfolgen, den Spool prüfen und andere betroffene Verbindungen testen. Bei Nebenwirkungen die gesicherte Reihenfolge wiederherstellen. Ohne bestätigten SMTP-Match nicht blind Regeln verschieben; Zielserver, DNS, Route und TLS nach dem verlinkten MTA-Runbook prüfen und bei weiterem Fehler den Befund an den Support geben.

Alias-Nachrichten fehlen im Portal

Das ist nicht automatisch ein Fehler des Digests. Sophos dokumentiert ausdrücklich, dass quarantänisierte Nachrichten an Alias-Adressen nicht im User Portal erscheinen. Primäradresse, Alias-Zuweisung, Digest-Inhalt und administrative SMTP-Quarantäne werden deshalb getrennt geprüft.

Betrieb und Rollback

Digest-Mails enthalten Kommunikationsmetadaten und können ausserhalb der Firewall in Postfächern, Archiven oder Tickets weiterbestehen. Der Empfängerkreis sollte klein bleiben, die Mailbox-Aufbewahrung zum Schutzbedarf passen und ein gemeinsam genutzter Alias nur bewusst in Berichten erscheinen.

Vor dem Rollback werden globaler Digest-Status, Zeitplan, Release-Link, Benutzer- und Gruppenzuweisungen sowie gemeinsam genutzte Portal- und Notification-Einstellungen dokumentiert. Für die Prüfung wird je eine kontrollierte Spam-Nachricht an den Pilotbenutzer und an einen weiterhin aktivierten Kontrollbenutzer gesendet und unter Email > SMTP quarantine bestätigt. Anschliessend wird Enable quarantine digest deaktiviert oder die Zuweisung beim Pilotbenutzer zurückgenommen und jeweils mit Apply (Email) / Save (Authentication) gespeichert.

Nach dem nächsten geplanten Digest-Lauf darf der Pilotbenutzer keinen Bericht erhalten. Wird nur seine Zuweisung zurückgenommen, bestätigt der Digest des Kontrollbenutzers, dass der Lauf stattgefunden hat. Portal- oder Notification-Einstellungen werden nur zurückgebaut, wenn kein anderer Dienst sie verwendet. Die Quarantäne selbst bleibt unabhängig vom Digest bestehen und wird nicht als Teil des Rollbacks gelöscht.