Tienda Wifi

Tienda Wifi
CiudadWireless es la tienda Wifi recomendada por elhacker.NET

Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Configurar correo electrónico aún más seguro con ARC y DANE

viernes, 19 de abril de 2024 | Publicado por el-brujo | Editar entrada

Una vez configurados correctamente los clásicos SPF, DMARC y DKIM podemos añadir una nivel extra de seguridad con ARC y DANE.





Autenticación de correo electrónico de ARC



  • Authenticated Received Chain (ARC)
  • Conserva los resultados de la autenticación de correo de los mensajes reenviados
La cadena recibida autenticada (ARC) es un estándar de correo que verifica la autenticación de correo de los mensajes que se han reenviado al destinatario final. La ARC reduce las posibilidades de que los mensajes reenviados no superen la autenticación de correo.

Los encabezados de los correos electrónicos y el contenido de los mensajes se modifican durante el reenvío de correos electrónicos, por lo que SPF y DKIM fallan en el correo electrónico como resultado de una verificación fallida. Cuando el MTA de reenvío aplica ARC para el correo electrónico, se aplican tres encabezados ARC adicionales al correo electrónico, así como los datos de autenticación SPF y DKIM del mensaje original. Los tres nuevos encabezados son los siguientes:

  1. AAR (ARC-Autenticación-Resultados)
  2. AS (sello ARC)
  3. AMS (ARC-Mensaje-Firma)
Durante la verificación DMARC, el protocolo toma en consideración los encabezados ARC que hacen referencia a la información de autenticación del mensaje original para verificar la legitimidad del mensaje, anulando los cambios realizados por cualquier servidor intermediario. En caso de que el mensaje reenviado sea legítimo, DMARC pasa por él.

A veces, el reenvío de mensajes puede cambiar el contenido de los mensajes reenviados. Si se modifica el contenido de los mensajes reenviados, los mensajes legítimos pueden no superar el proceso de autenticación. La ARC ayuda a evitar que esto ocurra al hacer lo siguiente:

  • Conservar los resultados de autenticación anteriores para los mensajes reenviados
  • Verificar los servidores de reenvío
  • Añadir encabezados a los mensajes para indicar el estado de autenticación de los mensajes

Hay tres encabezados de mensajes de ARC:

  • Encabezado de resultados de autenticación de ARC: indica el estado de la autenticación de los mensajes. 
  • Encabezado de firma de mensajes de ARC: se trata de una vista general de la información de encabezado del mensaje original, que se añade a los mensajes reenviados. En este encabezado se incluyen los encabezados originales del mensaje (Para, De y Asunto) y el cuerpo del mensaje original.
  • Encabezado de sello de ARC: abarca los resultados de autenticación y de firma de ARC, que se añaden a los mensajes reenviados. Este encabezado incluye una etiqueta de validación de cadena: cv=. Esta etiqueta tiene uno de los siguientes valores, que indican los resultados de evaluación de la cadena de ARC: none, fail o pass. 

La ARC no evalúa ni proporciona información sobre la reputación del remitente ni del reenviador. La ARC no puede evitar que los servidores de reenvío añadan contenido dañino a los mensajes ni que eliminen los encabezados de ARC de los mensajes.

  • Google recomienda agregar encabezados ARC a los correos electrónicos salientes
  • Gmail empezó a quejarse de los mensajes reenviados no pasan la validación ARC.

Los remitentes de Google deben implementar ARC si:

  • Reenvían correos electrónicos de forma regular o frecuente.
  • Usan listas de correo
  • Usan puertas de enlace de entrada

Google explica que han optado por incluir ARC como parte de sus últimas pautas para remitentes, ya que los encabezados de ARC podrían identificar mensajes como «reenviados» en lugar de no autorizados, así como reconocer la dirección o dominio de reenvío original.

ARC comprueba el estado de autenticación anterior de los mensajes reenviados. Si un mensaje reenviado supera la autenticación SPF o DKIM, pero ARC muestra que anteriormente no superó la autenticación, Gmail trata el mensaje como no autenticado.

Recomendamos a los remitentes que utilicen la autenticación ARC, especialmente si reenvían correo electrónico con regularidad. Más información sobre la autenticación ARC.

Podemos utilizar OpenARC para implementar ARC en nuestro MTA.

 

DANE (DNS-Based Authentication of Name Entities)

 



  • Autenticación basada en DNS SMTP de entidades con nombre
DANE (autenticación basada en DNS de entidades con nombre) es una opción segura para el transporte de correo. El DANE utiliza la infraestructura DNSSEC y trabaja con registros TLSA para autenticar la identidad de los servidores destinatarios. Al establecer un canal seguro entre el remitente y el destinatario, el DANE evita que los correos electrónicos sean interceptados en tránsito o lleguen a manos equivocadas.




DANE para SMTP RFC 7672 usa la presencia de un registro de autenticación de seguridad de la capa de transporte (TLSA) en el conjunto de registros DNS de un dominio para indicar un dominio y sus servidores de correo admiten DANE. Si no hay ningún registro TLSA presente, la resolución DNS para el flujo de correo funcionará como de costumbre sin que se intente realizar ninguna comprobación dane. El registro TLSA indica de forma segura la compatibilidad con TLS y publica la directiva DANE para el dominio.

Domain-based Authentication of Named Entities (DANE) es una norma más reciente que permite publicar información sobre certificados en DNS con registros TLSA. De este modo, un remitente puede verificar el certificado del servidor de correo electrónico receptor basándose en la información del registro TLSA. Esto también indica que el receptor admite el cifrado antes de iniciar una conexión STARTTLS. Para garantizar la validez de la información del certificado, DANE sólo funciona en combinación con DNSSEC.

Al enviar correos electrónicos, su servidor de correo no admite DANE.


¿Cuáles son los componentes de DANE?

Registro de recursos TLSA

El registro de autenticación TLS (TLSA) se usa para asociar el certificado X.509 o el valor de clave pública de un servidor con el nombre de dominio que contiene el registro. Los registros TLSA solo pueden ser de confianza si DNSSEC está habilitado en el dominio. Si usa un proveedor de DNS para hospedar el dominio, dnssec puede ser una configuración que se ofrece al configurar un dominio con ellos.


 Implementar registros TLSA

Registro tipo TLSA de ejemplo:

_25._tcp.ns2.elhacker.net

 _[port]._[protocol].[domain]

Puerto 25, TCP, MX ns2.elhacker.net


DANE utiliza el registro de recursos DNS "TLSA", que se especifica en rfc6698. Un registro TLSA contiene información sobre un certificado x.509 que cabe esperar del servicio al que se está conectando (como servicios web HTTPS o servicios SMTP).


Hay 4 valores:

  1. Usage
  2. Selector
  3. Matching
  4. Certificado Asociado
[usage] [selector] [matching type] [certificate association data]

Por ejemplo:

3 1 1 15fb2335e1ca1eb4013f7389322c6f0a7ebd361b9e841f46a1eed58783c3d06a

Usage 

  • 0 - PKIX-TA: Certificate Authority Constraint
  • 1 - PKIX-EE: Service Certificate Constraint
  • 2 - DANE-TA: Trust Anchor Assertion
  • 3 - DANE-EE: Domain Issued Certificate
0 El certificado usado es la entidad de certificación pública de anclaje de confianza de la cadena de confianza X.509.
1 El certificado comprobado es el servidor de destino; Las comprobaciones de DNSSEC deben comprobar su autenticidad.
2 Use la clave privada del servidor del árbol X.509 que debe validar un delimitador de confianza en la cadena de confianza. El registro TLSA especifica el delimitador de confianza que se usará para validar los certificados TLS para el dominio.
3 Solo coincide con el certificado del servidor de destino.

Selector

  • 0 - Cert: Use full certificate
  • 1 - SPKI: Use subject public key
0 Use el certificado completo.
1 Use la clave pública del certificado y el algoritmo con el que se identifica la clave pública que se va a usar.

Matching-Type


  • 0 - Full: No Hash
  • 1 - SHA-256: SHA-256 hash
  • 2 - SHA-512: SHA-512 hash
0 Los datos del registro TSLA son el certificado completo o SPKI.
1 Los datos del registro TSLA son un hash SHA-256 del certificado o spki.
2 Los datos del registro TSLA son un hash SHA-512 del certificado o spki.


Según las instrucciones de implementación de RFC para SMTP DANE, se recomienda un registro TLSA compuesto por el campo Uso de certificado establecido en 3, el campo Selector establecido en 1 y el campo Tipo de coincidencia establecido en 1.

Certificado Asociado


Y el último valor 4 es serial (el valor) del certificado:

# When using selector=0 (Full Certificate) on the certificate:
openssl x509 -in certificate.pem -outform DER | sha256sum

# When using selector=1 (SubjectPublicKeyInfo) on a certificate:
openssl x509 -in certificate.pem -pubkey -noout | openssl rsa -pubin
 -outform der | sha256sum 

# When using selector=1 (SubjectPublicKeyInfo) on the private key:
openssl rsa -in private.pem -pubout -outform DER | sha256sum

# When using selector=1 (SubjectPublicKeyInfo) on the public key:
openssl rsa -pubin public.pem -outform DER | sha256sum




Etiquetas: , , , , , ,

0 comentarios :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.