Configurer Mail Protection sur Sophos Firewall en mode Legacy

En Legacy mode, Sophos Firewall fonctionne comme un proxy de messagerie transparent. Le serveur de messagerie interne reste l’endpoint SMTP réel ; le firewall transmet le trafic au moyen des règles firewall et NAT existantes tout en recherchant le spam, les malwares, les types de fichiers ou les correspondances Data Control.

Ce fonctionnement est fondamentalement différent du MTA mode. Le firewall ne devient pas un Mail Transfer Agent, ne prend pas en charge la distribution des messages pour les domaines protégés et ne fournit pas de MTA mail spool pour ce chemin. Un test de port SMTP réussi ne prouve donc ni l’analyse par le proxy ni l’application de la bonne politique.

⚠️ La modification du SMTP Deployment Mode est un changement global du chemin de protection de la messagerie. Avant la commutation, il faut documenter le backup, les politiques existantes, les règles firewall et NAT ainsi qu’un chemin de secours testé. Un problème MTA ne justifie pas de passer au Legacy mode sans planification.

Legacy mode en neuf étapes

1. Documenter le chemin SMTP entrant et sortant existant avec les adresses IP, les ports, le NAT et les Firewall Rule IDs.
2. Vérifier si le fonctionnement en proxy transparent convient réellement mieux que le MTA mode.
3. Garantir un backup de configuration et un accès d’administration indépendant.
4. Sous Email > General settings, sélectionner Switch to legacy mode.
5. Définir la limite de taille SMTP, l’action pour les messages surdimensionnés, IP Reputation, les limites DoS et le comportement TLS.
6. Créer uniquement les politiques SMTP malware et SMTP spam nécessaires ou contrôler leur ordre.
7. Limiter les chemins DNAT entrants et SNAT sortants au serveur de messagerie réel.
8. Activer Scan SMTP ou Scan SMTPS dans les règles firewall qui correspondent réellement.
9. Valider les messages de test entrants et sortants avec la Rule ID, le résultat de la politique, le certificat et les logs du proxy Legacy.

Choisir entre Legacy mode et MTA mode

Legacy mode convient principalement aux environnements existants dans lesquels le serveur de messagerie interne est déjà publié directement par NAT et où ce chemin doit être conservé. SFOS se place de manière transparente entre le peer distant et le serveur. La cible MX, l’acceptation SMTP et la logique de distribution restent intégrées à la conception existante du serveur de messagerie.

MTA mode constitue le meilleur choix lorsque le firewall doit accepter lui-même les messages, les router par domaine protégé, les relayer et les conserver dans un spool en cas d’échec temporaire de distribution. Mail logs et mail spool appartiennent explicitement à ce modèle d’exploitation. La configuration complète est décrite dans Configurer Mail Protection en MTA mode.

Selon l’aide SFOS 22, MTA mode n’est pas disponible sur les XGS 87/87w et XGS 88/88w. Cela ne fait toutefois pas automatiquement de Legacy mode une bonne architecture de messagerie cloud. Microsoft 365, Google Workspace et les services hébergés modernes imposent leurs propres exigences en matière de TLS, d’authentification et de protection contre les abus. Leur compatibilité avec un proxy transparent doit être vérifiée au préalable.

En bref : MTA mode possède son propre flux de messagerie. Legacy mode protège un chemin SMTP qui fonctionne déjà. Mélanger ces deux modèles conduit à chercher dans le mauvais log, sur la mauvaise destination NAT ou dans un spool inexistant.

Topologie d’exemple et chemin de secours

L’exemple suivant utilise des valeurs de documentation et doit être adapté à l’environnement réel avant sa mise en œuvre :

• serveur de messagerie interne 10.20.30.25 dans la zone DMZ
• adresse SMTP publique 192.0.2.25 sur le chemin WAN
• service SMTP entrant TCP 25
• SMTPS facultatif sur TCP 465, uniquement si les peers et le serveur utilisent réellement cette variante
• règles firewall SMTP_In_Legacy et SMTP_Out_Legacy

192.0.2.25 appartient à la plage TEST-NET et n’est pas une valeur de production. Avant le changement, effectuer un test entrant externe et un test sortant avec horodatage. Conserver les Rule IDs actuellement utilisées, l’adresse source publique employée par le serveur sortant et la chaîne de certificats.

Le chemin de secours ne se limite pas à rétablir le mode précédent. Il faut également pouvoir restaurer l’état documenté des nouvelles options d’analyse, de l’ordre des politiques, du DNAT, des règles SNAT réflexives ou manuelles et des tests temporaires.

Définir les paramètres SMTP globaux

Limite de taille, action sur les messages surdimensionnés et protection DoS

Sous Email > General settings > SMTP settings, Don’t scan emails greater than définit la taille maximale des messages à analyser. Sur le chemin SMTP, la valeur 0 signifie 51,200 KB selon l’aide SFOS 22, et non une taille illimitée. Les options disponibles pour les messages plus volumineux sont Accept, Reject et Drop.

Accept distribue un message surdimensionné sans l’analyser. Reject le refuse et informe l’expéditeur, tandis que Drop le rejette sans notification. Ce choix est une décision délibérée en matière de risque et d’exploitation. Un Drop non testé complique le diagnostic ; un Accept non évalué crée une lacune d’analyse qui doit être documentée.

Verify sender’s IP reputation vérifie l’adresse IP de l’expéditeur avant les critères antispam de la politique SMTP. Les valeurs SMTP DoS limitent les connexions, les messages et les destinataires. Les limites de production sont déduites du volume réel de messagerie et d’une baseline, et non copiées depuis un exemple Internet générique.

Bypass spam check for SMTP/S authenticated connections ignore globalement le contrôle antispam pour les connexions que le serveur de messagerie signale comme authentifiées. Ce choix n’est acceptable qu’après vérification de l’authentification, des sources autorisées et de la protection contre les abus de ce chemin. Une connexion réussie ne remplace ni l’analyse antimalware ni un test négatif avec une connexion non authentifiée. Les domaines sous Spam check exceptions constituent également un contournement global et ne servent pas de remplacement rapide à une exception étroitement limitée.

La bannière globale de messagerie propose Inline, no conversion, MIME part et Off. Elle n’apparaît que si l’analyse SMTP ou SMTPS est active dans la règle de pare-feu correspondante. Comme la modification du body peut invalider une signature DKIM existante, le chemin sortant réel est validé en contrôlant les headers chez le destinataire.

Ne pas surestimer TLS à cause d’une case à cocher

Sous SMTP TLS configuration, sélectionner le certificat CA ou serveur destiné à l’analyse. Allow invalid certificate reste désactivé. Selon l’aide, Disable legacy TLS protocols désactive uniquement les protocoles antérieurs à TLS 1.1 et ne prouve pas l’établissement d’une session TLS 1.2 ou TLS 1.3 précise.

Sophos signale également une limite importante du mode Legacy : le firewall établit la connexion TLS à partir de l’adresse IP du domaine plutôt que de son nom. Si plusieurs domaines partagent une même adresse IP, la validation du certificat peut échouer. Dans ce cas, Sophos recommande un autre chemin de protection, comme Sophos Email Security. Il ne faut pas contourner la vérification avec Allow invalid certificate.

Require TLS negotiation impose TLS pour les Remote Hosts ou réseaux sélectionnés ; Require sender email domains l’impose pour les domaines expéditeurs. Si la connexion TLS ne peut pas être établie, SFOS rejette les messages concernés. Skip TLS negotiation autorise intentionnellement des connexions SMTP non chiffrées avec les peers sélectionnés et doit être réservé à des exceptions documentées.

Utiliser les politiques d’analyse de manière ciblée

Après l’activation de l’abonnement Email Protection, Sophos Firewall applique automatiquement la politique par défaut default-smtp-av au trafic SMTP en Legacy mode. Les politiques personnalisées sont créées sous Email > Policies et traitées dans l’ordre de la liste. Il faut donc commencer par vérifier quelle politique existante correspond à l’expéditeur et au destinataire concernés.

SMTP malware scan

Une politique SMTP malware scan contrôle les types de fichiers bloqués, les exceptions MIME, l’analyse antivirus et les actions de distribution. Avec Single antivirus, le moteur sélectionné ne s’applique selon l’aide qu’aux messages entrants ; les messages sortants sont analysés par les deux moteurs. Dual antivirus exécute successivement le moteur principal et le moteur secondaire.

L’action Quarantine est combinée aux actions destinées au destinataire et à l’administrateur. Don’t deliver, Deliver original et Remove and deliver produisent des résultats très différents. Une pièce jointe protégée ou non analysable ne doit pas être assimilée automatiquement à un malware. Chaque action nécessite donc un message de test, un état attendu pour le destinataire et un chemin de libération documenté.

Quarantine ne signifie pas automatiquement que le destinataire ne reçoit aucun message ; la Delivery option for recipient reste déterminante. Selon Sophos, Notify sender fonctionne uniquement avec Don’t deliver. Les pièces jointes protégées ne sont pas analysées, mais peuvent tout de même déclencher une notification. L’action distincte pour les administrateurs décide si aucune copie, l’original ou un message sans pièce jointe leur est envoyé. Ces quatre résultats ne sont pas déduits d’un seul message de test réussi.

SMTP spam scan

Une politique SMTP spam scan peut correspondre à la classification du spam, à la source ou à la destination, à une RBL, à la taille du message, aux headers ou à une Data Control List. Selon le chemin, les actions disponibles sont Reject, Accept, Change recipient, Prefix subject, Drop et Quarantine.

Le critère Data control list et l’affectation SPX de cette politique s’appliquent uniquement aux messages sortants. None applique en revanche l’action sélectionnée à tous les messages entre les groupes d’expéditeurs et de destinataires définis. Change recipient ne remet pas également au destinataire d’origine, mais le remplace par la destination configurée. Ces trois portées sont testées avec un cas destinataire positif et un cas négatif avant le classement de la politique en production.

Préparer des types de fichiers personnalisés et Data Control

En Legacy mode, les types de fichiers personnalisés sont créés sous Email > Policies > File type > Add à partir d’un modèle, d’extensions ou de types MIME. Les extensions sont saisies sans point initial et seuls les types personnalisés sont modifiables. Un nouveau type n’est pas ajouté automatiquement aux policies existantes. Il faut ouvrir la scan policy concernée, y ajouter le type, puis l’enregistrer à nouveau. Un test positif avec une pièce jointe et un test négatif similaire montrent si l’action prévue s’applique réellement.

Une Data Control List est créée sous Email > Data control list > Add à partir des Content Control Lists nécessaires. Les filtres Type et Region aident à ne sélectionner que les modèles pertinents de données financières, d’identité ou d’autres données sensibles. La correspondance de la liste ne définit pas encore l’action ; celle-ci est configurée dans la scan policy associée. Une petite liste pilote avec un test de contenu positif et un test négatif est plus sûre qu’une vaste collection de CCL non vérifiées.

En Legacy mode, SPX peut être sélectionné dans cette politique pour les messages sortants. Le modèle de mot de passe, le portail et la validation constituent toutefois un processus de sécurité distinct ; voir Configurer le chiffrement des e-mails SPX. Aucune Data Control List ni affectation SPX n’est ajoutée au premier test élémentaire du proxy.

Une classification erronée confirmée ne se corrige pas en désactivant une stratégie étendue. Créer et tester en toute sécurité des exceptions de messagerie explique comment ignorer un contrôle précis pour une combinaison exacte de source, d’expéditeur et de destinataire, puis tester le trafic qui ne doit pas correspondre.

Utiliser la journalisation facultative des e-mails en respectant la protection des données

Sous Email > General settings > Email journaling > Add, SFOS peut envoyer les copies des messages SMTP/S entrants de destinataires ou de groupes d’adresses sélectionnés vers une adresse de journalisation distincte. La sélection Any couvre tous les messages entrants. La fonction s’applique uniquement à SMTP/S et ne journalise pas le trafic POP ou IMAP.

La journalisation crée une copie supplémentaire de l’e-mail. Elle ne constitue pas automatiquement une archive inviolable et ne prouve pas le respect des obligations légales de conservation. Avant de l’activer, il faut définir sa finalité, les destinataires autorisés, l’accès à la boîte de journalisation, le chiffrement, la durée de conservation, le stockage nécessaire et le responsable.

Pour le premier test, une seule boîte de test est sélectionnée à la place de Any. Un message entrant destiné à cette boîte doit apparaître dans la destination normale et dans la boîte de journalisation ; un message adressé à un destinataire non sélectionné ne doit pas produire de copie. L’adresse de journalisation ne doit pas déclencher un flux qui renvoie la copie vers SFOS et crée une boucle.

La sélection des destinataires n’est étendue qu’après les tests positif et négatif. Pour le rollback, l’entrée de journalisation est supprimée ou l’état antérieur documenté est restauré. Les copies déjà distribuées restent dans la boîte de journalisation et doivent être traitées selon ses propres règles de conservation.

Associer NAT et règles firewall

Publier le chemin SMTP entrant

Pour les messages entrants, une règle DNAT traduit l’adresse WAN publique vers le serveur de messagerie interne. Original Source est limité autant que la conception de messagerie le permet ; Original Destination est l’adresse publique prévue ; Translated Destination est 10.20.30.25 ou le serveur de messagerie réel. Original service et translated service restent limités aux ports SMTP réellement proposés.

Une règle réflexive crée également un SNAT pour le sens inverse. Elle n’est sélectionnée que si cette identité source publique précise est prévue pour le chemin sortant. Plusieurs liaisons WAN, smarthosts ou chemins opérateur différents nécessitent une conception propre du routing et du SNAT. L’ordre général et la zone de destination après NAT sont expliqués dans Publier un serveur avec DNAT.

Utiliser deux règles firewall précises

Pour la validation, deux règles séparées sont plus compréhensibles qu’une règle bidirectionnelle contenant plusieurs zones et des objets Any :

• Entrant : WAN vers la zone du serveur de messagerie interne, hôte de destination 10.20.30.25, uniquement les services SMTP requis, logging activé
• Sortant : zone et hôte du serveur de messagerie interne vers WAN ou le smarthost précis, uniquement les services SMTP requis, logging activé

Sous Scan email content, activer Scan SMTP dans les deux sens nécessaires et Scan SMTPS uniquement lorsque SMTPS est réellement utilisé. Une case cochée n’ajoute pas automatiquement un service manquant à une conception de sécurité correcte. Le service, le NAT, le listener du serveur et l’option d’analyse doivent décrire le même chemin de port.

Placer les règles au-dessus des règles plus générales qui correspondent déjà au même trafic. Après l’enregistrement, la Firewall Rule ID consignée fait foi. La structure des règles, la zone NAT et l’ordre sont décrits dans Configurer les règles Sophos Firewall en toute sécurité.

Valider le flux de messagerie et l’analyse du proxy

Envoyer d’abord un petit message externe vers une boîte de test. Faire ensuite envoyer par le serveur de messagerie interne un second message vers un destinataire externe contrôlé. Les deux tests reçoivent des objets uniques et des horodatages UTC.

Pour STARTTLS sur le port 25 et une connexion TLS directe sur le port 465, les contrôles en lecture seule suivants peuvent aider depuis un système de test autorisé :

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

Remplacer mail.example.net par le FQDN réel et tester uniquement les ports effectivement proposés. OpenSSL confirme l’accessibilité, la chaîne de certificats et les paramètres TLS négociés. Il ne prouve ni la distribution réussie du message ni l’analyse des malwares, du spam ou de Data Control.

Dans Log Viewer, la source, la destination, le service, l’action et la Firewall Rule ID doivent correspondre aux nouvelles règles. Pour le proxy SMTP/S Legacy, corréler awarrensmtp.log et awarrenmta.log avec le même horodatage. Les fichiers de log sont décrits dans Services et logs Sophos Firewall.

Effectuer ensuite un test négatif. Une source non prévue, un port non autorisé ou un message de test ne satisfaisant pas au critère de la politique ne doivent pas bénéficier par erreur du même chemin de protection. Aucun malware réel n’est utilisé dans un test de production ; la validation de l’analyse repose sur des modèles de test inoffensifs reconnus et une boîte contrôlée.

Isoler les erreurs selon le symptôme

SMTP fonctionne, mais la politique ne s’applique pas

Commencer par vérifier la Firewall Rule ID. Si une autre règle correspond, corriger l’ordre, la source, la destination, la cible NAT et le service. Si la règle attendue correspond, Scan SMTP ou Scan SMTPS, l’ordre des politiques et les groupes d’expéditeurs et de destinataires doivent convenir au test. Une politique seule n’active pas le proxy transparent.

Le courrier entrant n’atteint pas le serveur

Contrôler séparément l’adresse de destination publique, le hit DNAT, la translated destination, la zone de destination, le listener du serveur et le chemin retour. Une connexion TCP ouverte jusqu’au firewall ne prouve pas que le DNAT et la règle firewall atteignent le serveur interne. Packet Capture et Rule ID doivent montrer l’entrée et le transfert.

Le courrier sortant utilise la mauvaise adresse IP publique

Contrôler le SNAT, la règle réflexive, le gateway WAN, la route SD-WAN et le comportement des reply packets. Le proxy Legacy ne sélectionne pas automatiquement l’adresse source publique requise pour SPF, RDNS ou l’autorisation du fournisseur. Prouver le chemin concret avant toute modification globale de Route Precedence.

TLS échoue après l’activation de l’analyse

Relever le FQDN, l’adresse IP de destination, le certificat, l’émetteur, la chaîne et la version négociée. Si plusieurs domaines partagent une adresse IP, le contrôle de certificat fondé sur l’adresse IP documenté peut être en cause. Allow invalid certificate ne doit pas être activé comme solution rapide.

Un message manque et rien n’apparaît dans le MTA mail spool

Ce n’est pas un critère de réussite pertinent en Legacy mode, car mail spool et les mail logs spécifiques au MTA appartiennent au MTA mode. La chaîne pertinente comprend ici la règle firewall, le NAT, les logs du serveur SMTP, Log Viewer, awarrensmtp.log et awarrenmta.log. Contrôler séparément les messages mis en quarantaine sous Email > SMTP quarantine.

Effectuer un rollback sûr

Pour le rollback, restaurer d’abord les règles pilotes et les options d’analyse dans leur état antérieur documenté. Supprimer ensuite les nouvelles affectations de politiques ou rétablir leur ordre. Les modifications temporaires du DNAT, du SNAT ou des certificats ne sont supprimées que si aucun autre service n’en dépend.

Ce n’est qu’ensuite que le SMTP Deployment Mode est rétabli si la modification incluait cette commutation. Le flux de messagerie entrant et sortant d’origine doit à nouveau fonctionner avec les Rule IDs, les adresses publiques et les logs serveur attendus. Les messages, le contenu de la quarantaine et les logs du proxy ne sont pas supprimés dans le cadre d’un rollback standard.

Checklist d’exploitation

• Le proxy transparent est un choix délibéré et les exigences MTA ont été exclues.
• Le backup, l’accès d’administration et les Rule IDs d’origine sont documentés.
• La limite de taille SMTP, l’action sur les messages surdimensionnés, IP Reputation et les limites DoS sont justifiées.
• Le certificat, les exceptions TLS et les domaines concernés ont été contrôlés.
• Le DNAT, le SNAT, la zone de destination et les ports réels du serveur correspondent.
• Les règles firewall entrante et sortante sont précises, journalisées et leur correspondance est prouvée.
• Les politiques par défaut et personnalisées possèdent un ordre traçable.
• La journalisation facultative est limitée aux destinataires nécessaires et répond à un objectif documenté de protection et de conservation des données.
• Les tests positif, négatif, TLS et de distribution ont réussi.
• Les logs du proxy Legacy et du serveur de messagerie peuvent être corrélés dans le temps.
• Le responsable, la date de révision et le chemin de secours complet sont consignés.

FAQ