Guide de configuration DMARC pour Cisco ESA

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

Si vous estimez que l'authentification DMARC et les rapports de votre système sont déjà correctement configurés, veuillez prendre le temps de lire attentivement ces informations et de les comparer à vos paramètres actuels. Ces paramètres représentent les meilleures pratiques de l'industrie, et nous vous encourageons à ne pas vous en écarter. La version d'AsyncOS de votre ESA doit être 13 ou supérieure. Si elle est de 14, elle doit être 14.0.2 ou supérieure en raison d'un bogue dans les versions antérieures de 14.

NOTES :

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

• Des paramètres s'écartant des recommandations concernant la manière dont votre environnement effectue la vérification SPF ou DKIM, ou si elle l'effectue, affecteront la capacité du système à réaliser une analyse DMARC adéquate et dégraderont également (au point de les rendre inutilisables) la qualité de toutes les données de rapport envoyées par le système.

• Modifier l'action d'application DMARC du système par rapport à la politique déterminée pour les messages compromet le travail que les propriétaires de domaines du monde entier ont investi pour authentifier leur trafic. S'ils ont fait le nécessaire pour vérifier et corriger l'authentification et publier une politique p=reject ou p=quarantine, veuillez vous y conformer et permettre à votre ESA d'obéir au résultat.

• Si votre ou vos domaines n'ont pas encore atteint p=reject ou p=quarantine, les paramètres d'application sur votre ESA n'affecteront pas les e-mails avec votre domaine dans l'en-tête From. Et au moment où 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 rapport et d'application dont vous bénéficiez.

Résultats de l'application de ces modifications

• Votre ESA déterminera correctement les résultats d'authentification SPF et DKIM pour les messages entrants. Il n'y a pas de composant d'application à cela, c'est-à-dire que la détermination de ce résultat n'altérera pas les résultats de livraison.
  • Il pourra y avoir des journaux supplémentaires liés dans les logs de courrier et des informations utiles additionnelles dans les en-têtes des messages acceptés.

• Votre ESA déterminera les résultats d'authentification DMARC (s'appuie sur les résultats d'authentification SPF et DKIM) et appliquera la politique ; cela offre une protection supplémentaire contre le spam et le phishing.
  • Il pourra y avoir des journaux supplémentaires liés dans les logs de courrier et des informations utiles additionnelles 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é pendant 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 sur 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 générera et enverra les données RUA DMARC aux propriétaires de domaines aux adresses spécifiées dans leurs enregistrements DMARC. Par exemple, si votre ESA détecte des messages où gmail.com était présent dans l'en-tête From des messages, l'ESA générera un rapport RUA à l'adresse de rapport de gmail.com, qui est actuellement [email protected].

---

---

---

Profils de vérification

Techniquement, il devrait s'agir de « profils de vérification DKIM », car personne ne devrait utiliser « DomainKeys » — cette technologie a été dépréciée en 2007.

Nous vous suggérons de créer, conserver ou modifier uniquement le profil PAR DÉFAUT ; vous ne devriez pas en avoir besoin d'un autre. Comme mentionné précédemment, la vérification DKIM en soi (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 affichés dans la capture d'écran suivante :

Profils de vérification – Notes

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

Configuration DMARC

Contrairement à la section précédente, certains paramètres ci-dessous devront être adaptés par rapport à la capture d'écran, en fonction de votre environnement spécifique. Vous pouvez configurer votre système comme indiqué ci-dessous et consulter les directives des sections suivantes pour savoir ce que vous devez modifier pour votre propre environnement.

Configuration DMARC – Paramètres globaux

• Planification : Afin de se conformer assez fidèlement aux normes et recommandations RFC, vous devez définir l'heure de génération des rapports planifiés à environ 15 minutes avant la fin de la journée en temps UTC. En d'autres termes, si vous êtes aux États-Unis sur la côte Est, vous aurez un réglage différent de celui de la côte Ouest. Cisco a un bug concernant la piètre qualité de cet élément de configuration, alors interrogez-les à ce sujet. C'est beaucoup plus compliqué que vous ne le pensez. Le bug Cisco est CSCun35657.

• Entité : Votre entreprise ou organisation. Ce paramètre doit être identique sur tous vos ESA.

• Contact supplémentaire : Ceci est renseigné dans les données XML envoyées aux propriétaires de domaines. Il devrait s'agir d'une adresse réelle de votre domaine, mais peut-être avec des paramètres antispam et de collecte des indésirables stricts. Vous devriez pouvoir recevoir des commentaires ou des questions de la part de personnes qui analysent les rapports XML de votre système — ce serait assez rare, mais cela arrive.

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

Configuration 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 mettront en œuvre les paramètres des deux sections précédentes. Voici les trois étapes :

1. Mettre à jour les paramètres par défaut
2. Mettre à jour les politiques entrantes pour accepter les paramètres par défaut
3. Corriger les politiques sortantes/de relais pour remplacer les paramètres par défaut

Politiques de flux de courrier – Mise à jour des paramètres 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. À l'exception de S/MIME (nous n'en faisons rien), si vous avez d'autres configurations, conservez-les.

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

• Vérification DKIM: Vous souhaitez que cette option soit Activée, et que le profil soit celui par DÉFAUT que nous avons configuré précédemment.

• S/MIME: ignorer

• Vérification SPF: Activé, et uniquement avec la conformité SPF. Utilisez les paramètres tels qu'indiqués.

• Vérification DMARC: Cette option doit être Activée. Utilisez le profil de vérification DÉFAUT. Envoyez des rapports agrégés. N'envoyez pas de rapports si vous n'avez pas suivi toutes les instructions de configuration relatives à l'authentification et à l'application des politiques.

Vous devez maintenant revenir à votre liste globale de politiques de flux de messagerie (comme indiqué ci-dessous), et vous assurer des points suivants :

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

Politiques de flux de messagerie – Mettre à jour les politiques entrantes

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

REMARQUE : Toutes les autres politiques non-relais doivent être identiques.

Politiques de flux de messagerie – Corriger les politiques sortantes/de relais

Corriger les politiques sortantes/de relais pour remplacer les valeurs par défaut. Lorsque vous examinez la politique de type Relais, les paramètres doivent ressembler à ce qui suit :

• La signature DKIM est définie sur Activé ici, en supposant que vous avez déjà configuré la signature DKIM pour les messages sortants. Si ce n'est pas le cas, laissez le paramètre sur Désactivé et envisagez de configurer la signature DKIM sortante si cela est approprié depuis 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-le nous savoir.

Nous sommes là pour vous aider
Avec une équipe d'experts en sécurité e-mail et une mission visant à rendre l'e-mail et Internet plus fiables grâce à la sécurité des domaines, dmarcian est là pour aider à évaluer le catalogue de domaines d'une organisation, et à implémenter et gérer DMARC sur le long terme.