El correo electrónico es uno de los servicios fundadores de internet, ha sobrevivido a muchos cambios y sigue siendo de los más utilizados. Desafortunadamente cuando se diseño no se pensó en la seguridad, es común la suplantación de identidades o el envió de correos masivos mejor conocidos como SPAM.
Los primeros esfuerzos por evitar el SPAM surgió a partir del uso de listas negras (blacklist), me llegó a tocar aparecer en algunas, luego solicitarles amablemente que te quitaran cumpliendo primero con algunos requisitos.
Pero esto era poco práctico y con demasiados falsos positivos, por eso ahora hay dos técnicas que se utilizan ampliamente para validar el origen de un correo electrónico y son DKIM y SPF.
DomainKeys Identified Mail (DKIM) es un método para la autentificación de correo electrónico, permite a una persona que recibe el correo electrónico verificar que el mensaje procede efectivamente del dominio que pretende haber venido. La necesidad de este tipo de autentificación surge porque el SPAM a menudo ha falsificado las cabeceras de los mensajes.
Sender Policy Framework (SPF) es la última iniciativa para combatir el SPAM. Se trata de un protocolo que mediante dos técnicas intenta averiguar si existe una suplantación de identidad en los mensajes recibidos, con sólo examinar sus cabeceras.
En pocas palabras, todos los correos van a salir con un sello que certifica su origen, así no van a poder decir que a chuchita la bolsearon.
En este artículo voy a intentar explicar como activar ambas técnicas usando un servidor Ubuntu, no tiene que ser necesariamente esta distribución, pero pueden existir ligeras diferencias en una u otra y en temas de seguridad hasta un bit importa, si algo no esta bien las firmas no lo estarán, el mensaje no se validará y no llegaremos a ningún lado. Sin embargo, supongo que esta información se puede adaptar a prácticamente cualquier distribución de linux.
No voy a profundizar en los aspectos de la instalación de un Ubuntu server ya que en internet hay muchos sitios que tratan el tema.
Les puedo recomendar el uso de virtualbox para hacer algunas pruebas antes de hacer esto en un servidor en producción.
Instalar el software necesario.
Instalar postfix como MTA, opendkim para firmar los correos y mpack para enviar la configuración a otro equipo.
sudo apt-get install postfix opendkim mpack
Elegir la configuración de Sitio de internet para postfix.
Nombre de dominio www.sysadminsdecuba.com y Hostname del servidor mail . Cualquier nombre de dominio esta bien para hacer algunas pruebas. Claro que esto lo tienen que cambiar para un servidor en producción.
Generar las llaves de opendkim
Llegó el momento de ponernos serios, les recuerdo que estos valores son de ejemplo y tendrán que ajustarlos a sus propias instalaciones.
Primero, crear una carpeta en /etc/opendkim
Y luego hay que generar las llaves para opendkim con el comando:
opendkim-genkey -s mail -d www.sysadminsdecuba.com
Nombre del selector mail y dominio www.sysadminsdecuba.com son de ejemplo pero son valores importantes.
Esto genera dos archivos mail.txt y mail.private que son las llaves que se van a usar para firmar los correos.
Enviamos el archivo mail.txt a un correo electrónico ya que contiene la información necesaria para modificar el DNS.
mpack -s “info mail” /etc/opendkim/mail.txt [email protected]
Para esto usé el comando mpack para mandarlos por correo, pero pueden copiar el archivo a un dispositivo usb o cualquier otro medio que tengan a la mano.
Antes de poder usar este archivo, primero hay que hacerle algunos ajustes.
Cadena Original:
mail._domainkey IN TXT "v=DKIM1;=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB452iQKBgQDao2xAQRdxOKCw+sgUCreo2sL5Jo7hd36goGbktsu9E0vYWf2RD2m1si1gTM8DDrXFHMYa9U7iflpduStkeAYEEecs47nnqYi4nohYV9nSAHSQ1/9akn+orLdilv/j4a4i7qHAG/mTANpSnZAU4upWstaD4xZnt/iqrDlt5p/2rwIDAQAB" ; ----- DKIM mail for www.sysadminsdecuba.com
Tenemos que agregar la letra k antes de =rsa; y agregar el texto t=y; después del rsa para indicar que es de prueba.
Con los ajustes realizados quedaría más o menos así:
mail._domainkey IN TXT "v=DKIM1;k=rsa;t=y; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB452iQKBgQDao2xAQRdxOKCw+sgUCreo2sL5Jo7hd36goGbktsu9E0vYWf2RD2m1si1gTM8DDrXFHMYa9U7iflpduStkeAYEEecs47nnqYi4nohYV9nSAHSQ1/9akn+orLdilv/j4a4i7qHAG/mTANpSnZAU4upWstaD4xZnt/iqrDlt5p/2rwIDAQAB" ; ----- DKIM mail for www.sysadminsdecuba.com
Y con esto obtenemos básicamente lo que es la definición del DNS que tenemos que ajustar en el dominio.
Atención.
Las instrucciones para dar de alta esta información en nuestro DNS puede ser muy variadas, tendrán que investigar por su cuenta sobre como modificar la información de un DNS.
Probamos si esta todo correcto con esta instrucción:
opendkim-testkey -d www.sysadminsdecuba.com
-s mail -k mail.private -vvv
al final la instrucción debe decir:
opendkim-testkey: key OK
Eso quiere decir que esta correcto.
Configurar opendkim
Primero se edita el archivo /etc/default/opendkim y agregamos esta línea.
SOCKET="inet:8891@localhost"
Editamos el archivo /etc/opendkim.conf y ajustamos las siguientes líneas.
Domain www.sysadminsdecuba.com
KeyFile /etc/opendkim/mail.private
Selector mail
InternalHosts /etc/opendkim/internal_hosts
Creamos el archivo internal_hosts cuyo contenido será las direcciones IP que están autorizadas por dkim para firmar correos.
sudo nano /etc/opendkim/internal_hosts
direccion.ip.de.su.servidor
Reiniciamos opendkim:
sudo service opendkim restart
Configurar postfix.
Agregar estas líneas al final del archivo /etc/postfix/main.cf
smtpd_milters=inet:localhost:8891
non_smtpd_milters=inet:localhost:8891
ajustar los valores:
myhostname = mail.www.sysadminsdecuba.com
y
mynetworks = agregando la dirección ip de donde quieren que se manden los correos.
Mediante la directiva mynetworks definimos qué redes o hosts pueden enviar correo a través de nuestro Postfix. Un ejemplo sería
mynetworks = 127.0.0.0/8, 192.168.2.0/24, 172.16.3.4/32
Con esta configuración estamos definiendo: La red 127.0.0.0 puede enviar. Esta red siempre será nuestra propia máquina (localhost). Los 254 hosts de la red 192.168.2.0 pueden usar nuestro servidor. Solo el host 172.16.3.4 puede usar nuestro servidor, y ninguno más de la red 172.16.3.0. Por ejemplo, el 172.16.3.14 no podría.
Reiniciamos posftfix
sudo service postfix restart
Configurar SPF en DNS
Es mucho más sencillo siguiendo esta regla:
“v=spf1 ip4:REPLACE_WITH_IP a mx a:REPLACE_WITH_HOSTNAME ~all”
Ejemplo,
"v=spf1 ip4:192.168.0.1 a mx include:mail.www.sysadminsdecuba.com
~all"
Esto se coloca en el DNS como un TXT general.
Verificar SPF en Postfix
Instalar el demonio
Lo primero es lo primero que tenemos que instalar el demonio que se va a comprobar los registros SPF para nosotros. Esto viene como un módulo postfix tendremos que configurar.
sudo apt-get install postfix-policyd-spf-perl
Lo siguiente que necesitamos para localizar el archivo ejecutable, por defecto este se encuentra en /usr/sbin/postfix-policyd-spf-perl
sin embargo para otros sabores linux esto es probable que encuentra en otros lugares.
Para localizar el ejecutable podemos utilizar los siguientes comandos
updatedb locate policyd-spf
Ubicaciones probables son /usr/bin/
, /usr/sbin/
, /usr/local/bin/
etc. (Las ubicaciones habituales que encontrarían un ejecutable a). Tome nota de la ubicación del ejecutable, ya que lo necesitará más adelante.
Configurar postfix
Lo siguiente que necesitamos para configurar postfix para utilizar el nuevo demonio que hemos instalado. Abra /etc/postfix/main.cf
con su editor favorito
nano /etc/postfix/main.cf
Agregue la siguiente opción en la parte inferior del archivo
policy-spf_time_limit = 3600s
Esto cambia el tiempo límite para que el servidor de políticas no se interrumpirá mientras que todavía se está procesando un mensaje.
Después de eso ahora tenemos que editar /etc/postfix/master.cf
para configurar un nuevo servicio para postfix a utilizar.
policy-spf unix - nn - - spawn user=nobody argv=/usr/sbin/postfix-policyd-spf-perl
Cambie el argv=
opción en consecuencia con la ubicación del ejecutable que instalamos previamente.
Finalmente tenemos que añadir el nuevo servicio de la política en nuestro smtpd_recipient_restrictions
opción en /etc/postfix/main.cf
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policy-spf
Nota: Coloque el servidor de la política después de reject_unauth_destination para evitar respuestas inesperadas del servicio de la política y para evitar que el sistema se convierta en una retransmisión abierta. También debe poner el servicio de la política después de usted permite remitentes locales, ya que sólo queremos comprobar los registros SPF de correo entrante de Internet, correo no saliente de usted o sus usuarios.
Lo último que hay que hacer es postfix reload
sudo /etc/init.d/postfix reload
Verificación Está funcionando
La forma más sencilla de varify usted ha instalado correctamente y configurado la comprobación SPF es monitorear su registro electrónico, mientras que el envío de un correo electrónico a ti mismo desde una fuente externa, como Gmail.
tail -f /var/log/mail.log
Si hay un problema con el servicio de la política o su integración con Postfix que se registrará, correo asimismo aceptado que pasa la comprobación SPF también se registrará.
Aug 11 17:23:51 <redacted> postfix/policy-spf[5509]: Policy action=PREPEND Received-SPF: pass (gmail.com ... _spf.google.com: Sender is authorized to use '<redacted>@gmail.com' in 'mfrom' identity (mechanism 'include:_netblocks.google.com' matched)) receiver=<redacted>.armandof.com; identity=mailfrom; envelope-from="<redacted>@gmail.com"; helo=mail-qg0-f46.google.com; client-ip=<redacted>
Pruebas, pruebas y más pruebas.
Una forma muy sencilla de probar si todo es correcto es configurando un cliente de correo electrónico (puedo sugerir thunderbird) para que utilice el servidor que acabamos de configurar como su SMTP y enviar un correo a [email protected]
Su respuesta nos dará los resultados:
The Port25 Solutions, Inc. team
=====================================
Summary of Results
=====================================
**SPF check: pass**
DomainKeys check: neutral
**DKIM check: pass**
Sender-ID check: pass
SpamAssassin check: ham
Si todo salió bien y terminaron las pruebas, entonces quiten el texto t=y; del DNS para indicar que ya son valores finales y las pruebas terminaron.
Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0
hola a todos, estoy teniendo dificultades con DKIM, quisiera saber si hay que tener control de la zona DNS, y si en caso de no tenerla, el registro DKIm debe estar agregado en los DNS de ETECSA, pues ya lo tengo configurado y mi DNS interno y obtengo el siguiente error
‘default._domainkey.uptcer.co.cu’ record not found
ademas al hacer un netstat no monta el puerto 8891 por ningun lado y sin embargo el servicio inicia
necesito ayuda pues estoy teniendo dificultades con la suplantacion de identidad, tengo corregido la suplantacion interna y dominio y usuarios inexistentes externos, sin embargo, cuando el correo existe realmente no matchea de que el helo es diferente del remitente
mi mail es [email protected]
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
tengo estos errores alguna idea
opendkim-genkey -b 2048 -d domain.com -s mail opendkim-genkey: openssl exited with status %d
Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
I have been surfing online more than 7 hours today
#SYSAdmin – #Servidor de #correo #Postfix con #DKIM y #SPF , yet I never found any
interesting article like yours. It’s pretty worth enough for me.
In my view, if all webmasters and bloggers made good content as you did,
the web will be a lot more useful than ever before.
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
That´s the main problem with the internet these days, a lot of info, but poorly documented or badly executed. We try not to fall on that terms… We test all we write here, thousands of times… 😀
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Estimados compañeros, es posible utilizar alguna herramienta como cbpolicyd para rechazar ataques de SPAM al Zimbra.
Warning: Undefined array key 1 in /var/www/html/sysadminsdecuba/wp-content/plugins/wp-useragent/wp-useragent-detect-os.php on line 668
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Si es posible, y se ha utilizado para crear filtro de correos por usuarios que puedan enviar local, nacional e internacional, así mismo se puede habilitar otros módulos, como el de SPF, amavis, etc.
Access Control
Access control lists. Matching policies can have verdicts of HOLD, REJECT, DISCARD, FILTER, REDIRECT and contain optional verdict data.
Amavis
Support for Amavisd-new.
CheckHelo
Support for various HELO/EHLO checks.
CheckSPF
Support for various SPF checks.
Greylisting
Greylisting support.
Información aquí:
Para versiones 8.7.x y 8.8.x
https://www.sysadminsdecuba.com/2017/12/zimbra-implementacion-de-cbpolicyd/
Para versiones anteriores a 8.7.x
https://wiki.zimbra.com/wiki/How-to_for_cbpolicyd
https://www.jorgedelacruz.es/2014/03/10/zimbra-cluebringer-policyd/
hola,hace poco que descrubri este sitio y me encanto,esta buenisimo y trata buenos temas,aqui les traigo una duda a ver si me pueden ayudar, yo estoy configurando un servidor de correo con postfix y dovecot en debian7, ya lo tengo configurado completamente el unico problema que tengo es que mediante una coneccion via telnet por el puerto 25 y luego con el comando mail puedo mandar un correo sin problemas y sin la debiada autenticacion… como puedo eliminar ese problema???saludos de antemano
a mi me parece perfecto, yo cree los regisros SPF , configure postfix para chequear, aun tego dudas, por ejemplo tengo claro que ya con mi registro SPF nadie me puede suplantar mi dominio o mi ideintidad, pero por ejemplo otras personas si podrian suplantar la ideintidad de un dominio que no tenga creado correctamente el registro SPF o inventar un dominio y enviarme mensajes, no me queda claro el chequeo del helo ehlo necesito ayuda, he intentado probar y si me he mandando mensajes de dominios que existen y no pasa nada
a la hora de generar el key opendkim-genkey -s mail -d http://www.sysadminsdecuba.com, me da error bash: opendkim-genkey: no se encontró la orden; esto sobre debian 8, alguna idea?
Ahora quisiera que me aclaras algo:
Cuando alguien hace telnet 1.2.3.4 25
ehlo ac.cu
mail from:[email protected]
rcpt to: [email protected] (Aqui debe poner un reject??)
En mi caso no lo pone pero tampoco llega al usuario que se quiere suplantar.
Salu2
A primera lectura me parece muy útil. Voy a seguirle bien los pasos para realizarlo en mi entorno,
Aprovecho para reconocer el eficiente y desinteresado trabajo de divulgación que haces en pro de conocer más profundamente el software libre. Debieras recibir un premio, junto a otros promotores de GUTL por este esfuerzo
No hay de que men, la idea es poner los manuales que de verdad funcionan a disposicion de todos y que en sus servidores este la seguridad al mas alto nivel posible, para que puedan dormir tranquilamente