Configurer Sophos Firewall Mail Protection en mode MTA

En MTA mode, Sophos Firewall accepte lui-même les e-mails, les inspecte et les remet au serveur de messagerie interne ou au relais suivant. Le flux ne fonctionne que si l’enregistrement MX, la règle MTA automatique, la SMTP route and scan Policy, le relais, TLS et la vérification des destinataires sont cohérents.

La configuration comporte six étapes : définir le flux et le chemin de repli, activer MTA mode, ajouter le domaine, créer la route and scan Policy, sécuriser le relais et modifier l’enregistrement MX. Il faut ensuite valider les flux entrant et sortant à l’aide de commandes externes, de la quarantaine, du spool et des logs.

Quand utiliser MTA mode

Mail Protection sur le pare-feu convient surtout aux environnements on-premises et hybrides conçus à cet effet, dans lesquels un serveur Exchange local ou un autre serveur de messagerie doit être protégé. Pour Microsoft 365, Google Workspace et de nombreux environnements entièrement cloud, Sophos Central Email ou une autre passerelle de messagerie cloud constitue généralement une architecture plus claire. L’enchaînement de deux passerelles complique la quarantaine, les headers, TLS, SPF/DKIM/DMARC et le dépannage.

Il faut distinguer trois fonctions de Sophos Firewall :

• MTA mode : le pare-feu accepte, inspecte et route les e-mails.
• Legacy mode : ancien traitement proxy transparent pour les environnements existants.
• SMTP Relay dans Device Access : contrôle les zones depuis lesquelles le MTA est joignable. Les e-mails entrants d’Internet nécessitent WAN ; le relais sortant est en outre limité à des serveurs internes précis.

Les prérequis comprennent une licence Email Protection valide, un routage et un DNS opérationnels, une adresse IP publique connue, le serveur interne et son port cible, ainsi que des stratégies TLS, de quarantaine et de repli définies. Selon la présentation actuelle de Sophos, MTA mode n’est pas disponible sur les XGS 87/87w et XGS 88/88w.

Anti-Spam, RDNS, SPF, RBL, IP Reputation et SXL2 Live Protection nécessitent un accès Internet. Le routage des e-mails, l’analyse antimalware, le filtrage MIME et SPX peuvent continuer à fonctionner avec la licence appropriée dans un environnement airgap, mais un MTA actif ne signifie pas que tous les contrôles de protection y sont disponibles.

Configurer MTA mode de bout en bout

1. Définir le flux et le chemin de repli

Pour le flux entrant, l’enregistrement MX public pointe vers l’adresse sur laquelle Sophos Firewall accepte TCP 25. Le pare-feu inspecte le message et le remet au serveur interne. Une ancienne règle DNAT ne doit pas laisser ce serveur directement accessible depuis Internet sans inspection, sous peine de contourner le MTA. Publier un serveur avec DNAT explique la logique DNAT générale.

Pour le flux sortant, seul le serveur prévu envoie via le pare-feu. Le chemin d’envoi, le smarthost, PTR/rDNS, HELO, SPF, DKIM et DMARC doivent correspondre à l’identité publique de l’expéditeur. Une règle générale LAN to WAN est trop large ; la base de règles doit identifier clairement l’expéditeur SMTP autorisé. Comprendre les règles Sophos Firewall explique leur ordre.

Avant la migration, documenter :

• l’enregistrement MX actuel, sa priorité et son TTL ;
• la nouvelle adresse publique du pare-feu et le serveur cible interne ;
• les règles DNAT et SMTP existantes et les connecteurs du serveur ;
• les expéditeurs de test entrants et sortants ;
• l’ancien MX ou chemin de messagerie comme repli ;
• la supervision de la file du serveur, du spool du pare-feu et de la quarantaine.

Réduire le TTL suffisamment tôt si un retour rapide peut être nécessaire. Toute modification du MX de production doit intervenir dans une fenêtre de maintenance.

2. Configurer MTA mode et les paramètres SMTP de base

Sous Email > General settings, sélectionner Switch to MTA mode si nécessaire. Sophos Firewall crée alors la règle Any-to-Any Auto added firewall policy for MTA pour SMTP et SMTPS. Cette règle ne doit pas être modifiée et doit rester en tête de la liste. Le passage à Legacy mode la supprime ; le retour à MTA mode la recrée.

Configurer ensuite les paramètres de base :

1. Sous SMTP hostname, saisir le nom de domaine, par exemple example.com, et non le hostname du serveur interne. Cette valeur apparaît dans HELO et dans la bannière SMTP des notifications générées par le système.
2. Activer Reject based on IP reputation pour rejeter les connexions d’expéditeurs de mauvaise réputation.
3. Sous SMTP TLS configuration, sélectionner un certificat publiquement approuvé et n’autoriser Allow invalid certificate que pour des exceptions documentées.
4. Activer Disable legacy TLS protocols, sauf si des systèmes anciens documentés l’empêchent. Cette option désactive les protocoles antérieurs à TLS 1.1 ; elle n’impose pas automatiquement uniquement les versions TLS actuelles.
5. Activer Scan outgoing mails si les messages sortants doivent également être inspectés.

Utiliser Require TLS negotiation avec prudence : si SFOS ne peut pas établir la connexion TLS requise, il supprime les e-mails vers la destination concernée ou provenant du domaine expéditeur configuré. Le pare-feu valide en outre SMTP TLS au moyen de l’adresse IP du domaine et non de son nom. Plusieurs domaines sur une même IP peuvent donc provoquer des erreurs de certificat.

3. Ajouter le domaine comme Address Group

1. Ouvrir Email > Address group > Add.
2. Définir Group type sur Email address/domain et Type sur Manual.
3. Ajouter le domaine protégé, par exemple example.com.
4. Enregistrer le groupe.

Les nouvelles SMTP route and scan Policies sont conçues autour des domaines, et non d’adresses de destinataires individuelles. Les adresses individuelles migrées peuvent rester actives, mais elles ne peuvent plus être ajoutées ni modifiées dans les policies actuelles.

4. Créer une SMTP route and scan Policy

Ouvrir Email > Policies and exceptions > Add a policy > SMTP route and scan :

1. Saisir un nom clair, par exemple Inbound example.com to Exchange.
2. Sous Protected domain, sélectionner l’Address Group.
3. Choisir Route by :
   • Static host : adresse IP fixe du serveur interne ; en cas de panne, le pare-feu essaie l’hôte suivant de la liste.
   • DNS host : nom DNS tel que mailserver.example.com ; plusieurs enregistrements A sont répartis entre les remises et les serveurs défaillants sont ignorés.
   • MX : remise basée sur un enregistrement MX.
4. Pour Static host, sélectionner le serveur sous Host list. Créer son IP host sous Hosts and services > IP host si nécessaire.
5. Définir Global action sur Accept.
6. Activer Spam protection et Malware protection conformément au concept d’exploitation.
7. N’activer File protection et Data protection qu’après avoir compris leurs effets sur les pièces jointes, les messages volumineux, SPX et DKIM.
8. Enregistrer la policy.

Avec Route by MX, le MX résolu par le pare-feu ne doit pas repointer vers ce même pare-feu, sinon une boucle de routage se produit. Le pare-feu doit résoudre correctement les destinations internes ; les DNS Request Routes sont utiles avec le split DNS.

L’option Route inbound mail through gateway n’est nécessaire que pour des conceptions particulières, par exemple des serveurs cibles dans la zone WAN, l’application de la règle d’origine aux destinations LAN/DMZ ou le choix d’une passerelle précise avec plusieurs accès Internet. Ne pas l’activer sans besoin concret de routage.

5. Sécuriser l’accès entrant et le relais sortant

Sous Administration > Device access, autoriser SMTP Relay depuis toutes les zones qui doivent joindre le MTA. Les e-mails entrants d’Internet nécessitent WAN ; les e-mails sortants nécessitent également la zone du serveur interne, généralement LAN ou DMZ. Sous Email > Relay settings > Host-based relay, limiter ensuite l’accès aux serveurs, scanners ou applications précis.

Des autorisations larges pour les hôtes ou les réseaux créent un risque d’open relay. Si des imprimantes ou applications doivent envoyer des e-mails, les documenter comme objets hôtes précis. Sécuriser l’accès à Sophos Firewall explique les bases de Device Access.

La SMTP route and scan Policy ne prend pas en charge SMTP AUTH. Pour les appareils, Host-based relay constitue donc la méthode fiable. Il existe aussi des Authenticated relay settings séparés pour les utilisateurs et groupes ; Sophos indique cependant qu’ils ne prennent pas en charge une norme SMTP Authentication conforme aux RFC, ce qui impose de tester la compatibilité du client. Cette situation est différente de l’authentification du pare-feu auprès d’un smarthost en amont, pour laquelle SFOS prend en charge PLAIN et LOGIN. Ne jamais utiliser une adresse d’interface du même pare-feu comme smarthost, car cela créerait une boucle de routage.

6. Modifier l’enregistrement MX

Ne modifier le MX public vers l’adresse du pare-feu qu’une fois la règle MTA, le domaine, la policy, le relais et le chemin de remise interne prêts. Envoyer immédiatement un message externe de test et vérifier qu’il apparaît dans Log Viewer ou Mail logs, qu’il est remis au serveur interne et qu’il arrive dans la boîte aux lettres.

Si les expéditeurs externes ne peuvent pas atteindre le pare-feu ou si les messages légitimes sont largement rejetés, restaurer l’ancien chemin documenté. Si le pare-feu accepte les messages mais ne les remet pas, contrôler d’abord le routage, le DNS, TLS, recipient verification et les logs du serveur.

Choisir consciemment les protections

Spam protection ne se limite pas à l’action appliquée au spam. Les échecs SPF et RBL sont rejetés directement et ne suivent pas les actions normales pour spam ou probable spam. Greylisting rejette volontairement un message de façon temporaire et oblige le serveur expéditeur à réessayer.

Recipient verification empêche les messages destinés à des utilisateurs inconnus :

• With callout : interroge le serveur cible. S’il est temporairement indisponible, SFOS accepte les destinataires après une durée définie au lieu de bloquer durablement tout le flux.
• In Active Directory : effectue la vérification via Simple, SSL ou STARTTLS avec un timeout de 30 secondes.

Malware Protection peut utiliser une ou deux analyses antivirus. Pour utiliser Zero-Day Protection avec une seule analyse, Sophos doit être le moteur principal. Sophos Firewall Zero-Day Protection explique les limites et les décisions de libération.

Pour les messages sortants, l’ordre de traitement est important. Le chiffrement SPX, les préfixes d’objet, File ou Data Protection et les bannières sortantes peuvent modifier le header ou le body après l’ajout d’une signature DKIM. La validation DKIM échoue alors chez le destinataire. Il faut décider si le serveur interne, Sophos Firewall ou une passerelle ultérieure signe les messages.

Configurer et tester le chiffrement des e-mails SPX explique comment le modèle, la priorité des déclencheurs, le modèle de mot de passe et le Reply Portal fonctionnent ensemble.

Valider le flux de messagerie

Exécuter les commandes suivantes depuis un système extérieur au réseau :

dig MX example.com
dig A mail.example.com
dig AAAA mail.example.com
nc -vz mail.example.com 25
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com

Remplacer example.com et mail.example.com par les valeurs réelles. Ces commandes testent le DNS, TCP 25 et STARTTLS, mais ni l’autorisation de relais ni la remise complète. openssl s_client reste interactif après le handshake ; l’arrêter avec Ctrl+C.

Tester au minimum les cas suivants :

• message externe vers un destinataire valide ;
• message externe vers un destinataire non valide ;
• message sortant via le serveur prévu ;
• test spam ou malware adapté à la policy ;
• STARTTLS et chaîne de certificats présentée ;
• action de quarantaine et remise après libération ;
• tentative de relais bloquée depuis une source non autorisée ;
• absence de remise directe contournant le MTA via une ancienne règle DNAT.

Pour la première vérification, utiliser Email > Mail logs, Email > Mail spool, Email > SMTP quarantine et Log Viewer. Pour une analyse approfondie, noter l’heure du test, l’expéditeur, le destinataire, l’objet, l’IP source et le Message-ID, puis les corréler avec ces fichiers :

• MTA : smtpd_main.log
• rejets : smtpd_reject.log
• erreurs d’analyse : smtpd_error.log
• erreurs MTA internes : smtpd_panic.log
• anti-spam : sasi.log
• proxy SMTP legacy : awarrensmtp.log
• proxy POP/IMAP : warren.log

Services et logs Sophos Firewall explique la correspondance et l’accès via Advanced Shell.

Exploiter la quarantaine et le Mail spool

Sous Email > SMTP quarantine, filtrer par période, expéditeur, destinataire, objet et motif de quarantaine :

• Release : remettre le message.
• Delete : supprimer le message.
• Release and report : libérer et signaler à SophosLabs uniquement les faux positifs classés Spam ou Probable spam.

Les messages infectés par un virus ou classés malveillants par Zero-Day Protection ne peuvent pas être libérés. La suppression d’entrées Zero-Day Protection nécessite un droit d’écriture pour cette fonction dans le profil administrateur. Lorsque la quarantaine est pleine, les anciens messages sont purgés.

Seuls les utilisateurs qui se sont authentifiés au moins une fois auprès du pare-feu reçoivent les résumés de quarantaine. Les adresses alias doivent être contrôlées séparément dans la conception ; les messages destinés aux alias n’apparaissent pas dans User Portal.

Email > Mail spool contient les messages non encore remis ou en échec. SFOS retente la remise pendant trois jours et supprime les messages après quatre jours supplémentaires ; les messages supprimés restent visibles dans Mail logs. Un spool croissant signale donc un problème de routage, DNS, TLS, policy ou serveur de messagerie et ne justifie pas des clics répétés sur Retry sans diagnostic.

La quarantaine et le spool consomment du stockage local. Surveiller l’espace libre, l’état du SSD et System Health ; voir Nettoyer le stockage et les reports et Contrôler SSD Health. En HA, les logs et reports sont séparés pour chaque node et ne sont pas synchronisés ; il faut donc contrôler les deux. Clusters HA Sophos Firewall présente les bases.

Dépannage

Les e-mails externes n’arrivent pas

Contrôler MX, A/AAAA, l’IP publique, TCP 25 et SMTP Relay depuis WAN. Vérifier ensuite que MTA mode est actif, que le domaine protégé correspond à la policy et qu’aucune ancienne règle DNAT ou règle de priorité supérieure ne modifie le chemin attendu. Si smtpd_main.log ne montre aucune connexion, le problème se situe probablement avant Mail Protection.

Le pare-feu accepte mais ne remet pas le message

Contrôler le serveur interne, la route, le DNS, le port cible, TLS et recipient verification. Static host, DNS host et MX utilisent des chemins de résolution et de failover différents. Corréler les logs de rejet et d’erreur du pare-feu avec ceux du serveur.

De nombreux messages restent dans le spool

Contrôler d’abord Email > Mail spool et les logs MTA. Une cause fréquente est une règle placée au-dessus de la règle MTA automatique qui matche déjà SMTP. Sous Rules and policies > Firewall rules, vérifier les nouvelles règles en position Top, les règles IPsec ou hotspot générées automatiquement et les autres chevauchements. Ne déplacer aucune règle à l’aveugle ; son match SMTP réel est déterminant.

SFOS 22.0 MR2 corrige également NC-177930, qui laissait des messages dans le spool après un crash de mailpoller. Si le problème apparaît sur une version antérieure, inclure la version du firmware dans le diagnostic.

Central affiche Invalid API request

Sous SFOS 22.0 MR1, Release et Delete pouvaient échouer lorsque le pare-feu était ouvert via Sophos Central. Le workaround sûr consiste à se connecter directement au WebAdmin local et à effectuer l’action sous Email > SMTP quarantine. SFOS 22.0 MR2 Build 546 a corrigé le problème. S’il persiste, contrôler séparément le profil administrateur, l’accès Central et les permissions locales.

Impossible d’activer Reject based on RBL

Sophos répertorie sous NC-144563 un cas propre à SFOS 20.0.2 MR2 Build 378 : si les groupes RBL par défaut ont été renommés sous Email > Address group, il est impossible d’activer Reject based on RBL lors de la création d’une policy SMTP route and scan. Dans une policy existante, l’option ne peut plus être réactivée après sa désactivation. La Known Issues List actuelle n’indique aucune version corrigée.

Les groupes par défaut s’appellent Premium RBL services et Standard RBL services. Documenter d’abord le build exact et les noms actuels des groupes. Si ces deux conditions sont remplies, rétablir les noms d’origine des RBL par défaut, rouvrir la policy et vérifier l’option. Ne pas confondre les RBL personnalisées avec ces deux groupes système.

Sur d’autres builds, ou si les noms par défaut n’ont pas changé, une option grisée ne suffit pas à confirmer NC-144563. Vérifier séparément le type de policy, Spam protection, la licence Email Protection et le reste de la configuration.

Un expéditeur légitime est classé comme spam

Contrôler le domaine expéditeur, SPF/DKIM/DMARC, les headers, la réputation, le policy match et les destinataires concernés. Créer seulement ensuite une exception étroite avec une date de révision.

Les systèmes internes ne peuvent pas relayer

Contrôler la zone source sous Administration > Device access, l’objet hôte sous Email > Relay settings > Host-based relay et les logs MTA. Si un scanner attend SMTP AUTH standard, Host-based relay est généralement plus fiable. Le relais authentifié séparé, non conforme aux RFC, doit être testé avec le client concerné.

Checklist d’exploitation

• Licence, prise en charge du modèle, DNS et services Internet requis vérifiés.
• MX, TTL, chemins public et interne ainsi que repli documentés.
• Règle MTA automatique inchangée et maintenue en tête.
• Aucune ancienne règle DNAT ne contourne Mail Protection.
• Address Group, destination de routage et policy match testés.
• SMTP Relay entrant depuis WAN et autorisations d’hôtes sortantes correctement séparés.
• Effets de SPF/RBL, recipient verification, TLS, DKIM, SPX et des bannières compris.
• Tests externes positifs et négatifs effectués.
• Quarantaine, spool, stockage et logs surveillés.
• Flux de messagerie retesté après les mises à jour du firmware.

Pour une conservation et une corrélation plus longues, utiliser Central Firewall Reporting ou envoyer les logs Sophos Firewall à un SIEM.

FAQ