Configurar correo electrónico seguro con SPF, DMARC y DKIM

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

Pero, eso 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.

https://toolbox.googleapps.com/apps/checkmx/

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.

https://toolbox.googleapps.com/apps/messageheader/

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.

"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

Crear configuración DMARC

https://mxtoolbox.com/DMARCRecordGenerator.aspx?domain=elhacker.net

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

¿Qué ocurre si mi dominio ya tiene una clave DKIM?

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

https://admin.google.com/u/2/ac/apps/gmail/authenticateemail?hl=es

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

Añadimos y/o comentamos y descomentamos las líneas

Mode sv

Canonicalization relaxed/simple

#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:

Etiquetas: dkim , dmarc , dns , e-mail , manual , marketing , mta , phishing , Postfix , selector , sendmail , spf , sysadmin , tutorial

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.

Tienda Wifi

Tutoriales y Manuales

Entradas Mensuales

Síguenos en:

Blogroll

Etiquetas

Entradas populares