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 seguro con SPF, DMARC y DKIM

sábado, 28 de noviembre de 2020 | Publicado por el-brujo | Editar entrada

Pero, esto del SPF, DKIM y DMARC… ¿qué son? Empecemos por el principio. Seguro que sabes que los ataques en el envío de emails son cada vez más numerosos y selectivos. El phishing es una técnica utilizada por los estafadores para obtener información personal. Los phishers envían un email fingiendo ser una organización de confianza (banco, Paypal, eBay, Amazon…), con el fin de robarnos datos confidenciales como la información bancaria, datos de acceso a cuentas, etc. Gracias a estos datos, los estafadores pueden, por ejemplo, realizar transferencias bancarias a sus cuentas o conectarse a un sitio para enviar spam. La razón es bastante simple: estos son los principales protocolos para verificar la identidad de los remitentes y evitar que tus e-mails lleguen a la temida  carpeta de spam o correo no deseado. Evitar el spoofing, el phishing y el spam. Gmail quiere acabar con el Phishing usando cuentas verificadas por e-mail con el soporte de BIMI, con el logotipo verificado de un e-mail. La idea es que las marcas verificadas que envíen correos tendrán un logotipo de la marca en el espacio del avatar en la esquina superior izquierda de los mensajes para garantizar su veracidad.



Protocolos de autenticación

  • SPF (Sender Policy Framework)
  • DMARC (Autenticación de mensajes, informes y conformidad basada en dominios, del inglés Domain-based Message Authentication, Reporting & Conformance) 
  • DKIM (Domain Keys Identified Mail)
Para configurar los ajustes de autenticación SPF, DKIM y DMARC para tu dominio, necesitas acceder a los registros DNS de tu cuenta de hosting (OVH, 1&1, HostGator, etc.). Si no los encuentras o no tienes acceso a ellos, tu proveedor de alojamiento puede ayudarte.

Normalmente tu proveedor de hosting creará un registro SPF adecuado para tu dominio, y tú no tendrás que hacer nada más. Pero de todos modos es importante que sepas cómo funciona por si tuvieras que modificarlo, o si tuvieras que crearlo tú.

Enviado por: elhacker.net (SPF)
Firmado por: elhacker.net (DKIM)




Puedes Identificar en el código fuente (mostrar original o ver cabeceras) las referencias "spf=pass", "dkim=pass", y "dmarc=pass")



En paneles de control tipo Plesk, CPanel la configuración es automática.

SPF

El Sender Policy Framework, o SPF, es un estándar de autenticación que vincula un nombre de dominio a una dirección de correo electrónico. Consiste en definir cuál es el remitente (o remitentes) autorizado "pass" para enviar emails con un dominio determinado. De este modo, los clientes de emails como Gmail o Outlook pueden comprobar que el email entrante procede de un host autorizado por el administrador del dominio desde el que se envía.

Ejemplo:

v=spf1 ip4:91.126.217.153 ip4:72.9.144.207 include:_spf.google.com -all
  • v=spf1 --> versión del spf1
  • ip4 --> dirección IPv4
  • ip6 --> dirección IPv6
  • a --> ip dominio actual
  • mx --> ip que resuelve el registro MX de la DNS
  • include --> _spf.google.com todos los servidores de correo de Google Apps, si tu  servidor (que no webmail) correo MX lo gestiona Google
all | ip4 | ip6 | a | mx | ptr | exists | include

Indicadores
  • +all --> pass
  • -all --> fail
  • ~all --> softfail
  • ?all --> neutral

Comprobar configuraciones


"Check MX" es una herramienta de Google para validación de DNS fácil de usar que permite buscar las configuraciones de los registros MX incorrectas más frecuentes.


Por ejemplo al hacer _spf.google.com incluye automáticamente las siguientes direcciones IP se han tomado de las directivas IP4/IP6 e includes del registro SPF:

_spf.google.com
_netblocks.google.com
35.190.247.0/24
64.233.160.0/19
66.102.0.0/20
66.249.80.0/20
72.14.192.0/18
74.125.0.0/16
108.177.8.0/21
173.194.0.0/16
209.85.128.0/17
216.58.192.0/19
216.239.32.0/19
_netblocks2.google.com
2001:4860:4000::/36
2404:6800:4000::/36
2607:f8b0:4000::/36
2800:3f0:4000::/36
2a00:1450:4000::/36
2c0f:fb50:4000::/36
_netblocks3.google.com
172.217.0.0/19
172.217.32.0/20
172.217.128.0/19
172.217.160.0/20
172.217.192.0/19
172.253.56.0/21
172.253.112.0/20
108.177.96.0/19
35.191.0.0/16
130.211.0.0/22


Analizar cabeceras (Headers) de un e-mail

Investigar problemas de correo Messageheader analiza los encabezados de los mensajes SMTP, lo que ayuda a identificar el motivo que origina los retrasos en la entrega. Puedes detectar servidores con una configuración incorrecta y problemas de enrutamiento del correo. 

¿Qué información puede proporcionarme esta herramienta sobre las cabeceras de correos electrónicos? Identifica retrasos de entrega. Identifica el origen aproximado del retraso. Identifica al posible usuario responsable.

Spoofing y phishing


 Los spammers pueden falsificar tu dominio para enviar mensajes falsos suplantando la identidad de tu organización. Los mensajes falsificados suelen utilizarse con fines malintencionados, como divulgar información falsa o enviar software malicioso. También se envían para suplantar identidades (phishing), una estafa que consiste en engañar a los usuarios para que proporcionen información sensible, como nombres de usuario, contraseñas o datos de tarjetas de crédito. El spoofing puede afectar durante mucho tiempo a la reputación de una organización y menoscabar la confianza de los usuarios y clientes. 

A veces, los spammers falsifican mensajes para que parezca que proceden de organizaciones legítimas o conocidas. Si los spammers envían mensajes falsos con el nombre de tu organización, los usuarios que reciban estos mensajes pueden marcarlos como spam. Si muchas personas marcan estos mensajes como spam, es posible que los mensajes legítimos de tu organización también se marquen como tal. 

Cómo evita DMARC el spoofing 

DMARC indica a los servidores de correo qué hacer cuando reciben un mensaje que parece que procede de tu organización, pero que no supera las comprobaciones de autenticación o no cumple los requisitos de autenticación indicados en el registro de la política de DMARC. Los mensajes sin autenticar podrían estar suplantando a tu organización o proceder de servidores no autorizados. DMARC siempre se usa con estos dos métodos o comprobaciones de autenticación de correo electrónico:


  • El marco de políticas del remitente (SPF) permite que el propietario de un dominio autorice las direcciones IP que pueden enviar mensajes en ese dominio. Los servidores que reciben los mensajes pueden verificar si los que parecen proceder de un dominio concreto se han enviado desde servidores permitidos por el propietario de ese dominio. 
  • DomainKeys Identified Mail (DKIM) añade una firma digital a cada mensaje enviado. Gracias a esa firma, los servidores que reciben los mensajes pueden verificar que son auténticos y que no se han falsificado ni modificado durante el envío.



DMARC

Antes de poder crear un registro DMARC, tienes que haber creado los registros para DKIM y SPF 

La autenticación de mensajes, informes y conformidad basada en dominios (DMARC) es un método de autenticación de correos electrónicos estándar. Con DMARC, los administradores de correo pueden evitar que los hackers y otros atacantes suplanten la identidad de su organización o falsifiquen su dominio. El spoofing es un tipo de ataque en el que se falsifica la dirección del campo De de un mensaje de correo electrónico. Un mensaje falsificado parece proceder de la organización o del dominio suplantados. 

DMARC también te permite solicitar informes de servidores de correo electrónico que reciben mensajes de tu organización o dominio. Estos informes contienen información que ayuda a identificar posibles problemas de autenticación y actividad maliciosa en los mensajes enviados desde tu dominio. 

DMARC (Autenticación de mensajes, informes y conformidad basada en dominios, del inglés Domain-based Message Authentication, Reporting & Conformance) es una técnica de autenticación de correos electrónicos. DMARC fue creado por PayPal junto con Google, Microsoft y Yahoo! Con DMARC, un dueño de un dominio publica un registro DMARC y ganará percepción y control sobre el correo electrónico enviado en su nombre. Puede usar DMARC para proteger sus dominios contra el abuso en phishing o ataques de redireccionamiento.

p=

  • "none" ninguna política se aplica. Esta opción se usa cuando únicamente se pretende dar feedback al emisor del correo. 
  • "quarantine": El correo cuya verificación falle debe tratarse como sospechoso, señalándolo como tal al usuario final o enviando a carpeta de spam. 
  • "reject": El correo cuya verificación falle debe rechazarse.

Opciones básicas DMARC:
  • «v=» es el nombre del registro (en este caso le hemos denominado «DMARC1») 
  • «p=» es la indicación de lo que el DMARC debe hacer con los emails (puede ser «reject» para rechazarlos, «quarantine» para ponerles en cuarentena o espera, o «none» se procesa de manera habitual
  • «sp=» es el subdomain policy y se refiere a los subdomnios
  • pct --> Porcentaje de correos electrónicos que se deben tratar de acuerdo con la política (policy) establecida anteriormente; ese valor suele ser 100.
  • «rua» corresponde a la forma en la que el DMARC solicita que se ejecuten los reportes de fallos detectados (en este caso, «rua» es utilizado cuando queremos un resumen general
  • «ruf» es cuando se busca recibir a detalle los mensajes que hayan fallado).
Modelo de feedback

  • Aggregate: Mediante un fichero XML los receptores informan de los servidores intermediarios que ven en la ruta del correo. Incluye entre otros datos, el número de correos, resultado de autenticación, dominios contenidos en el correo, política solicitada y política aplicada.
  • Failure (forensics): La especificación permite a los emisores solicitar información sobre correos individuales para su análisis. Esta información contendrá las cabeceras Subject, From, cabecera de trazas, URLS y ficheros adjuntos, etc.

Otras opciones:
  • “adkim” puedes escoger entre dos opciones de configuración; “r” (relajado), o “s” (estricto). Lo normal es escoger la opción “r”, ya que es más útil cuando se envían correos desde subdominios, pues de lo contrario estos no pasarían el registro DMARC, aunque realmente verdaderos y fiables. Ejemplo correo@elhacker.net o correo@subdominio.elhacker.net
  •  aspf Configuración para la verificación de DKIM o SPF: - s=Strict: el dominio debe coincidir exactamente (estricto). Por ejemplo: usuario@elhacker.net - r=Relaxed: se puede tratar de un subdominio (relajado). Por ejemplo: usuario@newsletter.elhacker.net
  • fo --> Failure Reporting Options son las opciones de configuración especial respecto a los avisos de correos electrónicos con resultado negativo: - fo=0: cuando SPF y DKIM establecen resultado negativo. Esta es la configuración por defecto. - fo=1: cuando uno de los dos procesos (SPF y DKIM) no “aprueba” la verificación. - fo=d: avisar de fallo de DKIM si la firma no es correcta, aunque la clave coincida. - fo=s: avisar de fallo de SPF si la autentificación SPF falla por algún motivo, incluso si los registros SPF en el encabezamiento y el informe DNS concuerdan. En el registro DMARC pueden incluirse varias opciones separadas por dos puntos.
  • rf  --> Formato de informe: - afrf: Authentication Failure Reporting Formats (formato de autentificación de informes negativos) - iodef: Incident Object Description Exchange Format (formato para la descripción e intercambio) El formato afrf viene por defecto.
  • ri --> Reporting Interval a indicar en segundos; estándar es 86 400, es decir, 24 horas (una vez al día).



DMARC no necesita una configuración específica. Los servidores de la lista blanca se enumeran en un registro DNS, TXT o SPF. _dmarc IN TXT ("v = DMARC1; p = none; sp = none; rua = mailto: user@domain.com")

Ejemplo:
Nombre del host DNS (nombre del registro TXT): 
v=DMARC1;p=quarantine;sp=reject;rua=mailto:webmaster@elhacker.net

El reporting o informe también forma parte de DMARC. Los servidores receptores deben enviar con regularidad un informe al dominio del remitente informando sobre los correos sospechosos (es decir, aquellos que no se pudieron autentificar, ni con DKIM, ni con SPF). Estas direcciones de correo electrónico quedan registradas en DMARC. Recibirás un reporte en XML en el e-mail indicado en mailto:

Por ejemplo de Google, Mail.ru, Yahoo.com, Yahoo.com.ar

De: noreply-dmarc-support@google.com
Asunto: Report domain: elhacker.net Submitter: google.com Report-ID: XXX

De:dmarc_support@corp.mail.ru
Asunto:Report Domain: elhacker.net; Submitter: Mail.Ru; Report-ID: XXX

Asunto:Report Domain: elhacker.net Submitter: yahoo.es Report-ID: <XXX>
From: noreply@dmarc.yahoo.com

Report Domain: elhacker.net; Submitter: Mail.Ru; Report-ID: XXXX
dmarc_support@corp.mail.ru

Report Domain: elhacker.net Submitter: yahoo.com.ar Report-ID: <XXX>
noreply@dmarc.yahoo.com

Comprobar configuración DMARC

DKIM

  • Autenticar el correo electrónico mediante DKIM

DKIM es DomainKeys Identified Mail y se utiliza en servidores de correo, como Postfix o Sendmail, para firmar correos electrónicos y así autenticar al remitente para que se pueda detectar una falsificación. También reduce la posibilidad de que un correo electrónico se marque como spam, pero no es una prevención definitiva. DKIM incluye un hash criptográfico en el encabezado del correo electrónico que se calcula con la clave privada (en el servidor) y se verifica con la clave pública (en el registro DNS).

Si en tu dominio ya tienes una clave DKIM de otro sistema de correo electrónico, genera una clave de dominio única para poder usarla con Gmail. 

Estas claves de dominio incluyen una cadena de texto, denominada prefijo selector, que puedes editar cuando generas la clave. El prefijo selector predeterminado de la clave de dominio de Google Workspace es google. Al generar la clave, puedes cambiar el prefijo selector predeterminado de google por el texto que elijas y utilizar el nuevo selector junto con la configuración de la clave DKIM actual del dominio.

Si utilizas Google Apps  (Google for Education de pago) también puedes firmar los e-mails con DKIM, para ello debes ir a al Admin Console:

Aplicaciones --> G Suite --> Configuración de Gmail --> Autenticar el correo electrónico

Google Apps te proporcionará la public key de forma automática, sólo deberás añadirla al registros DNS.


Selector de Google es "google" en el ejemplo usaremos "default" y normalmente se usa "smtp" o "k1"

Nombre del host DNS (nombre del registro TXT):
google._domainkey
Valor del registro TXT:
v=DKIM1; k=rsa; p=xxx

  • Selector (s): google
  • Domain (d): yourdomain.com 
  • Public Key (p)

El registro DKIM cuenta con dos claves de cifrado de los correos electrónicos desde las direcciones email bajo un dominio Web: 

  • La primera clave es absolutamente privada, lo que significa que está reservada al propietario o administrador del dominio Web, y crea una firma cifrada que va incluida en cada correo electrónico que se envía. 
  • La segunda clave es pública y sirve para que el servidor receptor, donde se encuentra la dirección email del destinatario del envío, verifique si el email entrante fue enviado desde una dirección de correo fiable y que tiene acceso a la clave privada del registro DKIM del dominio Web.

 OpenDKIM

Vamos a ver cómo configurar OpenDKIM con el MTA sendmail.

alternatives --config mta

Nos aseguramos que nuestro MTA sea sendmail en vez de postifx u otro

Instalar opendkim con dnf o ym

yum install opendkim

El fichero de configuración se encuentra en:

/etc/opendkim.conf 

Busca la línea "Mode v" y cámbiela por "Modo sv". Por defecto, OpenDKIM está configurado en modo verificación (v), que verifica las firmas DKIM de los mensajes de correo electrónico recibidos. Si cambiamos el modo a "sv", podremos activar el modo de firma para los mensajes de correo electrónico salientes. 



Mode sv

Y además: 

Canonicalization relaxed/simple


Estableces la postura de canonicalización para el dominio de envío. Esto regula los cambios en los espacios en blanco y el ajuste del texto en un mensaje. Hay dos posturas de canonicalización: 'simple' no permite ningún cambio, y 'relaxed' permite cambios comunes en los espacios en blanco y en el ajuste de línea de la cabecera. La canonicalización en la cabecera y el cuerpo puede gestionarse individualmente y utiliza un formato cabecera/cuerpo.


Traducción realizada con la versión gratuita del traductor DeepL.com 

#KeyFile /etc/opendkim/keys/default.private

KeyTable /etc/opendkim/KeyTable

SigningTable refile:/etc/opendkim/SigningTable

ExternalIgnoreList refile:/etc/opendkim/TrustedHosts

Tres nuevos ficheros de configuración:

  • /etc/opendkim/TrustedHosts --> añadimos a parte de 127.0.0.1 ip's de confianza
  • /etc/opendkim/SigningTable -->  *@elhacker.net default._domainkey.elhacker.net #Todos los usaurios de @elhacker.net pueden firmar. Puedes especificar usuarios y dominios en vez de usar un wildcard
  • /etc/opendkim/KeyTable --> default._domainkey.elhacker.net elhacker.net:default:/etc/opendkim/keys/elhacker.net/default.private # hemos usado el selector default
Generar las claves privadas en un directorio por si tenemos varios dominios:

# cd /etc/opendkim/keys 
# mkdir elhacker.net
# opendkim-genkey -D /etc/opendkim/keys/elhacker.net -d elhacker.net -s default

De nuevo podemos especificar el -s el selector y -d el dominio y -D el directorio 


El comando genera una clave privada (default) y una clave pública (default.txt). Probablemente los cambiará de nombre para que coincidan con la configuración. Una nota importante aquí es que los archivos son propiedad del usuario opendkim, o obtendrá errores de permiso denegado en /var/log/mail.err. Los permisos predeterminados sobre esos archivos son -rw——. Mueve la clave privada a donde especificó que debería estar en KeyTable.


Dar permisos:

chown root:opendkim default.*

Iniciar y habilitar el servicio:

# systemctl start opendkim 

# systemctl enable opendkim 


Ahora falta modificar sendmail para que trabaje con Opendkim

Editar el fichero de configuración (no edites directamente el sendmail.cf)

cat /etc/mail/sendmail.mc

Añade la línea:

INPUT_MAIL_FILTER(`opendkim', `S=inet:8891@localhost')

Regenera sendmail y reinicialo

# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf 

# systemctl restart sendmail 

Si usas PostFix en el fichero de configuración /etc/postfix/main.cf añade


milter_protocol = 2

milter_default_action = accept

smtpd_milters = inet:localhost:8891

non_smtpd_milters = inet:localhost:8891


 Para comprobar que sendmail está funcionando con opendkim

/var/log/maillog 

Deberías ver algo así:

ns2 sendmail[3821493]: Milter insert (1): header: DKIM-Filter:  OpenDKIM Filter v2.11.0 ns2.elhacker.net 

ns2 opendkim[3044718]: DKIM-Signature field added (s=default, d=elhacker.net)


Sólo falta añadir registro DNS a tu dominio:

# cat /etc/opendkim/keys/elhacker.net/default.txt
default._domainkey      IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCaYC/q5Zys3i/B1OuhL9/Hwr2j1MqyxiupvW0t0YLBTgm2J9tsGQBjs6S90BPGgsrbz5Z8yDyWp6cln1yAjhriSqKMeYYD8arKyf0eUoioN4LSLXcLDAzxBIfmrNPM8DJs7ss83iWAShdU4LG9N8BuPuVWGZTxpaZLlu/CEnxv+QIDAQAB" )  ; ----- DKIM key default for elhacker.net

SSL Sendmail: 

Por defecto Sendmail viene con SSL habilitado con certificados autofirmados:

dnl Enable STARTTLS for receiving email. 

define(`CERT_DIR', `/etc/mail/certs')dnl 

define(`confSERVER_CERT', `CERT_DIR/host.cert')dnl

define(`confSERVER_KEY', `CERT_DIR/host.key')dnl

define(`confCLIENT_CERT', `CERT_DIR/host.cert')dnl 

define(`confCLIENT_KEY', `CERT_DIR/host.key')dnl 

define(`confCACERT', `CERT_DIR/cacert.pem')dnl 

define(`confCACERT_PATH', `CERT_DIR')dnl

define(`confDH_PARAMETERS', `CERT_DIR/dh.param')dnl


Para configurar los nuestros primero haremos una copia de los originales:

cp -r /etc/mail/certs /etc/mail/certs.ori


Ahora ya podemos editar la configuración:


cd /etc/mail 

vi sendmail.mc

 dnl Enable STARTTLS for receiving email. 

define(`CERT_DIR', `/etc/mail/certs/elhacker.net')dnl 

define(`confSERVER_CERT', `CERT_DIR/fullchain.cer')dnl 

define(`confSERVER_KEY', `CERT_DIR/elhacker.net.key')dnl 

define(`confCLIENT_CERT', `CERT_DIR/fullchain.cer')dnl 

define(`confCLIENT_KEY', `CERT_DIR/elhacker.net.key')dnl 

define(`confCACERT', `CERT_DIR/ca.cer')dnl 

define(`confCACERT_PATH', `CERT_DIR')dnl 

define(`confDH_PARAMETERS', `CERT_DIR/dh.param')dnl 

Los certificados los obtendremos como mas guste, acme, certbot o cualquier otro método. Compilamos la configuración:

make 

cp sendmail.cf sendmail.cf.ori 

cp sendmail.mc.cf sendmail.cf

Reiniciamos el servicio:

service sendmail restart

Dejamos un tail en el log para asegurarnos de que todo sigue funcionando:

 tail -f /var/log/maillog

 Realizamos una prueba manual para comprobar que nos sirve el certificado correcto: 

openssl s_client -connect ns2.elhacker.net:25 -starttls smtp 

Una forma de comprobar el SSL tanto la entrada como la salida es mediante esta web: 

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

Strict Transport Encryption (DANE)



  • 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.