Sophos Firewall Mail Protection im Legacy Mode einrichten

Im Legacy Mode arbeitet Sophos Firewall als transparenter Mail-Proxy. Der interne Mailserver bleibt der eigentliche SMTP-Endpunkt; die Firewall leitet den Verkehr über bestehende Firewall- und NAT-Regeln weiter und prüft ihn dabei auf Spam, Malware, Dateitypen oder Data-Control-Treffer.

Das unterscheidet den Legacy Mode grundlegend vom MTA Mode. Die Firewall wird nicht zum eigenen Mail Transfer Agent, übernimmt keine Mailzustellung über geschützte Domains und bietet für diesen Pfad keinen MTA-Mail-Spool. Ein grüner SMTP-Porttest beweist deshalb weder den Proxy-Scan noch die richtige Policy.

⚠️ Der Wechsel des SMTP Deployment Mode ist eine globale Änderung am Mail-Schutzpfad. Vor dem Umschalten müssen Backup, vorhandene Policies, Firewall- und NAT-Regeln sowie ein getesteter Rückweg dokumentiert sein. Ein MTA-Problem ist kein Grund, ungeplant auf Legacy Mode umzuschalten.

Legacy Mode in neun Schritten

1. Bestehenden eingehenden und ausgehenden SMTP-Pfad mit IP-Adressen, Ports, NAT und Firewall Rule IDs dokumentieren.
2. Prüfen, ob transparenter Proxy-Betrieb wirklich besser passt als der MTA Mode.
3. Konfigurationsbackup und unabhängigen Managementzugang sichern.
4. Unter Email > General settings auf Switch to legacy mode wechseln.
5. SMTP-Grössenlimit, Oversize-Aktion, IP Reputation, DoS-Grenzen und TLS-Verhalten festlegen.
6. Nur die benötigten SMTP-Malware- und SMTP-Spam-Policies erstellen beziehungsweise deren Reihenfolge prüfen.
7. Eingehende DNAT- und ausgehende SNAT-Pfade eng auf den realen Mailserver begrenzen.
8. In den tatsächlich getroffenen Firewall-Regeln Scan SMTP beziehungsweise Scan SMTPS aktivieren.
9. Eingehende und ausgehende Testmails mit Rule ID, Policy-Ergebnis, Zertifikat und Legacy-Proxy-Logs abnehmen.

Legacy Mode oder MTA Mode wählen

Legacy Mode passt vor allem zu Bestandsumgebungen, in denen der interne Mailserver bereits direkt über NAT veröffentlicht ist und dieser Pfad beibehalten werden soll. SFOS sitzt dabei transparent zwischen Gegenstelle und Server. MX-Ziel, SMTP-Annahme und Zustelllogik bleiben beim vorhandenen Mailserverdesign.

MTA Mode ist dagegen die passendere Wahl, wenn die Firewall E-Mails selbst annehmen, nach geschützten Domains routen, relayen und bei temporären Zustellfehlern im Spool halten soll. Mail logs und Mail spool gehören ausdrücklich zu diesem Betriebsmodell. Der vollständige Aufbau steht unter Mail Protection im MTA Mode einrichten.

Bei XGS 87/87w und XGS 88/88w ist MTA Mode laut SFOS-22-Hilfe nicht verfügbar. Das macht Legacy Mode aber nicht automatisch zu einer guten Cloud-Mail-Architektur. Microsoft 365, Google Workspace und moderne gehostete Dienste verwenden eigene TLS-, Authentifizierungs- und Anti-Abuse-Vorgaben. Vor einem transparenten Proxy muss deren Unterstützung geklärt werden.

Kurz gesagt: MTA Mode besitzt einen eigenen Mailflow. Legacy Mode schützt einen bereits funktionierenden SMTP-Pfad. Wer diese beiden Modelle vermischt, sucht später im falschen Log, am falschen NAT-Ziel oder in einem nicht vorhandenen Spool.

Beispieltopologie und Rückfallweg

Das folgende Beispiel verwendet Dokumentationswerte und wird vor der Umsetzung an die reale Umgebung angepasst:

• interner Mailserver 10.20.30.25 in der Zone DMZ
• öffentliche SMTP-Adresse 192.0.2.25 am WAN-Pfad
• eingehender SMTP-Dienst TCP 25
• optional SMTPS auf TCP 465, nur wenn Gegenstellen und Server diese Variante tatsächlich verwenden
• Firewall-Regeln SMTP_In_Legacy und SMTP_Out_Legacy

192.0.2.25 gehört zum TEST-NET-Bereich und ist kein produktiver Wert. Vor der Änderung werden ein externer Eingangstest und ein ausgehender Test mit Zeitstempel durchgeführt. Die aktuell getroffenen Rule IDs, die öffentliche Quelladresse des ausgehenden Servers und die Zertifikatskette werden gesichert.

Der Rückfallweg besteht nicht nur aus dem Zurückschalten des Modus. Auch neue Scanoptionen, Policy-Reihenfolge, DNAT, reflexive oder manuelle SNAT-Regeln und temporäre Tests müssen auf den dokumentierten Vorzustand zurückgesetzt werden können.

Globale SMTP-Einstellungen festlegen

Grössenlimit, Oversize-Aktion und DoS-Schutz

Unter Email > General settings > SMTP settings legt Don’t scan emails greater than die maximale Nachrichtengrösse für den Scan fest. Der Wert 0 bedeutet im SMTP-Pfad laut SFOS-22-Hilfe 51,200 KB, nicht unbegrenzt. Für grössere Nachrichten stehen Accept, Reject und Drop zur Verfügung.

Accept stellt eine zu grosse Nachricht ohne Scan zu. Reject lehnt sie ab und informiert den Absender, Drop verwirft sie ohne Benachrichtigung. Diese Wahl ist eine bewusste Risiko- und Betriebsentscheidung. Ein ungeprüftes Drop erschwert die Fehlersuche; ein ungeprüftes Accept erzeugt eine dokumentationspflichtige Scan-Lücke.

Verify sender’s IP reputation prüft die Absender-IP vor den Spamkriterien der SMTP-Policy. Die SMTP-DoS-Werte begrenzen Verbindungen, Nachrichten und Empfänger. Produktive Grenzwerte werden aus dem realen Mailvolumen und einer Baseline abgeleitet, nicht aus einem pauschalen Internetbeispiel übernommen.

Bypass spam check for SMTP/S authenticated connections überspringt den Spamcheck global für Verbindungen, die der Mailserver als authentifiziert meldet. Das ist nur vertretbar, wenn Authentisierung, erlaubte Quellen und Missbrauchsschutz dieses Pfads geprüft sind. Ein erfolgreicher Login ersetzt weder Malware-Scan noch einen Negativtest mit einer nicht authentifizierten Verbindung. Unter Spam check exceptions eingetragene Domains sind ebenfalls ein globaler Bypass und werden nicht als schneller Ersatz für eine eng begrenzte Ausnahme verwendet.

Der globale E-Mail-Banner bietet Inline, no conversion, MIME part und Off. Er erscheint nur, wenn SMTP- beziehungsweise SMTPS-Scanning in der getroffenen Firewall-Regel aktiv ist. Da die Änderung am Body eine bereits vorhandene DKIM-Signatur brechen kann, wird der reale ausgehende Pfad mit Headerprüfung beim Empfänger abgenommen.

TLS nicht durch eine Checkbox überschätzen

Unter SMTP TLS configuration wird das für den Scan vorgesehene CA- oder Serverzertifikat gewählt. Allow invalid certificate bleibt deaktiviert. Disable legacy TLS protocols schaltet laut Hilfe nur Protokolle vor TLS 1.1 ab und beweist keine konkrete TLS-1.2- oder TLS-1.3-Sitzung.

Sophos weist zudem auf eine wichtige Legacy-Grenze hin: Die Firewall baut die TLS-Verbindung anhand der Domain-IP statt des Domainnamens auf. Teilen sich mehrere Domains dieselbe IP-Adresse, kann die Zertifikatsprüfung scheitern. In diesem Fall empfiehlt Sophos einen anderen Schutzpfad wie Sophos Email Security. Die Prüfung wird nicht mit Allow invalid certificate umgangen.

Require TLS negotiation erzwingt TLS für ausgewählte Remote Hosts oder Netze; Require sender email domains erzwingt es für Absenderdomains. Kann die TLS-Verbindung dann nicht aufgebaut werden, verwirft SFOS die betroffenen E-Mails. Skip TLS negotiation erlaubt bewusst unverschlüsselte SMTP-Verbindungen zu den ausgewählten Gegenstellen und gehört nur in dokumentierte Ausnahmefälle.

Scan-Policies bewusst einsetzen

Nach Aktivierung der Email-Protection-Subscription wendet Sophos Firewall im Legacy Mode die Standardpolicy default-smtp-av automatisch auf SMTP-Traffic an. Eigene Policies werden unter Email > Policies angelegt und in Listenreihenfolge verarbeitet. Deshalb wird zuerst geprüft, welche vorhandene Policy den konkreten Absender und Empfänger trifft.

SMTP malware scan

Eine SMTP malware scan Policy steuert blockierte Dateitypen, MIME-Ausnahmen, Antivirus-Scan und Zustellaktionen. Bei Single antivirus gilt die gewählte Engine laut Hilfe nur für eingehende Nachrichten; ausgehende Nachrichten werden mit beiden Engines geprüft. Dual antivirus lässt primäre und sekundäre Engine nacheinander scannen.

Die Aktion Quarantine wird mit den Empfänger- und Administratoraktionen kombiniert. Don’t deliver, Deliver original und Remove and deliver haben deutlich unterschiedliche Folgen. Eine geschützte oder nicht scannbare Anlage wird nicht automatisch als Malware gleichgesetzt. Jede Aktion braucht deshalb eine Testmail, einen erwarteten Empfängerzustand und einen dokumentierten Freigabeweg.

Quarantine bedeutet nicht automatisch, dass der Empfänger keine Nachricht erhält; die Delivery option for recipient bleibt entscheidend. Notify sender funktioniert laut Sophos nur zusammen mit Don’t deliver. Geschützte Anhänge werden nicht gescannt, können aber weiterhin eine Benachrichtigung auslösen. Die separate Administratoraktion entscheidet, ob keine Kopie, das Original oder eine Nachricht ohne Anlage an die Administratoren geht. Diese vier Ergebnisse werden nicht mit einer einzigen erfolgreichen Testmail gleichgesetzt.

SMTP spam scan

Eine SMTP spam scan Policy kann unter anderem auf Spamklassifizierung, Source oder Destination, RBL, Nachrichtengrösse, Header oder eine Data Control List reagieren. Als Aktionen stehen je nach Pfad Reject, Accept, Change recipient, Prefix subject, Drop und Quarantine zur Verfügung.

Die Kriterien Data control list und die SPX-Zuweisung gelten in dieser Policy nur für ausgehende Nachrichten. None wendet die gewählte Aktion dagegen auf alle Nachrichten zwischen den festgelegten Absender- und Empfängergruppen an. Change recipient liefert nicht zusätzlich an den ursprünglichen Empfänger, sondern ersetzt ihn durch das konfigurierte Ziel. Diese drei Reichweiten werden vor der produktiven Policy-Reihenfolge mit einem positiven und einem negativen Empfängerfall geprüft.

Eigene Dateitypen und Data Control vorbereiten

Eigene Dateitypen werden im Legacy Mode unter Email > Policies > File type > Add aus einer Vorlage oder aus Dateiendungen beziehungsweise MIME-Typen erstellt. Dateiendungen werden ohne führenden Punkt eingetragen; nur eigene Typen sind editierbar. Ein neuer Typ ergänzt bestehende Policies nicht automatisch. Die betroffene Scan-Policy muss danach geöffnet, um den Dateityp ergänzt und erneut gespeichert werden. Ein positiver und ein ähnlicher negativer Anhangstest zeigen, ob wirklich die vorgesehene Policy-Aktion greift.

Eine Data Control List wird unter Email > Data control list > Add aus den benötigten Content Control Lists aufgebaut. Die Filter Type und Region helfen, nur passende Finanz-, Identitäts- oder andere sensible Datenmuster auszuwählen. Der Listenmatch bestimmt noch keine Aktion; diese wird in der verknüpften Scan-Policy festgelegt. Eine kleine Pilotliste mit positivem und negativem Inhaltstest ist deshalb sicherer als eine breite Sammlung ungeprüfter CCLs.

SPX kann im Legacy Mode über diese Policy für ausgehende Nachrichten ausgewählt werden. Passwortmodell, Portal und Abnahme sind jedoch ein eigener Sicherheitsablauf; dafür dient SPX E-Mail-Verschlüsselung einrichten. Eine Data Control List oder SPX-Zuweisung wird nicht in den ersten reinen Proxytest aufgenommen.

Eine bestätigte Fehlklassifizierung wird nicht mit einer breiten Policy abgeschaltet. Wie einzelne Prüfungen für eine genaue Quell-, Absender- und Empfängerkombination übersprungen und danach negativ getestet werden, erklärt E-Mail-Ausnahmen sicher anlegen und testen.

Optionales Email Journaling datenschutzkonform einsetzen

Unter Email > General settings > Email journaling > Add kann SFOS Kopien der eingehenden SMTP/S-Nachrichten ausgewählter Empfänger oder Adressgruppen an eine separate Journaladresse senden. Die Auswahl Any erfasst alle eingehenden Nachrichten. Die Funktion gilt nur für SMTP/S; POP- und IMAP-Verkehr wird damit nicht journalisiert.

Journaling erzeugt eine zusätzliche E-Mail-Kopie. Es ist weder automatisch ein manipulationssicheres Archiv noch ein Nachweis, dass gesetzliche Aufbewahrungspflichten erfüllt sind. Vor der Aktivierung werden Zweck, berechtigte Empfänger, Zugriff auf das Journalpostfach, Verschlüsselung, Aufbewahrungsdauer, Speicherbedarf und verantwortlicher Owner festgelegt.

Für den ersten Test wird ein einzelnes Testpostfach statt Any gewählt. Eine eingehende Nachricht an dieses Postfach muss im normalen Ziel und im Journalpostfach erscheinen; eine Nachricht an einen nicht erfassten Empfänger darf keine Journal-Kopie erzeugen. Die Journaladresse darf keinen Mailflow auslösen, der die Kopie erneut an SFOS zurückführt und eine Schleife erzeugt.

Erst nach dem Positiv- und Negativtest wird die Empfängerauswahl bei Bedarf erweitert. Beim Rollback wird der Journal-Eintrag entfernt oder auf den dokumentierten Vorzustand gesetzt. Bereits zugestellte Kopien bleiben im Journalpostfach und müssen nach dessen eigenen Aufbewahrungsregeln behandelt werden.

NAT und Firewall-Regeln zusammenführen

Eingehenden SMTP-Pfad veröffentlichen

Für eingehende E-Mails übersetzt eine DNAT-Regel die öffentliche WAN-Adresse auf den internen Mailserver. Original Source wird so eng begrenzt, wie es das Maildesign erlaubt; Original Destination ist die vorgesehene öffentliche Adresse; Translated Destination ist 10.20.30.25 beziehungsweise der echte Mailserver. Original und translated Service bleiben auf den tatsächlich angebotenen SMTP-Ports.

Eine reflexive Regel erzeugt zusätzlich SNAT für die Gegenrichtung. Sie wird nur gewählt, wenn genau diese öffentliche Quellidentität für den ausgehenden Pfad vorgesehen ist. Mehrere WAN-Links, Smarthosts oder abweichende Provider-Routen benötigen ein eigenes Routing- und SNAT-Design. Die allgemeine Reihenfolge und die Zielzone nach NAT erklärt Server per DNAT veröffentlichen.

Zwei enge Firewall-Regeln verwenden

Für die Abnahme sind getrennte Regeln verständlicher als eine bidirektionale Regel mit mehreren Zonen und Any-Objekten:

• Eingehend: WAN zur Zone des internen Mailservers, Zielhost 10.20.30.25, nur benötigte SMTP-Dienste, Logging aktiv
• Ausgehend: Zone und Host des internen Mailservers zu WAN oder zum konkreten Smarthost, nur benötigte SMTP-Dienste, Logging aktiv

Unter Scan email content werden in beiden tatsächlich benötigten Richtungen Scan SMTP und nur bei echtem SMTPS-Betrieb Scan SMTPS aktiviert. Die aktivierte Checkbox ergänzt keinen fehlenden Dienst automatisch in ein korrektes Sicherheitsdesign. Service, NAT, Serverlistener und Scanoption müssen denselben Portpfad beschreiben.

Die Regeln stehen oberhalb allgemeinerer Regeln, die denselben Traffic bereits matchen. Nach dem Speichern entscheidet die protokollierte Firewall Rule ID. Regelaufbau, NAT-Zone und Reihenfolge sind unter Sophos Firewall-Regeln sicher konfigurieren vertieft.

Mailflow und Proxy-Scan abnehmen

Zuerst wird eine kleine externe Nachricht an ein Testpostfach gesendet. Danach versendet der interne Mailserver eine zweite Nachricht an einen kontrollierten externen Empfänger. Beide Tests erhalten eindeutige Betreffe und UTC-Zeitstempel.

Für STARTTLS auf Port 25 und eine direkte TLS-Verbindung auf Port 465 helfen von einem zulässigen Testsystem folgende lesende Prüfungen:

openssl s_client -starttls smtp -connect mail.example.net:25 -servername mail.example.net
openssl s_client -connect mail.example.net:465 -servername mail.example.net

mail.example.net wird durch den echten FQDN ersetzt; nur tatsächlich angebotene Ports werden getestet. OpenSSL bestätigt Erreichbarkeit, Zertifikatskette und ausgehandelte TLS-Parameter. Es beweist weder erfolgreiche Mailzustellung noch Malware-, Spam- oder Data-Control-Scanning.

Im Log Viewer müssen Source, Destination, Service, Action und Firewall Rule ID zu den neuen Regeln passen. Für den Legacy SMTP/S Proxy werden awarrensmtp.log und awarrenmta.log mit demselben Zeitpunkt korreliert. Die Logdateien sind unter Sophos Firewall Services und Logs eingeordnet.

Anschliessend folgt ein negativer Test. Eine nicht vorgesehene Quelle, ein nicht freigegebener Port oder eine Testmail ohne Policy-Kriterium darf nicht versehentlich denselben Schutzpfad erhalten. Der produktive Test verwendet keine echte Malware; für die Scanabnahme werden etablierte harmlose Testmuster und ein kontrolliertes Postfach verwendet.

Fehler nach Symptom eingrenzen

SMTP funktioniert, aber die Policy greift nicht

Zuerst die Firewall Rule ID prüfen. Trifft eine andere Regel, sind Reihenfolge, Source, Destination, NAT-Ziel und Service zu korrigieren. Trifft die erwartete Regel, müssen Scan SMTP beziehungsweise Scan SMTPS, Policy-Reihenfolge sowie Absender- und Empfängergruppe zum Test passen. Eine Policy allein aktiviert den transparenten Proxy nicht.

Eingehende Mail erreicht den Server nicht

Öffentliche Zieladresse, DNAT-Hit, translated Destination, Zielzone, Serverlistener und Rückweg getrennt kontrollieren. Eine offene TCP-Verbindung bis zur Firewall beweist nicht, dass DNAT und Firewall-Regel den internen Server erreichen. Packet Capture und Rule ID müssen Eingang und Weiterleitung zeigen.

Ausgehende Mail verwendet die falsche öffentliche IP

SNAT, reflexive Regel, WAN-Gateway, SD-WAN-Route und Reply-Packet-Verhalten prüfen. Der Legacy Proxy wählt nicht automatisch die für SPF, RDNS oder Providerfreigabe gewünschte Quelladresse. Vor einer globalen Route-Precedence-Änderung wird der konkrete Pfad belegt.

TLS schlägt nach Aktivierung des Scans fehl

FQDN, Ziel-IP, Zertifikat, Aussteller, Kette und ausgehandelte Version erfassen. Bei mehreren Domains auf derselben IP kann die dokumentierte IP-basierte Zertifikatsprüfung die Ursache sein. Allow invalid certificate wird nicht als schneller Fix aktiviert.

Eine Nachricht fehlt und im MTA-Spool steht nichts

Das ist im Legacy Mode kein verwertbares Erfolgskriterium, weil Mail spool und die MTA-spezifischen Mail logs zum MTA Mode gehören. Firewall-Regel, NAT, SMTP-Serverlogs, Log Viewer, awarrensmtp.log und awarrenmta.log bilden hier die relevante Kette. Quarantänierte Nachrichten werden separat unter Email > SMTP quarantine geprüft.

Sicher zurückrollen

Für den Rollback werden zuerst die Pilotregeln und Scanoptionen auf den dokumentierten Vorzustand gesetzt. Danach werden neue Policy-Zuweisungen beziehungsweise deren Reihenfolge zurückgenommen. Temporäre DNAT-, SNAT- oder Zertifikatsänderungen werden nur entfernt, wenn kein anderer Dienst davon abhängt.

Erst dann wird der SMTP Deployment Mode zurückgestellt, falls der Change genau diesen Wechsel umfasste. Der ursprüngliche eingehende und ausgehende Mailflow muss wieder mit den erwarteten Rule IDs, öffentlichen Adressen und Serverlogs funktionieren. Nachrichten, Quarantäne oder Proxy-Logs werden nicht als Standard-Rollback gelöscht.

Betriebscheckliste

• Transparenter Proxy ist bewusst gewählt; MTA-Anforderungen wurden ausgeschlossen.
• Backup, Managementzugang und ursprüngliche Rule IDs sind dokumentiert.
• SMTP-Grössenlimit, Oversize-Aktion, IP Reputation und DoS-Grenzen sind begründet.
• Zertifikat, TLS-Ausnahmen und betroffene Domains sind geprüft.
• DNAT, SNAT, Zielzone und reale Serverports stimmen überein.
• Eingehende und ausgehende Firewall-Regel sind eng, geloggt und treffen nachweislich.
• Standard- und eigene Policies besitzen eine nachvollziehbare Reihenfolge.
• Optionales Journaling ist auf die benötigten Empfänger begrenzt und besitzt einen dokumentierten Datenschutz- und Aufbewahrungszweck.
• Positiv-, Negativ-, TLS- und Zustelltest sind bestanden.
• Legacy-Proxy-Logs und Mailserverlogs lassen sich zeitlich korrelieren.
• Owner, Review-Datum und vollständiger Rückfallweg sind festgehalten.

FAQ