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-Hostname, Grössenlimits, Oversize-Aktion, IP Reputation, DoS-Grenzen, Ports 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 Mail-Einstellungen festlegen

Wo MTA Mode verfügbar ist, nennt die Hilfe ihn als Standardmodus. Unter Email > General settings mit Switch to legacy mode gezielt umstellen; vorher den dokumentierten Rückfallweg sichern. Ein Moduswechsel allein erstellt keinen geprüften Legacy-Mailpfad.

Unter Email > General settings gilt SMTP hostname nur für systemgenerierte Benachrichtigungen in HELO- und SMTP-Banner-Strings; der Default lautet SMTP. Der Wert ersetzt weder den produktiven FQDN des Mailservers noch dessen öffentliches DNS. Wird er geändert, muss deshalb eine SFOS-Benachrichtigung und nicht nur eine normale Servermail geprüft werden.

XML-API-Prüfung: Die SFOS-23-Dokumentation führt für Email Configuration den Operationsstatus 506 mit Message.AVGeneralConfInvalidSmtpNtfyHostname auf. Das ist ein nicht aufgelöster Meldungsschlüssel, kein englischer Fehlertext und kein HTTP-Statuscode. Erscheint dieser Status in der tatsächlichen XML-API-Antwort, den übermittelten Benachrichtigungs-Hostnamen, die Operationsantwort und die gespeicherte Konfiguration prüfen, bevor die Änderung als erfolgreich gilt. Aus dem Schlüssel lassen sich keine konkreten Validierungsregeln ableiten. Der zusätzliche Dokumentationseintrag belegt weder eine Einführung des Verhaltens mit SFOS 23 noch eine Gültigkeit für REST.

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 und weist E-Mails von IP-Adressen mit schlechter Reputation ab. Die sechs SMTP-DoS-Felder haben in SFOS 22 folgende zulässige Bereiche:

• Maximum connections: 1 bis 20000 Verbindungen zum Mailserver
• Maximum connections/host: 1 bis 10000 Verbindungen eines Hosts
• Maximum emails/connection: 1 bis 1000 Nachrichten pro Verbindung
• Maximum recipients/email: 1 bis 256 Empfänger pro Nachricht
• Emails rate: 1 bis 20000 Nachrichten eines Hosts pro Minute
• Connections rate: 1 bis 20000 Verbindungen eines Hosts pro Sekunde

Zulässig bedeutet nicht automatisch passend. Produktive Grenzwerte werden aus dem realen Mailvolumen und einer Baseline abgeleitet, damit legitime Versandspitzen nicht wie ein DoS behandelt werden.

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.

POP/IMAP und Ports getrennt planen

POP/IMAP besitzt unter POP and IMAP TLS configuration eine eigene TLS certificate-Auswahl für die CA. Allow invalid certificate deaktiviert lassen, um ungültige Serverzertifikate abzuweisen; Disable legacy TLS protocols sperrt hier ebenfalls nur Protokolle vor TLS 1.1. SMTP-Einstellungen ersetzen diese Konfiguration nicht. Der vollständige Abrufpfad steht unter POP/IMAP-E-Mail-Scanning; CA- und Zertifikatsverwaltung unter Zertifikate verwalten.

Legacy Mode umfasst auch transparentes POP3/S- und IMAP/S-Scanning. Unter POP/S and IMAP/S settings bedeutet 0 bei Don’t scan emails greater than 10,240 KB. Die Recipient headers bestimmen, in welchen Headern SFOS Empfänger für POP/IMAP-Policies sucht; die Defaults sind Delivered-To, Received und X-RCPT-TO. Sie werden nur geändert, wenn ein aufgezeichneter Nachrichtenheader des eingesetzten Servers dies begründet.

Die dokumentierten Standardports sind SMTP 25, SMTPS 465, POP3 mit STARTTLS 110, POP3S 995, IMAP mit STARTTLS 143 und IMAPS 993. SFOS kann E-Mail-Scanning auch für andere Ports konfigurieren; Port 587 wird in der Hilfe ausdrücklich genannt. Ein alternativer Port gehört sowohl als Service in die passende Firewall-Regel als auch zum tatsächlich aktivierten Scanprotokoll. Ein Portwechsel allein macht aus implizitem TLS kein STARTTLS und umgekehrt.

Eine POP-IMAP scan Policy kann Absender- und Empfängergruppen mit Kriterien wie Eingangsklassifizierung, Quell-IP, Nachrichtengrösse oder Header verknüpfen. Als Aktionen stehen hier nur Accept und Prefix subject zur Verfügung. Die Policy aktiviert den Proxy nicht selbst: In der passenden Firewall-Regel muss unter Scan email content zusätzlich das tatsächlich verwendete POP3-, POP3S-, IMAP- oder IMAPS-Protokoll ausgewählt sein.

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. Jedes dieser Felder nimmt laut Hilfe höchstens 512 Hosteinträge auf; vor breiten Listen werden Überschneidungen zwischen Erzwingen und Überspringen ausgeschlossen.

Scan-Policies bewusst einsetzen

Ohne gültige Email Protection-Subscription kann Mailtraffic weiterhin erlaubt sein, erhält aber keinen Email-Protection-Schutz. Erreichbarkeit ist deshalb kein Lizenz- oder Scannachweis. Globale E-Mail-Einstellungen werden vor SMTP- und POP-IMAP-Policies verarbeitet. IP Reputation unter Email > General settings > SMTP settings im Legacy Mode mit Verify sender’s IP reputation aktivieren und mit Apply speichern; der MTA-Schalter heisst dagegen Reject based on IP reputation. Der globale ausgehende E-Mail-Banner unterstützt nur Text.

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.

Neue Legacy-SMTP-Policies unter Email > Policies > Add policy mit SMTP malware scan oder SMTP spam scan erstellen. Für eine bestehende Policy unter Email > Policies bei der betreffenden Policy Edit wählen, die benötigten Einstellungen ändern und die Policy anschliessend speichern. Danach die Policy-Reihenfolge prüfen und den Positiv- sowie den Negativtest wiederholen.

Unter Email > General settings > Malware protection wird die primäre Antivirus-Engine global als Sophos oder Avira gewählt. Wird Avira verwendet, schaltet SFOS Zero-day Protection in SMTP-Policies mit Single antivirus aus. Vor einem Engine-Wechsel werden deshalb alle betroffenen Single-Antivirus-Policies inventarisiert und nach dem Wechsel erneut geprüft.

SMTP malware scan

Beim Anlegen einen eindeutigen Namen sowie die E-Mail-Adress- oder Domaingruppen für Absender und Empfänger festlegen. Unter Block file types die zu sperrenden Anhänge wählen; mehrere Typen lassen sich mit Ctrl+Shift auswählen. MIME whitelist erlaubt die gewählten MIME-Header, während die übrigen Dateitypen laut Hilfe blockiert werden. Diese Dateityp-Freigabe ist kein Antivirus-Bypass. Disable bedeutet dagegen ausdrücklich, dass E-Mails nicht gescannt werden.

Die Delivery option for recipient gilt für infizierte, geschützte und verdächtige Anhänge:

• Don’t deliver: weder Nachricht noch Benachrichtigung an den Empfänger.
• Deliver original: ursprüngliche Nachricht an den Empfänger; diese Wahl ist keine Bereinigung.
• Remove and deliver: infizierten Anhang entfernen, über die Entfernung benachrichtigen und die Nachricht zustellen. Diese Aktion gilt nicht für die unter Block file types festgelegten Dateitypen; daraus lässt sich keine andere Zustellaktion für blockierte Typen ableiten.

Geschützte Anhänge bleiben ungeprüft; standardmässig wird der Empfänger benachrichtigt, sofern nicht anders konfiguriert. Nach der Konfiguration mit Save speichern und die tatsächlichen Zustell- und Benachrichtigungsergebnisse mit harmlosen Positiv- und Negativfällen prüfen.

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.

⚠️ Die Zustellzuordnung der Administratoroption Remove attachment ist nicht abschliessend geklärt. Die obige Zusammenfassung ist für diese Option keine freigegebene Zustellanweisung. Vor produktivem Einsatz Empfängerziel und Administratorbenachrichtigung unabhängig klären; nicht aus den Empfängeraktionen auf die Administratoraktion schliessen.

SMTP spam scan

Einen Namen und die E-Mail-Adress- oder Domaingruppen für Absender und Empfänger festlegen. Für diese Gruppen bewusst exakten Match oder Keyword-Match wählen: Eine Stichwortsuche darf nicht unbeabsichtigt den Geltungsbereich erweitern. Keine nicht belegte Regex-, Wildcard- oder AND/OR-Syntax voraussetzen.

• Inbound email is und Outbound email is: Richtung getrennt wählen; Kriterien sind Spam, probable spam, virus outbreak oder probable virus outbreak.
• Source IP/network address und Destination IP/network address: benötigte Absender- beziehungsweise Empfänger-IP oder das Netz angeben.
• Sender remote blacklist: die passende RBL-Gruppe für den Absender wählen.
• Message size: obere oder untere Grössengrenze festlegen, nicht mit dem globalen Oversize-Limit verwechseln.
• Message header: Header wählen; bei Other die Details eintragen, exakten oder Keyword-Match wählen und den Keyword-Wert festlegen.

Reject weist die Nachricht ab und informiert den Absender. Accept stellt sie zu. Prefix subject ergänzt den Betreff und stellt ebenfalls zu; etwa kennzeichnet ein Präfix Probable spam einen kontrollierten Test. Drop verwirft ohne Absenderbenachrichtigung, Quarantine hält die Nachricht in Quarantäne. Für Accept und Prefix subject ist die SPX-Template-Auswahl dokumentiert, ausschliesslich für ausgehende E-Mails. Daraus folgt weder SPX-Unterstützung für jede andere Aktion noch eine automatische Verschlüsselung jeder akzeptierten Nachricht. Mit Save speichern und Match sowie Aktion getrennt prüfen.

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

Beim eigenen Dateityp einen Namen vergeben und das Objekt mit Save speichern, bevor die Policy angepasst wird. Der separate MTA-Anlegepfad lautet Email > Policies and exceptions > File type > Add; er ersetzt den Legacy-Pfad nicht. Dateitypen werden auch in Web-Policies verwendet; deren Konfiguration gehört zu Web Protection. Auch der Data Control List einen eindeutigen Namen geben und nach der CCL-Auswahl Save wählen.

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 durch das Abschalten einer breit wirkenden Policy behoben. Im Legacy Mode wird stattdessen die passende SMTP malware scan- oder SMTP spam scan-Policy gezielt angepasst; ein Positivtest und ein Negativtest ausserhalb des vorgesehenen Geltungsbereichs müssen die Wirkung bestätigen. E-Mail-Ausnahmen sicher erstellen und testen beschreibt dagegen ausschliesslich das Ausnahmeobjekt im MTA Mode: Quelle, Absender oder Empfänger sind alternative Auslöser (OR), keine exakt kombinierte AND-Bedingung aus allen drei Merkmalen. Dieses MTA-Ausnahmeobjekt ist kein Legacy-Steuerelement.

Optionales Email Journaling datenschutzkonform einsetzen

Dem Journal-Eintrag einen eindeutigen Namen geben und Empfängerauswahl sowie Journalziel mit Save speichern, bevor die folgenden Tests beginnen.

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

Zum Anlegen unter Rules and policies > Firewall rules die tatsächliche Protokollfamilie IPv4 oder IPv6 wählen und Add firewall rule > New firewall rule öffnen. Name und benötigte Felder festlegen, mit Save speichern. Die IPv4-Beispieladressen dieses Artikels nicht in eine IPv6-Regel übernehmen.

⚠️ Die Zuordnung von Destination networks im eingehenden Legacy-Mailproxy-Beispiel ist gegenüber dem allgemeinen DNAT-Ablauf nicht abschliessend geklärt. Den unten genannten internen Zielhost nicht ungeprüft als universelle Feldvorgabe übernehmen und nicht auf Verdacht durch die öffentliche Adresse ersetzen. Vor produktivem Einsatz diese Zuordnung für den konkreten Proxy-Pfad klären; die ausgehende SNAT-Variante löst diese Frage nicht.

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. Fehlt der Standardport des gewählten Protokolls unter Services, bietet SFOS Add ports an. Bei einem abweichenden Port wird stattdessen zuerst der passende Service bewusst definiert. Service, NAT, Serverlistener und Scanoption müssen denselben Portpfad beschreiben; Add ports ersetzt diese Prüfung nicht.

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.

Optional: ausgehend eine andere öffentliche Quelladresse verwenden

Dieser Aufbau gilt für weitergeleiteten SMTP-Traffic des internen Servers, nicht für systemgenerierte MTA-Nachrichten. Er ist sinnvoll, wenn statt der WAN-MASQ-Adresse eine andere zugeteilte öffentliche Identität benötigt wird. Providerzuteilung, Route sowie SPF, RDNS und Providerfreigaben müssen zu dieser Identität passen; SNAT ändert diese Voraussetzungen nicht.

1. Unter Network > Interfaces > Add interface > Add alias das tatsächliche physische WAN-Interface, IP version IPv4 und die zugeteilte Adresse mit passender IPv4/Netmask wählen; Save. Providerpfad, Device Access und Aliasprüfung erklärt Alias-IP einrichten.
2. Unter Hosts and services > IP host > Add einen benannten Host für dieselbe öffentliche Adresse anlegen: IP family IPv4, Type IP, IP address die zugeteilte Adresse; Save. Ein Hostobjekt allein bindet keine Adresse ans Interface.
3. Unter Rules and policies > NAT rules > New NAT rule Original source auf den tatsächlichen internen Mailserver begrenzen und Translated source (SNAT) auf den öffentlichen IP Host setzen. Original destination auf die benötigten Mailziele beziehungsweise den Smarthost, Original service auf die benötigten SMTP-Dienste begrenzen. Translated destination (DNAT) und Translated service (PAT) bleiben Original. Inbound interface und Outbound interface müssen dem wirklichen Server-zu-WAN-Pfad entsprechen. Mit Save speichern und oberhalb anderer ebenfalls passender SNAT-Regeln einordnen; NAT- und Firewall-Reihenfolge getrennt prüfen. NAT-Grundlagen erklärt das First-Match-Modell. Any, Top, Port1 und Port2 aus Beispielen sind keine Pflichtwerte.
4. Unter Rules and policies > Firewall rules > Add firewall rule > New firewall rule eine passende ausgehende IPv4-Regel erstellen oder die vorhandene enge Regel prüfen: Action Accept, tatsächliche Serverzone und Serverhost als Quelle, WAN und die benötigten Ziele, nur die benötigten SMTP-Dienste, Log firewall traffic aktiv. Scan SMTP und gegebenenfalls Scan SMTPS wie oben wählen; Save und die Firewall-Reihenfolge unabhängig von NAT prüfen.
5. Eine neue SMTP-Verbindung zu einem kontrollierten externen Empfänger erzeugen. Firewall Rule ID, NAT Rule ID, übersetzte Quell-IP im Capture beziehungsweise beim externen Empfänger und tatsächliche Zustellung gemeinsam prüfen. Eine bestehende Session oder ein SMTP-Porttest genügt nicht. Auch eine nicht erfasste Quelle beziehungsweise ein nicht erlaubter Dienst wird negativ geprüft.

Beim Rückbau zuerst die dokumentierten Regeln und ihre Reihenfolge wiederherstellen und mit einer neuen Verbindung die frühere Quell-IP und Zustellung prüfen. Alias und IP Host erst entfernen, wenn kein anderer Dienst davon abhängt.

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-Hostname, SMTP- und POP/IMAP-Grössenlimit, Oversize-Aktion, IP Reputation und DoS-Grenzen sind begründet.
• Verwendete Standard- oder Alternativports und POP/IMAP-Recipient-Headers stimmen mit dem realen Serverpfad überein.
• Primäre Antivirus-Engine und die Auswirkung auf Zero-day Protection in Single-Antivirus-Policies sind geprüft.
• 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