DANE pour appliance de sécurité de la messagerie

Introduction

Ce document décrit l'implémentation DANE pour le flux de messages sortants ESA.

Conditions préalables

Connaissance générale des concepts et de la configuration ESA.

Exigences relatives à la mise en oeuvre du DANE :

• Résolveur DNS compatible DNSSEC
• ESA avec AsyncOS 12.0 ou version ultérieure

Informations générales

DANE a été introduit dans ESA 12 pour la validation du courrier sortant.

Authentification DNS des entités nommées (DANE).

• DANE est un protocole de sécurité Internet qui permet de lier des certificats numériques X.509 à des noms de domaine à l'aide de DNSSEC. (RFC 6698)
• DNSSEC est un ensemble de spécifications IETF pour la sécurisation des enregistrements DNS à l'aide de la cryptographie à clé publique. (Explication très élémentaire. RFC 4033, RFC 4034 et RFC 4035)

Considérations relatives à la mise en oeuvre

Vérifiez que l'ESA utilise un résolveur DNS compatible dnssec.

La capacité DNS à exécuter des requêtes DNSSEC/DANE est requise pour implémenter DANE.

Pour tester la fonctionnalité ESA DNS DANE, un test simple peut être effectué à partir de la connexion à l'interface de ligne de commande ESA.

La commande CLI « daneverify » exécute les requêtes complexes pour vérifier si un domaine est capable de passer la vérification DANE.

La même commande peut être utilisée avec un domaine valide connu pour confirmer la capacité de l'ESA à résoudre les requêtes dnssec.

'ietf.org' est une source mondialement connue. L'exécution de la commande cli « daneverify » permet de vérifier si le résolveur DNS est compatible DANE ou non.

RÉUSSITE VALIDE : RÉSULTATS « DANE SUCCESS » DU SERVEUR DNS COMPATIBLE DANE POUR ietf.org

> daneverify ietf.org

SECURE MX record(mail.ietf.org) found for ietf.org
SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
Connecting to 4.31.198.44 on port 25.
Connected to 4.31.198.44 from interface 216.71.133.161.
SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
Checking TLS connection.
TLS connection established: protocol TLSv1.2, cipher ECDHE-RSA-AES256-GCM-SHA384.
Certificate verification successful
TLS connection succeeded ietf.org.
DANE SUCCESS for ietf.org
DANE verification completed.

ÉCHEC NON VALIDE : RÉSULTATS « FAUX » DE SERVEUR DNS NON DANOIS POUR ietf.org

> daneverify ietf.org

BOGUS MX record found for ietf.org
DANE FAILED for ietf.org
DANE verification completed.

ECHEC VALIDE : daneverify cisco.com > cisco n'a pas implémenté DANE. Il s'agit du résultat attendu d'un résolveur compatible dnssec.

> daneverify cisco.com

INSECURE MX record(alln-mx-01.cisco.com) found for cisco.com
INSECURE MX record(alln-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (173.37.147.230) found for MX(alln-mx-01.cisco.com) in cisco.com
Trying next MX record in cisco.com
INSECURE MX record(rcdn-mx-01.cisco.com) found for cisco.com
INSECURE MX record(rcdn-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (72.163.7.166) found for MX(rcdn-mx-01.cisco.com) in cisco.com
Trying next MX record in cisco.com
INSECURE MX record(aer-mx-01.cisco.com) found for cisco.com
INSECURE MX record(aer-mx-01.cisco.com) found. The command will still proceed.
INSECURE A record (173.38.212.150) found for MX(aer-mx-01.cisco.com) in cisco.com
DANE FAILED for cisco.com
DANE verification completed.

Si les tests ci-dessus "VALIDE" fonctionnent :

• Une approche prudente consisterait à tester chaque domaine avant d'ajouter un profil pour le domaine.
• Une approche plus agressive serait de configurer DANE sur le profil de contrôle de la destination par défaut et de voir qui réussit/échoue.

La direction du courrier détermine si le DANE vérifiera.

Les stratégies de groupe d'expéditeurs/de flux de messages pour lesquelles l'action « RELAIS » est configurée effectueront une vérification DANE.

Les stratégies de groupe d'expéditeurs/de flux de messagerie dont l'action « ACCEPT » est configurée n'attendront PAS la vérification DANE.

Attention : si le contrôle de destination DANE est activé sur la stratégie par défaut de l'ESA, il existe un risque d'échec de livraison.  Si un domaine interne, tel que ceux répertoriés dans le TAD, passe par les politiques de flux de messages RELAY et ACCEPT, associées à la présence d'une route SMTP pour le domaine.

Routes SMTP

DANE échouera sur les routes SMTP à moins que l'hôte de destination ne soit configuré sur USEDNS.

DANE Opportunistic ne remettra pas les messages, les contenant dans la file d'attente de remise jusqu'à l'expiration du minuteur de profil de renvoi.

Pourquoi ? La vérification DANE est ignorée car une route SMTP serait une modification de la destination réelle et pourrait ne pas utiliser correctement DNS.

Solution : créez des profils de contrôle de destination pour désactiver explicitement la vérification DANE pour les domaines contenant des routes SMTP

DANE Opportuniste ou DANE Obligatoire

Les recherches suivantes sont effectuées lors de la vérification DANE.

Chaque vérification alimente le contenu pour effectuer la vérification suivante.

• La recherche d'enregistrement MX vérifie si >>> est sécurisé, non sécurisé, faux
• Une recherche d'enregistrement vérifie si >>> Secure Insecure > Bogus
• La recherche d'enregistrements TLSA vérifie si >>> est sécurisé, non sécurisé, faux, NXDOMAIN
• Vérification du certificat >> Réussite, Échec

Sécurisé :

• DNS a vérifié la présence d'un enregistrement sécurisé contenant un DNS et une DNSKEY RRSIG validés et signés, en amont de la chaîne de confiance.

Non sécurisé :

• Le DNS détermine que le domaine n'a pas d'enregistrement activé dnssec présent. 

Faux :

• Les entrées dnssec présentes sont incomplètes, mais la vérification peut échouer.
• Enregistrements non valides en raison d'une clé expirée.
• Enregistrement ou clé manquant dans la chaîne d'approbation.

NXDOMAIN

• Aucun enregistrement trouvé dans DNS.

Une combinaison de la vérification des dossiers ci-dessus et des résultats de la vérification déterminera le succès du DANE | DANE Fail | DANE revient à TLS."

Par exemple : si aucun enregistrement RRSIG n'est envoyé pour l'enregistrement MX d'example.com, la zone parent (.com) est vérifiée pour voir si example.com a un enregistrement DNSKEY, indiquant que example.com devrait signer ses enregistrements. Cette validation se poursuit jusqu'à la fin de la chaîne de confiance avec la vérification de la clé de la zone racine (.). Les clés de la zone racine correspondent à ce que l'ESA attend (valeurs codées en dur sur l'ESA, qui est automatiquement mis à jour sur la base de RFC5011).

DANOIS OBLIGATOIRE

DANOIS OBLIGATOIRE

Note : DANE OPPORTUNISTIC NE SE COMPORTE PAS COMME TLS PRÉFÉRÉ. La partie ACTION du tableau ci-dessous indique que DANE FAIL n'est pas disponible pour Obligatoire ou Opportuniste. Les messages resteront dans la file d'attente de remise jusqu'à l'expiration du minuteur, puis la remise se terminera.

DANOIS OPPORTUNISTE

DANOIS OPPORTUNISTE

Activer DANE sur plusieurs environnements d'appareils

La figure suivante illustre le workflow lorsque vous activez DANE dans un environnement à plusieurs appliances.

Si l'environnement comporte plusieurs couches d'appliances ESA, une pour l'analyse et une autre pour la remise des messages. Assurez-vous que DANE n'est configuré que sur l'appliance qui se connecte directement aux destinations externes.

Conception multi-ESA. DANE configuré sur l'ESA de livraison

Gestion de plusieurs résolveurs DNS

Si un ESA a plusieurs résolveurs DNS configurés, quelques-uns qui prennent en charge DNSSEC et quelques-uns qui ne prennent pas en charge DNSSEC, Cisco recommande de configurer les résolveurs compatibles DNSSEC avec une priorité plus élevée (valeur numérique inférieure), pour éviter les incohérences.

Cela empêche le résolveur non DNSSEC de classer le domaine de destination prenant en charge DANE comme « faux ».

Gestion du serveur DNS secondaire

Lorsque le résolveur DNS n'est pas accessible, le serveur DNS revient au serveur DNS secondaire. Si vous ne configurez pas DNSSEC sur le serveur DNS secondaire, les enregistrements MX pour les domaines de destination compatibles DANE sont classés comme « faux ». Cela a un impact sur la remise des messages, quels que soient les paramètres DANE (Opportuniste ou Obligatoire). Cisco vous recommande d'utiliser un résolveur DNSSEC secondaire.

Configuration

Configurez DANE pour le flux de messages sortants.

1. Webui Naviguez jusqu'à > Politiques de messagerie > Contrôles de la destination > Ajouter une destination
2. Remplissez la partie supérieure du profil selon vos préférences.
3. Prise en charge TLS : doit être définie sur « TLS Preferred » | Préféré - Vérifier | Requis | Obligatoire - Vérifier| Obligatoire - Vérifiez le domaine hébergé."
4. Une fois le support TLS activé, le menu déroulant DANE Support (Support DANE) s'active.
5. Assistance DANE : les options incluent « Aucun » | Opportuniste | Obligatoire.
6. Une fois l'option DANE Support terminée, envoyez et validez les modifications.

Profil de contrôle de la destination - Vérification DANE

Vérification du succès du DANE

État de livraison

Surveillez le rapport WebUI « Delivery Status » pour détecter toute accumulation non intentionnelle de domaines de destination, potentiellement due à une défaillance DANE.

Effectuez cette opération avant d'activer le service, puis régulièrement pendant plusieurs jours afin d'assurer une réussite continue.

ESA WebUI > Monitor > Delivery Status > cochez la colonne « Active Recipients ».

Journaux de messagerie

Journaux de messagerie par défaut au niveau d'information pour le niveau de journal.

Les journaux de messagerie affichent des indicateurs très subtils pour les messages négociés avec succès par DANE.

La négociation TLS sortante finale inclura une sortie légèrement modifiée pour inclure le domaine à la fin de l'entrée de journal.

L'entrée de journal inclura « TLS success protocol » suivi de TLS version/cipher « for domain.com ».

La magie est dans le "pour" :

myesa.local> grep "TLS success.*for" mail_logs

Tue Feb  5 13:20:03 2019 Info: DCID 2322371 TLS success protocol TLSv1.2 cipher DHE-RSA-AES256-GCM-SHA384 for karakun.com

Débogage des journaux de messagerie

Les journaux de messagerie personnalisés au niveau du débogage affichent les recherches DANE et dnssec complètes, la négociation attendue, les parties de la vérification qui réussissent/échouent et un indicateur de réussite.

Remarque : les journaux de messagerie configurés pour la journalisation de niveau de débogage peuvent consommer des ressources excessives sur un ESA en fonction de la charge et de la configuration du système.

Les journaux de messagerie configurés pour la consignation au niveau du débogage peuvent consommer des ressources excessives sur un ESA en fonction de la charge et de la configuration du système.

Les journaux de messagerie ne sont généralement PAS conservés au niveau de débogage pendant de longues périodes.

Les journaux de niveau de débogage peuvent générer un volume considérable de journaux de messages en peu de temps.

Il est fréquent de créer un abonnement de journal supplémentaire pour mail_logs_d et de définir la journalisation pour DEBUG.

Cette action empêche l'impact sur les journaux de messagerie existants et permet la manipulation du volume de journaux conservés pour l'abonnement.

Pour contrôler le volume des journaux créés, limitez le nombre de fichiers à gérer à un nombre inférieur, par exemple 2 à 4 fichiers.

Lorsque la surveillance, la période d'essai ou le dépannage est terminé, désactivez le journal.

Les journaux de messagerie définis pour le niveau de débogage affichent une sortie DANE très détaillée :

Success sample daneverify
daneverify ietf.org

SECURE MX record(mail.ietf.org) found for ietf.org
SECURE A record (4.31.198.44) found for MX(mail.ietf.org) in ietf.org
Connecting to 4.31.198.44 on port 25.
Connected to 4.31.198.44 from interface 194.191.40.74.
SECURE TLSA record found for MX(mail.ietf.org) in ietf.org
Checking TLS connection.
TLS connection established: protocol TLSv1.2, cipher DHE-RSA-AES256-GCM-SHA384.
Certificate verification successful
TLS connection succeeded ietf.org.
DANE SUCCESS for ietf.org
DANE verification completed.


debug level mail logs during the above 'daneverify' exeuction.
Sample output from the execution of the daneverify ietf.org will populate the dns lookups within the mail logs
Mon Feb  4 20:08:47 2019 Debug: DNS query: Q('ietf.org', 'MX')
Mon Feb  4 20:08:47 2019 Debug: DNS query: QN('ietf.org', 'MX', 'recursive_nameserver0.parent')
Mon Feb  4 20:08:47 2019 Debug: DNS query: QIP  ('ietf.org','MX','194.191.40.84',60)
Mon Feb  4 20:08:47 2019 Debug: DNS query: Q  ('ietf.org', 'MX', '194.191.40.84')
Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data([(0, 'mail.ietf.org.')], secure, 0, 1800)
Mon Feb  4 20:08:48 2019 Debug: DNS encache (ietf.org, MX, [(8496573380345476L, 0, 'SECURE', (0, 'mail.ietf.org'))])
Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'A')
Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'A', 'recursive_nameserver0.parent')
Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','A','194.191.40.84',60)
Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'A', '194.191.40.84')
Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data(['4.31.198.44'], secure, 0, 1800)
Mon Feb  4 20:08:48 2019 Debug: DNS encache (mail.ietf.org, A, [(8496573380345476L, 0, 'SECURE', '4.31.198.44')])
Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'AAAA')
Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'AAAA', 'recursive_nameserver0.parent')
Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','AAAA','194.191.40.84',60)
Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'AAAA', '194.191.40.84')
Mon Feb  4 20:08:48 2019 Warning: Received an invalid DNSSEC Response: DNSSEC_Error('mail.ietf.org', 'AAAA', '194.191.40.84', 'DNSSEC Error for hostname mail.ietf.org (AAAA) while asking 194.191.40.84. Error was: Unsupported qtype') of qtype AAAA looking up mail.ietf.org
Mon Feb  4 20:08:48 2019 Debug: DNS query: Q('mail.ietf.org', 'CNAME')
Mon Feb  4 20:08:48 2019 Debug: DNS query: QN('mail.ietf.org', 'CNAME', 'recursive_nameserver0.parent')
Mon Feb  4 20:08:48 2019 Debug: DNS query: QIP  ('mail.ietf.org','CNAME','194.191.40.83',60)
Mon Feb  4 20:08:48 2019 Debug: DNS query: Q  ('mail.ietf.org', 'CNAME', '194.191.40.83')
Mon Feb  4 20:08:48 2019 Debug: DNSSEC Response data([], , 0, 1800)
Mon Feb  4 20:08:48 2019 Debug: Received NODATA for domain mail.ietf.org type CNAME
Mon Feb  4 20:08:48 2019 Debug: No CNAME record(NoError) found for domain(mail.ietf.org)

Mon Feb  4 20:08:49 2019 Debug: DNS query: Q('_25._tcp.mail.ietf.org', 'TLSA')
Mon Feb  4 20:08:49 2019 Debug: DNS query: QN('_25._tcp.mail.ietf.org', 'TLSA', 'recursive_nameserver0.parent')
Mon Feb  4 20:08:49 2019 Debug: DNS query: QIP  ('_25._tcp.mail.ietf.org','TLSA','194.191.40.83',60)
Mon Feb  4 20:08:49 2019 Debug: DNS query: Q  ('_25._tcp.mail.ietf.org', 'TLSA', '194.191.40.83')
Mon Feb  4 20:08:49 2019 Debug: DNSSEC Response data(['0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6'], secure, 0, 1800)
Mon Feb  4 20:08:49 2019 Debug: DNS encache (_25._tcp.mail.ietf.org, TLSA, [(8496577312207991L, 0, 'SECURE', '0301010c72ac70b745ac19998811b131d662c9ac69dbdbe7cb23e5b514b56664c5d3d6')])

fail sample daneverify

[]> thinkbeyond.ch

INSECURE MX record(thinkbeyond-ch.mail.protection.outlook.com) found for thinkbeyond.ch
INSECURE MX record(thinkbeyond-ch.mail.protection.outlook.com) found. The command will still proceed.
INSECURE A record (104.47.9.36) found for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
Trying next A record (104.47.10.36) for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
INSECURE A record (104.47.10.36) found for MX(thinkbeyond-ch.mail.protection.outlook.com) in thinkbeyond.ch
DANE FAILED for thinkbeyond.ch
DANE verification completed.

mail_logs
Sample output from the execution of he danverify thinkbeyond.ch will populate the dns lookups within the mail logs
Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond.ch', 'MX')
Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond.ch', 'MX', 'recursive_nameserver0.parent')
Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond.ch','MX','194.191.40.84',60)
Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond.ch', 'MX', '194.191.40.84')
Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data([(10, 'thinkbeyond-ch.mail.protection.outlook.com.')], insecure, 0, 3600)
Mon Feb  4 20:15:52 2019 Debug: DNS encache (thinkbeyond.ch, MX, [(8502120882844461L, 0, 'INSECURE', (10, 'thinkbeyond-ch.mail.protection.outlook.com'))])
Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'A')
Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'A', 'recursive_nameserver0.parent')
Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','A','194.191.40.83',60)
Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'A', '194.191.40.83')
Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data(['104.47.9.36', '104.47.10.36'], insecure, 0, 10)
Mon Feb  4 20:15:52 2019 Debug: DNS encache (thinkbeyond-ch.mail.protection.outlook.com, A, [(8497631700844461L, 0, 'INSECURE', '104.47.9.36'), (8497631700844461L, 0, 'INSECURE', '104.47.10.36')])
Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA')
Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA', 'recursive_nameserver0.parent')
Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','AAAA','194.191.40.84',60)
Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'AAAA', '194.191.40.84')
Mon Feb  4 20:15:52 2019 Debug: DNSSEC Response data([], , 0, 32768)
Mon Feb  4 20:15:52 2019 Debug: Received NODATA for domain thinkbeyond-ch.mail.protection.outlook.com type AAAA
Mon Feb  4 20:15:52 2019 Debug: DNS query: Q('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME')
Mon Feb  4 20:15:52 2019 Debug: DNS query: QN('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', 'recursive_nameserver0.parent')
Mon Feb  4 20:15:52 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','CNAME','194.191.40.83',60)
Mon Feb  4 20:15:52 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', '194.191.40.83')
Mon Feb  4 20:15:53 2019 Warning: Received an invalid DNS Response: SERVER FAILED to IP 194.191.40.83 looking up thinkbeyond-ch.mail.protection.outlook.com
Mon Feb  4 20:15:53 2019 Debug: DNS query: QIP  ('thinkbeyond-ch.mail.protection.outlook.com','CNAME','194.191.40.84',60)
Mon Feb  4 20:15:53 2019 Debug: DNS query: Q  ('thinkbeyond-ch.mail.protection.outlook.com', 'CNAME', '194.191.40.84')
Mon Feb  4 20:15:54 2019 Warning: Received an invalid DNS Response: SERVER FAILED to IP 194.191.40.84 looking up thinkbeyond-ch.mail.protection.outlook.com
Mon Feb  4 20:15:54 2019 Debug: No CNAME record() found for domain(thinkbeyond-ch.mail.protection.outlook.com)

Informations connexes

• Guides d'utilisation ESA
• Notes de version ESA
• Guides de référence CLI ESA