Guide de configuration DMARC de Cisco ESA

Dans cet article, nous présentons un guide sur le déploiement de DMARC sur l'appliance de sécurité de messagerie de Cisco
(ESA).

Si vous pensez avoir déjà configuré correctement l'authentification et le reporting DMARC de votre système, prenez le temps de lire les informations et de les comparer à vos paramètres actuels. Ces paramètres sont les meilleures pratiques du secteur et nous vous encourageons à ne pas vous en écarter. La version d'AsyncOS de votre ESA doit être 13+. Si elle est 14, elle doit être 14.0.2 ou supérieure en raison d'un bug dans les versions inférieures de 14.

NOTES :

• Si vous ne le configurez pas correctement, ne le faites pas du tout. Si elle n'est pas configurée correctement, vous polluerez les données valides envoyées par d'autres sources, et vos données DMARC risquent d'être mises sur liste noire par les agrégateurs.

• Des paramètres différents des recommandations quant à la manière dont votre environnement effectue la vérification de SPF ou DKIM affecteront la capacité du système à effectuer une analyse DMARC adéquate et dégraderont également (jusqu'à l'inutilité) la qualité des données de rapport que le système envoie.

• La modification de l'action de mise en œuvre du système DMARC par rapport à la politique déterminée pour les messages sape le travail que les propriétaires de domaines du monde entier ont investi dans l'authentification de leur trafic. S'ils ont pris la peine de vérifier et de corriger l'authentification et de publier une politique à l'adresse p=reject ou p=quarantine , veuillez vous y conformer et permettre à votre ASE d'obéir au résultat.

• Si votre (vos) domaine(s) n'est (ne sont) pas encore à p=reject ou p=quarantine, les paramètres d'application de votre ESA n'affecteront pas les courriels contenant votre domaine dans l'en-tête From. Et lorsque vous voudrez appliquer ces paramètres à votre propre enregistrement DMARC, vous voudrez que tous les environnements adhèrent à votre politique. Participez à l'environnement global de reporting et de mise en œuvre dont vous bénéficiez.

Résultats de ces changements

• Votre ESA déterminera correctement les résultats d'authentification SPF et DKIM pour les messages entrants. Il n'y a pas d'élément de mise en application, c'est-à-dire que la détermination de ce résultat ne modifiera pas les résultats de la livraison.
  • Il peut y avoir d'autres enregistrements connexes dans les journaux de courrier et d'autres informations utiles dans les en-têtes des messages acceptés.

• Votre ASE déterminera les résultats de l'authentification DMARC (qui s'appuie sur les résultats de l'authentification SPF et DKIM) et appliquera la politique ; cela offre une protection supplémentaire contre le spam et le phishing.
  • Il peut y avoir d'autres enregistrements connexes dans les journaux de courrier et d'autres informations utiles dans les en-têtes des messages acceptés.

• Si le domaine pour lequel l'authentification DMARC a été vérifiée a une politique DMARC p=reject et que l'authentification a échoué, le message sera rejeté lors de la conversation SMTP comme prévu et demandé par le propriétaire du domaine.

• Si le domaine pour lequel l'authentification DMARC a été vérifiée a une politique DMARC p=quarantine et que l'authentification a échoué, le message sera mis en quarantaine dans la quarantaine de politique de l'ESA.

• Si le domaine pour lequel l'authentification DMARC a été vérifiée a une politique DMARC p=none et que l'authentification a échoué, aucune action ne sera entreprise sur le message.

• Votre ESA va générer et envoyer des données DMARC RUA aux propriétaires de domaines aux adresses spécifiées dans leurs enregistrements DMARC. Par exemple, si votre ESA voit des messages où gmail.com est présent dans l'en-tête From des messages, l'ESA va générer un rapport RUA à l'adresse de rapport gmail.com, qui se trouve être l'adresse mailauth-reports@google.com.

---

---

---

Profils de vérification

Techniquement, il devrait s'agir de "profils de vérification DKIM", puisque personne ne devrait utiliser "DomainKeys", qui a été déprécié en 2007.

Nous vous suggérons de ne créer, conserver ou modifier que le profil DEFAULT ; vous ne devriez pas avoir besoin d'un autre profil. Comme nous l'avons mentionné précédemment, la vérification DKIM en elle-même (configurée de cette manière) n'a aucun impact sur la livraison des messages.

Modifiez, mettez à jour ou créez le profil pour qu'il corresponde exactement aux paramètres comme indiqué dans la capture d'écran suivante :

Profils de vérification - Notes

• Les clés inférieures à 1024 sont connues pour être trop faibles pour une utilisation en production. N'utilisez pas et n'acceptez pas de clés DKIM inférieures à cette taille.
• Des clés plus grandes que 2048 sont utilisées ; le fait que l'ASE ne puisse pas encore créer ou vérifier ces clés plus grandes est un bug de Cisco.
• Certains paramètres visibles ici permettraient à l'administrateur de provoquer des rejets ou des retards de messages uniquement sur la base des résultats DKIM ou de l'échec de la vérification (en raison des résultats DNS). Ne les utilisez pas.

Configuration de DMARC

Contrairement à la section précédente, il y a certains paramètres ci-dessous que vous devrez modifier par rapport à la capture d'écran en fonction de votre environnement unique. Vous pouvez faire en sorte que votre configuration ressemble à celle ci-dessous et consulter les conseils des sections suivantes pour savoir ce que vous devez modifier pour votre propre environnement.

Configuration DMARC - Paramètres globaux

• Horaire: Afin de se conformer assez fidèlement aux normes et recommandations du RFC, l'heure prévue pour la génération du rapport doit se situer environ 15 minutes avant la fin de la journée en heure UTC. En d'autres termes, si vous êtes aux États-Unis sur la côte Est, vous aurez un paramètre différent de celui de la côte Ouest. Cisco a un bug sur la faiblesse de cet élément de configuration, alors demandez-leur. C'est beaucoup plus compliqué que vous ne le pensez. Le bogue de Cisco est CSCun35657.

• Entité: Votre entreprise ou organisation. Ce paramètre doit être le même pour tous vos SEC.

• Contact supplémentaire: Il est intégré dans les données XML envoyées aux propriétaires de domaines. Il doit s'agir d'une adresse réelle de votre domaine, mais peut-être avec des paramètres antispam et de collecte des déchets très stricts. Vous devriez être en mesure de recevoir un retour d'information ou des questions de la part des personnes qui analysent les rapports XML de votre système - ce serait assez rare, mais cela arrive.

• Laissez les autres paramètres comme indiqué dans la capture d'écran.

Configuration de DMARC - Profils de vérification

Configurez deux profils exactement comme indiqué dans la capture d'écran ci-dessous.

Politiques de flux de courrier

Les modifications apportées ici permettront de mettre en œuvre les paramètres des deux sections précédentes. Voici les trois étapes :

1. Mise à jour des valeurs par défaut
2. Mettre à jour les politiques entrantes pour accepter les valeurs par défaut
3. Corriger les politiques de sortie/relais pour remplacer les valeurs par défaut.

Politiques de flux de courrier - Mise à jour des valeurs par défaut

Ouvrez vos paramètres de politique par défaut, trouvez la section qui ressemble à la capture d'écran ci-dessous, et assurez-vous que tous les paramètres correspondent. En dehors de S/MIME (nous ne faisons rien avec cela), si vous avez quelque chose d'autre, conservez-le.

• Signature DKIM: La valeur par défaut est Désactivé, en partant du principe que la plupart des politiques HAT et autres MFP du système concernent le trafic entrant. Si votre système n'est pas configuré pour fonctionner de cette manière, la plupart de ces instructions ne vous concernent probablement pas, et vous savez probablement déjà comment modifier cette configuration pour qu'elle fonctionne correctement. Si ce n'est pas le cas, demandez de l'aide.

• Vérification DKIM: Vous souhaitez que cette option soit activée et que le profil soit le profil par défaut que nous avons configuré précédemment.

• S/MIME: ignorer

• Vérification SPF: Activé, et seulement avec la conformité SPF. Utilisez les paramètres comme indiqué.

• Vérification DMARC: Cette option doit être activée. Utilisez le profil de vérification DEFAULT. Envoyer des rapports globaux. N'envoyez pas de rapports si vous n'avez pas suivi toutes les instructions de configuration relatives à l'authentification et à l'application.

Maintenant, vous devez retourner à votre liste globale de politiques de flux de courrier (comme ci-dessous), et vous assurer de ce qui suit :

1. Vos politiques d'entrée acceptent les paramètres par défaut que nous venons de configurer.
2. Vos politiques de sortie (il s'agit généralement de politiques de relais) ont un comportement différent, généralement à l'opposé des politiques d'entrée.

Politiques de flux de courrier - Mettre à jour les politiques entrantes

Mettez à jour les politiques entrantes pour accepter les valeurs par défaut : Par exemple, en cochant Accepté et la section correspondante, vous devriez voir ce qui suit :

REMARQUE : Toutes les autres politiques de non-relais doivent être les mêmes.

Politiques de flux de courrier - Corriger les politiques de sortie/relais

Corrigez les stratégies Outbound/Relay pour remplacer les paramètres par défaut. Lorsque vous vous enregistrez dans une politique de type Relais, les paramètres doivent ressembler à ce qui suit :

• La signature DKIM est activée ici en supposant que la signature DKIM est déjà configurée pour les messages sortants. Si ce n'est pas le cas, laissez le paramètre sur Off, et envisagez de travailler sur la signature DKIM sortante si nécessaire à partir de cet environnement ESA.

Et maintenant, la dernière chose à faire est d'utiliser le bouton orange "Valider les modifications".

Si vous avez des questions sur la configuration de DMARC sur l'appliance de sécurité de messagerie de Cisco, faites-nous en part.

Nous sommes là pour vous aider
Avec une équipe d'experts en sécurité du courrier électronique et une mission visant à rendre le courrier électronique et l'Internet plus fiables grâce à la sécurité des domaines, dmarcian est là pour aider à évaluer le catalogue de domaines d'une organisation et à mettre en œuvre et gérer DMARC à long terme.