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 Central 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. Les endpoints SMTP sur TCP 25 sont particulièrement importants. Un responsable et un intervalle de révision sont documentés pour les objets hôtes.

Relier Microsoft 365 et SFOS en huit étapes

Consigner le MX, le SPF, les connecteurs, les headers, l’IP source publique et le chemin de secours actuels.
Préparer MTA mode, la règle MTA automatique, le certificat et l’analyse sortante sur SFOS.
Créer des objets IP host distincts pour les plages EOP actuelles.
Autoriser SMTP Relay depuis WAN, limiter Host-based relay aux objets EOP et bloquer toutes les autres sources.
Créer une politique SMTP route and scan pour le domaine protégé et la cible Microsoft du tenant.
Créer dans Exchange Online un connecteur de Microsoft 365 vers l’adresse publique du firewall.
Modifier MX et SPF pendant une fenêtre de maintenance.
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 IPv4 EOP actuelle, par exemple avec le préfixe O365_EOP_. Ne pas regrouper ces plages dans un réseau plus large. 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 commande une relation de destination distincte et ne remplace pas ce contrôle de source.

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, créer sous Mail flow > Connectors un connecteur From: Office 365 et To: Partner organization. Pour faire passer tout le courrier sortant par SFOS, appliquer sa condition de destination à tous les domaines destinataires (*). Un sous-ensemble volontairement limité doit correspondre à la conception documentée. L’IP publique ou le FQDN mail.example.com du firewall sert de smarthost.

Exiger TLS pour le connecteur. L’aide Sophos présente aussi une option compatible acceptant tout certificat numérique, y compris autosigné. En production, un certificat publiquement approuvé dont l’identité correspond au FQDN est plus robuste et doit être validé par un véritable 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 Exchange Online et l’identité source publique du firewall. Sophos donne v=spf1 include:spf.protection.outlook.com mx -all comme exemple simple. Ne pas remplacer aveuglément l’enregistrement existant : inventorier d’abord les autres expéditeurs, sous-domaines, chaînes include et la limite de requêtes DNS. Revérifier DKIM et DMARC dans de véritables headers.

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

Désactiver d’abord le connecteur Exchange Online ou restaurer son état antérieur. Restaurer ensuite MX et SPF et vérifier leur résolution publique. Ne supprimer la politique pilote, les objets EOP et les entrées de relais sur SFOS qu’après le retour des tests entrants et sortants par l’ancien chemin.

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

Microsoft 365 nécessite-t-il obligatoirement Sophos Firewall comme MTA ?

Non. Ce chemin est une architecture de passerelle possible. Sophos Central Email ou la protection cloud de Microsoft peuvent être plus simples pour un environnement exclusivement cloud. L’essentiel est une répartition volontaire des responsabilités sans double analyse imprévue.

Host-based relay peut-il simplement autoriser Any ?

Non. Pour Microsoft 365, seuls les réseaux sources EOP actuels sont autorisés. Any appartient à la liste Block afin de rejeter toute source qui n’est pas explicitement permise.

Pourquoi la politique route and scan ne doit-elle pas utiliser le MX public ?

Parce que le MX public pointe vers le firewall après la bascule. Si la politique résolvait le même MX, SFOS se distribuerait à lui-même. La cible doit être l’hôte Microsoft 365 propre au tenant.