Configurando DKIM sobre Proxmox Mail Gateway

Proxmox Mail Gateway (PMG) es una plataforma integral de seguridad de correo electrónico de fuente abierta que lo ayuda a proteger su servidor de correo de las amenazas de correo electrónico y a garantizar la integridad de los datos con su conjunto de funciones de clase empresarial. Pero carece del mecanismo de autenticación de correo electrónico DKIM, que aún no han implementado y que de seguro pondrán mas adelante. DKIM utiliza criptografía de clave pública para permitir al origen firmar electrónicamente correos electrónicos legítimos de manera que puedan ser verificados por los destinatarios. Entre los proveedores de servicio de correo que implementan ese sistema se encuentran Yahoo, Gmail, y FastMail. Cualquier correo originado desde estas organizaciones deben llevar una firma DKIM.

DKIM también protege contra la manipulación de correo electrónico, proporcionando integridad de extremo a extremo, desde un módulo firmante a un módulo validador. En la mayoría de los casos el módulo firmante actúa en nombre de la organización originaria insertando una firma DKIM en las cabeceras del mensaje, y el módulo de comprobación en nombre de la organización del receptor, validando la firma obteniendo la clave pública del firmante a través del DNS.

Cómo funciona

DKIM añade una cabecera llamada «DKIM-Signature» que contiene una firma digital del contenido (cabeceras y cuerpo) del mensaje. Los parámetros por defecto del mecanismo de autenticación son la utilización de SHA-256 como la firma criptográfica y RSA como el esquema de criptografía asimétrica. Finalmente se codifica la firma resultante con Base64.

El servidor SMTP utiliza el nombre de dominio perteneciente al emisor, la cadena «_domainkey», y un selector del campo de la firma DKIM para realizar una consulta al DNS. La respuesta debe incluir la clave pública del dominio. El receptor puede utilizar esta información para descifrar el valor de la firma del campo de la cabecera, y al mismo tiempo, recalcular el valor de la firma para el mensaje (cabeceras y cuerpo) que ha recibido. Si los dos resultados coinciden, esto prueba criptográficamente que el mensaje fue firmado por el dominio indicado y que no ha sido alterado en tránsito.

Un fallo en la verificación de la firma no fuerza el rechazo del mensaje. Por contra, las razones precisas por las cuales la autenticidad del mensaje no ha podido ser verificada deberían comunicarse tanto al proceso de envío como el de recepción.

Instalamos paquetes necesarios, es muy recomendable actualizar el sistema antes de continuar.

apt update && apt upgrade -y && apt dist-upgrade -y

aptitude install opendkim opendkim-tools ccze

Editamos el fichero de configuración /etc/opendkim.conf en nuestro caso como manejamos varios subdominios de correo, es decir un dominio principal y varios subdominios de este, vamos a necesitar un juego de llaves privada/pública para cada uno. Comentamos todas las líneas que aparecen en el fichero y al final añadimos todas estas que es en realidad como debe quedarnos el fichero.

nano /etc/opendkim.conf

El mismo debe de quedar de la siguiente forma:

PidFile /var/run/opendkim/opendkim.pid
Mode sv
Syslog yes
SyslogSuccess yes
LogWhy yes
UserID opendkim:opendkim
Socket inet:8891@localhost
Umask 002
Canonicalization relaxed/relaxed
Selector default
MinimumKeyBits 1024
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts

>>Salvamos y continuamos <<

Ahora conectamos OpenDKIM con Postfix.

Editamos el default de opendkim, nos debe quedar de la siguiente forma:

 nano /etc/default/opendkim

RUNDIR=/var/spool/postfix/var/run/opendkim
RUNDIR=/var/run/opendkim
SOCKET=local:$RUNDIR/opendkim.sock
SOCKET="inet:8891@localhost"
USER=opendkim
GROUP=opendkim
PIDFILE=$RUNDIR/$NAME.pid
EXTRAAFTER=

>>Salvamos y continuamos <<

Ahora crearemos la estructura de directorios que contendrán los host de confianza, firmas y claves criptográficas.

mkdir /etc/opendkim
mkdir /etc/opendkim/keys

Especificamos los hosts de confianza en el archivo /etc/opendkim/TrustedHosts

Vamos a utilizar este archivo para definir tanto ExternalIgnoreList y InternalHosts, los mensajes procedentes de estos hosts, dominios y direcciones IP son de confianza y pueden ser firmados.

Personalice y añada las siguientes líneas al archivo recién creado. Dominios múltiples pueden especificarse, no edite las tres primeras líneas:

nano /etc/opendkim/TrustedHosts

127.0.0.1
127.0.0.0/8
localhost
000.000.000.000 # ip del server interno de correo
pmg.dominio.cu #nombre y dominio de nuestro pmg

>> Salvamos y continuamos <<

Ahora creamos la tabla de llaves en el fichero /etc/opendkim/KeyTable

Una tabla de claves contiene cada selector por cada dominio y la ruta de acceso a su clave privada. Cualquier cadena alfanumérica puede ser utilizado como un selector, se utiliza en este ejemplo electrónico y no es necesario cambiarlo.

nano /etc/opendkim/KeyTable

default._domainkey.dominio.cu dominio.cu:default:/etc/opendkim/keys/dominio.cu/default.private

>> Salvamos y continuamos <<

Creamos una tabla de firmas. Este fichero se utiliza para declarar cada dominio de correo y su selector

nano /etc/opendkim/SigningTable

*@dominio.cu default._domainkey.dominio.cu

>> Salvamos y continuamos <<

Ahora vamos a generar las llaves privadas y públicas.

cd /etc/opendkim/keys

mkdir dominio.cu

cd dominio.cu

opendkim-genkey -r -b 2048 -d dominio.cu -s default

Cambiamos el propietario y el grupo para los ficheros de las claves privadas

cd /etc/opendkim/keys/

find . -type d -exec chown opendkim.opendkim {} \;
find . -type f -exec chown opendkim.opendkim {} \;

En este punto es el mas critico para los que no poseen delegada su zona DNS.

Añadiendo las claves públicas a los registros DNS para cada dominio. Contenido del fichero default.txt:

cat /etc/opendkim/keys/dominio.cu/default.txt

La clave pública se define con el parámetro p. No utilice la clave de este ejemplo, es sólo una ilustración y no funcionará en su servidor.

default._domainkey    IN    TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5N3lnvvrYgPCRSoqn+awTpE+iGYcKBPpo8HHbcFfCIIV10Hwo4PhCoGZSaKVHOjDm4yefKXhQjM7iKzEPuBatE7O47hAx1CJpNuIdLxhILSbEmbMxJrJAG0HZVn8z6EAoOHZNaPHmK2h4UUrjOG8zA5BHfzJf7tGwI+K619fFUwIDAQAB" ; ----- DKIM key mail for dominio.cu

Copiamos el contenido integro del fichero «default.txt» a nuestra zona DNS externa, y le añadiremos «.dominio.du.», quedando así:

default._domainkey.dominio.cu.   IN   TXT   "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5N3lnvvrYgPCRSoqn+awTpE+iGYcKBPpo8HHbcFfCIIV10Hwo4PhCoGZSaKVHOjDm4yefKXhQjM7iKzEPuBatE7O47hAx1CJpNuIdLxhILSbEmbMxJrJAG0HZVn8z6EAoOHZNaPHmK2h4UUrjOG8zA5BHfzJf7tGwI+K619fFUwIDAQAB" ; ----- DKIM key mail for dominio.cu

Debemos saber que Proxmox Mail Gateway no permite la modificacion directa de sus ficheros de configuración, así que necesitamos llegar a sus plantillas para que el reescriba el main.cf.

cd /var/lib/pmg/templates

nano main.cf.in

Y al final del mismo agregamos las siguientes líneas:

smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Nota Importante: Cuando actualice su PMG chequee que estos valores se mantengan agregados.

>> Salvamos y continuamos <<

Ahora para que aplique los cambios sin tener que reiniciar el contenedor, corremos este comando:

pmgconfig sync --restart 1

Nota: Recomiendo despues de reescribir los config con el comando anterior, en mi caso reinicio el postfix y el opendkim.

systemctl restart opendkim

systemctl restart postfix

Ahora comprobamos los mismos si estan corriendo correctamente

systemctl status opendkim

systemctl status postfix

 

Hasta aquí toda la configuración de nuestro DKIM sobre PMG, ahora solo nos queda comprobar que el mismo está firmando y comprobando correctamente los correos, para eso les dejo varios sitios muy interesantes:

http://dkimvalidator.com/

http://www.appmaildev.com/es/dkim

https://www.mail-tester.com/

Ahora en la consola ejecute el siguiente comando para que vea lo lindo que nuestro PMG utiliza el DKIM.

tailf /var/log/mail.log | ccze

En un proximo articulo como configurar Dmarc

¿De cuánta utilidad te ha parecido este contenido?

¡Haz clic en una estrella para puntuar!

Promedio de puntuación 5 / 5. Recuento de votos: 6

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

4 comentarios

  1. Google Chrome 93.0.4577.82 Google Chrome 93.0.4577.82 Windows 10 Windows 10
    Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.82 Safari/537.36

    como enlaso la configuracion que se hizo con la de la administracion web

  2. Google Chrome 93.0.4577.63 Google Chrome 93.0.4577.63 Windows 10 Windows 10
    Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36

    excelente ayuda un aporte muy importante tendras la configuracion del dmark en esta misma plataforma promox mailgateway gracias


  3. Warning: Undefined array key 1 in /var/www/html/sysadminsdecuba/wp-content/plugins/wp-useragent/wp-useragent-detect-os.php on line 668
    Firefox 69.0 Firefox 69.0 Ubuntu x64 Ubuntu x64
    Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

    Buen tutorial, solo un detalle:

    No es recomendable generar pares de llaves de 2048 bits pues algunos servers DNS tienen problemas con el largo que sobrepasa los 255 chars y no transfieren bien.

    Ya esto me mordió con dos dominios fuera de Cuba y el registro en Ceniai… la bajé a 1024 bits y todo al kilo.

    Es solo que cuando dices en el tutorial:

    opendkim-genkey -r -b 2048 -d dominio.cu -s default

    debes decir

    opendkim-genkey -r -b 1024 -d dominio.cu -s default


    • Warning: Undefined array key 1 in /var/www/html/sysadminsdecuba/wp-content/plugins/wp-useragent/wp-useragent-detect-os.php on line 668
      Firefox 69.0 Firefox 69.0 Ubuntu x64 Ubuntu x64
      Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0

      el problema del tamaño de las llaves, es que hay que saberlas escribir en el dns, no es que no lo soporten, sino que en estos hay que escribirlas en bloques de 256bit, cada trozo. Y la forma de escribirlas en todos los dns no es la misma, pero lo recomendado son 2048 bit o superior, ya 1024 es vulnerable.

Dejar una contestacion

Tu dirección de correo electrónico no será publicada.


*