Aller au contenu
Avanet

Créer et tester des exceptions de messagerie Sophos Firewall

Une exception de messagerie sur Sophos Firewall ne se contente pas d’autoriser un expéditeur. Elle ignore certains contrôles de sécurité pour un chemin SMTP défini. C’est précisément pourquoi elle peut résoudre proprement un faux positif confirmé, mais aussi désactiver discrètement SPF, l’analyse antimalware, Zero-Day Protection ou les contrôles DKIM.

⚠️ Une exception ne doit être créée qu’après reproduction d’un faux positif. Seul le contrôle concerné est ignoré. Choisir la condition fiable la plus étroite, car l’hôte source, l’expéditeur et le destinataire sont des alternatives et non une condition ET commune. All checks et les caractères génériques étendus ne constituent pas une solution rapide standard.

Créer l’exception en sept étapes

  1. Consigner l’heure du test, l’adresse IP source SMTP, l’expéditeur de l’enveloppe, le destinataire, l’objet, le Message-ID et le motif exact du rejet.
  2. Vérifier si le problème provient du DNS, du routage, du relais, de TLS ou de la stratégie de messagerie elle-même plutôt que d’un contrôle de sécurité.
  3. Sous Email > Policies and exceptions > Add an exception, sélectionner uniquement le contrôle dont l’implication est démontrée.
  4. N’activer que la condition appropriée la plus étroite sous Sources or hosts, Sender addresses ou Recipient addresses.
  5. Tester positivement un message équivalent et négativement au moins une variante hors de la portée.
  6. Sous Email > Mail logs, comparer le résultat et le Reason avant et après ; tester séparément les autres protections avec des cas inoffensifs.
  7. Documenter le responsable, la justification et la date de révision, puis supprimer l’exception après correction de la cause.

Ce qu’une exception ignore réellement

SFOS regroupe les contrôles qui peuvent être ignorés selon leur effet. Spam protection contient RBL, Anti-spam, Greylisting, Recipient verification, IP reputation, RDNS/HELO, SPF et BATV. Malware protection contient Malware et Zero-day protection. Other contient Data protection, File protection, Encryption, Banner addition, DKIM signing et DKIM verification.

Cette sélection n’est pas une liste de commodité. Une exception pour SPF, par exemple, maintient les autres contrôles antispam et antimalware. En revanche, une exception pour Malware ou Zero-day protection supprime un contrôle de contenu central pour tous les messages correspondant à la portée. Encryption, DKIM signing ou DKIM verification modifient également la confidentialité et la validation de l’intégrité du flux de messagerie sortant ou entrant.

Cette exception appartient au MTA mode. Une stratégie SMTP route and scan réunit le routage et les actions antispam, antimalware, fichiers et données. En legacy mode, SFOS agit comme proxy transparent et utilise des stratégies SMTP malware scan et SMTP spam scan distinctes ; l’objet d’exception MTA n’est pas le réglage approprié. Voir Configurer Mail Protection de Sophos Firewall en mode MTA et Configurer Mail Protection en mode hérité.

Encryption désigne ici le chiffrement de messagerie de la stratégie MTA, par exemple le chiffrement SPX, et non le chiffrement de transport SMTP. Require TLS negotiation, la validation du certificat et Skip TLS negotiation se règlent séparément sous Email > General settings > SMTP TLS configuration. Une exception de messagerie ne corrige donc ni une négociation TLS, ni le routage, ni le relais, ni les règles de pare-feu.

Comprendre la correspondance avant d’enregistrer

Les trois groupes ne forment pas une condition ET. L’API officielle SFOS 22.0 les nomme ForTheseSourceHost, ORTheseSenderAddresses et ORTheseRecipientAddresses. Si plusieurs groupes sont actifs, une correspondance avec l’hôte source ou l’expéditeur ou le destinataire suffit. Une IP source, un domaine partenaire et une boîte pilote créent donc trois possibilités de correspondance, pas une combinaison plus étroite.

Cet objet ne permet pas d’imposer un ET. Deux exceptions élargiraient également la portée. Si une exception n’est acceptable qu’avec deux critères simultanés, corriger la cause ou isoler le flux avec une stratégie ou un chemin de passerelle approprié.

Sources or hosts

SFOS accepte comme sources les adresses IP, les plages IP, les listes IP, les réseaux ou les FQDN. Les FQDN génériques ne sont pas pris en charge pour les exceptions d’hôtes de messagerie. *.example.net n’est donc pas un remplacement valide de l’adresse source SMTP observée. Aucune exception n’est nécessaire pour localhost, car SFOS n’analyse pas les e-mails locaux par défaut.

Pour les services de messagerie cloud ou les passerelles distribuées, une seule adresse IP peut être trop restrictive, tandis qu’un réseau complet du fournisseur peut être beaucoup trop étendu. Utiliser uniquement un objet source publié et effectivement observé dans le flux de messagerie local. Si d’autres clients partagent les adresses IP du fournisseur, même cet objet peut être trop large. Ne pas exempter un contrôle de sécurité en se fondant uniquement sur ce réseau.

Expéditeur et destinataire

Pour Sender addresses et Recipient addresses, une adresse unique telle que sender@example.net ou un caractère générique tel que *@example.net est autorisé. Un second groupe n’est pas un ancrage plus étroit puisqu’il est relié par OU. Un expéditeur n’est pas une preuve de confiance indépendante lorsqu’on ignore SPF ou DKIM ; une exception de destinataire s’applique aux messages correspondants de tous les expéditeurs.

BATV comporte une règle particulière inhabituelle : pour ignorer le contrôle BATV des e-mails d’un expéditeur, son adresse doit être saisie à la fois sous Sender addresses et Recipient addresses. Si l’un des deux champs manque, l’exception est incomplète pour ce cas BATV.

Créer une exception étroite

L’exemple traite un faux positif SPF confirmé provenant de la passerelle dédiée d’un partenaire. 203.0.113.25 est une adresse de documentation à remplacer par l’IP publique observée dans Mail logs. L’exemple ne convient que si cette IP appartient exclusivement à la passerelle fiable ; le contournement serait trop large pour un relais cloud partagé.

  1. Ouvrir Email > Policies and exceptions > Add an exception.
  2. Saisir un nom traçable tel que FP-SPF-partner-example-review-2026-09-30.
  3. Sélectionner uniquement SPF parmi les contrôles à ignorer.
  4. Sous Sources or hosts, saisir l’hôte 203.0.113.25.
  5. Laisser Sender addresses et Recipient addresses désactivés ou vides : ils ajouteraient des correspondances OU.
  6. Enregistrer sans ajouter d’autres hôtes ou contrôles.

Le nom contient volontairement la cause et la date de révision. Il ne remplace toutefois pas la documentation dans le changement ou le ticket. Le nom n’impose techniquement aucune date d’expiration ; le responsable doit réellement effectuer la révision.

Effectuer des tests positifs et négatifs

Le partenaire renvoie le même message contrôlé. Il ne doit plus échouer pour le Reason SPF confirmé. Sous Email > Mail logs, filtrer par période, expéditeur, destinataire ou objet, puis par Result et Reason. SPF, RBL, Malware, Zero-day protection, DKIM verification et BATV ont leurs propres filtres Reason. smtpd_main.log et, en cas de rejet, smtpd_reject.log permettent une corrélation approfondie ; Services et journaux Sophos Firewall explique leur rôle.

Effectuer ensuite un test négatif par un chemin SMTP contrôlé non exempté. Il ne doit pas contourner le contrôle documenté à cause de cette exception. Avec une exception limitée à l’hôte source, d’autres expéditeurs ou destinataires passant par l’IP exemptée ne sont pas des tests négatifs : ils correspondent au même embranchement OU. Un fichier inoffensif peut contrôler séparément Malware et File Protection ; ne pas utiliser de véritable logiciel malveillant.

Une remise réussie ne prouve pas à elle seule la portée. La documentation officielle de Mail logs décrit les Reasons et l’état de remise, mais pas de champ explicite « matched exception » ni la liste des contrôles ignorés. Évaluer ensemble le Reason avant/après, la configuration et des cas positifs et négatifs séparés. Ne pas présenter la remise comme la preuve que toutes les autres protections ont été exécutées.

Identifier les exceptions risquées

Un seul caractère générique de domaine étendu ou un grand réseau source peut supprimer la protection d’une part importante du flux de messagerie. Saisir les deux ne réduit pas la portée, mais ajoute des correspondances OU. Les exceptions pour Malware, Zero-Day Protection, Data protection et File protection nécessitent en particulier une décision de risque documentée et une portée très petite et fiable indépendamment. Si l’erreur d’analyse est encore inconnue, ne pas désactiver préventivement tout le groupe.

Les options apparemment fonctionnelles sont également importantes pour la sécurité. Ignorer Encryption peut envoyer du contenu confidentiel sans protection. Sans DKIM signing, la signature sortante prévue est absente ; sans DKIM verification, une preuve d’identité entrante n’est pas évaluée. Une exception Banner peut supprimer des textes ou des marquages obligatoires. Ces modifications doivent être coordonnées avec les responsables de la messagerie et de la conformité.

Isoler les erreurs selon le symptôme

Le message est toujours rejeté

Évaluer d’abord la nouvelle entrée de journal plutôt que l’ancien message de test. L’adresse IP source réelle, l’expéditeur de l’enveloppe, le destinataire et le Reason doivent correspondre à la portée et au contrôle sélectionné. Un FQDN générique sous Sources or hosts ne fonctionne pas. Si le message est rejeté en raison de RBL, IP reputation, RDNS/HELO ou d’un autre contrôle, une exception limitée à SPF ne résout pas ce motif distinct.

L’exception correspond à trop de messages

Comparer séparément les trois groupes au flux réel. Chaque groupe OU actif augmente les correspondances. Ramener l’exception à un seul groupe fiable avec le moins de valeurs possible, puis répéter le test négatif.

L’e-mail passe le contrôle, mais n’est pas remis

Une exception contrôle les vérifications de sécurité, pas le MX, la route interne, le relais, TLS SMTP ou le serveur de messagerie de destination. Mail logs et le spool indiquent si le message échoue après l’analyse à cause du DNS, du routage, de la stratégie ou de la remise. Pour une erreur TLS, vérifier le certificat, Require TLS negotiation et le pair ; Encryption dans l’exception et une portée plus large ne la résolvent pas.

L’exception BATV ne s’applique pas

Vérifier que la même adresse d’expéditeur figure sous Sender addresses et Recipient addresses. Comparer ensuite à nouveau le Reason BATV précis et les autres champs de portée. Une deuxième exception plus large ne remplace pas le champ BATV manquant.

Exploitation et retour arrière

Chaque exception possède un responsable, un motif de faux positif démontré et une date de révision. Comparer les modifications à l’audit trail ; Suivre les modifications de configuration sur Sophos Firewall décrit la preuve appropriée. Le flux de messagerie réel reste visible séparément dans Mail logs et les fichiers MTA.

Avant la modification, consigner le nom, les contrôles, les valeurs de portée et l’ancien Reason. Pour préserver l’état, supprimer uniquement la nouvelle exception sans toucher aux stratégies ni aux autres exceptions. Retester l’erreur d’origine et un message de contrôle. Si la cause n’est pas corrigée, planifier d’abord une fenêtre de maintenance ou une correction plus étroite.

Liste de contrôle

  • Un faux positif reproductible et le Reason exact sont disponibles.
  • L’adresse IP source, l’expéditeur de l’enveloppe, le destinataire et le Message-ID sont documentés.
  • Seul le contrôle concerné est ignoré.
  • Privilégier un seul groupe de portée approprié ; tout groupe supplémentaire élargit la correspondance par OU.
  • Aucun FQDN générique n’est utilisé comme exception d’hôte.
  • Une exception BATV contient l’adresse de l’expéditeur dans les deux champs d’adresse.
  • Les tests positifs et négatifs, avec les Reasons avant et après, confirment l’effet attendu.
  • Les autres contrôles de spam, malware, fichiers, données et DKIM restent actifs.
  • Le responsable, la justification, la date de révision et le retour arrière sont documentés.

FAQ

Une exception de messagerie autorise-t-elle automatiquement le relais SMTP ?

Non. L’exception ignore certains contrôles de sécurité. Device Access, Relay settings, la stratégie MTA, le routage et les règles de pare-feu restent des conditions distinctes.

Peut-on utiliser un FQDN générique sous Sources or hosts ?

Non. Sophos Firewall ne prend pas en charge les FQDN génériques pour les exceptions d’hôtes de messagerie. Un caractère générique de domaine de messagerie tel que *@example.net n’est possible que dans les champs d’expéditeur et de destinataire.

L'hôte source, l'expéditeur et le destinataire sont-ils reliés par ET ?

Non. L’API SFOS 22.0 nomme les groupes ORTheseSenderAddresses et ORTheseRecipientAddresses. Chaque groupe actif supplémentaire élargit la portée ; cet objet ne peut pas exprimer un ET obligatoire.

Faut-il ignorer temporairement tous les contrôles pour un faux positif inconnu ?

Non. Il faut d’abord déterminer le Reason précis. Ensuite, seul ce contrôle est exempté pour une portée pilote étroite et testé avec des cas positifs et négatifs.