Configurer Sophos Firewall MTA avec Microsoft 365

Sophos Firewall peut fonctionner en MTA mode comme passerelle de messagerie distincte devant Microsoft 365. Les messages entrants atteignent d’abord le firewall, puis sont distribués à Exchange Online Protection. Exchange Online renvoie les messages sortants au firewall via un connecteur afin qu’ils soient analysés et transmis à Internet.

Cette conception est possible, mais elle n’est pas automatiquement la meilleure architecture. Sophos Email, Microsoft Defender for Office 365 et Mail Protection sur le firewall se chevauchent en partie. Avant tout changement, il faut définir le système responsable du spam, des malwares, de la quarantaine, de TLS, de DKIM et du diagnostic.

⚠️ Une autorisation de relais trop large peut transformer le firewall en open relay. Avant de modifier le MX, conserver une session d’administration locale, le flux existant et un chemin de secours testé. La bascule en production n’a lieu que lorsqu’une tentative de relais non autorisée est rejetée de manière fiable.

Dessiner d’abord le flux bidirectionnel

Le chemin entrant est Internet → Sophos Firewall MTA → Exchange Online Protection → boîte Microsoft 365. Le MX public pointe donc vers l’adresse SMTP publique du firewall. La politique SMTP route and scan distribue ensuite vers la cible Microsoft propre au tenant, par exemple example-com.mail.protection.outlook.com.

Le chemin sortant est Exchange Online → connecteur Microsoft 365 → Sophos Firewall MTA → Internet. Le firewall ne doit accepter le relais que depuis les réseaux Exchange Online Protection actuels. HELO, certificat, IP source publique, PTR/rDNS, SPF, DKIM et DMARC doivent correspondre à ce chemin.

Configurer Mail Protection en MTA mode explique les principes MTA, les champs de politique, la quarantaine et les logs. Cet article se concentre sur la liaison avec Microsoft 365.

Valeurs d’exemple et prérequis

L’exemple utilise le domaine example.com, le FQDN du firewall mail.example.com, l’adresse de documentation 192.0.2.25 et la cible du tenant example-com.mail.protection.outlook.com. Ils doivent être remplacés par le domaine réel, une adresse publique fixe et la véritable cible Microsoft. 192.0.2.25 appartient à TEST-NET et ne doit pas être utilisée en production.

TCP 25 doit fonctionner d’Internet vers le firewall, du firewall vers Microsoft 365 et du firewall vers les serveurs de messagerie externes. Il faut aussi une licence Email Protection adaptée, la prise en charge MTA par le modèle, un certificat publiquement approuvé, un accès DNS contrôlé et des droits sur Exchange Admin Center et le DNS autoritatif.

Les réseaux Exchange Online Protection changent. Ils ne sont pas copiés depuis un exemple statique, mais maintenus à partir de la liste des endpoints Microsoft 365 actuelle liée par Sophos. Il faut utiliser l’entrée Exchange Online obligatoire pour *.mail.protection.outlook.com et *.mx.microsoft sur TCP 25 (ID 10 dans l’instance Worldwide), et non l’ensemble bien plus vaste des adresses Exchange Online. Une autre instance cloud Microsoft nécessite sa propre liste. Un responsable et un intervalle de révision sont documentés pour les objets hôtes.

Relier Microsoft 365 et SFOS en huit étapes

1. Consigner le MX, le SPF, les connecteurs, les headers, l’IP source publique et le chemin de secours actuels.
2. Préparer MTA mode, la règle MTA automatique, le certificat et l’analyse sortante sur SFOS.
3. Créer des objets IP host distincts pour les plages EOP actuelles.
4. Autoriser SMTP Relay depuis WAN, limiter Host-based relay aux objets EOP et bloquer toutes les autres sources.
5. Créer une politique SMTP route and scan pour le domaine protégé et la cible Microsoft du tenant.
6. Créer dans Exchange Online un connecteur de Microsoft 365 vers l’adresse publique du firewall.
7. Modifier MX et SPF pendant une fenêtre de maintenance.
8. Valider les messages entrants, sortants et les relais rejetés avec headers, Mail logs, spool et traces Microsoft.

Préparer Sophos Firewall

MTA mode, règle automatique et certificat

Activer MTA mode sous Email > General settings. SFOS crée Auto added firewall policy for MTA pour SMTP et SMTPS. Cette règle n’est pas modifiée et reste en tête conformément à la recommandation Sophos. Si elle manque alors que MTA mode est actif, ne pas créer de remplacement Any-to-Any ; vérifier d’abord le mode, la configuration et le recours au support.

Dans SMTP settings, renseigner SMTP hostname avec le nom de domaine prévu. Choisir un certificat publiquement approuvé sous SMTP TLS configuration et laisser Allow invalid certificate désactivé. Scan outgoing mails doit être actif si les messages venant d’Exchange Online doivent également être analysés.

Autoriser le relais depuis les sources EOP

Sous Hosts and services > IP host, créer un objet clairement nommé pour chaque plage SMTP actuelle de cette entrée Microsoft, par exemple avec le préfixe O365_EOP_. Ne pas regrouper ces plages dans un réseau plus large. Si SMTP est publié ou routé en IPv6, couvrir également les plages IPv6 indiquées ; sinon, veiller à ce qu’aucun chemin IPv6 involontaire ne contourne le contrôle IPv4. Après une modification Microsoft, ajouter ou retirer les réseaux de manière contrôlée et les retester.

Activer SMTP Relay pour WAN sous Administration > Device access. Ce sélecteur de zone est trop large à lui seul ; le restreindre sous Email > Relay settings > Host-based relay :

• Allow relay from hosts/networks: uniquement les objets EOP maintenus ;
• Block relay from hosts/networks: Any.

Sophos évalue une correspondance Allow avant le Block qui la chevauche. La liste Allow ne doit donc contenir aucun réseau étendu de fournisseur, de cloud ou Any. Upstream host définit séparément les réseaux dont les messages entrants destinés aux domaines protégés sont acceptés ; cette autorisation n’accorde pas à ces sources un relais sortant illimité.

Pour le courrier Internet entrant normal, la procédure Sophos définit Upstream host > Allow relay from hosts/networks sur Any. Cela permet aux hôtes SMTP externes de distribuer vers les domaines protégés ; il ne s’agit pas de la même autorisation que le Host-based relay sortant. Si une passerelle externe définie se trouve déjà devant SFOS, la liste Upstream est limitée à ses réseaux sources réels.

Politique route and scan pour la distribution Microsoft

Créer le domaine protégé comme Email address/domain sous Email > Address group. Ajouter ensuite sous Email > Policies and exceptions > Add a policy > SMTP route and scan une politique avec :

• l’Address Group sous Protected domain ;
• Global action: Accept ;
• Route by: DNS host et la cible Microsoft propre au tenant ;
• des paramètres de protection spam, malware, fichiers et données choisis consciemment.

L’hôte de routing n’est pas le MX public de example.com après que celui-ci pointe vers le firewall. Sinon, le firewall se distribue à lui-même et crée une boucle. La véritable cible Microsoft est enregistrée avant la modification du MX et sa résolution par SFOS est vérifiée.

Créer le connecteur Exchange Online

Dans Exchange Admin Center, ouvrir Mail flow > Connectors > Add a connector, puis sélectionner Connection from: Office 365 et Connection to: Partner organization. Sous Use of connector, choisir Only when email messages are sent to these domains et saisir * pour acheminer tout le courrier sortant via SFOS. Une liste de domaines volontairement limitée doit correspondre à la conception documentée. Sous Routing, sélectionner Route email through these smart hosts, puis utiliser l’IP publique ou le FQDN mail.example.com du firewall. Ces champs suivent la procédure Microsoft 365 actuelle de Sophos.

Sous Security restrictions, activer Always use Transport Layer Security (TLS) to secure the connection (recommended). La procédure Sophos sélectionne ensuite Any digital certificate, including self-signed certificates. Ce choix impose TLS, mais ne vérifie ni une autorité de certification approuvée ni le nom. En production, suivre la documentation Microsoft sur les connecteurs : sélectionner Issued by a trusted certificate authority (CA) et exiger aussi le nom de sujet ou SAN mail.example.com. Remplacer ce nom par le véritable FQDN du firewall et le valider avec un test du connecteur.

La validation du connecteur peut échouer avant le changement DNS. Elle ne remplace donc ni le test de bout en bout ultérieur ni le test négatif du relais. Après l’enregistrement, Microsoft Message Trace doit confirmer que les messages sortants utilisent réellement le connecteur et le firewall prévus.

Modifier MX et SPF de manière contrôlée

Le MX public ne pointe vers mail.example.com que lorsque la politique du firewall, le relais EOP, la cible Microsoft interne et le connecteur sont prêts. Réduire la TTL avant la fenêtre de maintenance. Garder l’ancienne cible MX disponible pour le rollback documenté, mais pas en parallèle si des expéditeurs peuvent contourner aléatoirement la nouvelle protection.

Le SPF doit autoriser chaque source qui envoie réellement vers Internet. Sophos donne v=spf1 include:spf.protection.outlook.com mx -all comme exemple simple : mx autorise les adresses des hôtes MX, tandis que include:spf.protection.outlook.com reste nécessaire si Exchange Online envoie aussi directement vers Internet pour ce domaine. Si tout le courrier externe sort sans exception par SFOS, il n’est pas utile d’autoriser par habitude un chemin direct Microsoft inutilisé. Ne jamais remplacer aveuglément l’enregistrement existant : inventorier d’abord les autres services d’envoi, les sous-domaines, les chaînes include et la limite SPF documentée par Microsoft de dix mécanismes déclenchant des requêtes DNS. Des headers réels doivent ensuite confirmer que SPF réussit pour la dernière IP d’envoi observée et que DKIM et DMARC restent alignés.

Valider le chemin complet

Depuis un système de test externe, les contrôles en lecture seule suivants sont utiles :

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

Remplacer les noms d’exemple par les valeurs réelles. DNS, TCP et TLS ne prouvent pas la distribution. Tester au minimum un message externe vers Microsoft 365, un message sortant depuis Microsoft 365, un destinataire invalide et une tentative de relais depuis une IP non autorisée.

Sur SFOS, corréler Email > Mail logs, Mail spool, SMTP quarantine, Log Viewer, smtpd_main.log, smtpd_reject.log et smtpd_error.log au même instant. Côté Microsoft, Message Trace et l’état du connecteur indiquent si EOP a accepté ou envoyé le message. Services et logs de Sophos Firewall classe les fichiers de log.

Isoler les erreurs selon le symptôme

Le courrier externe n’atteint pas Microsoft 365

Contrôler d’abord le MX, l’adresse publique, TCP 25, SMTP Relay depuis WAN, la règle MTA automatique et les Mail logs. Si SFOS accepte mais ne distribue pas, vérifier la résolution DNS de la cible du tenant, la politique route and scan, TLS et le spool.

Le courrier sortant contourne le firewall

Contrôler la portée et la priorité du connecteur ainsi que Message Trace dans Exchange Admin Center. N’évaluer la correspondance du relais SFOS, la politique et l’adresse source publique que lorsque la trace montre le firewall comme smarthost. Avec plusieurs WAN, consulter la section correspondante dans Mail Protection en MTA mode.

Le relais est rejeté ou serait trop largement autorisé

Comparer l’IP source EOP réelle à la liste Microsoft actuelle et aux objets SFOS. Un réseau EOP autorisé doit figurer sous Allow relay from hosts/networks ; toutes les autres sources atteignent Block relay from hosts/networks: Any. Une autorisation cloud ou WAN étendue n’est pas une correction.

TLS ou la validation du connecteur échoue

Contrôler séparément le FQDN, le DNS public, le nom du certificat, la chaîne complète, la validité et STARTTLS. Un openssl s_client réussi confirme l’endpoint du firewall, pas la portée du connecteur ni la distribution complète. Allow invalid certificate n’est pas une solution permanente.

Une boucle de messagerie se produit

Comparer le MX public et la cible de la politique SMTP route and scan. Si les deux pointent vers mail.example.com, corriger la politique vers la cible Microsoft du tenant. Restaurer l’ancien chemin documenté tant que le routing n’est pas sans ambiguïté.

Effectuer un rollback sûr

Le rollback restaure l’état antérieur consigné, et non une valeur par défaut supposée. Rétablir d’abord exactement l’état d’activation, la portée, le routage et les paramètres TLS précédents du connecteur Exchange Online ; ne le désactiver que s’il a été créé pour cette modification. Restaurer ensuite les cibles et priorités MX enregistrées ainsi que la valeur TXT SPF antérieure complète. Vérifier que le DNS autoritatif et plusieurs résolveurs publics renvoient les anciennes valeurs.

Conserver la politique pilote, les objets EOP et les entrées de relais jusqu’à ce que les tests entrants et sortants fonctionnent de nouveau par l’ancien chemin et que l’ancienne TTL DNS soit écoulée. Ne supprimer ensuite que les éléments créés pour cette modification ; ne pas toucher aux objets préexistants ou partagés.

Ne pas supprimer aveuglément les messages du spool ou de la quarantaine. Ils font partie de la transition documentée et ne sont traités qu’après vérification de l’expéditeur, du destinataire et du chemin souhaité.

Checklist d’exploitation

• Les responsabilités de SFOS, Microsoft 365 et des autres passerelles sont définies.
• L’ancien MX, SPF, connecteur et flux sont documentés comme solution de secours.
• Les objets EOP proviennent de la liste Microsoft actuelle et ont un responsable.
• SMTP Relay n’est utilisable que par des entrées Host-based relay précises ; les sources non autorisées sont rejetées.
• La politique route and scan pointe vers la cible Microsoft du tenant et non vers le MX public.
• Connecteur, certificat, DNS, MX, SPF, DKIM et DMARC ont été validés avec de vrais messages.
• Les tests entrant, sortant, destinataire invalide et relais non autorisé ont réussi.
• Mail logs, spool, quarantaine et Microsoft Message Trace peuvent être corrélés dans le temps.
• Les réseaux EOP et l’expiration du certificat sont révisés régulièrement.

FAQ