Sophos Phish Threat : autoriser les expéditeurs, domaines et adresses IP
Sophos Phish Threat ne peut fournir des résultats de campagne réalistes que si les simulations sont distribuées et si les utilisateurs peuvent accéder aux pages de phishing et de formation correspondantes. Pour cela, les domaines d’expéditeur, adresses IP et destinations Web fournis par Sophos doivent être autorisés à tous les points de contrôle effectivement traversés. Il n’est toutefois ni nécessaire ni judicieux de contourner globalement la sécurité de la messagerie ou du Web.
Cette procédure est indépendante du fournisseur. Elle s’applique aux passerelles de messagerie en amont, aux Mail Transfer Agents, aux Secure Web Gateways, aux proxys, aux pare-feu, aux filtres DNS et URL, ainsi qu’aux produits qui analysent automatiquement les liens ou les pièces jointes. Les étapes propres à chaque produit figurent dans les guides de distribution pour Microsoft 365 et Google Workspace.
Rechercher les valeurs actuelles dans Sophos Fusion (anciennement Sophos Central)
La liste de référence doit être récupérée dans le tenant Sophos Fusion concerné :
- Cliquer sur l’icône Global Settings.
- Ouvrir Products and Services > Sophos Phish Threat.
- Cliquer sur Sending domains and IPs.
- Consigner tous les domaines d’expéditeur, adresses IP et destinations Web affichés, avec la date de récupération.
Les adresses IP Sophos Mailflow régionales ne doivent pas être ajoutées systématiquement à la liste d’autorisation Phish Threat. Elles sont utilisées uniquement pour les connecteurs Mailflow Microsoft 365 configurés automatiquement ou pour restaurer ces connecteurs après une modification de configuration. Ces réseaux doivent donc être saisis exclusivement dans le cadre de la configuration documentée des connecteurs Mailflow et uniquement pour la région utilisée, et non par précaution dans les passerelles en amont, les proxys ou les filtres Web.
La liste peut contenir des valeurs destinées à différentes fonctions :
- adresses IP et domaines utilisés pour l’envoi des e-mails de campagne,
- domaines d’expéditeur ou de Return-Path,
- destinations de suivi et de redirection pour la mesure des clics,
- domaines des pages simulées de phishing ou de connexion,
- pages de formation et autres destinations Web nécessaires au déroulement de la campagne.
Les liens Phish Threat peuvent effectuer une redirection via la destination de suivi AWS awstrack.me documentée par Sophos. Une telle redirection est normale pour la mesure des clics. Avant l’envoi pilote, comparer les hôtes réellement nécessaires à la liste Sophos actuelle et aux destinations de la campagne concernée. Ne pas autoriser de sous-domaines supplémentaires sans besoin attesté dans cette liste ou dans la documentation du produit.
Cartographier le flux de données avant l’autorisation
L’autorisation s’effectue à chaque point de contrôle, et non uniquement sur le dernier serveur de messagerie. Il faut d’abord documenter le parcours réel d’un message et d’un clic de test :
- Sophos Phish Threat envoie la simulation.
- Un filtre cloud en amont, une Secure Email Gateway ou un MTA accepte le message.
- D’autres services antispam, antiphishing, de sandboxing ou d’analyse des liens le traitent.
- Le système de destination le distribue à la boîte aux lettres.
- Lors du clic de l’utilisateur, la requête traverse les filtres DNS, le proxy, la Secure Web Gateway, le pare-feu et, le cas échéant, la protection du navigateur ou de l’endpoint.
- Les pages de suivi, de phishing et de formation renvoient les événements à Phish Threat.
Pour chaque étape, consigner le produit, le propriétaire de la règle, la valeur requise, l’exception souhaitée, la date d’expiration ou de révision et la procédure de retour arrière. Si plusieurs filtres se succèdent, chacun des filtres concernés doit être pris en compte. Une autorisation uniquement dans la boîte aux lettres de destination ne résout pas un blocage au niveau d’une passerelle en amont.
Mettre en œuvre la liste d’autorisation la plus restrictive possible
La portée de la règle ne doit pas dépasser ce qui est techniquement nécessaire à la simulation. Privilégier les adresses IP ou noms d’hôte exacts, la liste Phish Threat actuelle et les destinataires de test prévus. N’utiliser un domaine complet, un motif générique ou une exception globale de scanner que si la configuration de la campagne ou le produit ne permet pas de règle plus restrictive.
| Point de contrôle | Autorisation type | Contrôle à effectuer ensuite |
|---|---|---|
| Passerelle de messagerie ou MTA | adresse IP source documentée du système SMTP expéditeur, domaine Envelope Sender ou domaine From visible | acceptation SMTP, en-têtes, chemin de distribution et verdict spam/phishing |
| Service antispam ou antiphishing | exception de simulation strictement limitée | le message est distribué ; les contrôles des logiciels malveillants restent actifs pour les autres messages |
| Scanner de liens et de pièces jointes | exception limitée aux valeurs Phish Threat identifiées | le scanner ne génère pas de clics de campagne et n’ouvre pas les pièces jointes de simulation |
| Filtre DNS ou URL | destinations de suivi, de phishing et de formation nécessaires | la résolution, la redirection et la page de destination fonctionnent |
| Proxy Web ou Secure Web Gateway | hôtes exacts ou motif générique requis | la connexion TLS et la chaîne de redirection ne sont ni bloquées ni réécrites |
| Pare-feu | connexions nécessaires selon le flux de données | aucune autorisation inutile de source, de destination ou de port |
| Extension de navigateur ou d’endpoint | exception ciblée, si elle est techniquement prise en charge | les clics réels des utilisateurs sont enregistrés ; les autres destinations Web restent protégées |
Certains produits distinguent la distribution, l’évaluation du spam, la réécriture des URL, le contrôle Time-of-Click, l’Attachment Sandboxing et l’accès Web. Une seule règle « Allow » ne couvre pas automatiquement toutes ces fonctions. Inversement, une autorisation pour la distribution des e-mails ne doit pas exempter involontairement de tout contrôle l’ensemble des fichiers ou URL provenant du même expéditeur.
N’autoriser les hôtes variables qu’en cas de besoin avéré
Commencer par ajouter individuellement uniquement les hôtes indiqués dans Sophos Fusion ou dans la documentation du produit et utilisés dans la campagne. Si une destination de produit ou de campagne utilise manifestement des hôtes variables et que l’autorisation ne peut pas être limitée techniquement à des noms d’hôte exacts, un caractère générique peut être nécessaire. Dans ce cas, appliquer des contrôles supplémentaires :
- placer le caractère générique uniquement sous le domaine de base indiqué par Sophos,
- ne pas autoriser l’intégralité du domaine parent du fournisseur,
- limiter la règle au trafic Phish Threat et, si possible, aux destinataires pilotes,
- consigner le responsable et la date de révision,
- avant chaque nouveau modèle de campagne, vérifier si un hôte supplémentaire est utilisé.
Une autorisation très large, telle qu’une plateforme cloud ou d’envoi partagée entière, augmente le risque d’admettre du trafic tiers. Si un produit ne permet pas de définir la portée restrictive requise, ce risque résiduel doit être accepté avant la modification ou un autre chemin de distribution doit être choisi.
Éviter les faux clics et l’ouverture automatique des pièces jointes
Les produits de sécurité de la messagerie contrôlent souvent les messages en consultant les URL ou en ouvrant les pièces jointes dans une sandbox. Phish Threat peut interpréter une telle consultation comme une action de l’utilisateur. Des clics ou des ouvertures de pièces jointes sont alors signalés alors que le destinataire n’a pas encore traité le message.
Les indices suivants indiquent généralement qu’il s’agit d’un scanner plutôt que d’un utilisateur :
- les événements surviennent avant la distribution ou immédiatement après,
- de nombreux destinataires présentent presque simultanément la même action,
- les adresses sources ou les User-Agents appartiennent au service de sécurité,
- plusieurs liens du même message sont ouverts à intervalles très rapprochés,
- le comportement peut être reproduit avec un nouveau message pilote.
La correction doit être effectuée sur le scanner à l’origine du problème : ajouter les adresses IP et domaines Phish Threat actuels à la liste prévue pour les simulations de phishing autorisées ou les exceptions d’analyse ciblées. L’exception doit correspondre à la fois à la source identifiée et à la fonction d’analyse concernée. Autoriser uniquement une adresse d’expéditeur ne suffit pas si le service ouvre indépendamment chaque URL dans une sandbox.
L’absence d’événements de clic a souvent la cause inverse. Les destinations de suivi peuvent être bloquées par des Secure Web Gateways, des filtres DNS ou des extensions de navigateur telles que les bloqueurs de publicité. En cas de télémétrie manquante, ne pas relancer immédiatement la campagne : vérifier d’abord la chaîne de redirection dans le navigateur, ainsi que les journaux du proxy, du DNS et des endpoints.
En-têtes de contournement Microsoft 365 uniquement comme exception héritée
Les anciens guides utilisent des règles de transport avec les en-têtes X-MS-Exchange-Organization-SkipSafeLinksProcessing ou X-MS-Exchange-Organization-SkipSafeAttachmentProcessing. De telles règles ne constituent pas la configuration de référence d’une nouvelle installation. Pour une distribution SMTP via le pipeline de transport Microsoft 365, Microsoft prévoit l’Advanced Delivery Policy. Pour les nouvelles installations, Sophos recommande en revanche M365 Direct Delivery ; ce chemin de distribution contourne le pipeline de transport, de sorte qu’Advanced Delivery ne s’y applique pas. La configuration Microsoft 365 concrète doit suivre les instructions Sophos actuelles pour le chemin de distribution choisi et n’entre pas dans le cadre de cet article.
Les en-têtes hérités ne doivent être envisagés que si un environnement existant en a encore manifestement besoin, si l’état actuel de la prise en charge a été vérifié et si une modification approuvée avec une portée IP/domaine restrictive existe. La priorité, l’effet et les conséquences de la règle sur la sécurité doivent être testés séparément. Ne pas conserver d’anciennes règles d’en-tête « par précaution » en parallèle d’une autorisation de simulation actuelle.
Valider une campagne pilote
Commencer par un petit groupe pilote composé de comptes de test contrôlés. Il doit inclure au moins une boîte aux lettres pour chaque chemin de distribution, groupe de stratégies et site concernés. Le test couvre un message avec un lien et, si cela correspond à l’utilisation prévue, une campagne avec pièce jointe et formation.
Avant l’envoi, consigner les horodatages, l’ID de campagne, les destinataires, l’expéditeur attendu, le domaine utilisé et les ID des règles modifiées. Vérifier ensuite les points suivants :
- La passerelle accepte le message et le distribue une seule fois à la boîte aux lettres attendue.
- Les valeurs réellement utilisées pour la correspondance de règle prévue concordent avec la liste Sophos actuelle : le domaine From visible approprié ou le domaine Envelope Sender/Return-Path et, si la règle repose sur l’adresse IP, l’adresse IP source du système SMTP expéditeur consignée par la passerelle de contrôle comme pair de connexion. Vérifier ces champs séparément ; l’adresse IP du serveur destinataire ne peut pas servir d’adresse IP source de l’expéditeur.
- Le message n’arrive ni en quarantaine ni, de manière inattendue, dans le dossier Courrier indésirable.
- Aucun événement de clic ou de pièce jointe n’apparaît dans Phish Threat avant une action de l’utilisateur.
- Un clic contrôlé de l’utilisateur ouvre la page de redirection, de simulation ou de formation attendue.
- Cette action précise apparaît dans le résultat de campagne à une heure plausible.
- Les journaux du proxy, du pare-feu, du DNS et du scanner indiquent la règle attendue, mais aucun contournement inutilement large.
- Un message de test externe normal et une destination Web non autorisée continuent d’être contrôlés selon les stratégies de sécurité existantes.
La réussite ne signifie pas seulement que « l’e-mail est arrivé ». Il faut confirmer conjointement la distribution, l’exactitude des mesures de campagne, l’accessibilité des destinations Web et le maintien de contrôles de sécurité efficaces. La règle ne doit être étendue au groupe de destinataires prévu qu’ensuite.
Isoler les erreurs de manière systématique
En cas d’échec de la distribution, contrôler chaque étape en partant du premier point d’acceptation vers l’intérieur : journal SMTP, passerelle en amont, quarantaine, règle de transport en aval et boîte aux lettres de destination. L’erreur SMTP ou le verdict du produit indique à quel niveau le message a été rejeté. Ajouter des exceptions larges sans cette preuve complique l’analyse de la cause racine.
En cas de faux clics, comparer au contraire la chronologie de l’envoi à la distribution. Les journaux du scanner, l’adresse IP source et le User-Agent permettent d’attribuer une requête automatique reproductible au produit qui la génère. Si des clics réels ne sont pas enregistrés, contrôler la résolution DNS, la décision du proxy, la connexion TLS, les redirections et les extensions du navigateur.
Si la cause reste indéterminée, arrêter la campagne pilote. Une exception ne doit pas être élargie progressivement jusqu’à ce que la distribution fonctionne par hasard.
Annuler les modifications et assurer un suivi continu
Avant la mise en œuvre, définir un retour arrière pour chaque règle : état antérieur, ID de règle, export ou capture d’écran, personne responsable et ordre d’annulation. En cas de distribution inattendue de messages tiers, de contournement trop large de la sécurité, d’accès proxy suspect ou de données de campagne toujours faussées, désactiver la modification ou rétablir le dernier état validé. Contrôler ensuite à nouveau les journaux de messagerie et Web.
Appliquer au minimum les contrôles suivants en exploitation courante :
- comparer les valeurs actuelles à Sophos Fusion avant chaque campagne importante,
- retester les règles après un changement de produit, de routage ou de fournisseur,
- vérifier régulièrement si la portée des caractères génériques et exceptions globales peut être réduite,
- supprimer les domaines, adresses IP et règles héritées qui ne sont plus nécessaires,
- associer à chaque exception une date de révision, un propriétaire et une justification technique,
- après chaque modification, toujours lancer une campagne pilote sans faux clic automatique.