DANÉS para el dispositivo de seguridad del correo electrónico
Contenido
Introducción
Este documento describe la implementación del DANÉS para el flujo de correo saliente ESA.
Prerrequisitos
Conocimiento general de los conceptos y de la configuración ESA.
Requisitos de implementar al DANÉS:
- Solucionador de DNS DNSSEC capaz
- ESA con AsyncOS 12.0 o más nuevo
Antecedentes
Han presentado al DANÉS a ESA 12 para la validación saliente del correo.
Autenticación basada en DNS de Entities Nombrada (DANÉS).
- El DANÉS es un protocolo de seguridad de Internet para permitir que los Certificados digitales X.509, estén limitados a los Domain Name usando DNSSEC. (RFC 6698)
- DNSSEC está una colección de especificaciones IETF para asegurar los expedientes DNS con el uso del Cifrado de clave pública. (Explicación muy elemental. RFC 4033, RFC 4034, y RFC 4035)
Consideraciones para la implementación
Verifique el ESA utiliza un solucionador de DNS capaz del dnssec.
La capacidad DNS de realizar las interrogaciones dnssec/DANE se requiere implementar al DANÉS.
Para probar la capacidad del DANÉS ESA DNS una prueba simple se puede realizar del login ESA CLI.
El comando CLI “daneverify” realizará las interrogaciones complejas para verificar si un dominio es capaz de pasar la verificación del DANÉS.
El mismo comando se puede utilizar con un buen dominio sabido para confirmar la capacidad ESA de resolver las interrogaciones del dnssec.
“ietf.org” es una fuente global sabida. Realizando el comando cli “daneverify” verificará si el solucionador de DNS es DANÉS capaz o no.
PASO VÁLIDO: El SERVIDOR DNS CAPAZ “ÉXITO del DANÉS del DANÉS” RESULTA PARA 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.
FALL INVÁLIDO: RESULTADOS “FALSOS” CAPACES del SERVIDOR DNS NON-DANE PARA ietf.org
> daneverify ietf.org
BOGUS MX record found for ietf.org
DANE FAILED for ietf.org
DANE verification completed.
FALL VÁLIDO: daneverify cisco.com > Cisco no ha implementado al DANÉS. Éste es el resultado esperado de un software de resolución de nombres capaz del 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 el trabajo “VÁLIDO” antedicho de las pruebas:
- Un método cauteloso sería probar cada dominio antes de agregar un perfil para el dominio.
- Un acercamiento más agresivo sería configurar al DANÉS en el perfil predeterminado de los controles del destino y considerar quién fallan los pasos/.
La dirección del correo determina si el DANÉS verifica.
Las directivas del flujo del grupo/correo del remitente que tienen la acción de la “RETRANSMISIÓN” configurada verificación del DANÉS del peform.
Las directivas del flujo del grupo/correo del remitente que tienen “VALIDAR” la acción configurada no verificación del DANÉS del pefor.
Rutas S TP
El DANÉS fallará en las rutas S TP a menos que la “computadora principal de destino” se configure a “USEDNS.”
El DANÉS oportunista no entregará los mensajes, conteniéndolos en la cola de la salida hasta que expire el temporizador del perfil de la despedida.
¿por qué? La verificación del DANÉS consigue saltada puesto que una ruta S TP sería una modificación del destino verdadero y puede no utilizar correctamente el DNS.
Solución: Cree los perfiles del control del destino para inhabilitar explícitamente la verificación del DANÉS para los dominios que contienen las rutas S TP
DANÉS oportunista o DANÉS obligatorio
Las operaciones de búsqueda siguientes se realizan durante la verificación del DANÉS.
Cada verificación alimenta el contenido para realizar la verificación subsiguiente.
- Las operaciones de búsqueda del registro MX verifican si >>> seguro, inseguro, falso
- Las operaciones de búsqueda de registro verifican si inseguro del >>> > falso seguros
- TLSA registran las operaciones de búsqueda verifican si >>> seguro, inseguro, falso, NXDOMAIN
- El certificado verifica >> éxito, fallado
Asegure:
- El DNS verificó la presencia de un registro seguro que contenía un RRSIG firmado validado RRSIG DS y DNSKEY, encima del encadenamiento de la confianza.
Inseguro:
- El DNS determina el dominio no tiene ningún expediente habilitado dnssec presente.
Falso:
- Las entradas incompletas, pero del presente del dnssec pueden fallar la verificación.
- Expedientes inválidos debido a una clave expirada.
- Expediente o clave que falta en el encadenamiento de la confianza.
NXDOMAIN
- Ningún expediente encontrado en el DNS.
Una combinación del control de registro antedicho y de los resultados de la verificación determinará el “éxito del DANÉS | Fall del DANÉS | Retraso del DANÉS a TLS.”
Eg.: si no hay RRSIG enviados para el registro MX de example.com, la zona del padre (.com) se marca para considerar si example.com tiene un expediente DNSKEY, indicando que example.com debe firmar sus expedientes. Esta validación continúa encima del encadenamiento del acabamiento de la confianza con la clave verification.is de la zona de la raíz (.) alcanzado, y de la coincidencia de las claves de la zona de la raíz qué el ESA espera (los valores codificados por hardware en el ESA, que consigue auto-actualizado basado en el RFC5011).
DANÉS MANDATORY
DANÉS MANDATORY
DANÉS OPORTUNISTA
DANÉS OPORTUNISTA
DANÉS del permiso en el entorno múltiple del dispositivo
La figura siguiente ilustra el flujo de trabajo cuando usted habilita al DANÉS en un entorno múltiple del dispositivo.
Si el entorno tiene capas múltiples de dispositivos ESA, uno para analizar y otro para entregar los mensajes se asegura que el DANÉS consigue solamente configurado en el dispositivo que conecta directamente con los destinos exteriores.
Diseño Multi-ESA. DANÉS configurado en la salida ESA
Manejo de los solucionadores de DNS múltiples
Si un ESA tiene solucionadores de DNS múltiples configurados, algunos que soportan DNSSEC algunos que no soporten DNSSEC, Cisco recomienda el configurar de los softwares de resolución de nombres DNSSEC capaces con una prioridad más alta (un valor numérico más bajo), para prevenir las inconsistencias.
Esto previene el software de resolución de nombres capaz NON-DNSSEC para clasificar el dominio del destino que soporta al DANÉS como “falso”.
Manejo del servidor DNS secundario
Cuando el solucionador de DNS no es accesible, el DNS recurre al servidor DNS secundario. Si usted no configura DNSSEC en el servidor DNS secundario, los expedientes MX para los dominios capaces del destino del DANÉS se clasifican como “falso.” Esto afecta la entrega de mensajes con independencia de las configuraciones del DANÉS (oportunista u obligatorio). Cisco le recomienda para utilizar un software de resolución de nombres DNSSEC capaz secundario.
Configuración
DANÉS de la configuración para el flujo de correo saliente.
- Webui navega a > las directivas del correo > destino de los controles del destino > Add
- Complete la porción superior del perfil a su preferencia.
- Soporte de TLS: se requiere para ser fijado a “TLS prefirió | Preferido - Verifique | Necesario | Requerido - Verifique| Requerido - Verifique el dominio recibido.”
- Una vez que se ha habilitado el soporte de TLS, soporte del DANÉS: el menú desplegable llegará a ser activo.
- Soporte del DANÉS: las opciones no incluyen “ninguno | Oportunista | Obligatorio.
- Una vez que se ha completado la opción del soporte del DANÉS, someta y confíe los cambios.
Perfil del control del destino - El DANÉS verifica
Verifique el éxito del DANÉS
Estatus de la salida
Monitoree del “el informe estatus de la salida” del WebUI para cualquier acumulación involuntaria de los dominios del destino, potencialmente debido al error del DANÉS.
Realice esto antes de habilitar el servicio, después periódicamente durante varios días para asegurar el éxito continuo.
WebUI ESA > monitor > estatus > control de la salida la columna de los “beneficiarios activos”.
Registros del correo
Registros predeterminados del correo en el nivel informativo para el nivel del registro.
Los registros del correo muestran los indicadores muy sutiles para los mensajes con éxito negociados del DANÉS.
La negociación final de TLS saliente incluirá una salida levemente modificada para incluir el dominio en el extremo de la entrada de registro.
La entrada de registro incluirá “el protocolo del éxito de TLS” seguido por el TLS versión/la cifra “para domain.com”.
La magia está en “para”:
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
Debug de los registros del correo
Los registros de encargo del correo en el nivel de debug visualizarán las operaciones de búsqueda completas del DANÉS y del dnssec, negociación esperada, las porciones del control que pasan/fall y un indicador del éxito.
Los registros del correo configurados para el registro del nivel de debug pueden consumir a los recursos excesivos en un ESA dependiendo de la carga del sistema y de la configuración.
Los registros del correo no se mantienen generalmente en el nivel de debug por los períodos ampliados.
Los registros del nivel de debug pueden generar un enorme volumen de correo abren una sesión un período corto.
Una práctica frecuente es crear una suscripción adicional del registro para el mail_logs_d y fijar el registro para el DEBUG.
La acción previene el impacto a los mail_logs existentes y permite la manipulación al volumen de registros mantenidos para la suscripción.
Para controlar el volumen de registros creados, restrinja el número de archivos para mantener a un número más pequeño tal como 2-4 archivos.
Cuando la supervisión, el período de prueba o el troubleshooting ha completado, inhabilite el registro.
Envíe los registros fijados para el DANÉS muy detallado de la demostración del nivel de debug hechos salir:
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)
Información Relacionada
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)