Sophos Firewall POP3 und IMAP scannen und testen

Sophos Firewall kann E-Mails beim Abruf über POP3, POP3S, IMAP und IMAPS prüfen. Dafür reicht es nicht, nur eine POP-IMAP-Policy anzulegen. Erst die passende Firewall-Regel lenkt den Mailverkehr durch den Proxy und aktiviert die konfigurierten Scan- und TLS-Einstellungen.

Der wichtigste Erfolgstest ist deshalb nicht ein grüner Schalter, sondern ein echter Abruf vom vorgesehenen Client zum vorgesehenen Mailserver. Dabei müssen Firewall Rule ID, verwendeter Port, Zertifikatskette, ausgehandelte TLS-Version und warren.log zum geplanten Pfad passen.

⚠️ Ohne Scan email content in der tatsächlich getroffenen Firewall-Regel wendet SFOS die POP/IMAP-Einstellungen und -Policies nicht an. Eine vorhandene Policy allein bietet keinen Schutz.

POP/IMAP-Scanning in acht Schritten

1. Clientnetz, Mailserver, Protokolle und tatsächlich verwendete Ports dokumentieren.
2. Eine einzelne Pilotquelle auswählen und deren bisherigen Mailabruf testen.
3. Die ausstellende CA des Mailservers unter Certificates > Certificate authorities importieren, falls sie noch nicht vertrauenswürdig vorhanden ist.
4. Unter Email > General settings die POP/S and IMAP/S settings und die POP and IMAP TLS configuration festlegen.
5. Nur bei Bedarf unter Email > Policies and exceptions eine POP-IMAP scan Policy für Absender, Empfänger oder Nachrichtenmerkmale erstellen.
6. Eine enge, geloggte Firewall-Regel für den Pilotclient und den Mailserver anlegen und unter Scan email content die benötigten Protokolle aktivieren.
7. Abruf, TLS-Verbindung, Firewall Rule ID und warren.log mit einer kleinen Testnachricht prüfen.
8. Erst nach dem Positiv- und Negativtest weitere Clients aufnehmen und den Rückweg dokumentieren.

Was der POP/IMAP-Proxy schützt

POP3 und IMAP dienen dem Abruf und der Verwaltung von Nachrichten im Postfach. Sie sind nicht mit SMTP zu verwechseln, das Nachrichten zwischen Absender, MTA und Mailserver transportiert. Der MTA-Mode-Artikel erklärt deshalb MX, SMTP-Routing, Relay, Spool und SMTP-Quarantäne; dieser Ablauf konzentriert sich auf den Mailabruf eines Clients.

SFOS unterscheidet die unverschlüsselten beziehungsweise per STARTTLS hochgestuften Ports von den direkt verschlüsselten Varianten:

• POP3: TCP 110, optionaler Wechsel auf TLS mit STARTTLS
• POP3S: TCP 995, TLS ab Verbindungsbeginn
• IMAP: TCP 143, optionaler Wechsel auf TLS mit STARTTLS
• IMAPS: TCP 993, TLS ab Verbindungsbeginn

In neuen Designs sollten Mailclients verschlüsselte Verbindungen verwenden. Die Wahl des Protokolls in SFOS ändert jedoch keine Clientkonfiguration. Verwendet der Client einen anderen Port oder umgeht er die geplante Regel, wird dieser Verkehr nicht automatisch durch die markierte Standardoption geschützt.

POP/IMAP-Scanning benötigt eine gültige Email Protection-Lizenz. Es ersetzt weder den Schutz des Mailservers noch die Prüfung beim Eingang über SMTP. Gerade bei Cloud-Maildiensten muss vorab geklärt werden, ob der Anbieter einen klassischen POP/IMAP-Abruf überhaupt zulässt und ob ein transparenter Proxy mit dessen TLS- und Authentifizierungsanforderungen kompatibel ist.

Beispiel und Testgrenze festlegen

Ein kontrollierter Pilot verhindert, dass eine falsche Zertifikats- oder Regelkonfiguration gleichzeitig alle Mailclients betrifft. Das folgende Beispiel verwendet Dokumentationswerte:

• Pilotclient 10.20.30.50 in der Zone LAN
• Mailserver mail.example.net
• Zieladresse 192.0.2.25
• genutztes Protokoll IMAPS auf TCP 993
• Firewall-Regel Pilot_POP_IMAP_Scan

10.20.30.50, mail.example.net und 192.0.2.25 werden durch die echten Werte ersetzt. Die Zieladresse gehört zum dokumentierten TEST-NET-Bereich und darf nicht als produktive Serveradresse übernommen werden. Der Pilot sollte ein eigenes Testpostfach verwenden und nicht das einzige Konto eines Administrators sein.

Vor der Änderung wird eine Nachricht abgerufen und der aktuelle Zertifikatsaussteller notiert. Ausserdem werden die bestehende Firewall-Regel, ihr Regelzähler und die Clientkonfiguration gesichert. Damit lässt sich später unterscheiden, ob ein Fehler durch Routing, TLS, Proxy-Scanning oder den Mailserver entsteht.

TLS und Scan-Grenzen vorbereiten

CA und Zertifikatsprüfung

Unter Certificates > Certificate authorities wird die CA hinzugefügt, die das Zertifikat des Mailservers ausgestellt hat, sofern sie auf der Firewall nicht bereits vertrauenswürdig vorhanden ist. Private CA-Dateien kommen nur aus der eigenen PKI oder einer anderen verifizierten Quelle. Der allgemeine Import- und Kettencheck steht unter Zertifikate auf Sophos Firewall importieren.

Danach wird unter Email > General settings > POP and IMAP TLS configuration das vorgesehene TLS certificate gewählt. Allow invalid certificate bleibt deaktiviert. Eine ungültige, abgelaufene oder nicht vertrauenswürdige Gegenstelle wird nicht dadurch repariert, dass ihre Prüfung pauschal ausgeschaltet wird.

Disable legacy TLS protocols deaktiviert laut SFOS-Hilfe Protokolle vor TLS 1.1. Diese Option beweist nicht, dass eine konkrete Sitzung TLS 1.2 oder TLS 1.3 verwendet. Wenn die eigene Sicherheitsvorgabe mindestens TLS 1.2 verlangt, muss die ausgehandelte Version im echten Clientpfad kontrolliert werden. Lässt sie sich mit der eingesetzten Kombination nicht einhalten, wird der Rollout gestoppt und eine andere Schutzarchitektur geprüft.

Da die Firewall verschlüsselten Mailverkehr zur Prüfung verarbeitet, können Zertifikatswarnungen auf dem Client sichtbar werden. Eine neue Warnung wird nicht weggeklickt. Stattdessen werden präsentierter Name, Aussteller, Kette und Clientvertrauen geprüft und die Ursache vor dem breiten Rollout behoben.

Nachrichtengrösse und Empfänger-Header

Unter POP/S and IMAP/S settings legt Don’t scan emails greater than die maximale Nachrichtengrösse für den Scan fest. Der Wert 0 bedeutet bei POP/IMAP nicht unbegrenzt, sondern laut SFOS-Hilfe 10,240 KB. Grössere Nachrichten werden nicht gescannt. Die gewählte Grenze muss daher zu typischen Anhängen, verfügbarer Leistung und dem akzeptierten Restrisiko passen.

Die Recipient headers helfen SFOS, Empfänger für POP/IMAP-Policies zu erkennen. Standardmässig verwendet die Firewall Delivered-To, Received und X-RCPT-TO. Zusätzliche Header werden nur aufgenommen, wenn der reale Mailserver sie verlässlich setzt. Ein erfundener oder nachgelagert entfernter Header führt sonst zu schwer nachvollziehbaren Policy-Matches.

Optionale POP-IMAP-Policy erstellen

Mit aktiver Email-Protection-Subscription wendet SFOS die Standardpolicy default-pop-av automatisch auf POP3/S- und IMAP/S-Verkehr an. Sie entfernt virusinfizierte Anhänge und ersetzt den Nachrichtentext durch einen Hinweis. Diese automatische Grundpolicy muss bei Tests und bei der Fehlersuche berücksichtigt werden, bevor eine eigene Policy als Ursache angenommen wird.

Eine POP-IMAP-Policy ist für zusätzliche Kriterien und Benutzerhinweise gedacht. Unter Email > Policies and exceptions > Add a policy > POP-IMAP scan werden zuerst Name sowie Absender- und Empfängergruppen festgelegt. Danach kann die Policy unter anderem auf Spam-Einstufung, Quell-IP oder -Netz, Nachrichtengrösse oder einen Header reagieren.

Die dokumentierten Aktionen sind Accept und Prefix subject. Prefix subject stellt die Nachricht zu und ergänzt den Betreff um einen Hinweis. Die Policy ist damit keine allgemeine Quarantäne- oder Blockregel. Wird als Kriterium None gewählt, gilt die Aktion für alle Nachrichten zwischen den angegebenen Absendern und Empfängern. Diese Reichweite muss vor dem Speichern bewusst geprüft werden.

Für einen ersten technischen Proxytest kann die zusätzliche Policy entfallen. So bleibt sichtbar, ob bereits die Grundkette aus TLS, Firewall-Regel und Scan funktioniert. Eine Policy wird erst ergänzt, wenn Absender-, Empfänger- oder Headerlogik tatsächlich benötigt wird.

Firewall-Regel für den Mailabruf anlegen

Die Regel wird unter Rules and policies > Firewall rules erstellt. Sie sollte nur das vorgesehene Clientnetz beziehungsweise den Pilothost, das Mailserverziel und die tatsächlich benötigten Mailports enthalten. Eine allgemeine LAN-zu-WAN-Regel mit vielen Schutzfunktionen ist für die Abnahme unübersichtlich.

Für das Beispiel Pilot_POP_IMAP_Scan passen folgende Werte:

• Source zones: LAN
• Source networks and devices: Host 10.20.30.50
• Destination zones: Zone des Mailserverpfads, bei einem externen Server meist WAN
• Destination networks: Hostobjekt für 192.0.2.25 beziehungsweise den echten Mailserver
• Services: IMAPS
• Log firewall traffic: aktiviert

Unter Scan email content wird Scan IMAPS aktiviert. Für Umgebungen mit weiteren tatsächlich verwendeten Protokollen werden zusätzlich Scan IMAP, Scan POP3 oder Scan POP3S gewählt. Über Add ports ergänzt SFOS die zugehörigen Dienste; danach müssen sie unter Services der Regel sichtbar sein.

Die Regel wird oberhalb einer allgemeineren Regel platziert, die denselben Client und Mailserver bereits matcht. Nach dem Speichern entscheidet die tatsächliche Firewall Rule ID im Log Viewer, nicht die erwartete Position im Regelwerk. Aufbau, Reihenfolge und Rule-ID-Prüfung erklärt Sophos Firewall-Regeln sicher konfigurieren.

Den vollständigen Pfad testen

Zuerst wird im privaten Testpostfach eine kleine, harmlose Nachricht bereitgestellt. Der Pilotclient ruft sie über den vorgesehenen FQDN und Port ab. Im Log Viewer müssen Quell-IP, Ziel-IP, Service, Action und Firewall Rule ID zur neuen Regel passen. Ein Zähleranstieg an einer anderen Regel ist eine Stop-Bedingung.

Für den Zertifikats- und TLS-Abgleich können von einem Client im gleichen Netz beispielsweise diese lesenden Verbindungen verwendet werden:

openssl s_client -connect mail.example.net:993 -servername mail.example.net
openssl s_client -connect mail.example.net:995 -servername mail.example.net
openssl s_client -starttls imap -connect mail.example.net:143 -servername mail.example.net
openssl s_client -starttls pop3 -connect mail.example.net:110 -servername mail.example.net

Nur die Protokolle ausführen, die der Mailserver wirklich anbietet. mail.example.net wird durch den echten FQDN ersetzt. Die Ausgabe bestätigt Zertifikat, Kette und TLS-Parameter, aber weder einen erfolgreichen Login noch die inhaltliche Malwareprüfung. Die interaktive Verbindung wird nach der Kontrolle mit Ctrl+C beendet.

Danach wird der Abruf mit dem echten Mailclient wiederholt. Für die Proxyanalyse dient warren.log; Log Viewer und Packet Capture zeigen zusätzlich Regelmatch und Netzwerkpfad. Zeitstempel, Client-IP, Server-IP, Port und Testbetreff werden gemeinsam notiert. Die Logdatei und der sichere Zugriff sind unter Sophos Firewall Services und Logs eingeordnet.

Ein belastbarer Abnahmetest umfasst ausserdem einen Negativfall. Ein nicht freigegebener Pilothost oder ein nicht ausgewählter Port darf nicht versehentlich über eine breite zweite Scanregel denselben Schutzstatus erhalten. Steht eine eigens vorbereitete Testgegenstelle mit ungültiger Zertifikatskette zur Verfügung, muss diese scheitern, solange Allow invalid certificate deaktiviert ist; an der produktiven Gegenstelle wird dafür kein Zertifikatsfehler erzeugt.

Fehler nach Symptom eingrenzen

Der Abruf funktioniert, aber der Proxy scannt nicht

Zuerst die Firewall Rule ID prüfen. Trifft eine höhere oder allgemeinere Regel, werden Position, Source, Destination und Service korrigiert. Trifft die gewünschte Regel, müssen das passende Scan IMAP/IMAPS/POP3/POP3S und der Port unter Services aktiv sein. Eine POP-IMAP-Policy allein aktiviert den Proxy nicht.

Der Mailclient meldet nach der Aktivierung einen Zertifikatsfehler

Präsentierten FQDN, Aussteller, Laufzeit und vollständige Kette erfassen. Danach die unter POP and IMAP TLS configuration gewählte CA und das Vertrauen des Clients prüfen. Allow invalid certificate wird nicht als dauerhafter Workaround aktiviert. Bleibt unklar, welches Zertifikat der Proxy oder Server präsentiert, wird der Pilot zurückgerollt, bevor weitere Clients betroffen sind.

STARTTLS funktioniert, POP3S oder IMAPS aber nicht

Ports und Betriebsarten getrennt prüfen. POP3 auf 110 und IMAP auf 143 wechseln erst mit STARTTLS in eine verschlüsselte Sitzung; POP3S auf 995 und IMAPS auf 993 beginnen direkt mit TLS. Mailclient, Serverlistener, Firewall-Service und aktivierte Scanoption müssen dieselbe Variante verwenden.

Eine grosse Nachricht wird zugestellt, aber nicht geprüft

Den Wert Don’t scan emails greater than und die tatsächliche Nachrichtengrösse vergleichen. Auch 0 begrenzt den POP/IMAP-Scan auf 10,240 KB. Die Grenze wird nicht für einen einzelnen Test blind erhöht, ohne Auswirkung auf Leistung und akzeptiertes Risiko zu bewerten.

Das Subject-Präfix fehlt

Absender- und Empfängergruppe, Matchtyp, Kriterium und Recipient headers prüfen. Die Nachricht kann technisch gescannt worden sein, obwohl die optionale Policy nicht matched. Proxyfunktion und Policyaktion werden deshalb getrennt bewertet.

Betrieb und Rollback

Nach erfolgreichem Pilot werden weitere Clients schrittweise aufgenommen. Regelzähler, warren.log, TLS-Fehler und Helpdesk-Rückmeldungen werden während des Rollouts beobachtet. Änderungen an Mailserverzertifikat, FQDN, Port oder Clientprofil gehören danach in denselben Change-Prozess, weil sie den geprüften Pfad verändern.

Für den Rollback wird der Pilot zuerst aus der engen Regel entfernt oder die zugehörige Scanoption deaktiviert. Danach muss der ursprüngliche Mailabruf wieder funktionieren und die erwartete frühere Regel matchen. Eine importierte CA oder eine globale POP/IMAP-Einstellung wird nur zurückgenommen, wenn kein anderer Dienst sie verwendet. Nachrichten, Logs oder Zertifikate werden nicht als Standard-Rollback gelöscht.

FAQ