Sophos Email : gérer en toute sécurité les exceptions Allow/Block entrantes

Inbound Allow/Block détermine quels expéditeurs Sophos Email autorise ou bloque pour les messages entrants. La liste administrateur s’applique à toutes les boîtes protégées, tandis qu’une liste personnelle ne s’applique qu’à l’utilisateur concerné. En cas de conflit, Admin list est prioritaire.

Procédure rapide et sûre : dans Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block, exportez d’abord la liste. Ajoutez ensuite à Admin list la valeur d’expéditeur la plus précise possible, activez Enforce Message Authentication pour une entrée Allow, documentez le motif et le responsable, puis testez un message correspondant et un autre ne correspondant pas. Un domaine, un joker ou un réseau étendu ne remplace pas l’analyse d’un faux positif.

Important : une entrée Allow ne désactive pas toute la protection. Pour un expéditeur correspondant et suffisamment authentifié, Sophos ignore uniquement les contrôles indiqués ci-dessous ; l’analyse antimalware reste active. Sans authentification obligatoire, un message usurpé utilisant une adresse autorisée peut contourner les contrôles documentés et atteindre la boîte de réception. La liste d’URL autorisées Time of Click est une fonction distincte qui n’est pas gérée ici.

Comprendre la portée et la correspondance

Ces listes concernent uniquement les messages entrants. Pour les adresses et domaines, Sophos compare l’expéditeur de l’enveloppe SMTP et l’adresse de l’en-tête From visible. La correspondance de l’un des deux déclenche l’action Allow ou Block. Vérifiez donc les deux valeurs dans les en-têtes bruts ou les détails du message.

La liste administrateur accepte :

les adresses e-mail individuelles, comme billing@example.com ;
les domaines, comme example.com ;
les adresses IP, comme l’adresse de documentation 192.0.2.25 ;
les réseaux IPv4 avec des préfixes de /16 à /32, par exemple 192.0.2.0/24 ;
les jokers au début, au milieu ou à la fin d’une adresse ou d’un domaine, comme *.example.com, name*@example.com, name@example*.com ou *.example ;
les jokers pour des TLD entières, avec *.example comme forme documentaire sûre plutôt qu’une TLD de production.

End user list accepte uniquement les adresses e-mail et domaines, sans adresse IP ni joker. La limite documentée pour l’ensemble des listes est de 100 000 entrées. Un utilisateur peut ajouter au maximum 500 entrées à sa liste Allow ou Block ; les entrées créées depuis Smart Banners peuvent dépasser cette limite individuelle.

Un message provenant d’un expéditeur ou d’une IP cliente bloqués est rejeté sans analyse supplémentaire. Les messages provenant d’adresses sur une liste Block sont normalement rejetés pendant SMTP, avant que le serveur les accepte. En revanche, avec plusieurs destinataires dont les paramètres personnels de blocage diffèrent, le message est d’abord accepté, puis bloqué uniquement pour ceux qui ont bloqué l’expéditeur. Dans ce cas, l’acceptation SMTP ne signifie pas une remise au destinataire qui a bloqué l’expéditeur. Le test concret est décrit plus loin.

Préparer et restreindre la modification

Avant toute modification, consignez le ticket, le motif, le responsable et la date d’expiration ou de révision ; le type exact (Admin list ou End user list) ; l’action et la valeur la plus précise ; les utilisateurs concernés ; un export actuel avec le nombre d’entrées ; ainsi que l’expéditeur, le destinataire et les résultats attendus des tests avec et sans correspondance.

Sophos ne documente pas d’expiration automatique par entrée. Planifiez donc la révision dans le système de gestion des changements et supprimez l’exception devenue inutile. La description doit mentionner brièvement le motif et le ticket, sans donnée confidentielle.

Configurer la liste administrateur

Dans Sophos Fusion (anciennement Sophos Central), cliquez sur Global Settings.
Ouvrez Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Sélectionnez Admin list, puis Add.
Choisissez Allow ou Block et saisissez exactement une adresse, un domaine, une IP, un réseau CIDR pris en charge ou une valeur avec joker.
Ajoutez une Description contenant le motif et le ticket, sans donnée confidentielle et limitée à 250 caractères.
Pour les entrées Allow, activez Enforce Message Authentication. Ne désactivez pas cette option pour contourner un échec d’authentification de l’expéditeur.
Enregistrez puis retrouvez l’entrée. Advanced Search filtre par Allow/Block, Message Authentication et adresse ou domaine expéditeur.

N’utilisez Override duplicates qu’après comparaison de l’entrée existante ; Sophos retient la sélection la plus récente. Vous pouvez modifier la description de plusieurs entrées administrateur ou activer Message Authentication sur plusieurs entrées Allow, sans toutefois regrouper silencieusement des motifs ou responsables différents.

Les réglages propres à chaque entrée sous Enforce Message Authentication reprennent les options d’authentification de User Settings. Pour chaque entrée Allow, vous pouvez conserver ou remplacer certaines options, notamment les contrôles SPF et les domaines d’enveloppe. Comparez et documentez aussi ces valeurs, pas seulement le commutateur principal. La protection globale contre l’usurpation ne remplace pas ce commutateur : si Enforce Message Authentication est désactivé sur une entrée Allow administrateur, un expéditeur usurpé peut exploiter cette entrée même lorsque l’option globale est activée.

Contrôles ignorés après une correspondance Allow authentifiée

Pour une entrée Allow administrateur avec authentification obligatoire, au moins un contrôle DMARC, SPF ou DKIM doit réussir. L’option Prevention of spoofing of allowed address activée et les réglages de l’entrée déterminent l’évaluation détaillée ; notamment, un échec DMARC avec une politique autre que p=none peut faire échouer l’authentification. Une réussite SPF quelconque ne constitue donc pas une preuve suffisante à elle seule. Pour une correspondance Allow correctement authentifiée, Sophos ignore :

Header anomalies;
Impersonation protection;
Anti-spam;
BATV (Bounce Address Tag Validation);
Country of origin;
Language;
Data control.

Une correspondance Allow utilisateur correctement authentifiée ignore uniquement Impersonation protection, Anti-spam, Country of origin et Language. La section suivante explique les descriptions contradictoires de l’authentification utilisateur. Dans les deux cas, l’analyse antimalware reste active. Le guide sur la protection contre les malwares, pièces jointes et URL explique les contrôles de contenu et d’URL qui s’appliquent indépendamment.

Allow utilisateur : descriptions contradictoires de l’authentification

Les descriptions actuelles de Inbound Allow/Block et du traitement des listes Allow indiquent que les entrées Allow utilisateur imposent toujours Message Authentication. En revanche, User Settings présente Prevention of spoofing of allowed address comme une option à activer pour l’authentification Allow utilisateur décrite sur cette page. Elle indique que l’option est désactivée par défaut pour les clients existants et peut ne pas être encore disponible dans tous les tenants. Ces descriptions ne sont pas clairement cohérentes entre elles. Elles ne permettent de conclure ni à un contournement fiable de l’authentification lorsque l’option est désactivée, ni à une protection démontrée dans tous les tenants indépendamment de cette option. Le conflit concernant l’authentification reste non résolu.

En exploitation, maintenez les contrôles de protection existants actifs et, si Prevention of spoofing of allowed address est disponible, planifiez son activation avec une validation contrôlée des circuits d’envoi légitimes. Si l’option manque ou si son effet est incertain, ne fondez pas une nouvelle exception Allow utilisateur sur un fonctionnement supposé de l’authentification ; clarifiez l’état du tenant à l’aide de détails de messages expurgés des données sensibles et des paramètres actuels. Ne désactivez ni Enforce Message Authentication, ni la protection contre l’usurpation, ni d’autres contrôles pour contourner le problème.

Pour la vérification documentée avec Prevention of spoofing of allowed address activé, une adresse autorisée ne peut contourner les contrôles que si l’authentification réussit selon l’évaluation suivante. Sinon, Sophos ignore l’état Allow et effectue toutes les analyses :

Un résultat DMARC pass suffit. Si DMARC échoue avec une politique de l’expéditeur autre que p=none, l’authentification Allow échoue dans cette configuration de test avec l’option activée.
Avec p=none, ou si DMARC ne peut pas être exécuté, SPF et DKIM déterminent le résultat.
SPF contrôle le domaine d’enveloppe du message.
DKIM doit réussir pour le domaine de l’entrée Allow.
SPF check for non-aligned address peut accepter une réussite SPF même si le domaine d’enveloppe de l’adresse expéditeur n’est pas aligné sur l’adresse autorisée. Sophos déconseille cette option : une adresse header-from usurpée pourrait correspondre à une adresse autorisée par l’utilisateur et accroître le risque d’usurpation.
SPF check for envelope domain demande à Sophos de lire le domaine d’enveloppe pour chaque adresse d’en-tête autorisée par l’utilisateur, afin d’appliquer SPF au domaine d’enveloppe du message. Ne l’utilisez que si ce workflow SPF exceptionnel non aligné est nécessaire.

Ce chemin d’exception non aligné élargit la confiance et ne constitue pas une solution standard. Corrigez d’abord SPF, DKIM ou DMARC sur le service d’envoi légitime. Consultez le guide sur l’authentification de l’expéditeur.

Administrer les listes utilisateurs

User Settings ne peut pas être configuré en mode EMS. Hors de ce mode, les utilisateurs peuvent gérer leur liste dans Sophos Central Self Service Portal si Release/Delete et Allow/Block List sont activés sous Global Settings > Products and Services > Email > User Settings. Deux dépendances de sécurité s’appliquent :

Si End-user message settings est activé et que les liens Allow sender et Block sender sont configurés sur Smart Banners, Allow/Block List doit rester activé.
Si End-user message settings est désactivé et que Release/Delete ou Allow/Block List est désactivé, Sophos contourne les listes Allow/Block existantes des utilisateurs.

L’administrateur peut consulter et modifier ces mêmes listes de manière centralisée :

Ouvrez Global Settings > Protection and Remediation > Allow and Block > Email > Inbound Allow/Block.
Sélectionnez End user list, puis cliquez sur Add.
Affectez l’entrée au bon utilisateur, choisissez Allow ou Block et utilisez uniquement une adresse e-mail ou un domaine.
Enregistrez et vérifiez l’entrée avec Advanced Search par action, expéditeur ou utilisateur.

Override duplicates remplace ici aussi une valeur identique par le choix le plus récent. Vérifiez d’abord la liste administrateur globale, qui prévaut sur une entrée utilisateur contradictoire. Consultez le libre-service de quarantaine.

Tester correctement plusieurs destinataires

Pour un message à plusieurs destinataires, les listes personnelles peuvent différer pour le même expéditeur. Si seul person1@example.com l’a bloqué, person2@example.com reçoit toujours le message ; il est bloqué uniquement pour person1@example.com. Dans le cas normal, le rejet intervient avant l’acceptation SMTP. Dans le cas mixte à plusieurs destinataires, le message est d’abord accepté, puis bloqué individuellement. Une acceptation SMTP réussie ne prouve donc pas la remise au destinataire qui a bloqué l’expéditeur.

Pour un pilote contrôlé, utilisez deux boîtes de test et un expéditeur de test qui vous appartiennent ; remplacez les adresses d’exemple par ces valeurs autorisées. Vérifiez d’abord les entrées prioritaires de la Admin list globale et les autorisations des listes utilisateurs décrites dans la section précédente. Le pilote exige des listes utilisateurs effectivement appliquées. En particulier, si End-user message settings est désactivé, désactiver Release/Delete ou Allow/Block List peut contourner les listes existantes ; ce n’est pas une solution à un résultat de test inattendu.

Consignez les entrées personnelles d’origine. Bloquez l’expéditeur de test uniquement pour le premier destinataire ; le second ne doit avoir aucun blocage correspondant.
Envoyez un nouveau message inoffensif aux deux destinataires en une seule opération d’envoi. Vérifiez chaque action séparément dans Message History et contrôlez les boîtes : le premier doit subir un blocage sans remise, le second doit recevoir le message, sauf si un autre contrôle l’arrête.
Si l’accès SMTP est explicitement autorisé, conservez aussi le journal de cet envoi et distinguez acceptation et rejet. Vérifiez que les deux destinataires appartiennent à la même transaction SMTP ; des transactions séparées ne démontrent pas le cas mixte. Comparez avec un test distinct à un seul destinataire, adressé à la boîte qui bloque, pour lequel le rejet normal avant acceptation est attendu. Ne déduisez ni code SMTP ni étape de traitement du seul état de remise.
Après le pilote, restaurez les entrées personnelles consignées et vérifiez-les de nouveau. Si le résultat est inattendu, arrêtez le changement et vérifiez priorité administrateur, affectation utilisateur, correspondance et autorisations, au lieu de créer une règle Allow plus large.

Un test SMTP à un seul destinataire ne reproduit pas le cas mixte. Sans accès SMTP autorisé, vous pouvez vérifier les résultats par destinataire, mais pas déclarer l’étape SMTP démontrée de manière indépendante.

Exporter et importer un CSV en toute sécurité

Avant un import en masse, exportez la liste comme sauvegarde et référence. Le CSV exporté contient des colonnes supplémentaires et ne convient pas tel quel à l’import. Téléchargez le modèle actuel de Sophos Fusion, respectez exactement son format et ses colonnes et n’inventez aucun nom de colonne.

Ouvrez le bon onglet Admin list ou End user list et conservez l’export intact.
Sélectionnez Add > Import allow/block list et téléchargez les modèles.
Préparez le CSV ; vérifiez ligne par ligne l’action, la valeur, Description et, le cas échéant, l’utilisateur.
Dans l’aperçu, contrôlez des entrées Allow et Block, les caractères spéciaux, domaines et utilisateurs.
Importez d’abord un petit fichier pilote, puis recherchez et testez ses entrées.

Avertissement : Replace existing list with this import supprime définitivement toutes les entrées actuelles de la liste concernée lors de l’ajout du CSV. Ne l’utilisez que pour un remplacement intégral approuvé, avec sauvegarde vérifiée et pilote réussi, jamais pour un simple ajout.

Sécuriser et annuler un remplacement intégral

Avant un remplacement intégral, un approbateur désigné doit valider l’onglet exact, la sauvegarde complète et intacte avec son nombre de lignes consigné, le fichier de restauration préparé, le résultat du pilote et la fenêtre de maintenance. Le pilote doit employer le même modèle Sophos actuel dans un tenant hors production ou une liste de test distincte et contrôlée. N’exécutez jamais un fichier pilote partiel sur la liste de production avec Replace existing list with this import.

Si des entrées manquent ou sont incorrectes après le remplacement, arrêtez tous les imports suivants et ne corrigez pas la liste ligne par ligne. Après approbation de l’incident ou du changement, convertissez la liste complète, précédemment exportée et reconnue comme correcte, dans un nouveau fichier conforme au modèle Sophos actuel ; conservez l’export d’origine intact. Avant l’import, comparez le nombre de lignes et des entrées Allow et Block représentatives, ainsi que les affectations utilisateur pour les listes utilisateurs et des échantillons du début et de la fin. Dans le bon onglet et pendant une fenêtre contrôlée, importez ensuite ce fichier de restauration complet avec Replace existing list with this import. Enfin, exigez que le nombre d’entrées corresponde à celui d’avant la modification, vérifiez les mêmes échantillons et répétez les tests de correspondance, de non-correspondance et d’authentification pour confirmer le retour à l’état correct connu. En cas d’écart, maintenez le changement à l’arrêt et escaladez ; l’analyse antimalware et tous les autres contrôles de protection restent actifs.

Limites distinctes : 500 000 entrées au maximum dans la liste d’import créée, 500 par utilisateur, 1 MB (1 Mo) par CSV et 250 caractères par Description ; un texte plus long est tronqué. Fractionnez les fichiers volumineux. Si un tableur modifie les séparateurs, premiers caractères ou l’encodage, annulez, recréez le fichier depuis le modèle Sophos intact et vérifiez l’aperçu. Ne devinez pas l’encodage et ne modifiez pas la sauvegarde.

Valider le résultat

Après une modification individuelle ou chaque import, effectuez un petit test documenté :

Correspondance : Un nouveau message dont l’expéditeur d’enveloppe ou l’en-tête From correspond exactement doit produire l’effet Allow ou Block attendu.
Absence de correspondance : Une adresse similaire ou un domaine voisin non couvert par l’entrée doit suivre les contrôles normaux. Cela révèle notamment une portée trop large pour les jokers et CIDR.
Authentification réussie : Vérifiez un expéditeur légitime avec un résultat d’authentification documenté au regard des options globales et propres à l’entrée réellement activées. Maintenez Enforce Message Authentication actif pour Allow administrateur ; pour le test contrôlé d’Allow utilisateur, utilisez Prevention of spoofing of allowed address disponible et activé. Seuls les contrôles documentés pour chaque cas peuvent être ignorés ; l’analyse antimalware reste active. Une réussite SPF seule ne prouve pas une correspondance Allow réussie avec une évaluation DMARC plus stricte.
Échec d’authentification : Dans cette configuration de test protégée, un message contrôlé pour lequel les trois contrôles échouent ne doit pas bénéficier de l’état Allow et doit subir toutes les analyses. Vérifiez aussi l’échec DMARC avec une politique autre que p=none si ce cas fait partie du test autorisé. Sans configuration de test Allow utilisateur vérifiable, sa validation reste ouverte ; ne désactivez aucun contrôle de protection pour forcer la remise.
Block et plusieurs destinataires : Pour les listes Block personnelles, testez dans le même message un destinataire concerné et un autre non concerné ; documentez les deux actions séparément. Vérifiez en plus l’acceptation ou le rejet SMTP uniquement avec un accès autorisé, pas à partir de la seule remise.
CSV : Comparez le nombre, l’action, la valeur, Description et l’affectation utilisateur avec le fichier source et la sauvegarde. Vérifiez aussi des échantillons au début et à la fin de la liste.

Dans Message History, notez l’heure, l’expéditeur d’enveloppe, From, l’IP cliente, le destinataire, l’authentification et l’action. La remise ne prouve pas à elle seule que l’entrée Allow a correspondu : le message peut avoir réussi les analyses normales.

Résoudre les problèmes et maintenir les exceptions

Allow ne fonctionne pas : comparez l’expéditeur d’enveloppe et From avec l’entrée, puis vérifiez priorité administrateur, options de l’entrée et DMARC/SPF/DKIM. Les analyses normales sont prévues lorsque l’authentification obligatoire échoue. Si l’effet d’Allow utilisateur est incertain, consignez aussi l’état réel de la protection contre l’usurpation ; ne contournez pas le conflit documentaire décrit en désactivant des protections.
Block ne concerne que certains destinataires : vérifiez les utilisateurs et le cas multidestinataire ; la règle administrateur est prioritaire.
Wildcard ou CIDR correspond mal : vérifiez syntaxe et préfixe ; seuls /16 à /32 sont documentés et les listes utilisateurs n’acceptent ni IP/CIDR ni joker. Retirez l’entrée étendue pendant l’analyse.
Import absent ou incorrect : vérifiez onglet, taille, limite utilisateur, modèle, colonnes supplémentaires, descriptions tronquées et encodage visible. Ne recommencez pas avec Replace existing list with this import avant d’avoir identifié la cause et vérifié la sauvegarde.
Un message légitime reste bloqué : comparez listes, enveloppe, From et IP, puis l’authentification et Message History. Ne créez pas une entrée Allow plus large comme raccourci.

Au moins chaque trimestre et lors d’un changement de responsable, comparez la liste, le ticket et le besoin. Après approbation, supprimez les exceptions expirées, sans responsable, en double ou trop larges et refaites les tests. Si la cause reste inconnue, annulez la nouvelle entrée et transmettez l’ID du message, l’horodatage, l’export, la ligne concernée et les résultats d’authentification, sans divulguer de message confidentiel ni de liste de production complète.