Configurer Sophos Firewall Mail Protection en mode MTA

Sophos Firewall peut non seulement autoriser le trafic email comme une connexion de pare-feu normale, mais aussi fonctionner en mode MTA comme Mail Transfer Agent entre Internet et le serveur de messagerie interne. Le pare-feu accepte les connexions SMTP, contrôle les messages avec Mail Protection, puis les remet au serveur de messagerie défini.

Aujourd’hui, nous recommandons Mail Protection sur le pare-feu uniquement pour des cas particuliers planifiés consciemment, par exemple lorsqu’un serveur Exchange local ou un autre serveur de messagerie interne doit être protégé directement par le pare-feu. Pour Microsoft 365, Google Workspace et la plupart des environnements de messagerie cloud modernes, Sophos Central Email est généralement la meilleure solution. Central Email est plus proche du service de messagerie réel, s’intègre plus proprement aux boîtes aux lettres cloud, réduit la complexité dans le jeu de règles du pare-feu et évite de nombreux sujets MTA classiques comme les changements MX, les spools locaux, les questions de relais et l’analyse des erreurs sur le pare-feu.

Autre point pratique : par rapport à Sophos Central Email, Email Protection sur le pare-feu ressemble depuis un certain temps à une fonction de parc existant, surtout pertinente pour les serveurs de messagerie on-premises déjà en place. Pour une nouvelle planification aujourd’hui, il faut donc d’abord vérifier si une passerelle de messagerie cloud constitue l’architecture la plus propre.

La solution est techniquement puissante, mais aussi sensible aux erreurs si DNS, enregistrement MX, TLS, relais, vérification des utilisateurs, policies et logs ne sont pas planifiés proprement. Un MTA mal configuré peut bloquer des emails légitimes, retarder le mailflow ou, dans le pire des cas, être compris comme un relais.

Cet article explique la mise en place pratique de Sophos Firewall Mail Protection en mode MTA. Il ne remplace pas une planification Sophos Central Email. Pour de nombreux environnements Microsoft 365 ou Google Workspace, une passerelle de messagerie cloud est souvent plus adaptée. Mais lorsqu’un Exchange local, un serveur de messagerie hybride ou un chemin SMTP volontairement basé sur le pare-feu est exploité, un plan d’exploitation clair est nécessaire.

Quand Mail Protection sur le pare-feu est pertinente

Mail Protection sur Sophos Firewall est surtout pertinente lorsque le trafic SMTP doit volontairement passer par le pare-feu et que celui-ci doit faire plus que simplement transférer le port 25.

Scénarios typiques :

• Les emails entrants doivent d’abord être acceptés et contrôlés sur le pare-feu.
• Un serveur de messagerie interne ne doit pas être joignable directement depuis Internet.
• Le contrôle du spam, des malwares, des types de fichiers ou du contenu doit s’appliquer avant la remise.
• Les emails sortants doivent être envoyés de manière contrôlée via le pare-feu ou un smarthost.
• La quarantaine, le mail spool et les logs SMTP doivent être traçables sur le pare-feu.

Toutes les configurations de messagerie ne doivent pas passer par le pare-feu. Si Sophos Central Email, Microsoft Defender for Office 365 ou une autre passerelle de messagerie cloud prend déjà en charge tout le mailflow, il ne faut pas intercaler Mail Protection sur le pare-feu en plus sans documenter précisément le flux de messagerie. Les passerelles doublées entraînent rapidement des responsabilités peu claires pour la quarantaine, les en-têtes, SPF/DKIM/DMARC, TLS et le dépannage.

Distinguer mode MTA, Legacy mode et SMTP Relay

Avec Sophos Firewall, trois éléments doivent être clairement séparés :

• MTA mode: Le pare-feu accepte les emails, les contrôle et les remet ensuite. Mailflow SMTP entrant ou sortant avec policies.
• Legacy mode: ancien traitement mail basé sur proxy. Environnements existants migrés ou volontairement maintenus.
• SMTP Relay comme service local: des systèmes internes envoient via le pare-feu. Imprimantes, scanners, applications ou systèmes de monitoring.

Le MTA mode est le mode cible normal pour les scénarios modernes de Mail Protection sur pare-feu. Le service local SMTP Relay, en revanche, relève de Device Access. Il ne doit être joignable que depuis des réseaux internes définis. Une autorisation trop large peut favoriser l’abus de relais. Le durcissement des services locaux est décrit dans Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access.

Prérequis

Avant la configuration, ces points doivent être clarifiés :

• Sophos Firewall avec Email Protection valide ou bundle adapté.
• Tous les modèles ne prennent pas en charge le MTA mode. Les XGS 87 et XGS 88 sont des appliances sans prise en charge du MTA mode.
• La zone DNS publique et l’enregistrement MX sont connus.
• Le serveur de messagerie interne, le port cible et le chemin de remise sont documentés.
• L’adresse IP publique ou l’adresse WAN pour le trafic SMTP entrant est définie.
• Le pare-feu peut router vers le serveur de messagerie interne et l’atteindre.
• L’accès DNS sortant du pare-feu fonctionne.
• La stratégie TLS et certificats souhaitée est clarifiée.
• Le processus de quarantaine et de libération est défini au niveau organisationnel.

Avant de modifier le mailflow, une fenêtre de maintenance doit être planifiée. Un test sur des enregistrements MX productifs sans plan de retour arrière est risqué, car les emails entrants peuvent être rapidement retardés ou refusés selon l’expéditeur.

Définir l’architecture cible

Il faut d’abord décider quelle direction le pare-feu doit traiter.

Mailflow entrant

Pour le mailflow entrant, les enregistrements MX externes pointent vers l’adresse publique sur laquelle Sophos Firewall accepte SMTP. Le pare-feu contrôle le message et le transmet au serveur de messagerie interne.

Déroulement typique :

1. L’expéditeur externe se connecte par SMTP à l’adresse MX publique.
2. Sophos Firewall accepte la connexion en MTA mode.
3. Mail Protection contrôle l’expéditeur, le destinataire, le spam, les malwares, les pièces jointes et la policy.
4. Le pare-feu remet l’email au serveur de messagerie interne.
5. Le serveur de messagerie interne livre dans la boîte aux lettres ou traite le message.

Il est important que le serveur de messagerie interne ne reste pas également joignable sans filtrage depuis Internet. Si une règle DNAT pointe encore directement vers le serveur de messagerie en parallèle, une partie du trafic peut contourner Mail Protection. Pour les publications de serveurs normales, Publier un serveur avec DNAT constitue la base adaptée, mais en MTA mode le pare-feu lui-même est le point d’acceptation SMTP.

Mailflow sortant

Pour le mailflow sortant, le serveur de messagerie interne envoie via Sophos Firewall. Selon la configuration, le pare-feu peut contrôler les messages, les transférer à un smarthost ou les remettre directement.

Clarifier au préalable :

• L’adresse IP publique du pare-feu est-elle autorisée à envoyer des emails directement ?
• SPF, DKIM et DMARC correspondent-ils au chemin d’envoi choisi ?
• Un smarthost de fournisseur est-il nécessaire ?
• Le trafic SMTP sortant doit-il être limité à certains systèmes internes ?
• Où les messages refusés ou retardés sont-ils surveillés ?

Pour le trafic mail sortant, il faut utiliser une structure de règles et de policies dédiée et traçable. Une règle générale LAN to WAN sans restriction claire est généralement trop large pour des serveurs de messagerie. Les bases de l’ordre des règles et des profils de sécurité sont décrites dans Comprendre et construire proprement les règles Sophos Firewall.

Préparer le changement MX et les tests externes

Un changement Mail Protection devient critique uniquement lorsque les expéditeurs externes utilisent réellement le nouveau chemin. Il faut donc vérifier l’enregistrement MX, le DNS TTL, la joignabilité externe et le rollback avant le passage en production.

Avant le changement :

• Documenter l’enregistrement MX actuel, la priorité et le TTL.
• Réduire le DNS TTL suffisamment tôt si un retour rapide peut être nécessaire.
• Distinguer clairement l’ancien chemin mail et la nouvelle adresse Sophos Firewall.
• Identifier les anciennes règles DNAT directes vers le serveur de messagerie.
• Définir les destinataires et expéditeurs de test.
• Définir le plan de retour arrière : ancien MX, ancienne règle DNAT ou smarthost temporaire.
• Préparer le monitoring du spool, de la quarantaine et de la queue du serveur de messagerie.

Contrôles externes utiles depuis un système hors du réseau propre :

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

Ces commandes ne remplacent pas un test complet du mailflow, mais montrent rapidement si DNS, port 25 et STARTTLS sont globalement joignables. example.com et mail.example.com doivent être remplacés par le domaine réel et l’hôte mail réel.

Après le basculement, il faut envoyer immédiatement un email de test entrant et documenter tout le chemin :

• Connexion visible dans Log Viewer ?
• Entrée présente dans smtpd_main.log ?
• Vérification du destinataire réussie ?
• Remise au serveur de messagerie interne effectuée ?
• Message arrivé dans la boîte aux lettres ?
• Pas de remise directe parallèle contournant le MTA ?

Si le pare-feu accepte les emails mais ne les remet pas, il ne faut pas remettre immédiatement le MX en arrière. Il faut d’abord clarifier s’il s’agit d’un problème interne de routage, DNS, TLS ou serveur de messagerie. Mais si les expéditeurs externes ne peuvent pas établir de connexion au pare-feu ou si des emails légitimes sont largement refusés, un retour rapide au chemin mail précédent est souvent plus judicieux que de longues expérimentations dans le chemin MX productif.

Activer le MTA mode

Les paramètres de base se trouvent dans Sophos Firewall sous :

Email > General settings

Pour ce guide, MTA mode doit être actif. Si le firewall fonctionne encore en Legacy Mode, le passage se fait avec Switch to MTA mode.

Après l’activation, Sophos Firewall crée automatiquement une règle de firewall pour SMTP/SMTPS nommée Auto added firewall policy for MTA. Cette règle doit rester visible et placée haut dans la base de règles. Une règle MTA ne doit pas être traitée comme une règle LAN-to-WAN normale ni déplacée vers le bas au passage, sinon le trafic SMTP entrant ne suit plus le chemin MTA attendu.

Les paramètres de base sont ensuite vérifiés:

1. Sous SMTP settings, définir le SMTP hostname. C’est le hostname que le firewall utilise dans les contextes HELO et banner pour les messages générés par le système. Ne pas saisir aveuglément le nom du serveur mail interne si le nom mail public est différent.
2. Activer Reject based on IP reputation si les connexions SMTP entrantes doivent être rejetées selon une mauvaise réputation d’expéditeur.
3. Sous SMTP TLS configuration, choisir un certificat public fiable adapté si SMTP TLS doit être présenté proprement par le firewall.
4. Activer Disable legacy TLS protocols, sauf si des anciens systèmes documentés s’y opposent.
5. Activer Scan outgoing mails si les messages sortants du serveur mail doivent également être contrôlés par le firewall.

Dans les environnements existants, ne pas basculer simplement entre Legacy mode et MTA mode sans tester le mailflow. Le traitement, les logs et la logique de policy diffèrent. Avant une migration, la configuration actuelle du pare-feu, les enregistrements MX, les connecteurs du serveur de messagerie et les paramètres de relais doivent être documentés.

Configurer le routage SMTP et les domaines

Pour les emails entrants, le pare-feu doit savoir quels domaines il doit accepter et où il doit les remettre.

Créer une Address Group pour les domaines mail

Une Address Group est d’abord créée pour les domaines mail protégés:

1. Ouvrir Email > Address group.
2. Cliquer sur Add.
3. Vérifier que Group type est défini sur Email address/domain.
4. Laisser Type sur Manual si les domaines sont maintenus manuellement.
5. Sous Email address/domain, saisir le domaine, par exemple example.com, puis l’ajouter.
6. Cliquer sur Save.

Il s’agit ici de domaines, pas d’adresses de destinataires individuelles. Des adresses existantes ou migrées peuvent encore intervenir selon la configuration, mais dans les SMTP route and scan policies actuelles elles ne doivent plus être planifiées comme nouveaux éléments. Pour un état cible propre, il faut donc travailler avec des domaines et une vérification adaptée des destinataires.

Créer une SMTP route and scan Policy

La policy MTA proprement dite est créée sous le chemin suivant:

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

Déroulement typique pour les mails entrants vers un serveur mail interne:

1. Définir un Name parlant, par exemple Inbound example.com to Exchange.
2. Sous Protected domain, sélectionner l’Address Group créée précédemment.
3. Définir Route by:
   • Static host: pour des adresses IP fixes de serveurs mail internes.
   • DNS host: pour un nom DNS comme mailserver.example.com.
   • MX: si le firewall doit remettre selon les enregistrements MX.
4. Avec Static host, sélectionner le serveur mail interne sous Host list. Les IP hosts sont créés au besoin sous Hosts and services > IP host.
5. Régler Global action sur Accept si le domaine doit être accepté et contrôlé selon la policy.
6. Activer Spam protection et décider consciemment si le spam doit être marqué, mis en quarantaine, droppé ou remis sans action.
7. Activer Malware protection. Pour Zero-Day Protection avec Single-Antivirus-Scan, Sophos doit être utilisé comme moteur primaire.
8. Activer File protection et Data protection uniquement si les effets sur les pièces jointes, les grands messages, SPX et DKIM sont compris.
9. Cliquer sur Save.

Avec plusieurs serveurs mail internes, le type de routage est important. Avec Static host, le firewall passe à l’hôte suivant si le premier n’est pas joignable. Avec DNS host et plusieurs A-Records, la remise peut être répartie. C’est pratique, mais cela doit correspondre au design mail, aux certificats TLS et à l’analyse d’erreurs.

Le DNS est particulièrement important pour les serveurs de messagerie internes. Le pare-feu doit pouvoir résoudre correctement les cibles internes, et les expéditeurs externes doivent atteindre l’entrée MX publique. Si la résolution DNS interne joue un rôle, Configurer DNS Request Routes sur Sophos Firewall aide.

Planifier les policies pour le spam, les malwares et les pièces jointes

Mail Protection n’est aussi efficace que les policies qui s’appliquent réellement. Une policy ne doit pas seulement être créée, mais nommée avec un objectif clair.

Questions importantes sur les policies :

• Quels domaines ou groupes de destinataires sont concernés ?
• Le trafic mail entrant, sortant ou bidirectionnel est-il traité ?
• Que se passe-t-il en cas de spam, malware, pièces jointes suspectes ou types de fichiers indésirables ?
• Les emails sont-ils bloqués, mis en quarantaine, remis ou marqués avec des en-têtes ?
• Recipient verification par Callout ou Active Directory doit-elle être utilisée?
• Qui peut vérifier la quarantaine et libérer des emails ?
• Quels processus de faux positifs existent ?

Avec Spam Protection, SPF, RBL, Greylisting, BATV et Recipient verification ne doivent pas être traités comme de simples cases à cocher. Les détections RBL ou SPF ne sont pas traitées comme des actions spam normales; elles peuvent rejeter directement des messages. Recipient verification réduit le backscatter et les destinataires invalides, mais peut devenir elle-même une source d’erreurs en cas de problèmes AD, TLS ou serveur mail.

Pour les messages sortants, DKIM est particulièrement sensible. Le chiffrement SPX, les préfixes de sujet, les types de fichiers bloqués, Data Protection ou une bannière sortante peuvent modifier les headers ou le body. Le hash DKIM peut alors casser chez le MTA destinataire. Si les signatures sortantes sont importantes, il faut décider si la signature se fait sur le serveur mail, sur Sophos Firewall ou sur une gateway ultérieure.

Si Zero-Day Protection est utilisé, les pièces jointes suspectes peuvent être analysées en plus. Les limites, rapports et décisions de libération sont expliqués dans Comprendre et exploiter Sophos Firewall Zero-Day Protection.

Sécuriser le relais et Device Access

Une erreur fréquente consiste à confondre mailflow MTA et relais SMTP ouvert. Le pare-feu ne doit pas pouvoir être utilisé comme relais depuis des réseaux arbitraires.

Vérifier :

• Sous Administration > Device access, SMTP Relay est joignable uniquement depuis les zones internes nécessaires.
• Si des ACL Exception Rules sont utilisées, les sources sont définies de manière stricte.
• Sous Email > Relay settings, seuls des serveurs mail, scanners ou serveurs applicatifs définis sont inscrits comme sources autorisées dans Host-based relay.
• Les zones non nécessaires, les réseaux invités et les réseaux untrusted ne doivent pas pouvoir relayer globalement.
• Si des services cloud comme Exchange Online Protection doivent remettre ou relayer via le firewall, les plages sources autorisées doivent être maintenues très précisément. Les autorisations larges Any sont un risque d’Open Relay.
• La journalisation est active afin que les abus ou mauvaises configurations soient visibles.

Si des imprimantes, scanners ou applications doivent envoyer des emails, il faut documenter pour cela un chemin de relais interne dédié. Ces systèmes ne doivent pas communiquer directement avec n’importe quelles destinations SMTP externes si l’environnement peut l’éviter.

Tester le mailflow

Après la configuration, un seul envoi réussi ne suffit pas. Plusieurs tests doivent être effectués et les résultats documentés.

Tester l’entrant

Vérifier au minimum :

• L’enregistrement MX externe pointe vers l’adresse attendue.
• Le port 25 est joignable depuis l’extérieur.
• Le pare-feu accepte la connexion en MTA mode.
• L’email est transféré au serveur de messagerie interne.
• Le destinataire existe et reçoit le message.
• Le test spam ou malware est traité comme attendu.
• L’entrée de quarantaine ou de log est traçable.

Tester le sortant

Vérifier au minimum :

• Le serveur de messagerie interne envoie par la route attendue.
• La règle de pare-feu et la mail policy s’appliquent.
• SPF, DKIM et DMARC correspondent au chemin d’envoi.
• Le serveur cible accepte le message.
• Les bounces ou messages Deferred sont surveillés.
• Aucun autre système interne n’envoie directement vers l’extérieur de façon non planifiée.

Vérifier les logs

Pour un contrôle visuel rapide, Log Viewer aide. Pour une analyse plus profonde, les fichiers de logs mail sont importants. La correspondance est indiquée dans Dépannage Sophos Firewall : services et logs.

Fichiers de logs pertinents :

• SMTP MTA: smtpd_main.log.
• Erreurs SMTP: smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Anti-Spam: sasi.log.
• Legacy SMTP/MTA: awarrensmtp.log, awarrenmta.log, awarrenmta_debug.log.
• POP/IMAP Proxy: warren.log.

En dépannage urgent, il faut noter l’heure du test, collecter expéditeur, destinataire, objet, IP source et Message-ID, puis corréler Log Viewer et fichiers de logs dans le temps.

Quarantaine, spool et stockage

Mail Protection génère des données locales. Selon le volume, les messages arrivent dans la quarantaine, le spool ou des zones temporaires. L’espace de stockage, l’état du SSD et le plan de recovery deviennent donc plus importants qu’avec une simple règle de pare-feu.

Questions pratiques d’exploitation :

• Qui vérifie la quarantaine et à quelle fréquence ?
• Comment les faux positifs sont-ils libérés ?
• Quand un message est-il supprimé plutôt que libéré ?
• Comment un mail spool en croissance est-il détecté ?
• Existe-t-il un monitoring de l’espace de stockage et du System Health ?
• Un bref test du mailflow est-il prévu après les mises à jour de firmware ?

Pour les sujets de stockage et de reporting, Nettoyer le stockage et les rapports Sophos Firewall et Vérifier le SSD Health de Sophos Firewall conviennent. Dans les environnements HA, il faut aussi noter que la quarantaine mail et les données mail traitées peuvent être des données d’exploitation liées au noeud. Les bases HA sont décrites dans Variantes de cluster HA Sophos Firewall.

Vérifier la quarantaine directement dans WebAdmin

Si un firewall est géré via Sophos Central, l’accès par Central est pratique. Pour Mail Protection, il faut tout de même savoir où se trouve la quarantaine localement et comment la vérifier directement sur le firewall.

Email > SMTP quarantine

On peut y filtrer les messages en quarantaine par période, expéditeur, destinataire, objet et motif de quarantaine. Pour l’exploitation, trois actions sont surtout importantes:

• Delete: Supprimer le message de la quarantaine.
• Release: Libérer le message vers le destinataire.
• Release and report: Libérer le message et le signaler comme mal classé.

Il existe un cas particulier important avec SFOS 22.0 MR1: si le firewall est géré via Sophos Central, des actions de quarantaine comme Release ou Delete peuvent échouer avec Invalid API request. Cela ne signifie pas automatiquement que le flux mail, la quarantaine ou la policy MTA est défectueux. Le contournement pratique consiste à se connecter directement au WebAdmin local du firewall et à libérer ou supprimer le message sous Email > SMTP quarantine.

Après une mise à jour vers SFOS 22.0 MR2 ou une version plus récente, il faut retester le processus: mettre un message de test inoffensif en quarantaine, exécuter l’action via le chemin d’administration prévu, puis vérifier Log Viewer, la quarantaine et la boîte du destinataire.

Dépannage

Les emails externes n’arrivent pas

Vérifier d’abord DNS et joignabilité : enregistrement MX, IP publique, port 25, anciens éléments NAT, MTA mode et domaine mail responsable. Vérifier ensuite dans Log Viewer et dans smtpd_main.log si la connexion atteint le pare-feu. Si aucune connexion n’est visible, le problème se situe probablement avant Mail Protection.

Le pare-feu accepte les emails, mais ne les remet pas

Le serveur de messagerie interne, le routage, DNS, le port cible, TLS, la vérification du destinataire ou la policy sont alors plus probables. Il faut vérifier si le pare-feu peut atteindre le serveur de messagerie et si celui-ci accepte la connexion. Les reject logs et les logs du serveur de messagerie doivent être évalués ensemble dans le temps.

Beaucoup d’emails restent dans le spool

Un spool qui grossit indique souvent des problèmes de remise : serveur de messagerie interne non joignable, exigence TLS inadéquate, échec de résolution DNS ou refus du message par le serveur cible. Dans ce cas, il ne faut pas seulement remettre des messages isolés, mais chercher la cause dans le chemin de routage et SMTP.

Un cas important d’ordre des règles est facile à manquer : si une règle de pare-feu créée automatiquement ou manuellement se trouve au-dessus de la règle MTA et matche le trafic SMTP, la règle MTA réelle n’est plus évaluée. Des emails peuvent alors rester bloqués dans le mail spool même si DNS, le port 25 et le serveur de messagerie semblent globalement corrects.

Vérifier :

1. Ouvrir Rules and policies > Firewall rules.
2. Vérifier les règles au-dessus de la règle MTA ou SMTP.
3. Contrôler les nouvelles règles automatiques, règles IPsec, règles hotspot ou règles placées manuellement sur Top.
4. Réaliser à nouveau le test SMTP et comparer Log Viewer, mail spool et smtpd_main.log.

La règle ne doit pas être déplacée aveuglément vers le bas si elle remplit d’autres objectifs productifs. Le point décisif est de savoir si elle intercepte de manière inattendue le trafic SMTP avant la règle MTA.

Digest de quarantaine manquant pour les adresses alias

Si les utilisateurs emploient des adresses alias, il ne faut pas vérifier les paramètres de quarantaine uniquement pour l’adresse email primaire. Selon Sophos, les paramètres de quarantaine ne sont pas appliqués automatiquement par défaut aux adresses alias. Si des emails digest ou des libérations manquent pour des destinataires alias, les adresses alias doivent être prises en compte avec l’adresse primaire dans le contexte de quarantaine ou d’utilisateur.

Un expéditeur légitime est reconnu comme spam

Les faux positifs ne doivent pas être traités immédiatement par de larges exceptions. Vérifier d’abord le domaine expéditeur, SPF/DKIM/DMARC, les en-têtes, la réputation, le match de policy et les destinataires concernés. Si une exception est nécessaire, elle doit être strictement limitée et documentée avec une date de revue.

Les systèmes internes ne peuvent pas relayer

Vérifier si SMTP Relay sous Administration > Device access est autorisé depuis la bonne zone et si la source correspond à l’ACL. Vérifier ensuite les logs mail. Si un scanner ou une application doit relayer, la source doit être documentée comme objet hôte, et il ne faut pas autoriser inutilement tout un réseau.

Le comportement mail change après une mise à jour de firmware

Après les mises à jour de firmware, MTA mode, policies, certificats, mail spool, quarantaine et logs pertinents doivent être vérifiés. Pour les mises à jour plus importantes, Vérifier Sophos Firewall avant la mise à niveau SFOS 22 convient également.

Une action de quarantaine affiche Invalid API request

Si Release ou Delete échoue avec Invalid API request sur un firewall ouvert via Sophos Central, vérifier d’abord la version SFOS. Avec SFOS 22.0 MR1, ce flux peut être concerné.

L’étape suivante n’est pas de reconstruire la policy mail. Il faut d’abord passer au WebAdmin local du firewall et traiter le message sous Email > SMTP quarantine. Ensuite documenter:

1. Version et build SFOS.
2. Si l’action a été tentée via Sophos Central ou directement dans WebAdmin.
3. Expéditeur, destinataire, objet et motif de quarantaine.
4. Résultat après le test direct dans WebAdmin.
5. Si une mise à jour vers SFOS 22.0 MR2 ou plus récent est prévue ou installée.

Checklist d’exploitation

• Licence Mail Protection et prise en charge appliance vérifiées.
• MTA mode choisi consciemment et documenté.
• Enregistrement MX, IP publique et serveur cible interne corrects.
• Changement MX, tests externes et rollback préparés.
• Aucune règle DNAT parallèle non filtrée ne contourne le MTA.
• Policies entrantes et sortantes nommées de manière compréhensible.
• L’ordre des règles de pare-feu n’empêche pas la règle MTA de s’appliquer.
• SMTP Relay autorisé uniquement depuis des sources internes définies.
• Processus de quarantaine et de faux positifs défini.
• Adresses alias prises en compte dans le processus de quarantaine et de digest.
• Mail spool, espace de stockage et System Health surveillés.
• Logs conservés assez longtemps localement, dans Sophos Central ou via Syslog.
• Un test du mailflow est effectué après les mises à jour de firmware.

Pour une conservation plus longue et une corrélation avec d’autres événements de sécurité, il faut vérifier Central Firewall Reporting ou Envoyer le Syslog Sophos Firewall vers un SIEM.

FAQ